The Pragmatic Programmer sets the Bar
The Pragmatic Programmer has a given place in my list of must read books for professional developers. The subtitle “from journeyman to master” explains the contents very well. The book is made up of short chapters with concrete advice on how to become a master software developer. The 70 numbered tips are short and look simple, but set a really high bar on the standards to strive for. Anyone following a majority of the tips would definitely be considered a master.
Have you heard about the DRY (Don’t Repeat Yourself) principle? This is the book that introduced it and has the original explanation and motivation for the concept. To be a book about software it is remarkable timeless. Most of the tips are as relevant today as they were 10 years ago when the book was written. Source control is now much more widespread than it was back then, but Tip 23: Always use source code control still applies. Believe it or not, there are projects out there without it.
Tip 4: Don’t Live with Broken Windows
With a metaphor from research in the field of crime and urban decay the authors talks about the importance of fixing defects. If a real fix is not possible, at least board it up as a temporary fix. Don’t leave it broken without doing anything. It sounds obvious, but to be honest it’s hard to always live up to that standard. Being a consultant with constant managerial and customer pressure to be efficient and do more in less hours it is of course tempting to ignore the broken window, but each time I do I’m slicing off a bit of my professionalism.
Tip 11: DRY – Don’t Repeat Yourself
Tip 29: Write Code that Writes Code
Andy and David are really fond of writing helper scripts for anything that can be automated, including writing code. It might look like an overwhelming task to write a code generator, but it doesn’t have to be very complicated to work. The book makes a clear distinction between active and passive code generators, where the former are one-shot generators while the latter are meant to be re-run when code is updated. In the Code Generation – Blessing or Curse? post I’ve written about the double-edged sword of code generation.
Tip 44: Don’t Program by Coincidence
You’ve written a bunch of code, trying different alternatives until it passes you’re tests. Are you finished?
No, you’re probably not until you’ve went back and checked that code and made sure that you understand it. It should not be a coincidence that your program (appears to) work. When code reviewing I’m sometimes asking for an explanation of a perfectly looking piece of code. I want to make sure that the person who wrote it knows why it works and has not just programmed by coincidence.
Tip 61: Don’t Use Manual Procedures
This tip is from the chapter on ubiquitous automation. This is where the book really raises the bar. Everything that can be automated should. If you’re doing a task repeatedly, such as checking out code, compiling and deploying to a server, the entire sequence should be automated into one command. Reaching that is really high standards. Are you there? I’m not (yet).
The Other 64 Tips
I’ve mentioned 6 tips here, there are 64 more in the book. To be honest, there are some parts of the book that are a bit outdated, when it comes to details about architecture. Sometimes (e.g. design by contract) I also think that the authors go a bit too far, beyond what is practically possible to implement.
Nevertheless the overall impression remains. The book is well written and as time less as a book on software development can possibly get.
If you haven’t read it before, order yourself a copy and read it.
The links to Amazon in this post are sponsored.
You're currently writing a reply to an existing comment, so the comment form is busy elsewhere. To make a new comment (that isn't a reply to an existing ocmment), you have to cancel that reply.