By Chris Douce
The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt and David Thomas
Addison Wesley, 1997
I have been threatening to read this edition of the Programmatic Programmer ever since it was published. There are, of course, many different 'types' of programmer - applications programmer, systems programmer, firmware programmer, 'web' programmer. The Pragmatic Programmer has been written and should be of interest to all types.
The Pragmatic Programmer provides sensible pragmatic advice in an easy to read, bite (or byte?) sized sections in a style that is easy to digest. I personally found the style agreeable. They add humour to what can be a difficult and dry topic, adding useful (and fun) explanatory anecdotes.
Many topics are familiar - the software development group, the application of design patterns and the performance of continual refactoring to enhance existing code and the use of light weight 'extreme' methologies.
For very many programmers, a significant amount of their time is spent maintaining legacy systems. Older systems are touched upon, regarding the number of digits used within dates, the importance of considering your data structures and how they could be manipulated. The focus of the text lies very much with the contemporary, Java, C++ and Python all feature. The index does not extend to assembly language, Cobol or Fortran.
The advice given is sound and sensible. I found myself on a number of occasions thinking, 'I agree, that is the way to do it...', having been bitten by my own misconceived and misjudged actions during my day-to-day tasks.
Each section is complemented by a number of challenges or questions that aim to solidify the 'tips' that are given. These challenges would make useful discussion points within computer science courses, software engineering courses, or even amongst a small programming team.
Occasionally, the authors touch upon topics that are central to the psychology of programming community. Key issues include language design, naming of identifiers and comments. Language design is examined from a purely 'pragmatic' perspective. It is suggested that programmers may find it easier to solve certain types of problem if they are to design a language for a specific task.
Hunt and Thomas even go as far as showing us how very simple languages can be developed using tools such as Bison, also providing a simple implementation.
Identifiers are discussed in connection with the 'stoop' effect, that the names of colours are harder to read if they are written using a different colour ink. This was used as an analogy for function names, or, indeed, any form of identifier.
The authors clearly believe that programming is a craft. Look after your tools, they write. Learn your text manipulation languages, such as Perl, sed and awk well and they will serve you well in return, helping you do your job efficiently and effectively. Like a craftsman, they advise you to use your basic tools to craft other tools, such as jigs, allowing you to repeatedly carry out simple tasks that can be repeated with certainty.
Regarding documentation, the authors are especially pragmatic. About comments, they write, 'commenting source code gives you the perfect opportunity to document those elusive bits of a project that can't be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded'. They also caution about over commenting, stating that it is a maintenance overhead that can be done without
A recurring topic is education. The authors encourage the programmer to 'explore' and study the tools that they have available, such as text editors and scripting languages. They also encourage programmers to keep abreast of developments in programming practice, technological developments, approaches and methodologies. Read a book a technical book a month and try to think critically about what is written, they suggest.
There is one thing that I am not happy with, and this is the title. Whilst programming remains the core to the book, I cannot help but think that perhaps they could of called it 'the pragmatic software developer', or 'the pragmatic software architect'. Another title may have been, 'the well rounded programmer'.
Programming is, of course, much more than simply writing code. It is eliciting requirements from users, selling your concepts to your co-workers and management, writing accessible documentation, designing test cases and test strategies, explaining important concepts to the marketing department and listening to others concerns and reservations.
The Pragmatic Programmer reminds me a little like Programming Pearls, especially when it comes to the end of section questions, and the fact that Jon Bentley (ACM Press) describes laziness as one of the key qualities of a good programmer. The Pragmatic Programmer also reminds me of another text that I have been threatening to read for ages, The Practice of Programming by Kernighan and Pike. Another book that address similar ideas is Code Complete (and perhaps Writing Solid Code) by McConnell.
Some readers may find the authors style of writing a little hard to digest. I find its style appealing, primarily because it aims for accessibility. It's not a big book and can be read over a couple of hours an afternoon with the television turned on (apart from the chapter on algorithm complexity)
Whilst battling for hours over mysteriously disappearing numbers, I shall try to remember their sensible words: "If you think it is the compiler or the operating system, it isn't likely to be either".
Have you read a book that you think that others may find interesting? If so, please do tell us about it.