The Pragmatic Programmer Quick Reference Guide

From The Pragmatic Programmer: From Journeyman to Master

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 Surprise
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 Exceptional Problems
35. Finish What You Start
36. Minimize Coupling between Modules
37. Configure, Don’t Integrate
38. Put Abstractions in Code, 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 Tests 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