The Pragmatic Programmer

by Andy Hunt

"Kaizen" is a Japanese term that captures the concept of continuously making many small improvements. It was considered to be one of the main reasons for the dramatic gains in productivity and quality in Japanese manufacturing and was widely copied throughout the world. Kaizen applies to individuals, too. Every day, work to refine the skills you have and to add new tools to your repertoire.

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired.

Constantly review what's happening around you, not just what you personally are doing.

The scope and quality of the system you produce should be specified as part of that system's requirements.

Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution

Don't spoil a perfectly good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don't worry: it could never be perfect.

An investment in knowledge always pays the best interest.

Learn at least one new language every year.

Make what you're saying relevant in time, as well as in content. Sometimes all it takes is the simple question "Is this a good time to talk about...?"

if you don't listen to them, they won't listen to you.

EVERY PIECE OF KNOWLEDGE MUST HAVE A SINGLE, UNAMBIGUOUS, AUTHORITATIVE REPRESENTATION WITHIN A SYSTEM.

Two or more things are orthogonal if changes in one do not affect any of the others.

You get two major benefits if you write orthogonal systems: increased productivity and reduced risk.

Building unit tests is itself an interesting test of orthogonality.

No one knows what the future may hold, especially not us! So enable your code to rock-n-roll: to "rock on" when it can, to roll with the punches when it must.

Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system.

A good way to stay flexible is to write less code.

Good fences make good neighbors.

don't assume it, prove it.

Don't be a slave to history. Don't let existing code dictate future code. All code can be replaced if it is no longer appropriate.

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away....

The palest ink is better than the best memory.

1. Care About Your Craft xix Why spend your life developing software unless you care about doing it well?

2. Think! About Your Work xix Turn off the autopilot and take control. Constantly critique and appraise your work.

3. Provide Options, Don't Make Lame Excuses 3 Instead of excuses, provide options. Don't say it can't be ...

4. Don't Live with Broken Windows. 5 Fix bad designs, wrong decisions, and poor...

5. Be a Catalyst for Change. 8 You can't force change on people. Instead, show them how the future might be and help...

6. Remember the Big Picture 8 Don't get so engrossed in the details that you forget to check ...

7. Make Quality a Requirements Issue 11 Involve your users in determining the project's ...

8. Invest Regularly in Your Knowledge Portfolio 14 Make...

9. Critically Analyze What You Read and Hear 16 Don't be swayed by vendors, media hype, or dogma. Analyze information...

10. It's Both What You Say and theWay You Say It 21 There's no point in having great ideas if you don't...

11. DRY—Don't Repeat Yourself 27 Every piece of knowledge must have a single, unambiguous, authoritative ...

12. Make It Easy to Reuse 33 If it's easy to reuse, people will. Create an environ...

13. Eliminate Effects Between Unrelated Things 35 Design components that are self-contained, independent, and hav...

14. There Are No Final Decisions 46 No decision is cast in stone. Instead, consider each as being written in the sand ...

15. Use Tracer Bullets to Find the Target 49 Tracer bullets let you home in on your target by trying things ...

16. Prototype to Learn. 54 Prototyping is a learning experience. Its value lies not in the code you produce...

17. Program Close to the Problem Domain 58 Design and code in y...

18. Estimate to Avoid Surprises 64 Estimate before you start. You'll spot pote...

19. Iterate the Schedule with the Code. 69 Use experience you gain as you implement to refi...

20. Keep Knowledge in Plain Text. 74 Plain text won't become obsolete. It helps leverage your work and si...

21. Use the Power of Command Shells 80 Use the shell when graphical user i...

22. Use a Single Editor Well 82 The editor should be an extension of your hand; make sure your editor is configurab...

23. Always Use Source Code Control 88 Source code control is a time machine for your work—you can go back.

24. Fix the Problem, Not the Blame 91 It doesn't really matter whether the bug is your fault or someone else's—it is still your problem, and it still needs to be fixed.

25. Don't Panic When Debugging 91 Take a deep breath and THINK! about what co...

26. "select" Isn't Broken. 96 It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The b...

27. Don't Assume It—Prove It 97 Prove your assumptions in the actual environment with real da...

28. Learn a Text Manipulation Language 100 You spend a large part of each day working with text. Why not have the...