97 Things Every Programmer Should Know

Posted by Mirko Stocker on Sep 16, 2009

Sections

Process & Practices,

Architecture & Design,

Development

Topics

.NET ,

Agile ,

Community ,

Ruby ,

Java ,

Programming

Tags

Best Practices ,

Book ,

Wiki ,

Craftsmanship

After 97 Things Every Architect Should Know (InfoQ reported), the 97 Things series continues with the things that every programmer should know. The Things are collected in a wiki, and everybody is welcome to contribute and comment on the entries.

The wiki already contains (at the time of writing) 88 entries that are being worked on, for example: 

• Only the Code Tells the Truth by Peter Sommerlad
• Speed Kills by Uncle Bob
• The Golden Rule of API Design by Michael Feathers
• Know Your IDE by Heinz Kabutz
• Write Tests for People by Gerard Meszaros

InfoQ talked to 97 Things Every Programmer Should Know's editor Kevlin Henney to learn more about the project. 

The 97 Things series kicked off with the 97 Things Every Software Architect Should Know project, which was followed by 97 Things Every Project Manager Should Know, and now 97 Things Every Programmer Should Know. Each of these projects has been built up around individual contributions to a wiki, which are then edited, and then from which 97 items are selected for a book.

Contributors have become involved through announcements, specific invitations, recommendations and word of mouse. The Software Architect and Programmer projects have gone further with a more public call for contributions, so that anyone with sufficient interest and motivation can contribute. Word has got out through blogs, lists and, in the case of Programmer, Twitter (@97TEPSK).

The use of a Creative Commons licence for each contribution, plus the open call, gives the projects an open-source-like quality. Even after the corresponding book is published, the wiki associated with each project remains in place, with the aim of gathering comments and even further contributions.

After the architect, why now the programmer? 

And why not the other way around? :-) After all, programmers form a larger constituency than software architects among the roles involved in software development!

97 Things Every Software Architect Should Know was the first book out of the gate and the first to explore the format and approach. It was conceived as an individual book before there was any notion of a series. On a list managed by Bruce Eckel, Richard Monson-Haefel called for suggestions for a talk he was doing entitled "10 Things Every Software Architect Should Know", from which the idea for the book and the site – and ultimately the series – grew.

The specific idea to do a programmer-focused book came to me when I was pondering an oversight in some code I was reading, and found myself muttering something like "Dammit, that's just one of those things every programmer should know!" (something like... but the initial sentiment was probably expressed a little more strongly). The phrase "every programmer should know" was the trigger. I have written up and presented various lists of recommendations and considerations in the past, but having already contributed to Software Architect, I found the wisdom-of-crowds approach appealing.

What kind of programmer does the project target? 

This is a book for all programmers. It is not a how-to book, an introductory guide or a definitive listing of everything every programmer needs to know; it is slices of knowledge that every programmer may find valuable, drawn from a range of different perspectives and experiences. Some programmers may find it reinforces some of what they feel they know and ought to know. For others it may highlight gaps that they may want to work to fill, regardless of their level of experience. Others may find contradictions with their own experience, which is a great way to kick off a conversation.

It's meant to be the kind of book that can be read immersively or dipped into, useful for book study groups or reading alone, good on the couch and good in bed (not many programmer-focused books aim for that...), and a valuable time-filler at airports, stations or bus stops (weather permitting).

Is there already a fourth book planned? 

The 97 Things series is ongoing, so it's certainly expected that there will be more. That said, although a couple of other projects have been suggested and even tentatively started, at the moment I'm not aware of any other projects that are ready to see the light of day.

There is no overarching scheme of gaps to fill out – software architect, project manager, programmer, DBA, business analyst, UI designer, etc. – so the series is not preplanned in that sense. There is also nothing that limits these books to being focused on the roles and practices associated with software development. Each project is individually proposed and managed by an editor, so it is down to the editor to select and then drive the project.

By now, every reader must be wondering why they are exactly 97 things? 

It's a strong prime :-)

Which is, of course, true, but neither particularly useful nor the actual reason. It's 97 because that is conveniently close to 100 without actually being 100 or trying too obviously not to be (e.g., 99 and 101). It's around 100 because that allows for a diverse range of short items, each occupying two pages in printed form, and amounts to a reasonably sized book. The specific number 97 was chosen by Richard Monson-Haefel, editor of 97 Things Every Software Architect Should Know, the first book in the series – by definition, all other books in the 97 Things series are somewhat bound to follow the mould!

Significantly fewer items and either the items would be longer, less diverse and more like ordinary articles, which would discourage people from contributing, or the resulting book would be more like a pamphlet. Significantly more items and the items would either have to be shorter, making them little more than abstracts, or the resulting book would be too long for what it's trying to do.

More on the 97 Things Every Programmer Should Know wiki and don't miss the list of edited contributions.

• Older >