Systems and Society

I’ve had computer programming as my career and late evening passion for more than 20 years. The number of hours I’ve spent pursuing this craft is likely to be several tens of thousands. But, even with countless nights deep into rabbit holes, a PhD in computer science, and a few completed project in a pile of abandoned ones, I still rarely have a sense of mastery—and I don’t think I’m the only one. Why is that? Is there something special about programming?

As far as I’m aware, mastery boils down to repeating something over and over again until it becomes deeply ingrained in both body and mind. It’s like the repetition imposes an order on your very being, making it maximally ready to perform it again and again—in any of its variations. Skiing, painting, socializing, cooking. Like a dance, these skills are patterns you repeat. In fact, all skills are patterns we repeat, or we wouldn’t recognize them as distinct skills at all.

Now, is there something special about the computer programming skill? Well, I wouldn’t be writing this if I didn’t believe so. Compared to the other crafts I have some degree of familiarity with, I think programming stands out with respect to

1. complexity,
2. change, and
3. comparisonism.

Let’s have a go at each of these three, and then think about where this knowledge takes us.

It’s Complexity All The Way Down

I believe programming is an extraordinarily complex skill. What do I mean by that? Well, my thesis is that the more patterns or variations you must learn to repeat—the longer it’s going to take to master them. If this is true, then we can talk about the complexity of a skill as the number of its patterns or variations. Is computer programming more complex than most other skills? Are there more things to learn?

Becoming fast at typing, learning IDE keyboard shortcuts, learning how to scan a file of code effectively, reasoning your way to likely causes of bugs. These are all examples of things most programmers do over and over again—often enough to eventually master them. There are a lot more of things we often have to do, but perhaps don’t do as frequently. Write tests, chose dependencies, learn libraries, handle concurrency, manage software versions, debug, deciding what programming language features to use, setup build pipelines, prevent security breaches, support users, optimize, create system architectures, build up knowledge domains, optimize for user experience, and so on.

The number of things you are likely to need to do while programming is big enough that there will always be something you work with that you don’t master. While some of us can focus on a few of these things, most of us just can’t. In my experience, the things I get good at tend to fade into the background. I don’t pat myself on the back because I type considerably faster today than I did ten years ago, for example. Easy becomes invisible, while hard dominates our minds.

Your Tools Are Yesterday’s News

Another spanner in the mastery works is the fact that the world of software changes all the time. During my twenty some years doing programming, I’ve seen countless databases, frameworks, libraries, tools, and even whole programming languages, come and go. Mastering a single one of these can take a tremendous amount of time. While we certainly take something with us from each thing we get familiar with—it hardly feels like progress when the tool we spent months, or even years, learning is suddenly replaced by something else.

Many tools becoming more isn’t a problem in and of itself. It’s pace at which we move on to new ones that is. This rate of change is often not motivated by real progress, but by hypes and trends. Now, there being hypes shouldn’t really surprise anyone. Software is, in many ways, the frontier of the 21st century. It’s today’s equivalent of the gold rushes, factory booms and railroad expansions of yesteryear. The world’s largest companies are all software companies, and many of the richest and most influential people are the heads of these companies. Software is naturally going to attract both gold diggers and entrepreneurs, and these people know they won’t win if they don’t take risks—like betting on the latest and hottest frameworks or languages.

Things change fast because the slow racers are left behind—and mastery comes second to winning, which brings us to the last point.

You Have to Compare Yourself To The Competition

At some level, we all know we are in this grand race for software glory. It’s part of the software zeitgeist. Your software could be the thing that changes the world. It could be the next Napster, Bitcoin or LLM. This kind of potential—dare I even say hubris—leaves no one untouched. Just about every employer feel they must hire the best and brightest, and this means that every prospective hire must be the best and the brightest—even when they aren’t.

The race racks up the demand for and salaries of programmers, it makes us write résumés with long lists of technologies we barely used, and it fuels the rumors about the extraordinary productivity benefits of using LLMs—only unlocked by a select few. Should it come as a surprise that this environment has a tendency of making us feel as if everyone else is more productive than us? That mastery somehow only comes to the ones chosen by the software gods?

You have to stay ahead of the competition, and the competition is usually exaggerating, but sometimes outright lying, about their skills.

And Where Does This Leave Us?

My great wish would be for the software industry to just calm down. Relax. Allow software development projects to take much longer time, hire fewer people to carry them out and make sure compensation and benefits are good enough to not motivate job hopping. This would decrease competition, at least once you’re already hired, it would lessen the pressure to know everything, and it would make success seem less elusive. I don’t think this is likely to happen, however.

Perhaps the real solution is for me to just calm down and specialize. A specialist deals with a smaller part of the software domain, which makes master more approachable. But, specializing is a bit risky, because it means I’m more exposed to the tool shifts triggered by hypes and trends. And you have to chose what to specialize in. Hard. Maybe even inconvenient.