The Tragedy of Programming Style

Why programming will never be admired like art, and why that matters.

Svetlin Rusev is one of the most famous painters in the small country of Bulgaria, recognized for his works in oils and acrylics. Over a long career, he developed his own style with light, yellowish colors that you can instantly recognize.

While his contemporaries were working with dark and muted palettes, he found his identity in brighter tones.

As you walk through a gallery, you begin to notice that every painter has a style, the visual equivalent of a writer's voice.

Svetlin Rusev’s favorite painting

It may be the colors, the subject of the paintings, or something else - but there's a repetitive theme that they've iterated on for a lifetime. You see how better their later paintings are and how they've improved the imperfections of the earlier ones.

They all choose a niche, something to focus on.

Rusev painted numerous landscapes and houses in the countryside. Basquiat, who worked on the other side of the world, never did even one.

Because mastery requires devotion to a style.

No programming style

As an engineer, I take pride in not having a style. There's no label that people can put on me. I loudly proclaim that I have no preference over languages, whether they're object-oriented, functional, or procedural.

There's a tool for every problem, and I just pick the right one.

But in the fine details of Rusev's paintings, I see signs of craftsmanship that I don't see in my code.

I do my best to write good code, but my work is tied to a purely economic result. No matter how much I claim that programming is more art than science, it doesn't get close enough to exist for its own sake.

You don't read code like you'd marvel at a painting.

We take pride in our lack of mastery. It's a badge of honor to be a polyglot, a generalist, someone who can fill any missing link in the software development lifecycle.

I've written code for every part of the stack, from the database to the CSS.

Passable code, not great code. Maintainable, not masterful.

We've written books, held workshops, and given talks on the importance of good programming style. But if anyone decided to spend a decade improving their ability to write the perfect Monad-based implementation, they'd be considered a lunatic.

Style matters, but it's a means to an end. Our idea of style is tied to the idea of maintainability.

Style is a means to an end

We started thinking about style when software started living long enough that other people had to modify it.

Art is never finished, only abandoned. But software is never left behind. As long as people keep using it, there will be something to change. A feature to tweak, a bug to squash, an optimization to make.

We're all writers, but we're editors as well.

Without standards, when someone leaves a company, they'll leave a legacy of artistically written code to their colleagues to decipher. While I love reading between the lines of a novel, I dread having to do this for a living.

In our craft, self-expression is good for the creator, but bad for the creation.

Basquiat’s Untitled (1982)

When I need to resolve a production issue at 3 AM and I have a quarter of my brain cells working, good literature is not on my list of priorities.

I can recognize a Basquiat painting in a fraction of a second. But I’d never guess a good programmer by their writing style.

Through linters, standards, and idiomatic practices, we homogenize how code looks and make it look like it's all written by the same person. There's no Rusev when it comes to coding, no Basquiat.

You can't stand out with your bright colors.

And maybe you shouldn’t be able to.

There’s no self-expression

I'm the kind of programmer who enjoys just reading code for its own sake.

I've spent not a few Saturday mornings going through open-source software, reading it like a good book, trying to steal ideas for my own projects. But it's the same style again and again.

You recognize patterns and you can appreciate how they're used, but you can only find craftsmanship in the margins.

LLMs help the homogenization even more.

I was looking at the code of some fresh bootcamp graduates, and it was a lot better than what I was used to seeing from people at their level. With a linter, Prettier, and Cursor, you can put together a beautiful implementation.

When I reviewed projects from beginners in the past, I could see their thought patterns implemented in their code.

Now, it all looks the same because it's all written by a model with the same weights.

LLMs increase the quality floor

If you're a poor coder, an LLM will elevate your code to a good enough baseline that's understandable. But if you're excellent at expressing thoughts through code, they will lower you to that average, too.

I don't think I've seen as many switch statements in my whole career as I have in the last six months.

If you're not well-versed in a language, you can now produce the equivalent of a high school essay in it. But experienced engineers still may see that as slop - it's just the baseline.

There's so much more room for improvement in there.

Speed

Startups shell out 10K lines of code per day, and I doubt that someone is thoroughly reviewing all that for its aesthetic qualities.

Artists value speed, too. Basquiat did. He was blazing fast.

He produced more paintings in his short career than some artists do in a lifetime. In his own words, it's one thing to have an idea, and another to create something. The quicker you can try something out, the quicker you find out if it's worth pursuing.

I believe in this.

But I also believe in careful retrospection over your creation, or you'd just be creating the equivalent of plastic bags.

Does programming style even matter anymore?

Art evolves, technology evolves, and we won't be building things the same way forever.

But creative thought is important in that evolution, and the struggle is what pushes it to its boundaries.

I don't think we'll ever marvel at code the way we do at paintings and stories. In the grand scale of things, it will be a momentary medium. But in that small fraction of time, I want to be a craftsman.

Somewhere in this world, there's the programming equivalent of Rusev, someone who has the potential to write the most beautiful code we can ever imagine.

But we'll never find out, and that's the tragedy of programming style.