I’m not a developer. I’ve been working on a bit of design and a bit of development (I’ve heard someone like this called a sweeper. I always liked that name.), but I’m certainly not a developer.

On every blog and developer checklist, however, I kept hearing about this book, the Pragmatic Progammer by Hunt and Thomas. Recently, I was due for a new technical book and decided I could use an essential guide in the fundamentals. Pragmatic Progammer was the perfect choice.

I started reading this book for two reasons. First, for the developer side of my sweeper practice, I wanted to be efficient with my time, ensuring I would do things the right way, the first time. Second, I foresee a career of working with developers, and it makes sense for me to know what makes a good developer, how developers think.

While reading Pragmatic Programmer, I also realized that many of the lessons were applicable to any job, craft, or career. Use the best tools, be efficient with your time, improve as you go, plan, test, be thorough, etc. These lessons are ubiquitous.

Throughout the book, the authors have sprinkled just these types of career-neutral tips that perfectly summarize the book’s concepts. Rather than explain them all to you, I thought best to try something different and use this post to give you all of Pragmatic Progammer’s 70 tips — for progammers and people, alike:

1. Care About Your Craft
2. Think! About Your Work
3. Provide Options, Don’t Make Lame Excuses
4. Don’t Live with Broken Windows
5. Be a Catalyst for Change
6. Remember the Big Picture
7. Make Quality a Requirements Issue
8. Invest Regularly in Your Knowledge Portfolio
9. Critically Analyze What You Read and Hear
10. It’s Both What You Say and the Way You Say It
11. DRY - Don’t Repeat Yourself
12. Make It Easy to Reuse
13. Eliminate Effects Between Unrelated Things
14. There Are No Final Decisions
15. Use Tracer Bullets to Find the Target
16. Prototype to Learn
17. Program Close to the Problem Domain
18. Estimate to Avoid Surprises
19. Iterate the Schedule with the Code
20. Keep Knowledge in Plain Text
21. Use the Power of Command Shells
22. Use a Single Editor Well
23. Always Use Source Code Control
24. Fix the Problem, Not the Blame
25. Don’t Panic When Debugging
26. “select” Isn’t Broken
27. Don’t Assume It - Prove It
28. Learn a Text Manipulation Language
29. Write Code That Writes Code
30. You Can’t Write Perfect Software
31. Design with Contracts
32. Crash Early
33. Use Assertions to Prevent the Impossible
34. Use Exceptions for the Exception Problems
35. Finish What You Start
36. Minimize Coupling Between Modules
37. Configure, Don’t Integrate
38. Put Abstractions in Cod, Details in Metadata
39. Analyze Workflow to Improve Concurrency
40. Design Using Services
41. Always Design for Concurrency
42. Separate Views from Models
43. Use Blackboards to Coordinate Workflow
44. Don’t Program by Coincidence
45. Estimate the Order of Your Algorithms
46. Test Your Estimates
47. Refactor Early, Refactor Often
48. Design to Test
49. Test Your Software, or Your Users Will
50. Don’t Use Wizard Code You Don’t Understand
51. Don’t Gather Requirements - Dig for Them
52. Work with a User to Think Like a User
53. Abstractions Live Longer than Details
54. Use a Project Glossary
55. Don’t Think Outside the Box — Find the Box
56. Start When You’re Ready
57. Some Things Are Better Done than Described
58. Don’t Be a Slave to Formal Methods
59. Costly Tools Don’t Produce Better Designs
60. Organize Teams Around Functionality
61. Don’t Use Manual Procedures
62. Test Early. Test Often. Test Automatically.
63. Coding Ain’t Done ‘Til All the Test Run
64. Use Saboteurs to Test Your Testing
65. Test State Coverage, Not Code Coverage
66. Find Bugs Once
67. English is Just a Programming Language
68. Build Documentation In, Don’t Bolt It On
69. Gently Exceed Your Users’ Expectations
70. Sign Your Work

Posted in Books