, ,

Polars Pipe Operator in Action.

It seems we have several cadres of people when it comes to “clean code.” I know there is a lot of previous baggage that comes with that nomenclature, good and bad. But, I think we can think about “clean code” from a simplistic point of view. It doesn’t have to be that complex.

We live in the Age of AI, in relation to the generation of code, of products, features … the software developer’s role has shifted. We can argue how it’s shifted, but it has.

If the generation of most of the mundane and everyday code is given to our AI peons like Cursor and Claude, then what value can you bring to the table?

You can bring a sense of good architecture from a systems perspective and from a “these modules of code” perspective. This data pipeline. Sure, some places, businesses just want you to churn out bits and bytes as fast as those tokens will let you, I feel bad for you. Many places still recognize the business context and keep the product running well … leading to happy customers who give us money … is extremely important.

There is an argument to be made that you should ensure you, or your AI, is producing clean code.

Polars pipe operator as clean pipeline code.

Polars has become the new Pandas, I mean that in a good and bad way, and one would have to surmise that a decade from now there will be A LOT of Polars in the wild, running in production. That said, there is a feature of Polars you don’t hear much about.

Piping pieces of code, data transformations, whatever … has always been a great way of making sure the code is …

  • clean
  • logical
  • streamlined

Let’s take a classic data problem and write it how most people would in Polars.

This is the type of code we’ve seen writing since time and memorial, Pandas … Polars … pretty much every data pipeline created. One could argue that writing code and pipelines in this style has two major problems, depending on culture and the person.

  • logic not encapsulated in methods or functionsis
  • not very testable because the above
  • doesn’t lend itself to organizing code into modules

So another way to write this simple code would be to put logic into testable functions, in a utils file.

And then in our main entrypoint / pipeline, etc., we can pipe the methods together.

I understand that it might be more of a philosophical argument to some, but I think that misses the point. Even if AI is spewing out our code, we need to be able to at least prompt our way to glory. We don’t want problems later. One could argue that if AI is the one reading, updating, and writing all the code, who cares what it looks like?

There is some validity to that argument in some instances, but I think it misses some lessons we’ve all learned over the years writing code.

All code, including AI generated code will have bugs. Clean, simple, well organized code will ALWAYS have a tendency to have less bugs, better performance, and easier to extend and debug.

So yes, it does matter if your data pipeline code is “clean” and well-organized. Polars Pipe operators help lead you down that path.

Without .pipe():

  • You manage intermediate variables.

  • Logic is spread out.

  • Harder to reuse transformations.

With .pipe():

  • Data transformations become a clear, ordered pipeline.

  • Functions can be reused and tested in isolation.

  • The code reads like a workflow.

What, so you, oh, overlord of AI minions? Does clean code matter in the Age of AI? Should we care about these things? Do they still mater?