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