I just finished the book:
Henney, Kevlin. 2010. 97 things every programmer should know: collective wisdom from the experts. Sebastopol, Calif: O’Reilly. Also has companion website.
This book was written by computer programmers for computer programmers. Despite this, I think librarians and other professionals should read through it.
Before I get into this review, I should mention that my background is one of a computer power user (can figure out new software pretty easily or quickly find out tutorials for it) who has dabbled in programming. Additionally I’m very comfortable with HTML and know CSS reasonably well. So I consider myself more techy than the average librarian.
I’m also interested in the culture of computer programmers and software development generally, so I picked up this book.
The book’s introduction makes it clear this is not meant to be a bible or how-to guide:
With so much to know, so much to do, and so many ways of doing so, no single source can lay claim to “the one true way.” Instead, 97 Things Every Programmer Should Know draws on the wisdom of crowds and the voices of experience to offer not so much a coordinated big picture as a crowdsourced mosaic of what every programmer should know. This ranges from code-focused advice to culture, from algorithm usage to agile thinking, from implementation know-how to professionalism, from style to substance.
The short essays that follow show that preface doesn’t lie. The topics vary as does the accessibility of writing. Some essays were completely impenetrable to me, with no notes or glossaries to light my way. Because if you were a programmer, you’d understand. Others, while very computer oriented were accessible and a couple gave me ideas to take back to the office. Still others were focused on workplace and professional culture. These were both easy to understand and in some cases offered models for librarians to follow.
I came away from the book with more confidence about communicating with computer programmers and the usefulness of reading outside my field. I also took away these impressions:
- Programmers appear to agree that learning a computer language a year is both beneficial AND doable.
- There is no consensus on a number of issues, especially that between “If it ain’t broke, don’t fix it” and “Always take the opportunity to leave code better than when you found it.”
- There is some, but not universal acknowledgement, that programmers have more work to do in listening to users.
- Many programmers believe in the power of the reference interview, though they don’t call it that. Also that the first thing that users say they want might not be what they really want.
- Programmers are groping words better teamwork and partnership and trying to hoard information less. At least with each other.
- There is a lot more involved in testing software than I would have guessed.
- Some programmers feel very strongly that professional development is YOUR responsibility and that if you’re a professional, you’ll spend of some of your free time and/or money doing it. This is my view, though I also think that smart workplaces (like my own) do some investing as well.
- There really are a dearth of women programmers. Out of the ninety seven essays, I think at most five were written by women. To me, I thought all of the women wrote pretty accessible essays. A number of the guys did to, but not an overwhelming majority.
All 97 essays are available at the book’s companion website and are licensed Creative Commons. So in future postings I’ll be highlighting individual essays and what I took away from them.