The Pragmatic Programmer

We strongly believe that 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.

We’ve found that as our knowledge of the domain increases, we’re better able to make suggestions on other things that could be done to address the underlying business issues.

it’s these expectations of business value that really count—not just the software project itself. The software is only a means to these ends.

Our goal as developers is to delight users.

How will you know that we’ve all been successful a month (or a year, or whatever) after this project is done?

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.

That’s where we programmers come in. Our job is to help people understand what they want. In fact, that’s probably our most valuable attribute. And it’s worth repeating:

The Requirements Myth In the early days of software, computers were more valuable (in terms of amortized cost per hour) than the people who worked with them. We saved money by trying to get things correct the first time. Part of that process was trying to specify exactly what we were going to get the machine to do. We’d start by getting a specifica

We strongly believe that the only way to build software is incrementally. Build small pieces of end-to-end functionality, learning about the problem as you go. Apply this learning as you continue to flesh out the code, involve the customer at each step, and have them guide the process.