97 Things Every Programmer Should Know

1. 97 Things Every Programmer Should know by Kevlin Henney There is an art, craft and science to pro- gramming that extends far beyond the program. The act of programming mar- ries the discrete world of computers with the fluid world of human affairs. Programmers mediate between the ne- gotiated and uncertain truths of business and the crisp, uncompromising domain of bits and bytes and higher constructed types. mers what had already been done for software architects? A collective and open project based on voluntary contributions from programmers and others involved in the software development process. A cross section of people that would include big names — but, importantly, not just the big names. for Distributed Computing, which I co- authored with Frank Buschmann and Douglas Schmidt. In this we documented 114 patterns, which were divided and in- terconnected to form a coherent whole, speaking with one voice. For 97 Things Every Programmer Should Know, my goal as the editor has been to achieve the exact opposite: each item should reflect the identity, voice and thinking of its au- thor, and although there are overlaps and gaps, the overall diversity and richness becomes part of the charm, readability and utility. And yes, it is my hope that the outcome is useful. Not as a handbook, but as a source of ideas, discussion and even inspiration. The number of contributions has been overwhelming — well beyond 97 — but what comes across from each con- tributor is a certain passion and personal connection to programming. Although not strictly open source, the project has some open-source qualities. In particular, contributions are made under a non-restrictive license (Creative Commons Attribution 3.0, in this case). Individuals contribute blog-length items on, well, things that they think every pro- grammer should know. These items can be reused, repurposed and republished freely. There’s no small amount of wisdom scat- tered around the blogosphere about how to do this, but mostly hidden in a mo- rass of somewhat less-than-wise advice. Sound advice can also be found lurking within a number of books — and, again, bookish form is no guarantee of qual- ity. But most of the good stuff is locked up within the minds and experiences of practitioners. How to unlock some of this know how? There is also an element of crowdsourc- ing: taken together the items form part of a big picture, but the big picture is built up by sampling the wisdom of crowds rather than working to a design vision and progressively elaborating each detail as necessary. The writing is not collabora- tive and there’s no intent that contribu- tions should follow a common style or dovetail together like modular parts. If anything, the converse is true. A while back, “Dammit, that’s just one of those things every programmer should know!” was my response to some code I was thinking about. I had contributed to Richard Monson-Haefel’s 97 Things Every Software Architect Should Know project and I knew that Richard had been working with O’Reilly to create a 97 Things series. My own phrasing was the trigger: what about doing for program- You can find the 97 Things Every Programmer Should Know site at http://programmer.97things.oreilly.com You can follow it on Twitter as @97TEPSK The book is listed at http://oreilly.com/catalog/9780596809492 There is an InfoQ piece about 97 Things Every Programmer Should Know and the 97 Things series at http://www.infoq.com/ news/2009/09/97-things. My role as the editor and driver of the project has been quite a contrast to my involvement in A Pattern Language 34