Fifteen Years In: A Letter to Myself at Ten

Five years ago, at the ten-year mark in my career, I wrote a long piece of career advice for engineers. I recently re-read it. Most of it still holds. Some of it I'd qualify. And there's an entire layer I couldn't have written then — about what the last twelve months of agentic coding tools have done to this profession — that I want to add at the end.

What follows is the original post in blockquotes, with annotations from where I sit now: fifteen years in, leading engineering at a US healthcare company, watching the ground shift faster than at any point in my career.

On skipping software development to go straight to management

There were two factions in our group of graduates, one who was excited to learn the trade and grow as a software developer and the other who despised coding and decided to do MBA by skipping the queue to become a 'manager'... My advice to the new batch of engineers would be to spend a few years doing software development before you go and do your post graduation.

Still right, and the case is stronger now than it was then. Five years ago, an MBA-without-engineering-time meant you'd manage products without understanding how they got built. Today it means something worse: you'll manage teams whose individual leverage has grown five-to-ten-fold because of AI tooling, and you'll have no instinct for what's actually hard, what's actually easy, and what's being sandbagged. The MBAs who skipped the queue in 2015 could still bluff their way through. In 2026 they get found out in a quarter.

On breadth before depth

The focus in those years should be only on learning and instead of going for the depth of knowledge, go for the breadth. Try your hands on frontend, backend, devops, database... My advice would be to go for organisations who are building something from scratch.

Fifteen-years-in me would qualify this. Building something from scratch is valuable but it's not the only path to breadth. I've seen engineers at large, regulated companies develop sharper systems intuition than startup peers — because they had to navigate real organizational complexity, legacy systems, and stakeholders whose incentives didn't align. The actual signal isn't startup vs. enterprise. It's whether you're being asked to make decisions or just execute someone else's. Optimize for that.

On when to change jobs

You should think about changing jobs when the learning curve has slowed down... if you start getting a feeling that what you are doing day to day is easy and you are not sweating much, I would say start looking for a job change.

Still the right heuristic, but I'd add one more. Change jobs when the learning has slowed, or when you've stopped having access to the kind of problems you want to be known for solving. Early in your career these are the same thing. Later they diverge. By year ten you may have plenty to learn at your current job but be working on the wrong problems for the career you want to build. The cost of staying isn't always stagnation; sometimes it's drift.

On taking pride in your work

If you take your job as something you are doing 9 to 5 to earn money then most likely you won't grow that far. But, if you take pride in the work that you do, there is no stopping you... always build a product with the assumption that you will be the one doing production support for it.

This is the most important paragraph in the original post and I wouldn't change a word. If anything, the AI tools have made this point sharper. It is now trivially easy to ship code that compiles, passes tests, and looks plausible — and then fails in ways that are extremely hard to debug because no human ever held the full mental model. The engineers who treat their work as craft, who actually read what the model wrote and ask "would I be willing to be paged for this at 3am?", are pulling away from the ones who don't.

On "people leave managers, not jobs"

People don't leave jobs they leave managers, so if you are a manager who operates from a position of power then very soon you won't have a team to enjoy your power on.

Still true. I'd add: people also don't leave managers in isolation — they leave when a manager fails them at a moment that matters. A great engineer will tolerate a mediocre manager for years if they're growing. They'll leave a good manager in a week if that manager doesn't advocate for them when it counts: promotion case, scope expansion, an unfair performance review, a family emergency. The day-to-day matters less than people think. The handful of high-stakes moments matter more.

On choosing the manager track

The role that gives a sense of importance and leadership to self and looks very attractive and powerful to the outside world... this role is very risky and should be well thought through before choosing this path.

This held for a decade. It's about to be re-tested. When I wrote it, the IC vs. manager fork was about temperament — do you want to do the work, or enable the work? In the AI era the calculus is shifting. A senior IC with strong taste, who can direct a fleet of agents to do what previously took a five-person team, may be more leveraged than a manager of that same team. The IC track was always viable; it's becoming the more interesting track for a specific kind of person.

I'm not telling anyone to abandon management. I'm one of those managers. But if I were starting today and choosing between the two paths, I would think much harder about staying technical than I did in 2015.

What I couldn't have written five years ago

The original post assumed a profession that was, in its broad shape, stable. You learn syntax, you learn systems, you learn people, you compound. The senior engineer was a senior engineer the way a senior carpenter was a senior carpenter. There were debates about frameworks but not about whether the work itself was about to change.

The last twelve months have changed that.

Agentic coding tools — Claude Code, Augment Code, the autonomous IDEs — have done something I didn't expect. They haven't replaced engineers. They've amplified the strong ones to a degree I'm still adjusting to, and they've exposed the weak ones in a way nothing before them did.

Here's the pattern I think is emerging across the profession:

Engineers who already had taste – a sense of why some code is better than other code, the patience to actually read what they shipped — appear ro be operating at two to three times their previous output, with quality going up rather than down. The tools act as a force multiplier on a craft they already had.

Engineers in the middle seem to be split. Some are catching up fast, because the tools let them learn at a pace that was previously gated by typing speed and stack-overflow latency. Others are drifting in the other direction, shipping more code, faster, that they don't understand – and the bugs they produce are stranger and harder to debug.

And for engineers who treated the job as 9-to-5, who didn't take pride in the work, the equation has changed. Shipping code was the bottleneck they cleared; now that it isn't, the value of clearing it has fallen with it.

The skill that's becoming the most valuable, and the rarest, isn't coding speed. It's problem definition. Knowing what to build, why, for whom, with what tradeoffs — and being able to specify that clearly enough that the work (your own, the agents', the team's) can be directed at it. Five years ago I'd have called that "good product sense" and treated it as a nice-to-have for engineers. Today I think it's the central skill of the profession.

If you're early in your career and reading this, here's the update to everything I wrote five years ago:

It is a fantastic time to be a problem solver. It is a terrifying time to be someone who waits to be told what to do. The middle is collapsing. The two ends are diverging fast.

Pick which end you're on. Then build accordingly.