License: (CC 3.0) BY-NC-SA

Book

Andrew Hunt, David Thomas. The Pragmatic Programmer: from journeyman to master, first edition. Pearson Education, Inc, 2000.

Options

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 shell.
22. Use a single editor well.
23. Always use source code control.
24. Fix the problem, not the blame.
25. Don’t panic.
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. If it can’t happen, use assertions to ensure that it won’t.
34. Use exception 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 ‘till all the tests run.
64. Use saboteurs to test your testing.
65. Test stage 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.