The Pragmatic Programmer Is More Relevant Now Than When It Was Written

I just finished re-reading The Pragmatic Programmer by Andrew Hunt and David Thomas. First published in 1999. No React. No cloud. No LLMs. Just two engineers writing down what they'd figured out about how to think.

I expected it to feel dated. It doesn't. It hits harder.

Here's my honest reaction: every lesson in that book matters more now that AI writes code. Not less. The argument I keep seeing — that books about craft are relics now that Copilot can autocomplete a function — gets it exactly backwards.

AI is a multiplier. And a multiplier applied to weak fundamentals produces weak output, fast.

If you've read AI Will Make You Faster. It Won't Make You Better. on this blog, you already know where I stand. This is the long version, grounded in a book that I think every developer who uses AI tools should read.

The Book Is Not About Syntax. That's Why It Still Works.

Most technical books from the late 90s are museum pieces. They're full of specific frameworks, deprecated APIs, patterns that made sense before the internet scaled. You read them for historical curiosity.

The Pragmatic Programmer is different because it was never about syntax. It's about how to think as a software craftsperson. It's about ownership, judgment, and the discipline of building things that last.

None of those things have changed. The way AI tools interact with those things has made them more urgent.

Broken Windows and the Cost of Delegation

The book's "broken windows" concept comes from criminology: a single broken window left unrepaired signals neglect, which invites more neglect. In software, one bad patch tolerated today becomes ten bad patches next month.

AI introduces a new class of broken windows.

AI-generated code is often plausible-looking. It passes the eye test. It might even pass tests you wrote. But it can introduce subtle coupling, leak an abstraction, or duplicate logic in a way that only becomes a problem six months later when someone else is debugging at 2am.

The engineer who doesn't own the output — who accepts the suggestion without reading it — is letting broken windows accumulate silently, at a speed humans couldn't manage before.

Pragmatic Programmer principle: take responsibility. You own the code you ship, regardless of where it came from. That's not a nice sentiment. It's the only way codebases stay maintainable.

DRY at AI Speed Is a Real Problem

Don't Repeat Yourself. Classic principle. The idea is that every piece of knowledge in a system should have one authoritative source. Duplication creates maintenance debt — change a rule in one place, miss it in another, and you have bugs that are hard to trace.

AI will repeat yourself at scale without hesitation.

Ask Claude or Copilot to add a feature, and it might generate a helper function that's nearly identical to one you already have in a utility file. It doesn't know about your utility file. It doesn't know your codebase the way you do. It knows what you showed it.

The engineer who recognizes this — who spots the duplication and refactors instead of merging — is the engineer using AI as a productivity tool. The one who misses it is paying maintenance debt with interest.

This isn't a criticism of AI. It's an argument for knowing DRY well enough to catch violations the tool can't catch for you.

Tracer Bullets Are Perfectly Suited to the AI Era

This concept from the book is underappreciated. A tracer bullet is a thin, working slice of your system, end-to-end: a real request hitting a real API, touching a real database, returning a real response. Not a prototype. Not a mockup. A skeleton that works.

The reason to build tracer bullets is to discover unknown unknowns early. To see the system under load. To validate your assumptions about how the pieces connect before you've built all the pieces.

AI makes tracer bullets faster to build. That's the good news.

The risk is that AI also makes it easy to skip them. You can generate a lot of code quickly, feel like you're making progress, and discover the integration problem only when you're trying to assemble something that should have been a thin working slice six weeks ago.

Use AI to fill in each slice. But you have to be the one drawing the skeleton first.

Orthogonality: What AI Gets Wrong Without Trying

Orthogonality means keeping concerns separate. Your database layer shouldn't know about your UI. Your business rules shouldn't be entangled with your infrastructure. When components are orthogonal, changes are local. When they're coupled, a change in one place breaks something else somewhere else.

AI tends to entangle things. Not always, but often enough that it's worth watching for.

A model optimizing for a single request doesn't reason about what your auth middleware should and shouldn't know. It doesn't have a strong prior for "this concern doesn't belong in this layer." It produces working code for the request in front of it, not code that will be easy to maintain in the system you're building.

Recognizing when AI output violates orthogonality — and correcting it — requires knowing the principle well enough to see the violation. That judgment doesn't come from prompting. It comes from having read and internalized books like this one.

The Rubber Duck Is Not the LLM

The book has a section on debugging that most people gloss over: the rubber duck method. Before asking for help, explain the problem out loud to an inanimate object. Walk through it. The act of articulating the problem usually surfaces the answer.

This is about thinking before asking.

There's a version of AI use where you paste in an error message, get an answer, paste in the next error message, get another answer, and never actually understand what's happening. You make progress in short bursts, stay stuck on the same class of problem indefinitely, and have no model of the system you're building.

The rubber duck principle says: stop. Think first. What do I expect to happen? What is actually happening? Why might those differ?

The LLM is a powerful tool for the person who's already thought it through. It's a crutch for the person who hasn't.

Your Knowledge Portfolio: Invest in Judgment, Not Syntax

The book's "knowledge portfolio" concept treats your skills like a financial portfolio. Invest deliberately. Diversify. Tend it over time. Don't let it stagnate.

Here's what's happened to that framework in the AI era: the return on certain assets has changed dramatically.

Syntax fluency is depreciating. The ability to write a specific function from memory, to recall the signature of an obscure library method, to translate pseudocode to working code quickly — AI is very good at all of that. The delta between someone with that skill and someone without it is shrinking.

What's appreciating? Judgment. Architecture. The ability to evaluate AI output and know if it's actually good. The ability to design a system, set the constraints, and identify when a generated solution violates them.

Pragmatic Programmer told you in 1999 to invest deliberately in your knowledge portfolio. The AI era has changed which assets compound. The principle is exactly the same.

Good Enough Is a Discipline, Not an Excuse

The book has a chapter on "good enough software" that's often misread as permission to ship mediocre work. It isn't. It's about the discipline of knowing when something is done — when the tradeoffs are in the right place, when further investment returns diminishing value, when users need it now more than they need it perfect.

That judgment is harder to apply now.

AI makes it easy to ship something plausible. Something that works in the demo. Something that looks like it satisfies the requirement. The signal that a feature is "good enough" used to be that building it took significant effort — you had to think through edge cases to write the code at all.

AI removes that forcing function. You can have something plausible in twenty minutes. Whether it's actually good enough is a question the model can't answer for you.

The engineer who can tell the difference — between plausible and done, between passing the eye test and passing production — is the one who has internalized what "good enough" actually means.

The Closing Argument

The engineers who will thrive aren't the ones who use AI the most. They're the ones who use it the best.

Using it well means knowing when the output is good. It means catching the broken windows before they accumulate. It means drawing the skeleton before you let AI fill the flesh. It means recognizing entangled concerns, DRY violations, premature abstractions — the class of problems that AI introduces because it's optimizing for the local, not the systemic.

The Pragmatic Programmer is a book about developing that judgment. It's about building the mental models and the habits of mind that make you a craftsperson, not just a producer of code.

That's worth more now than it was in 1999.

Read it. Then pick up the AI tools. In that order.

FAQ

Is The Pragmatic Programmer still worth reading in 2024 and 2025?

Yes, and for a specific reason: it's not a book about technology. It's a book about how to think as a software craftsperson. The concepts it teaches — ownership, DRY, orthogonality, knowledge portfolio management — are durable. In the AI era, they're more important than ever, because AI doesn't teach judgment. It amplifies whatever judgment you already have.

Do software fundamentals matter if AI can write the code for you?

AI writes code that looks right. It doesn't evaluate whether the code is right for your system, your constraints, or six months from now. Catching the difference requires fundamentals: architectural judgment, understanding of coupling and cohesion, the ability to recognize when something is plausible versus actually good. Fundamentals determine the quality of what gets built, regardless of what writes the first draft.

How does The Pragmatic Programmer apply to developers using AI coding tools like Claude or Copilot?

Almost every principle in the book applies more directly in the AI era. The broken windows concept applies to AI-generated code that accumulates technical debt silently. DRY applies to duplication AI creates without knowing your codebase. Tracer bullets apply to the need to design a working end-to-end skeleton before letting AI fill it. The knowledge portfolio applies to investing in judgment and architecture, which appreciate as syntax skills depreciate. The book gives you the framework for evaluating AI output — not just generating it.

Full Stack Data Solutions writes about the developer tools, fundamentals, and systems that actually matter for solo founders and technical builders. If this resonated, the AI foundations article is a natural next read.