97 Things Every Programmer Should Know

Kevlin Henney (ed.)

Published by

O’Reilly

ISBN

978-0-596-80948-5

RRP

£22.99

Reviewed by

Kawal Banga MBCS CITP

Score

10 out of 10

97 Things Every Programmer Should KnowA fascinating book I just could not put down! This is an excellent book for all levels of developers, from those just starting out in programming to those who have been programming for a lifetime already.

It is also useful for testers and QA professionals who want to see how they can improve the quality of what comes out of development, so as to ease the pain of testing. Being an ex-developer and now into QA and testing, I can see the dual purpose of this book.

The book is basically a collection of 97 two-page contributions on various programming topics from 73 contributing authors. Due to the structure of the book, it is difficult to try to summarise what it contains in a book review like this. So, I have picked some sample contributions that caught my eye.

‘Act with prudence’ talks about technical debt as a term used to describe the impact of ‘doing it quick’ rather than ‘doing it right’ - it is like a loan in that you benefit from in the short term, but pay interest in the long term. In plain English, cutting corners in coding results in un-maintainable or difficult to change code.

‘Two heads are often better than one’ and ‘Pair program and feel the flow’ convey the virtues of pair programming, which include reducing the truck factor (i.e. if a developer gets hit by a truck there is no one else to take over), bringing new team members up to speed, solving problems more quickly and learning from each other being some of those listed.

‘Code reviews’ suggests that the purpose of reviews should be to share knowledge and establish common coding guidelines rather than focussing on finding errors.

‘Coding with reason’, ‘You gotta care about the code’, ‘Write code as if you had to support it for the rest of your life’ and ‘Read code’ provide some good practices for coding, for example making code readable and self-documenting.

‘Hard work does not pay off’ is also interesting, reinforcing the message that working long hours is unproductive and that you need time (your evenings, weekend and holidays) to educate yourself, go to conferences and learn new tools and techniques so that you become even more productive and better. In other words, work smarter, not harder.

‘Improve code by removing it’ is thought-provoking; it suggests reasons why programmers insert unnecessary code and features, and why by removing this you can actually improve product performance.

‘The longevity of interim solutions’ is something we will have all seen (or should I say suffered?). Reasons as to why we create interim solutions and what to do about them are provided.

‘When programmers and testers collaborate’ talks about the benefits of test-driven development and how working with the testers results in quicker and better code

‘Your customers do not mean what they say’ is a good summary of the challenges faced in trying to determine what the user requirements really are.

I could go on as there are so many good contributions including ‘Prevent errors’, ‘The professional programmer’ and ‘Put everything under version control’, but there is no more space in this review.

My only criticism of this book is that there are 25 pages of author biographies, which is about 11 per cent of the book, which is a bit excessive in my opinion. I would have preferred to see another 12 two-page contributions from the authors.

This book has certainly provided some useful insights into how to improve the quality of code, and hence the quality of software. An excellent book and a bargain at only £22.99.

Further Information: O’Reilly

August 2010