The Path Goes From Smart to Simple

I couldn’t have written it more convincingly than Ken Kantzer:

Simple Outperformed Smart. As a self-admitted elitist, it pains me to say this, but it’s true: the startups we audited that are now doing the best usually had an almost brazenly “Keep It Simple” approach to engineering. Cleverness for cleverness’ sake was abhorred. On the flip side, the companies where we were like “woah, these folks are smart as hell” for the most part kind of faded. Generally, the major foot-gun […] that got a lot of places in trouble was the premature move to microservices, architectures that relied on distributed computing, and messaging-heavy designs.

-Source: https://kenkantzer.com/learnings-from-5-years-of-tech-startup-code-audits/

I stopped programming professionally about 8 years ago, but I feel like I was at my best at that time. At that point, I was writing simple code that obviously worked and staying away from any kind of unnecessary complexity.

In my earlier years? Not so much. I welcomed abstract constructs and double indirections. C++ template metaprogramming and abstract singleton factories were exciting! I got so clever my boss even got mad at me once, and getting mad at each other was definitely not part of the company culture.

Over time, like so many before me, I learned the value of keeping things simple. When I program nowadays, I never do anything complex, because I never need to. I’ve got stuff I need my code to do and the quicker it does, the better. That’s more important than getting my neurons some exercise. There’s chess for that.

Crucially, though, my young self wasn’t wrong to love complexity. That’s how mastery works.

I remember visiting a retrospective exhibition of the Spanish painter Joan Miró many years ago. The exhibition presented his life’s work as a path going from gentle, slightly modern but also slightly bland countryside landscapes and portraits, then taking a turn towards the more abstract, then an outright angry phase with nervous, harsh lines and mutilated body parts, to finally arriving at the large, beautiful blue paintings with abstract, curved shapes that he’s known for:

In 1961, […] Miró began further purifying the deepening of his earlier discoveries. This development had been heralded by Blue I, II, III. It reflects, above all, the supreme confidence the artist had attained in composing and coloring his paintings. The style is unmistakable. Miró was playing with codes that describe the movement of objects in a uniquely simple way.

-Source: https://www.joan-miro.net/blue.jsp

With computer programming, like with many other forms of craft, it seems many follow a similar path. You start with learning the basics. Then curiosity leads you to explore the most difficult and complex areas of your craft. Eventually, your thirst for exploration fades until you emerge as the wise and experienced craftsperson who gets the job done efficiently and effortlessly.

When I see young developers showing off complex code (and sometimes stumbling), I remind myself to be kind. Not just because I was like that myself, but because they’re merely following the path.

Perhaps that’s what the Japanese call Shuhari.

Or perhaps it’s just me being a grumpy grandpa at 41 and no longer having the patience for getting lost in complexity. The kids need dinner in 45 minutes. A for loop will do just fine.