A Pragmatic Philosophy

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 requirement 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

A Pragmatic Approach

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

The Basic Tools

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
26. "Select" isn't broken
27. Don't assume it - prove it
28. Learn a text manipulation language
29. Write code that writes code

Pragmatic Paranoia

30. You can't write perfect software
31. Design with contracts(iContract)
32. Crash early
33. If it can't happen, use assertions to ensure that it won't
34. Use exceptions for exceptional problems
35. Finish what you start

Bend, or Break

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

While you are coding

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

Before the project

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

Pragmatic projects

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 state coverage, not code coverage
66. Find bugs once
67. English is just a programming language
68. Buid documentation in, don't build it on
69. Gently exceed your users' expectations
70. Sign your work