On getting better at programming

How do you get better at programming? Earlier this year, I gave some advice to someone about this, so I decided to post and expand a bit on it here.

What does programming mean in this context?

There are 3 concepts conflated when people usually say “good at programming”, and I find it helpful to unbundle them and talk about them separately.

At a low level, programming is knowledge about computation and computers. This is about understanding the computation model we work with (except for a few niche areas, everyone uses the same one) and how it’s implemented. In practical terms, at this level you want to know how CPUs and other computer components work, how they communicate with each other, all the tricks that go inside each component. Then you work your way up to understand how they execute code, then arrive at how an operating system works, all the tricks that go inside the OS, and so on, until you reach the level of abstraction you usually work with. There are enough details at each level of abstraction that people can have whole careers being deep in just one of them. It’s a ton of stuff to learn, study, and remember.

From this perspective, being good at programming means understanding all the pieces that are operating underneath the code you’re reading and/or writing, and being prepared to deal with multiple scenarios that come from those pieces. If you’ve ever received help from someone and they started investigating things that apparently weren’t related at all to the error you were seeing and ended up finding the cause, they were exercising this kind of knowledge.

At a high level, programming is problem solving, which is more about the math, the puzzle and the tradeoffs of each solution. Companies with pathological hiring processes are well known to test people on these while being starved for people who are actually good at the above — who hasn’t had to do hours of whiteboard programming prep and interview, only to find the bulk of the job isn’t about that at all?

Connecting both levels, we arrive at the code itself, reading and writing code. Understanding the language you’re working with and all the tricks it has available for you, but also how other humans read and work with code and how to capture and propagate knowledge in the best way possible.

This blends with the lower level knowledge in understanding how that language will be transformed to instructions that the machine will execute, and all the things that can and will happen at that point. But as we write code, we also store knowledge in it: business processes, specific edge cases of a problem, workarounds to a particular behaviour, explanation to algorithms we’re using… we’re constantly learning new things and writing code that concretizes these learnings, and in this way we’re also transmitting knowledge to other people (hopefully with quality comments as well, otherwise we’re usually writing knowledge as a puzzle for someone else to solve).

So what does “good at programming” mean? To me, it means being good at all of the above. And how do you get better at it?

Being a better person

Jack Rusher has recently said “think more about being a better person than being a better programmer”. He didn’t say it as a response to that exact question, but I think it definitely applies here as well. It’s a sentence that makes sense once you have many years (or more like decades) of experience, but I think it’s full of “ draw the rest of the fucking owl ” energy for others, so I’ll try to expand a bit on my interpretation of it.

One could expect that a regular career in software engineering would lead to being a better programmer, but from my experience, a regular career in software engineering will mostly give you more experience in reading and writing code, but will hardly exercise the other two perspectives.

Modern software is full of different layers of abstraction, and many careers start and end without venturing outside a handful of them. To learn how things work at every layer of the stack requires a humble and ridiculously curious mind. One interesting consequence of software engineers’ obsession with their abstractions and encapsulating behaviour is that usually we need to make an effort to break away from the layers we’re familiar with to peek and investigate others. That the tools we have available mostly suck doesn’t help either — they’re full of assumptions that the user of these tools is already at least familiar with what they’re doing and inspecting.

I think anyone aiming to be a better person would also welcome these characteristics, so maybe we should just aim to be better people instead?

I’m sure the benefits will be greater than focusing only on better programming — as I’ve matured as a human, I realised I got much better at having empathy ¹ and giving a fuck in general about things that don’t directly apply to me. These are all things that contribute in multiple ways to being a better programmer: writing code that is more universally readable, writing comments that matter, caring about users of your software and investigating and thinking how to make software that better meets their needs…

What being better at programming is not

As I was thinking about all of this and talking to the person I referred to at the beginning of this post, I realised there may be fallacies that affect us when gauging how good someone is at programming.

Here’s at least one: watching someone type and edit code really fast is pretty much a meme , but it doesn’t stop people ² from thinking those who do this are better programmers. In a more general sense, speed is usually not an indicator of programming skill — it’s an indicator of experience and familiarity with whatever workflow the person is performing. This may correlate with other skills, but correlation does not imply causation.