Dave Gardner
- dave@mpdconsulting.co.uk
- 07921 465358
back
The Pragmatic Programmer
Andrew Hunt and David Thomas
Ask a programmer to recommend an influential book on software engineering and The Pragmatic Programmer will invariably appear somewhere near the top. Published in 1999, and therefore relatively up-to-date when compared with titles such as The Mythical Man Month, it has quickly come to be held as a classic of software engineering.
The book itself is focussed on the details of the correct way to go about writing good software - what things can be done to improve the entire process. It does not focus on the specifics of any language and contains few practical examples. In this way, it is probably better suited to someone with some practical experience already in the field; this book will not teach you how to program. What it will do, however, is teach you how to be an excellent programmer.
One theme that runs through the book is the concept of Don't Repeat Yourself (DRY). Not only is this explained with regard to the obvious, for example don't write hundreds of lines of code if a loop will do the job in four, but the same principle is applied to all aspects of software engineering. This really is the flavour of the book - it often goes over things you will probably know, but making you actually think about them. Some of the Amazon reviews treat this as a negative, but I believe it is quite the opposite; the simplicity and thought provoking nature of the book is one of its strengths. This all builds together to promote a programming style encompassing real thoughtfulness and care - exemplified in Chapter 6: “don't program by coincidence”.
I found many of the sections of this book to be of use, including design by contract, decoupling and planning before a project. The book is well put together, and the short sections just about counter the sometimes dry nature of the text (some people complain of getting bogged down about half way through). The challenges that mark the end of a section are particularly interesting.
Use case diagrams as part of the UML process for gather requirements. Are they an effective way of communicating with your users? If not, why are you using them?”
I would definitely recommend this book, perhaps with a caveat that the text can get a bit hard work in places. However there are many useful lessons scattered throughout that make it essential reading.
