What an appetizing title! This book is part of an O’Reilly serie that treats a lot of interesting topic. Contrary to Beautiful Code, this one is much shorter but the title suggest it is much more pragmatic.

Each time, the author has some thing to say, it starts with a small phrase that can be disturbing, and then a complete explanation follows. This means you should be ready to be shaken, what the author tries to teach you are sometimes things you have to think about twice (at least I had this feeling).

The book is plit in two parts, theory and pratice. The first one is the longest, with 4 chapters, still the second has more chapters, with 10 ones.

Content and opinions

So the first part is about theory. A lot of things make sense, and even if you didn’t read the book, you should know them. Acceleration is about how you can do things faster. Well, it’s not much about developing than setting up you work environment (search utilities, shells, …) so that you can access things faster. Focus is about maintaining focus during development. Less distractions so that you can keep be focused (you need 15 minutes until you achive maximum productivity, so if you’re interrupted every 5 minutes, it’s cumbersome), more space on your desktop with several monitors or virtual desktops (the book gives links to useful tools, like virtual desktops for Windows), … Automation is linked to acceleration, but it is more, it is about doing the same thing several times. Different tools (bash, ruby, …) are used in different examples. What I mainly remember is that you need to master several different tools. The last chapter is Canonality, or the DRY principle (Don’t Repeat Yourself). There are several cases where you seem to need to have several times the same things (when maintaining UML diagrams, for instance), and then using automation, you can have canonality. This is spreading through several pages, and although it is natural to use automation to achieve canonality, you have to realize it first.

The second part is about practice, and more exactly what tools and processes you should use, based on the author’s experience. It seems to be mainly based on the agile patterns, with a start on test-driven development, and then several topics on software architecture, and they come regularly back in following chapters (a good thing INO). Two chapters are about the old times, one dedicated to what good can be extracted from past experiences, and one dedicated to bad experiences that keep on harming development (mainly people that think they know the truth, without questionning themselves, the so-called angry monkeys). The last two chapters are about using the right language for the application and using the right tool (the IDE in this case) for maximum productivity. This part about the actual ways of being more productive achieves, IMHO, its goal with good impulses for a productive programmer.

Conclusion

A lot of the tools that are presented in the first part are not free or open source, and sometimes there exists alternatives in the free community, so you have to look for them. The secon part tends to look more towards those free tools.

The whole book is definitely about good practices, with some more controversial than others. Some of them are also difficult to apply to any language, as tools for this practice are missing. I think the book describes a good set of practices to try to apply personnally ; at least, I’ve decided to try to and to better use the command-line and my IDEs (also fight angry monkeys).