I recently completed reading The Pragmatic Programmer by Andrew Hunt and David Thomas.
I wish I could take a time machine back to the year 2000 and read it then.
So much of the information in the book seems to be concepts that many software developers understand and take for granted as general knowledge now, that wasn’t at the time of its writing.
The book is very much a collection of knowledge from years of practical experience writing code. It is very specific in stating what kind of specific coding practices should be carried out and which ones should be avoided.
The content of the book lays somewhere between the low level software construction in a book like Code Complete and a book targeting a higher level methodology or project management.
Good:
- Years of experience packed into a small package.
- Most of the advice in this book is timeless.
- Practical real world truth instead of theoretical talk.
- Excellent focus on automation for everything you can automate.
- Technology independent advice.
Bad:
- There were definitely some dated pieces of advice that I wouldn’t recommend following today.
- If you are already familiar with many of the software craftsmanship or general agile principles, much of this book will echo what you already know. (Can’t fault the authors for that since this book is probably the origin of much of that information getting out, yet if you haven’t read the book, you should know what to expect.)
What I learned:
I really liked the section of the book that talked about using “tracer bullets” in software development. Basically the idea is that you can either prototype the software or build what you know and then adjust your aim to reach the user’s real requirements instead of trying to specify up front.
I think many times in development we get hung up on knowing all the details, but sometimes we need to fire “tracer bullets” first to see if we are hitting the target.
I also realized that I am guilty often of programming by coincidence. Sometimes I will have put a magic incantation into the code and not really understood why it worked. It is very important to understand why something works, not just make it work.
