97 Things Every Programmer Should Know
Welcome to the home page for the 97 Things Every Programmer Should Know project, pearls of wisdom for programmers collected from leading practitioners. You can read through the Edited Contributions , browse Contributions in Progress , view the list of current Contributors , and also learn How to Become a Contributor . If you would simply like to comment on a contribution, please also read How to Become a Contributor as some of it applies to you.
There is no overarching narrative: The collection is intended simply to contain multiple and varied perspectives on what it is that contributors to the project feel programmers should know. This can be anything from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance, etc.
The deadline for having something considered for inclusion in the the book form of the project is 16th October 2009. Following that, 97 contributions will be picked from the Edited Contributions and published in O'Reilly's 97 Things series, which already includes 97 Things Every Software Architect Should Know (also see the 97 Things Every Software Architect Should Know homepage ) and 97 Things Every Project Manager Should Know . You can find out more about the series and the 97 Things Every Programmer Should Know project in this InfoQ article .
The 97 chosen for the book will be the ones considered not only to be the best individually, but also the ones that fit best together. Every contributor whose contribution goes into the book will be fully acknowledged in the book and will get a complementary copy of the book when it is published. The contributions for the site are being edited by Kevlin Henney , who will also be listed as the editor of the published book.
- Fulfill Your Ambitions with Open Source by Richard Monson-Haefel
- Comment Only What the Code Cannot Say by Kevlin Henney
- Restrict Mutability of State by Kevlin Henney
- Speed Kills by Uncle Bob
- Encapsulate Behavior, not Just State by Einar Landre
- Only the Code Tells the Truth by Peter Sommerlad
- Interfaces Should Reveal Intention by Einar Landre
- Inter-Process Communication Affects Application Response Time by Randy Stafford
- Test for Required Behavior, not Incidental Behavior by Kevlin Henney
- Test Precisely and Concretely by Kevlin Henney
- Verbose Logging Will Disturb your Sleep by Johannes Brodwall
- The Road to Performance Is Littered with Dirty Code Bombs by Kirk Pepperdine
- Keep the Build Clean by Johannes Brodwall
- Use Aggregate Objects to Reduce Coupling by Einar Landre
- WET Dilutes Performance Bottlenecks by Kirk Pepperdine
- Testing Is the Engineering Rigor of Software Development by Neal Ford
- Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly by Scott Meyers
- Don't Just Learn the Language, Understand its Culture by Anders Norås
- Small! by Uncle Bob
- Don't Nail Your Program into the Upright Position by Verity Stob
- You Gotta Care about the Code by Pete Goodliffe
- Know Your Next Commit by Dan Bergh Johnsson
- The Professional Programmer by Uncle Bob
- The Three Laws of Test-Driven Development by Uncle Bob
- Programmers Who Write Tests Get More Time to Program by Johannes Brodwall
- The Single Responsibility Principle by Uncle Bob
- The Longevity of Interim Solutions by Klaus Marquardt
- Prefer Domain-Specific Types to Primitive Types by Einar Landre
- Distinguish Business Exceptions from Technical by Dan Bergh Johnsson
- Don't Ignore that Error! by Pete Goodliffe
- The Boy Scout Rule by Uncle Bob
- A Comment on Comments by Cal Evans
- Don't Touch that Code! by Cal Evans
- Own (and Refactor) the Build by Steve Berczuk
- Deploy Early and Often by Steve Berczuk
- Understand Principles behind Practices by Steve Berczuk
- Acknowledge (and Learn from) Failures by Steve Berczuk
- Hard Work Does not Pay off by Olve Maudal
- Continuous Refactoring by Michael Hunger
- Scoping Methods by Michael Hunger
- Improve Code by Removing It by Pete Goodliffe
- Learn to Estimate by Giovanni Asproni
- Domain-Specific Languages by Michael Hunger
- Learn Foreign Languages by Klaus Marquardt
- Check Your Code First before Looking to Blame Others by Allan Kelly
- Two Wrongs Can Make a Right (and Are Difficult to Fix) by Allan Kelly
- Floating-point Numbers Aren't Real by Chuck Allison
- The Linker Is not a Magical Program by Walter Bright
- Beware the Share by Udi Dahan
- Consider the Hardware by Jason P Sage
- Data Type Tips by Jason P Sage
- Reinvent the Wheel Often by Jason P Sage
- Improved Testability Leads to Better Design by George Brooke
- From Requirements to Tables to Code and Tests by George Brooke
- Put the Mouse Down and Step Away from the Keyboard by BurkHufnagel
- Expect the Unexpected by Pete Goodliffe
- Continuous Learning by Clint Shank
- Don't Be Cute with Your Test Data by Rod Begbie
- Choose Your Tools with Care by Giovanni Asproni
- Decouple that UI by George Brooke
- Know Your Limits by Greg Colvin
- Do Lots of Deliberate Practice by Jon Jagger
- Code Is Hard to Read by Dave Anderson
- Simple Is not Simplistic by Giovanni Asproni
- Missing Opportunities for Polymorphism by Kirk Pepperdine
- Code in the Language of the Domain by Dan North
- Make the Invisible More Visible by Jon Jagger
- Ask "What Would the User Do?" (You Are not the User) by Giles Colborne
- Balance Duplication, Disruption, and Paralysis by Johannes Brodwall
- Methods Matter by Matthias Merdes
- The Golden Rule of API Design by Michael Feathers
- Don't Rely on "Magic Happens Here" by AlanGriffiths
- Prevent Errors by Giles Colborne
- Write Small Functions Using Examples by Keith Braithwaite
- Reuse Implies Coupling by Klaus Marquardt
- Hands on in All Phases by Klaus Marquardt
- Implicit Dependencies Are also Dependencies by Klaus Marquardt
- How to Access Patterns by Klaus Marquardt
- Code Layout Matters by Steve Freeman
- One Binary by Steve Freeman
- Beauty Is in Simplicity by Jørn Ølmheim
- Integrate Early and Often by Gerard Meszaros
- Write Tests for People by Gerard Meszaros
- Know Your IDE by Heinz Kabutz
- Structure over Function by Peter Sommerlad
- Message Passing Leads to Better Scalability in Parallel Systems by Russel Winder
- Know Well More than Two Programming Languages by Russel Winder
- Read the Humanities by Keith Braithwaite
- Code Is Design by Ryan Brush
- The Guru Myth by Ryan Brush
- Learn to Say "Hello, World" by Thomas Guest
- Don't Reinvent the Wheel by Kai Tödter
- Take Advantage of Code Analysis Tools by Sarah Mount
- Install Me by Marcus Baker
- How to Use a Bug Tracker by Matt Doar
- Use the Right Algorithm and Data Structure by JC van Winkel
- Who Will Test the Tests Themselves? by Filip van Laenen
- Write a Test that Prints PASSED by Kevin Kilzer
- There Is No Such Thing as Self-Documenting Code by Carroll Robinson
- Convenience Is not an -ility by Gregor Hohpe
- First Write, Second Copy, Third Refactor by Mario Fusco
- Display Courage, Commitment, and Humility by Ed Sykes
- A Message to the Future by Linda Rising
- Don't Repeat Yourself by Steve Smith
- Use the Same Tools in a Team by Kai Tödter
- Step Back and Automate, Automate, Automate by Cay Horstmann
- Declarative over Imperative by Christian Horsdal
- There Is No Right or Wrong by Mike Nereson
- Apply Functional Programming Principles by Edward Garson
- Talk about the Trade-offs by Michael Harmer