The last two weeks where great! It was a rare period in my life where I was actually unemployed. Alas, I slept even less hours then I normally do. One of the highlights of this period is the hike to the top of Half Dome in the Yosemite. Considering the fact that most of my physical exercise in the last few years was moving around a laptop, its not half as hard as I expected. More details and pictures on the smiteam blog.
The book of this week is The Pragmatic Programmer. In my opinion every programmer should read it at least once, preferably once a year.
Like the Design Patterns book and the Worse is better article, It is one of the classics that will be relevant for decades to come. Though we are still being hit by waves of "programming without coding" prophecies, I do believe that the essence of the book will be relevant for long time.
The things I found most appealing in the book where:
- Use Tracer Bullets to Find the Target: I like tracer bullets a lot. At night, in real life combat when chaos is all around, communication is blocked, and all the nice high-tech toys we had stopped working it was the only way we could see what we're doing and communicate it to the rest of the team. You can see similar things in rapid development projects where you enter a new territory.
- Don't Live with Broken Windows: Fix bad designs, wrong decisions, and poor code when you see them.
- Be a Catalyst for Change: You can't force change on people. Instead, show them how the future might be and help them participate in creating it.
- Remember the Big Picture: Don't get so engrossed in the details that you forget to check what's happening around you.
- Invest Regularly in Your Knowledge Portfolio: I usually refer to it as "Sharpening The Saw", that fable from the 7 Habits of Highly Effective People won me over.
- Critically Analyze What You Read and Hear: Don't be swayed by vendors, media hype, or dogma. This one is not that easy.
- DRY–Don't Repeat Yourself: copy-paste is the root of all evil.
- Keep Knowledge in Plain Text: I have some problems with this once since I'm a fan of GTD softwares, WIKIs, and MindMaps.
- Design to Test: Start thinking about testing before you write a line of code.