Career

The curriculum teaches you to code. The job requires something else entirely. After years in this industry, here are the things that determine most of the variation in how careers go and that almost nobody says out loud.

After years of working with engineering teams, the most valuable person is almost never who you would expect. It is not the fastest coder. Not the one who knows the most. It is someone doing something much quieter and much harder.

Most engineering teams are spending serious money on cloud infrastructure and have only a vague idea where it is going. The bill arrives. It gets paid. Nobody asks hard questions until the number becomes impossible to ignore.

Every production system is built on open source software maintained by people working for free. Most companies have never thought seriously about what happens when those people stop. Some of them are about to find out.

Agile promised to make software development more human. For a lot of teams it has done the opposite. Here is what went wrong and why the calendar is not the problem.

Being right all the time is not what makes someone excellent at this work. Knowing what to do when you are wrong is. The engineers who progress the fastest have figured out something that takes most people years to understand.

Engineers talk about technical debt as if it is a technical phenomenon. It is not. It accumulates through decisions made by people with authority over engineering time, and it is resolved the same way.

On-call burnout is treated as a scheduling problem. It is not. It is a systems engineering problem. The rotation is the last place to look. Everything upstream of it is where the damage is actually done.

The most dangerous systems in any engineering organisation are not the ones that are broken. They are the ones that are working, that everyone depends on, and that nobody is responsible for.

Engineering teams propose rewrites with confidence and complete them with regret. The second system is almost never as much better as it was supposed to be, and the cost is almost always more than anyone planned. Here is why, and what to do instead.

The daily standup was invented to surface blockers and coordinate work. In most teams it has become a ritual performance of productivity. Here is how that happened, what it costs, and what the meeting was supposed to be.

At some point, many senior engineers quietly transition from building things to managing the building of things. This transition is often presented as growth. Sometimes it is. Often it is the beginning of a slow professional collapse.

Every failed microservices adoption I have seen made the same mistake: treating microservices as an infrastructure pattern instead of an organisational one. The technology is the easy part. The hard part is everything else.

There are two kinds of code. The kind you write in the daytime, caffeinated, with full context, and tests passing. And the kind that runs at 3am, in production, when everything is on fire and you wrote it six months ago. Most people only think about the first kind.

The user in your head when you make product decisions is not your actual user. The gap between those two people is where most product failures live.

Every serious engineering team runs post-mortems. Almost none of them work. The problem isn't the format or the facilitation — it's that most post-mortems are designed to produce closure rather than change.

Engineering teams don't slow down because they run out of ideas or lose good people. They slow down because the path from decision to production gets longer every month. Here's how that happens and what it actually costs.

AI is compressing the entry-level job market faster than the industry wants to admit. What that actually means for people starting out, and the only honest advice I have.