97 Things Every Programmer Should Know
From WikiContent
(Difference between revisions)
| (34 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| + | '''''<font color="Red" size="+1">Please note that this page is no longer being used for gathering contributions.</font>''''' | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
''Create an account by clicking [http://commons.oreilly.com/wiki/index.php?title=Special:Userlogin&returnto=Special:Userlogout here]. You don't need an email invitation to create an account.'' | ''Create an account by clicking [http://commons.oreilly.com/wiki/index.php?title=Special:Userlogin&returnto=Special:Userlogout here]. You don't need an email invitation to create an account.'' | ||
| Line 9: | Line 14: | ||
''97 Things Every Programmer Should Know'' is intended to be a book of wisdom for programmers collected from leading practitioners. There is no overarching narrative: it is intended simply to contain multiple and varied perspectives on what it is that you 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. | ''97 Things Every Programmer Should Know'' is intended to be a book of wisdom for programmers collected from leading practitioners. There is no overarching narrative: it is intended simply to contain multiple and varied perspectives on what it is that you 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. | ||
| - | Now that we have a suitable number of complete and high-quality contributions, we're looking to move to the next phase of the project, where we open up the existing items to the public for comment and further contributions. This looks like it will be mid August 2009. Following that we will move to the final phase of the project, publishing a book with a selection of the 97 contributions that work best together. | + | Now that we have a suitable number of complete and high-quality contributions, we're looking to move to the next phase of the project, where we open up the existing items to the public for comment and further contributions. This looks like it will be mid-August 2009. Following that we will move to the final phase of the project, publishing a book with a selection of the 97 contributions that work best together. |
Thank you for taking the time and making the effort to contribute. | Thank you for taking the time and making the effort to contribute. | ||
| Line 58: | Line 63: | ||
=== Completed === | === Completed === | ||
| - | Contributions in this section are effectively complete from the author's point of view. Items placed in this section must meet the word-count requirements (at least 400 words and not wildly over 500 words) and the associated author bio must also be complete | + | Contributions in this section are effectively complete from the author's point of view, with some possible edits in the pipeline, and are ready to be moved over to the public site, mid-August. Items placed in this section must meet the word-count requirements (at least 400 words and not wildly over 500 words) and the associated author bio must also be complete. |
# [[Fulfill Your Ambitions with Open Source]] by [[Richard Monson-Haefel]] | # [[Fulfill Your Ambitions with Open Source]] by [[Richard Monson-Haefel]] | ||
| Line 97: | Line 102: | ||
# [[Understand Principles behind Practices]] by [[Steve Berczuk]] | # [[Understand Principles behind Practices]] by [[Steve Berczuk]] | ||
# [[Acknowledge (and Learn from) Failures]] by [[Steve Berczuk]] | # [[Acknowledge (and Learn from) Failures]] by [[Steve Berczuk]] | ||
| - | # [[Hard | + | # [[Hard Work Does not Pay off]] by [[Olve Maudal]] |
# [[Continuous Refactoring]] by [[Michael Hunger]] | # [[Continuous Refactoring]] by [[Michael Hunger]] | ||
# [[Scoping Methods]] by [[Michael Hunger]] | # [[Scoping Methods]] by [[Michael Hunger]] | ||
| Line 110: | Line 115: | ||
# [[Beware the Share]] by [[Udi Dahan]] | # [[Beware the Share]] by [[Udi Dahan]] | ||
# [[Consider the Hardware]] by [[Jason P Sage]] | # [[Consider the Hardware]] by [[Jason P Sage]] | ||
| - | # [[Data Type | + | # [[Data Type Tips]] by [[Jason P Sage]] |
# [[Reinvent the Wheel Often]] 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]] | # [[Put the Mouse Down and Step Away from the Keyboard]] by [[BurkHufnagel]] | ||
# [[Expect the Unexpected]] by [[Pete Goodliffe]] | # [[Expect the Unexpected]] by [[Pete Goodliffe]] | ||
| Line 119: | Line 124: | ||
# [[Don't Be Cute with Your Test Data]] by [[Rod Begbie]] | # [[Don't Be Cute with Your Test Data]] by [[Rod Begbie]] | ||
# [[Choose Your Tools with Care]] by [[Giovanni Asproni]] | # [[Choose Your Tools with Care]] by [[Giovanni Asproni]] | ||
| - | # [[ | + | # [[Decouple that UI]] by [[George Brooke]] |
# [[Know Your Limits]] by [[Greg Colvin]] | # [[Know Your Limits]] by [[Greg Colvin]] | ||
# [[Do Lots of Deliberate Practice]] by [[Jon Jagger]] | # [[Do Lots of Deliberate Practice]] by [[Jon Jagger]] | ||
| Line 134: | Line 139: | ||
# [[Prevent Errors]] by [[Giles Colborne]] | # [[Prevent Errors]] by [[Giles Colborne]] | ||
# [[Write Small Functions Using Examples]] by [[Keith Braithwaite]] | # [[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]] | # [[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]] | # [[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]] | ||
| + | |||
| + | === Planning to Complete === | ||
| + | Contributions in this section are not yet complete, but the authors intend to complete them before mid-August. | ||
| + | |||
| + | # [[Take Time to Read Other People's Good (and Bad) Code]] by [[Craig Larman]] | ||
| + | # [[Apply Functional Programming Principles]] by [[Edward Garson]] | ||
| - | === | + | === Not Planning to Complete === |
| - | Contributions in this section are | + | Contributions in this section are not complete, and the authors do not intend to complete them before mid-August. |
# [[Duplicate to decouple]] by [[Klaus Marquardt]] | # [[Duplicate to decouple]] by [[Klaus Marquardt]] | ||
# [[Two hours of thinking can save two months of coding]] by [[Giovanni Asproni]] | # [[Two hours of thinking can save two months of coding]] by [[Giovanni Asproni]] | ||
| - | # [[Know your IDE]] by [[Heinz Kabutz]] | ||
| - | # [[Hands on in all phases]] by [[Klaus Marquardt]] | ||
| - | # [[Implicit dependencies are also dependencies]] by [[Klaus Marquardt]] | ||
# [[Learn reading and judging code, especially your own]] by [[Peter Sommerlad]] | # [[Learn reading and judging code, especially your own]] by [[Peter Sommerlad]] | ||
# [[Understand SCM]] by [[Steve Berczuk]] | # [[Understand SCM]] by [[Steve Berczuk]] | ||
| Line 157: | Line 170: | ||
# [[Use the same tools in a team]] by [[Kai Tödter]] | # [[Use the same tools in a team]] by [[Kai Tödter]] | ||
# [[Collection of Collections Is a Code Smell]] by [[Kirk Pepperdine]] | # [[Collection of Collections Is a Code Smell]] by [[Kirk Pepperdine]] | ||
| - | # [[Take Time to Read Other People's Good (and Bad) Code]] by [[Craig Larman]] | ||
# [[Planning for performance is not a premature optimization]] by [[Kirk Pepperdine]] | # [[Planning for performance is not a premature optimization]] by [[Kirk Pepperdine]] | ||
| - | # [[Reading Patterns]] by [[Klaus Marquardt]] | ||
| - | |||
| - | === Not Started === | ||
| - | Contributions in this section only have a couple of sentences of suggestion or are just titles. | ||
| - | |||
# [[Useful software is used longer than ever intended]] by [[Peter Sommerlad]] | # [[Useful software is used longer than ever intended]] by [[Peter Sommerlad]] | ||
# [[Measure, don't guess]] by [[Kirk Pepperdine]] | # [[Measure, don't guess]] by [[Kirk Pepperdine]] | ||
| Line 170: | Line 177: | ||
# [[Plenty of domain types]] by [[Steve Freeman]] | # [[Plenty of domain types]] by [[Steve Freeman]] | ||
# [[Logging is a user interface]] by [[Steve Freeman]] | # [[Logging is a user interface]] by [[Steve Freeman]] | ||
| - | # [[Reflection: Beauty or Horror?]] by [[Heinz Kabutz]] | ||
# [[Don't handle errors, design them away]] by [[Michael Feathers]] | # [[Don't handle errors, design them away]] by [[Michael Feathers]] | ||
# [[Protection is a social problem, not a technical problem]] by [[Michael Feathers]] | # [[Protection is a social problem, not a technical problem]] by [[Michael Feathers]] | ||
# [[Start Small, Grow Big]] by [[Jørn Ølmheim]] | # [[Start Small, Grow Big]] by [[Jørn Ølmheim]] | ||
| - | # [[Beauty is in Simplicity]] by [[Jørn Ølmheim]] | ||
# [[Objects Want to be Asynchronous]] by [[Michael Feathers]] | # [[Objects Want to be Asynchronous]] by [[Michael Feathers]] | ||
# [[There is no Up or Down in Software]] by [[Michael Feathers]] | # [[There is no Up or Down in Software]] by [[Michael Feathers]] | ||
| Line 180: | Line 185: | ||
# [[Allow faults to be diagnosable]] by [[Tony Barrett-Powell]] | # [[Allow faults to be diagnosable]] by [[Tony Barrett-Powell]] | ||
# [[Instrumentation for Quality Control]] by [[George Brooke]] | # [[Instrumentation for Quality Control]] by [[George Brooke]] | ||
| - | # [[ | + | # [[Reflection: Beauty or Horror?]] by [[Heinz Kabutz]] |
| + | # [[The Best Code]] by [[Chuck Allison]] | ||
=== Suggestion Box === | === Suggestion Box === | ||
Current revision
Please note that this page is no longer being used for gathering contributions.
Create an account by clicking here. You don't need an email invitation to create an account.
Hi!
Welcome to the home page for developing the initial phase of 97 Things Every Programmer Should Know.
97 Things Every Programmer Should Know is intended to be a book of wisdom for programmers collected from leading practitioners. There is no overarching narrative: it is intended simply to contain multiple and varied perspectives on what it is that you 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.
Now that we have a suitable number of complete and high-quality contributions, we're looking to move to the next phase of the project, where we open up the existing items to the public for comment and further contributions. This looks like it will be mid-August 2009. Following that we will move to the final phase of the project, publishing a book with a selection of the 97 contributions that work best together.
Thank you for taking the time and making the effort to contribute.
Contents |
What Will Come of All This?
This current site is for the initial phase of the project. In the next phase of the project, starting in August, O'Reilly will publish the contents of this wiki in a public and free web site off the O'Reilly properties. It will be free for anyone to access but you'll have to register to contribute or comment. Users (that's everyone who is registered) will be able to comment on other peoples contributions and create, edit, and improve their own contributions. Anyone and everyone be able to view the material without requiring registration. The web site will be strongly promoted by O'Reilly and all contributors will get full attribution.
After this, O'Reilly will consider taking the next step, which is to publish a 97 Things Every Programmer Should Know book. If a book is to be published, the best contributions and the contributions that fit best together will be selected and edited by me and Michael Loukides, an editor from O'Reilly. The book will sell in book stores and on-line. It will be listed as edited by Kevlin Henney. If your contribution is chosen, any recommended edits recommended will be contributed back to the 97 Things project for everyone to enjoy. 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.
To get a feel for this type of project take a look at another book in the series called 97 Things Every Software Architect Should Know. It's the flagship project for the 97 Things series and is the first book in the series.
How to Make a Contribution
- Each contributor is asked to provide one or more items (tips or bits of wisdom) that each have a title and associated discussion. The title should only be a 2 to 10 words long if possible and should summarize or capture the essence of the advice. In print, we want each contribution to fit on a two-page spread. Keep your discussion between 400 and 500 words. Any contribution under 400 words is unlikely to make it to the next phase of the project. And much more than 500 words will need to be edited down.
- Create an account and author page. To create and edit a page you will need to create an account. You can then contribute your items and provide an author page. For more details on this see How to Get Started.
- Please read the first contribution. I've added an example contribution in The Contribution section below to provide further guidelines on content style and to show you an example of what you will see when your are ready to add your own tip/axiom/pearl/guideline/contribution. Reading the initial contribution won't take long — it's not much more than 500 words!
Rules of Engagement
- Contributors need to have an account and to create an author page. Instructions for doing this can be found here.
- Minimize work in progress and work suggested but not started. Although it can be useful to put a place holder for an item, such as just its title or a couple of lines of content that are notes, please try to keep this to a minimum. It is more valuable to have submitted a few items that are complete and are of high quality than a long list of suggestions or partial submissions. Reducing work in progress makes it easier for you to see your own progress and for others to see the progress of the whole project. So, ideally, try to have no more than a couple of incomplete items at any one time.
- Nominate others. Contribution is by invitation only, but you can nominate others for inclusion by contacting me with your suggestions.
- Editing ethics. You have the ability to add or change your contributions at any time. To be a good participant, please edit your own contributions only. Be very careful that you don't accidentally alter someone else's work. As editor, I will limit my editorial changes to basic copy editing (spelling, punctuation, grammar, and formatting). I will discuss any other suggestions or comments on a contributed item directly with its author.
- Protect the privacy of our site. Please keep this URL private sharing it only with people you invite personally to contribute. Don't link to it, digg it, put it on your web pages, send it out to a mailing list, etc. First, it's only temporary. This project will not live within O'Reilly commons indefinitely. Second, we'd like to keep this under wraps until we have a decent block of material to release.
- Free of commercials. Please keep contributions free from references to specific products or technologies that compare their worth, or paint them in a positive or negative light.
- Legal stuff. All contributions made to this site are required to be made under the Creative Commons Attribution 3.0 license. This means that by making a content contribution, you are agreeing that it is licensed to us and to others under this license. If you do not want your content to be available under this license, you should not contribute it.
- Volunteers only. Contributions are made on a volunteer basis — in other words, contributors are not paid for their contributions. The contributions will be made easily available to everyone on the World Wide Web for free. However, remember that those of you whose tips are chosen for publication will get your name attached to your work, your bio published next to it, and a free copy of the published book. Any item you contribute you can also reuse in any form you wish, such as in a blog posting.
- Submit only your own work. You warrant that all work that you contribute to this site is your original work, except for material that is in the public domain or for which you have obtained permission. Feel free to draw from your own existing work (blogs, articles, talks, etc.), so long as you are happy with the Creative Commons licence.
The Contributions
Please add your contributions in the subsections below, placing them and moving them to the subsection that best fits the state of a contribution. For guidance on the mechanics of how to contribute an item, please see How to Get Started. The following is an example contribution you may find useful as a guideline:
Completed
Contributions in this section are effectively complete from the author's point of view, with some possible edits in the pipeline, and are ready to be moved over to the public site, mid-August. Items placed in this section must meet the word-count requirements (at least 400 words and not wildly over 500 words) and the associated author bio must also be complete.
- 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 the Aggregate Design Pattern 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
Planning to Complete
Contributions in this section are not yet complete, but the authors intend to complete them before mid-August.
- Take Time to Read Other People's Good (and Bad) Code by Craig Larman
- Apply Functional Programming Principles by Edward Garson
Not Planning to Complete
Contributions in this section are not complete, and the authors do not intend to complete them before mid-August.
- Duplicate to decouple by Klaus Marquardt
- Two hours of thinking can save two months of coding by Giovanni Asproni
- Learn reading and judging code, especially your own by Peter Sommerlad
- Understand SCM by Steve Berczuk
- Don't reinvent the wheel by Kai Tödter
- Use the same tools in a team by Kai Tödter
- Collection of Collections Is a Code Smell by Kirk Pepperdine
- Planning for performance is not a premature optimization by Kirk Pepperdine
- Useful software is used longer than ever intended by Peter Sommerlad
- Measure, don't guess by Kirk Pepperdine
- Programming is a team sport by Pete Goodliffe
- Get the names right by Steve Freeman
- Plenty of domain types by Steve Freeman
- Logging is a user interface by Steve Freeman
- Don't handle errors, design them away by Michael Feathers
- Protection is a social problem, not a technical problem by Michael Feathers
- Start Small, Grow Big by Jørn Ølmheim
- Objects Want to be Asynchronous by Michael Feathers
- There is no Up or Down in Software by Michael Feathers
- Cohesion and Coupling matter by Tony Barrett-Powell
- Allow faults to be diagnosable by Tony Barrett-Powell
- Instrumentation for Quality Control by George Brooke
- Reflection: Beauty or Horror? by Heinz Kabutz
- The Best Code by Chuck Allison
Suggestion Box
This subsection is not for authored contributions, but for ideas you feel would benefit from being written about. You may not have the time, inclination, or background to write up a topic but still feel that it deserves to be covered. If so, please add a bullet below. And if you are looking for ideas for what to write about, please look at the list below for inspiration!
- Program to an interface, not an implementation
- Exception handling
- Don't put core application logic in the UI code
- Build tools
- Postel's Law and/or preconditions and postconditions
- Type conversions and type compatibility (languages have rules that can both help and hinder)
- Concurrency
- Team and collaboration
- Algorithms and data structures (the importance of choosing the right ones)
- Hardware basics that can affect program performance (such as caching level and instruction pipelines)
- Memory usage
- The principle of least astonishment / law of least surprise
- Long argument lists
- Spikes, tracer bullets, and prototyping
- Design Patterns
- Code Metrics / Visualization
