I left university with what I now realise was a starter pack: enough syntax to write a program that compiled, enough theory to nod at a whiteboard, and almost no idea why any of it actually mattered in practice. The first job filled in some of the gaps and exposed others. I could hold my own with a debugger. I struggled to explain why a particular design was the right one — or to push back when someone more senior told me a design was good and I quietly thought it wasn’t.
The next five years, much more than the degree, are where I actually learned the craft. A lot of it was deliberate study. Books I should have read at university and didn’t. Source code of projects I admired. Side projects, mostly small, mostly thrown away, but each one a chance to make a mistake on something nobody was paying me to ship. The other half was harder, and probably more important: learning to recognise the bad practice I was surrounded by at work and not adopt it as my own. There are habits you pick up by osmosis when nobody’s watching — copy-pasting instead of refactoring, reaching for a framework before you understand the problem, treating a green test suite as a substitute for thinking. I had to consciously notice those things in other people’s code, decide they weren’t for me, and then catch myself doing them anyway. That part takes years.
The shift I’m most grateful for happened gradually and is hard to point at. At some stage I stopped thinking in syntax — what does this loop do, will this compile, why is this null — and started thinking in the bigger picture: what is this code for, who reads it, how will it fail, what does the system around it look like in two years. That move from local to global is what I’d now say separates an engineer from a person who can write code. It’s not a course you can take. It’s the accumulation of a thousand small re-readings of your own work where you wince a little less than the time before.
This blog is where I’ll write about all of that. There’ll be a learning path I’ll demo end-to-end for anyone just starting out — the foundations I wish I’d hit harder earlier, in the order I now think they’re worth taking on. There’ll be deep dives into the things I believe every engineer should understand whether or not their language of the week makes them obvious. There’ll be home projects, things I’m tinkering with for the joy of it, and write-ups of new frameworks as I work out where they actually fit and where they’re being oversold. And there’ll be a steady drumbeat of AI — not because every problem looks like one now, but because the tools, the workflows, and the way we reason about software are changing fast enough that ignoring them is a choice I’d rather not make.
The honest thing about this career is that you never stop learning. The shape of what you’re learning changes — less about syntax, more about systems, then less about systems, more about people, then back round to syntax when something genuinely new appears — but the curve doesn’t flatten. Anyone who tells you otherwise either retired ten years ago or is about to. This blog is my attempt to keep myself honest about that, in public.