Prefer to watch? Watch the video on YouTube.

If you want a successful career as an engineer, I’d recommend one book to every software engineer — whether you’re just starting out or you’ve been in the industry for 20+ years like me:

The Pragmatic Programmer by Andy Hunt and Dave Thomas.

First published in 1999. Updated in 2019 for the 20th anniversary edition. Somehow still just as relevant today as the day it was written.

Here’s why it matters, and my top five recommendations from it — the ones that have genuinely shaped how I lead engineering teams.

What the book is actually about

At its core, it’s a book about how to think as a software engineer. It’s not tied to a specific language, framework, or methodology. It’s about the mindset, habits, and principles that separate engineers who just write code from engineers who build great software and great careers.

Hunt and Thomas wrote it from the trenches. They were working developers who noticed patterns — things the best engineers consistently did differently — and distilled those patterns into a collection of practical tips. The 20th anniversary edition has 53 of them.

What makes the book special, and why it’s stood the test of time, is that it operates at the right level of abstraction. It doesn’t tell you which database to use or which front-end framework is best. It gives you thinking tools — principles you can apply regardless of what technology you’re working with, what company you’re at, or what decade it is.

I first read it early in my career. I’ll be honest: some of it went over my head. I understood the words, but I hadn’t lived through enough to feel the weight of what they were saying. Reading it again 15 years later as someone leading engineering organisations, it hit completely differently. Almost every piece of advice maps to a real situation I’ve seen play out — sometimes painfully.

Here are the five I think about most often, and the ones I find myself passing on to engineers on my teams.

#5 — Don’t live with broken windows

One of the most famous ideas in the book. It comes from the broken windows theory in urban studies: one broken window left unrepaired signals that nobody cares, and it opens the door to further neglect and decay.

In software, a broken window is that one hacky workaround someone left in the codebase. That test that’s been skipped for six months. That module everyone’s afraid to touch. Once one exists and nobody addresses it, it gives implicit permission for more. The codebase degrades — not in one dramatic moment, but slowly, through a thousand small compromises.

As a leader, this one resonates deeply. Culture works the same way. If you tolerate sloppy pull requests, unclear requirements, or skipped code reviews, you’re leaving broken windows in your team’s process — and they compound.

When you see something wrong, fix it. Or at the very least acknowledge it as technical debt and make a plan to resolve it. Don’t just walk past.

#4 — Be a catalyst for change

Hunt and Thomas tell the stone soup fable. A group of travellers come to a village where nobody wants to share food. So the travellers start boiling water with a stone in it. Curious villagers come over and the travellers say, “This stone soup is great, but it’d be even better with some carrots.” Someone contributes carrots. Then someone adds potatoes. Before long the whole village has contributed and everyone’s eating a great meal.

The lesson for engineers: sometimes you can’t get buy-in by presenting the grand vision up front. People resist big change. But if you start small, build a prototype, demonstrate value, get one person interested — momentum builds.

I’ve used this approach more times than I can count. Want to introduce a new testing strategy? Don’t write a 20-page proposal. Build a small proof of concept, show the results, let people lean in. Show them the stone soup.

Honestly one of the most underrated leadership skills in engineering — knowing how to seed change from the ground up rather than mandating it from the top down.

#3 — DRY: don’t repeat yourself

Most engineers have heard of DRY, but a lot of people misunderstand it. They think it means don’t copy and paste code. That’s part of it. But Hunt and Thomas meant something much broader.

DRY is about knowledge. Every piece of knowledge in your system should have a single, unambiguous, authoritative representation. That includes code, yes — but also documentation, database schemas, API contracts, build configurations, and even team processes.

When knowledge is duplicated, it drifts. One copy gets updated, the other doesn’t, and now you have two sources of truth that disagree. I’ve seen entire production incidents caused by a config value that was correct in one place and stale in another.

The more senior you get, the more you realise DRY isn’t just a coding principle. It’s a systems design principle, and an organisational design principle. If two teams are maintaining separate definitions of the same business logic, that’s a DRY violation at the org level, and it will eventually cause problems.

Think bigger than code. Think about where knowledge lives across your entire system.

#2 — Good-enough software

This one took me years to appreciate. Hunt and Thomas make the case that striving for perfection is often the enemy of delivery. They’re not saying write bad software. They’re saying: involve your users in the trade-off decisions. Understand what good enough actually means for the context you’re operating in.

A medical device has a very different quality bar than an internal admin dashboard. A V1 product testing a market hypothesis has different requirements than a mature platform serving millions of users.

Early in my career, I was the engineer who wanted to gold-plate everything — elegant abstractions, 100% test coverage, perfectly clean code. And I’d ship late, or over-engineer something that ended up getting thrown away because the business pivoted.

The pragmatic approach is to understand the constraints — time, budget, user expectations — and deliver software that’s genuinely fit for purpose. Not perfect. Not sloppy. Appropriate.

Surprisingly hard to develop, and even harder to teach — but it’s one of the biggest differentiators between mid-level engineers and senior engineers. Knowing when to say: this is good enough, let’s ship it and learn.

#1 — Take responsibility. It’s your life.

My number one pick is an open, direct challenge from Hunt and Thomas: it’s your life. You own your career. You own your growth. If you’re unhappy with your tech stack, your team, your skills — that’s on you to change.

A pitfall people sleepwalk into after being at a company for a long time: they think it’s their employer’s responsibility to upskill them. It can happen. Generally it doesn’t. It’s the people who take responsibility for their own growth who distinguish themselves. The ones who leave it to their employer get left behind.

Hunt and Thomas also talk about responsibility in a very practical way. When something goes wrong — a bug ships, a deadline slips, a project fails — don’t make excuses. Don’t blame. Come with an explanation of what happened, the impact, and the options for moving forward.

After 20+ years in this industry, this single trait is the biggest predictor of career growth I’ve ever seen. The engineers who take ownership, who treat problems as their problems to solve rather than someone else’s fault, are the ones who become tech leads, staff engineers, directors.

And as a leader, when someone on my team comes to me and says “this went wrong, here’s why, and here’s what I think we should do about it” — that builds trust faster than anything else. Compare it to “well, the requirements were unclear, and QA didn’t catch it, and the deadline was unrealistic.” Same situation. Completely different signal.

Own your craft. Own your career. Own your mistakes. That’s the pragmatic way.

Watch the full video

The 8-minute walkthrough is on YouTube — Want a successful engineering career? Read The Pragmatic Programmer.

This is the first in a series where I break down the books that have shaped how I think about engineering and leadership. If that sounds useful, subscribe to Insightful Pause on YouTube — same premise, look before leaping.