A classic for your shelf
As an engineer there are a number of classics you should have on your bookshelf. One of those books is “The Pragmatic Programmer” by Andrew Hunt and David Thomas.
What the book covers
The book is a summary of the insights the authors gained during their careers. With a combined 40 years of experience they managed to fill this book quite well! It is not only about tricks and tools, but also about how you keep developing yourself as a programmer, the mindset a good programmer should have and typical pitfalls you will encounter in every project. The book reads easily and is packed with examples.
Knowledge portfolio
What I enjoyed reading was the part about the “knowledge portfolio” of an engineer.
Your knowledge is your main asset
The most important assets of an engineer are the knowledge, skills and experience he has gained. Because new languages, tools and techniques enter the market at a murderous pace in IT, it is necessary to keep up. If you don’t, you become less and less interesting, or even irrelevant, for your customer.
Manage it like a financial portfolio
Consider everything you know about programming as your “knowledge portfolio”. Manage this portfolio as if it were a financial portfolio.
How do you build a knowledge portfolio?
- Invest regularly, even if it is only a little bit. Make it a habit to continuously gain new knowledge.
- Diversify: you need a base, a certain subject you know a lot about, but don’t stop there. Also invest in other subjects. If one is no longer popular, you are still relevant because of your knowledge of the other.
- Buy low, sell high: investing in an emerging language or technology before it becomes mainstream can pay off.
- Evaluate: because IT is so dynamic, it is good to stand still once in a while and check whether you are still on the right track. Something that was totally hot at the start of the year may not have caught on at all. Then it is time to look for another subject.
Concrete ways to build your portfolio
Some concrete ways to build your portfolio can also be found in the book:
- Learn a new language every year.
- Read a new book every quarter.
- Also read non-technical books. Besides computers you also work with people, be it customers or colleagues. You can also work on yourself. See this book list.
- Follow a course. If you work at a large company you often have a course budget and an internal training institute, but there are plenty of alternatives. Nowadays you can follow a (often free) course via MOOCs.
- Visit a meetup. In every city there are nice weekly meetups for engineers. Between 6 and 9 PM you have an interesting evening, often with a bite and a drink included.
Some nice pieces of wisdom
The book is bursting with wisdom. I will highlight a few of them here.
Don’t live with broken windows
You probably know this phenomenon. A building is closed and after some time a window is thrown in. Now that the first window is broken, a second one follows soon, and then the graffiti. In short, a broken window radiates something that leads to accelerated decay. As if nobody cares about this building anymore. This phenomenon also applies to software: as soon as you find a broken window in the code, you repair or replace it. If you don’t, the code will start to rot.
Abstractions live longer than details
Christer van der Meeren has put this nicely in his review of the book:
Consider a requirement-oriented example: “Employee records should only be visible to their superiors” is not just a requirement; it’s mixed with business rules. “Employee records should only be visible to selected users” is a better requirement. The fact that the privileged users in this case are the employees’ superiors is a business rule which can change at any time. Implement it as metadata instead (e.g. as configuration) – you’ll be glad later on that you didn’t hardcode it into your design. But of course (and this is my opinion), as with the previous tip, abstracting everything just for the sake of it isn’t a great idea.
Conclusion
Since the first edition dates from 1999, some parts are outdated. A lot of what they prescribe has nowadays been included in process and pipeline. Although this is a nice validation of their vision, it comes across as a bit old-fashioned. What stands out is that a lot of the text is still very much of this time, which makes the book worth reading.