Great tips applicable to any language or project, and a good read too. The book includes scores of good tips, but since the Quick Reference Guide has to go back to the library with the rest of the book:

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. Ba 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
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 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. Listen to Nagging Doubts–Start When You’re Ready
57. Some Things Are Better Done than Described
58. Don’t Be a Slave to Formal Methods
59. Expensive Tools Do Not Produce Better Designs
60. Organize Around Functionality, Not Job Functions
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. Treat English as Just Another Programming Language
68. Build Documentation In, Don’t Bolt It On
69. Gently Exceed Your Users’ Expectations
70. Sign Your Work