The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

by Andy Hunt

Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics. Even worse, often they don’t really exist at all.

Programmers Help People Understand What They Want

Alongside “managing complexity”, these are our most important responsibilities

initial statement of need is not an absolute requirement. The client may not realize this, but it is really an invitation to explore.

That’s what we do. When given something that seems simple, we annoy people by looking for edge cases and asking about them.

Ask until you irritate or exhaust all your doubts. Whatever comes later

the reality is that all of the work we do is actually some form of mockup. Even at the end of a project we’re still interpreting what our client wants.

We believe that the best requirements documentation, perhaps the only requirements documentation, is working code.

You might think that a single index card can’t hold the information needed to implement a component of the application. You’d be right. And that’s part of the point. By keeping this statement of requirements short, you’re encouraging developers to ask clarifying questions. You’re enhancing the feedback process between clients and coders before and during the creation of each piece of code.

Create and maintain a project glossary—one place that defines all the specific terms and vocabulary used in a project. All participants in the project, from end users to support staff, should use the glossary to ensure consistency. This implies that the glossary needs to be widely accessible—a good argument for online documentation.

It’s hard to succeed on a project if users and developers call the same thing by different names or, even worse, refer to different things by the same name.

The developer acting as typist must focus on the low-level details of syntax and coding style, while the other developer is free to consider higher-level issues and scope.

Proper pair programming

A team that doesn’t continuously experiment with their process is not an agile team.

good design makes things easy to change. And if it’s easy to change, we can adjust, at every level, without any hesitation. That is agility.

quality can come only from the individual contributions of all team members. Quality is built in, not bolted on.

Trying to get things done “whenever there’s a free moment” means they will never happen.

Too many teams are so busy bailing out water that they don’t have time to fix the leak. Schedule it. Fix it.

Be critical about what sticks and what doesn’t and continuously improve

There is a simple marketing trick that helps teams communicate as one: generate a brand.

This helps building the team’s identity

programmers who are two or three levels removed from the actual users of their code are unlikely to be aware of the context in which their work is used. They will not be able to make informed decisions.

You need the ability to see beyond the existing rules and exploit possibilities for advantage. That’s a very different mindset from “but Scrum/Lean/Kanban/XP/agile does it this way…” and so on. Instead, you want to take the best pieces from any particular methodology and adapt them for use.

Don't just follow dogmas

Civilization advances by extending the number of important operations we can perform without thinking. Alfred North Whitehead

Whether it is the build and release procedure, testing, project paperwork, or any other recurring task on the project, it has to be automatic and repeatable on any capable machine.

Many developers test gently, subconsciously knowing where the code will break and avoiding the weak spots. Pragmatic Programmers are different. We are driven to find our bugs now, so we don’t have to endure the shame of others finding our bugs later.

A bug-free system that answers the wrong question isn’t very useful. Be conscious of end-user access patterns and how they differ from developer test data

After you have written a test to detect a particular bug, cause the bug deliberately and make sure the test complains. This ensures that the test will catch the bug if it happens for real.

Once you are confident that your tests are correct, and are finding bugs you create, how do you know if you have tested the code base thoroughly enough? The short answer is “you don’t,’’ and you never will.

If a bug slips through the net of existing tests, you need to add a new test to trap it next time.

Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, “Oh, that will never happen again.”

Our goal as developers is to delight users. That’s why we’re here. Not to mine them for their data, or count their eyeballs or empty their wallets.

How do you unearth their expectations, then? Ask a simple question: How will you know that we’ve all been successful a month (or a year, or whatever) after this project is done?

developers, who are exposed to many different aspects of an organization, can often see ways of weaving different parts of the business together that aren’t always obvious to individual departments.

Even though your title might be some variation of “Software Developer” or “Software Engineer,” in truth it should be “Problem Solver.” That’s what we do, and that’s the essence of a Pragmatic Programmer. We solve problems.

Your signature should come to be recognized as an indicator of quality. People should see your name on a piece of code and expect it to be solid, well written, tested, and documented. A really professional job. Written by a professional.

We have a duty to ask ourselves two questions about every piece of code we deliver: Have I protected the user? Would I use this myself?

Never store a phone number in a numeric field.