intro #

I just finished reading Peter Seibel’s Coders at Work, and as I reflected on it, a pattern stood out to me that got me thinking. Listen to the likes of Peter Norvig or L. Peter Deutsch talk about their formative years, and you hear stories of genuine exploration. A lot of the great developers interviewed in this book moved freely between languages, picking up paradigms and technologies in a way that opened their minds and set them up for success.

Comparing that to today’s hiring landscape, something feels broken.

A developer could have years of experience with React, for example, and get passed up for a Vue job because they haven’t written that specific syntax. Or, a backend engineer with deep Laravel knowledge may be told they are unqualified for a Rails job, despite the frameworks being nearly conceptually identical.

It’s like we’ve forgotten that software engineering is more about concepts than syntax.

the for-loop problem #

I’ll use the humble for-loop to illustrate my point. A developer who understands that they need to iterate over a collection can always look up the syntax in any language. This task becomes even more trivial with modern LSPs and coding assistants. The true skill is knowing which tool to pull out of the toolbox and when to do so.

But, I think, hiring doesn’t work that way anymore. Somewhere along the line; maybe when recruiters became non-technical, or when teams became too large to assess actual thinking ability, people began to prioritise stack familiarity over general problem solving.

The cost of this shift isn’t immediate. You can staff entire teams with people who have mastered your stack, who can ship features quickly, who fit seamlessly into existing codebases. On a quarterly timeline, that works.

But zoom out, and I worry that we’re engineering something worse than inefficiency. We’re engineering a workforce that rewards predictability over possibility.

innovation at intersections #

One recurring theme in history is that the best ideas often don’t come from experts who confine themselves to a given domain. They come from polymaths.

These people can spot intersections - for example, bringing systems programming knowledge to a web project, or experience from chat applications into real-time gaming - where real innovation happens. It’s not just applying what they already know; it’s creating something that didn’t exist before.

Yet, the modern career path seems to actively discourage this. Pick your stack early. Go deep, not wide. Your resume and portfolio needs to show five years of unbroken specialisation, not five years of curious exploration. Wander too far, and you’re “unfocused”. Learn too broadly, and you’re “not senior enough” in any one thing.

Being called a “jack of all trades” now has undertones of criticism. And this is systematically filtering out the explorers.

the maverick question #

Maybe I’m romanticising the past. Maybe the era of Linus Torvalds and Dennis Ritchie and all those early hackers was a historical anomaly. Teams were smaller, there were fewer abstractions, and systems were simple enough for one person to hold the whole thing in their head. Maybe those days are gone, and modern software has become too complex, too specialised, too damn big for generalists to contribute meaningfully.

Or maybe we’ve decided we’re fine with mediocrity.

Maybe the industry has moved on from brilliant, cross-pollinating minds. What the industry wants, now, are fungible developers who can plug into a codebase and pick up where the last person left off. Competent, efficient, and utterly replaceable.

what we are losing #

Looking at the early years of my career, I find myself wondering what’s been stolen from me. Not just the chance to explore - though that matters - but the foundational understanding that comes from seeing the same problem solved five different ways in five different paradigms.

When you’ve only ever worked in one ecosystem, you think the way that system thinks. Have you ever heard of writing pythonic code? The patterns feel inevitable, the abstractions feel natural, the trade-offs feel obvious. You become very good at working within those constraints.

But, you never learn to question them.

The wandering developer learns something else: that every framework is making bets, every language is prioritising some concerns over others, every tool is a perspective. They learn to ask “why did they design it this way?” and “what would a different approach look like?”

That kind of scepticism and curiosity is how you build something entirely new. It’s also exactly the thing the modern hiring pipeline filters out.

so, what now? #

I don’t have a solution. Maybe this is just the reality of large-scale software development in 2025 as our industry enters its division of labour era. There are too many developers, too many codebases, and too much complexity to allow for the intellectual wandering that built the field in the first place.

But I can’t shake the feeling that we’re optimising for the wrong thing. What happens when, to use one example, every team becomes a homogenous, in-bred monolith of “Java-lifers” who have never wandered beyond the warm bosom of the JVM? Who will tell them, then, about the wonders of null safety?

Jokes aside, maybe part of the reason I’m writing all this is because I’m scared of being type-cast. Not in the programming sense, but in the acting sense. That feeling that the first role you land defines everything you’ll do after. My early jobs, my early stacks… sometimes it feels like they’ve locked me into a character I never actually chose. And honestly, that thought keeps me up more nights than I care to admit.