97 Things Every Programmer Should Know  (English, Paperback, Henney Kevlin)

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

With contributions from some of the most experienced and respected practitioners in the industry--including Michael Feathers, Pete Goodliffe, Diomidis Spinellis, Cay Horstmann, Verity Stob, and many more--this book contains practical knowledge and principles that you can apply to all kinds of projects.

A few of the 97 things you should know:

• "Code in the Language of the Domain" by Dan North
• "Write Tests for People" by Gerard Meszaros
• "Convenience Is Not an -ility" by Gregor Hohpe
• "Know Your IDE" by Heinz Kabutz
• "A Message to the Future" by Linda Rising
• "The Boy Scout Rule" by Robert C. Martin (Uncle Bob)
• "Beware the Share" by Udi Dahan

About The Author
Kevlin Henney is an independent consultant and trainer. His work focuses on patterns and architecture, programming techniques and languages, and development process and practice. He has been a columnist for various magazines and online publications, including The Register, Better Software, Java Report, CUJ, and C++ Report. Kevlin is co-author of two volumes in the Pattern-Oriented Software Architecture series: A Pattern Language for Distributed Computing and On Patterns and Pattern Languages. He also contributed to 97 Things Every Software Architect Should Know.

Table of Contents

Chapter 1. Act with Prudence
Chapter 2. Apply Functional Programming Principles
Chapter 3. Ask, "What Would the User Do?" (You Are Not the User)
Chapter 4. Automate Your Coding Standard
Chapter 5. Beauty Is in Simplicity
Chapter 6. Before You Refactor
Chapter 7. Beware the Share
Chapter 8. The Boy Scout Rule
Chapter 9. Check Your Code First Before Looking to Blame Others
Chapter 10. Choose Your Tools with Care
Chapter 11. Code in the Language of the Domain
Chapter 12. Code Is Design
Chapter 13. Code Layout Matters
Chapter 14. Code Reviews
Chapter 15. Coding with Reason
Chapter 16. A Comment on Comments
Chapter 17. Comment Only What the Code Cannot Say
Chapter 18. Continuous Learning
Chapter 19. Convenience Is Not an -ility
Chapter 20. Deploy Early and Often
Chapter 21. Distinguish Business Exceptions from Technical
Chapter 22. Do Lots of Deliberate Practice
Chapter 23. Domain-Specific Languages
Chapter 24. Don't Be Afraid to Break Things
Chapter 25. Don't Be Cute with Your Test Data
Chapter 26. Don't Ignore That Error!
Chapter 27. Don't Just Learn the Language, Understand Its Culture
Chapter 28. Don't Nail Your Program into the Upright Position
Chapter 29. Don't Rely on "Magic Happens Here"
Chapter 30. Don't Repeat Yourself
Chapter 31. Don't Touch That Code!
Chapter 32. Encapsulate Behavior, Not Just State
Chapter 33 Floating-Point Numbers Aren't Real
Chapter 34. Fulfill Your Ambitions with Open Source
Chapter 35. The Golden Rule of API Design
Chapter 36. The Guru Myth
Chapter 37. Hard Work Does Not Pay Off
Chapter 38. How to Use a Bug Tracker
Chapter 39. Improve Code by Removing It
Chapter 40. Install Me
Chapter 41. Interprocess Communication Affects Application Response Time
Chapter 42. Keep the Build Clean
Chapter 43. Know How to Use Command-Line Tools
Chapter 44. Know Well More Than Two Programming Languages
Chapter 45. Know Your IDE
Chapter 46. Know Your Limits
Chapter 47. Know Your Next Commit
Chapter 48. Large, Interconnected Data Belongs to a Database
Chapter 49. Learn Foreign Languages
Chapter 50. Learn to Estimate
Chapter 51. Learn to Say, "Hello, World"
Chapter 52. Let Your Project Speak for Itself
Chapter 53. The Linker Is Not a Magical Program
Chapter 54. The Longevity of Interim Solutions
Chapter 55. Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly
Chapter 56. Make the Invisible More Visible
Chapter 57. Message Passing Leads to Better Scalability in Parallel Systems
Chapter 58. A Message to the Future
Chapter 59. Missing Opportunities for Polymorphism
Chapter 60. News of the Weird: Testers Are Your Friends
Chapter 61. One Binary
Chapter 62. Only the Code Tells the Truth
Chapter 63. Own (and Refactor) the Build
Chapter 64. Pair Program and Feel the Flow
Chapter 65. Prefer Domain-Specific Types to Primitive Types
Chapter 66. Prevent Errors
Chapter 67. The Professional Programmer
Chapter 68. Put Everything Under Version Control
Chapter 69. Put the Mouse Down and Step Away from the Keyboard
Chapter 70. Read Code
Chapter 71. Read the Humanities
Chapter 72. Reinvent the Wheel Often
Chapter 73. Resist the Temptation of the Singleton Pattern
Chapter 74. The Road to Performance Is Littered with Dirty Code Bombs
Chapter 75. Simplicity Comes from Reduction
Chapter 76. The Single Responsibility Principle
Chapter 77. Start from Yes
Chapter 78. Step Back and Automate, Automate, Automate
Chapter 79. Take Advantage of Code Analysis Tools
Chapter 80. Test for Required Behavior, Not Incidental Behavior
Chapter 81. Test Precisely and Concretely
Chapter 82. Test While You Sleep (and over Weekends)
Chapter 83. Testing Is the Engineering Rigor of Software Development
Chapter 84. Thinking in States
Chapter 85. Two Heads Are Often Better Than One
Chapter 86. Two Wrongs Can Make a Right (and Are Difficult to Fix)
Chapter 87. Ubuntu Coding for Your Friends
Chapter 88. The Unix Tools Are Your Friends
Chapter 89. Use the Right Algorithm and Data Structure
Chapter 90. Verbose Logging Will Disturb Your Sleep
Chapter 91. WET Dilutes Performance Bottlenecks
Chapter 92. When Programmers and Testers Collaborate
Chapter 93. Write Code As If You Had to Support It for the Rest of Your Life
Chapter 94. Write Small Functions Using Examples
Chapter 95. Write Tests for People
Chapter 96. You Gotta Care About the Code
Chapter 97. Your Customers Do Not Mean What They Say
Appendix. Contributors
Colophon.