The Growth of a Programmer

Writing software is hard. I’m reminded of that every time someone asks me to teach them. The basics are convoluted, the syntax is unique; It’s 100% logic that you have to hold in your head while you craft words that semantically make little sense, unless you’re a compiler or interpreter.

Eventually, the programmer gets the basics down; they start to make something, like the oh-so-trivial todo application, for example. At a first attempt, it’s almost 100% guaranteed to be in one giant file. Because that’s what the programmer had done up until then. They’ll carry that habit on forever and spend 4-5 years trying to break the habit.

The programmer may go on to build more complex things, learning about patterns and algorithms. They may pick up some discrete mathematics and some physics equations if they go down the gaming route. They’ll learn to build things in discrete units and test them.

The programmer takes these lessons and builds excessively complex software. They learn to engineer. There are facades, flyweights, factories, decorators, builders, inversion containers, and so much more. They engineer themselves into tightly coupled systems.

The programmer learns from the mess they build, and they learn to decouple. They learn systems engineering. They learn message passing, command/query separation, eventual consistency, brokers, circuit breakers, n-tier. They learn to architect.

The programmer thinks they’ve mastered the craft. They write everything in one file and don’t give a damn. The code is concise and makes no sense until it’s been read five times over. Whatever they write, it generally works the first time. They love deleting code and fight against scope creep. There will be a typo on line 288 … but there’s nothing wrong with line 288, and they’ll flip the fucking table.

// todo: update in 10 more years