Jon McCaffrey's review of The Passionate Programmer by Chad Fowler motivated me to read it myself. I used to read lots of books like these, but over the past six or seven years, I’ve buried myself so deep in graphics that I've read very little general development books. It’s time to change that.
The Passionate Programmer is well worth a read. At about 200 pages, it is short, readable, and inspiring. It contains 53 bitesize chapters on being productive, marketing yourself, staying sharp, etc. I agree with the vast majority of the book's advice. It is a particularly great read for students and new developers; it will get them in the proper mindset to be awesome developers as Chad would say. If you are more experienced, you are probably already doing many things in this book; if not, you should consider them.
One of my favor chapters is 4. Be the Worst, which suggests surrounding yourself with the best developers you can, because doing so makes you grow faster and perform better. I couldn't agree more!
You would think that 14. Be a Mentor contradicts the advice of being the worst, but it does not. It is important to be a mentor to new developers because teaching is one of the best ways to learn. Do I really know how the automated build and test system works? I will once I try to explain it to someone.
Being a mentor also helps a team gel and integrate new developers quickly. If there is one thing our industry needs to get better at, it is mentoring. Electricians, plumbers, and tattoo artists do apprenticeships. Software developers do not. How often do we sit down with the experts in our development teams and learn from them? Probably never, or not often enough at best.
In 28. Eight-Hour Burn, Chad argues to only work eight-hour days but work with the utmost intensity. Working longer days leads to burning out, wasting time, and less overall long-term productivity. I agree; however, I am a hypocrite. Given my outside writing and teaching activities, I am consistently over 70 hours a week, and sometimes much higher. The only justification I have is writing and teaching are different enough from developing that the burn out isn’t as severe. I know I can't maintain this pace forever though.
Perhaps 39. Let Your Voice Be Heard is my favorite piece of advice. Chad suggests thinking beyond your current employer and contributing to the industry as a whole, first with a weblog (I don't know why he didn't just say blog), and eventually through publications and presentations. I really like this advice because there are a lot of sharp people in our field, and it is great to have everyone share ideas.
I don't think any advice in the book is terrible, but some needs to be put into perspective. For example, in 27. Learn to Love Maintenance, it is argued that maintenance development can allow for freedom, creativity, and direct-customer interaction. For old, large applications, this isn't always true. If you are working on a twenty-year old, multi-million line application that has seen the hands of hundreds of developers at various stages in their careers, maintenance is often a test of patience. For example, do we really want to continue to design legacy APIs using COM? Is making our code const correct easy when all the code we call is not? Do we really want to integrate old code using a struct for vectors with new code using a class? No. we want to build our skills using modern technology and techniques.
I advise interns and new grads to get in on the ground floor of a new project. They will be given the best opportunity and most responsibly. They will see the big picture, and will accelerate their skills faster than being bogged down by long build-times, legacy code, and legacy mistakes. The contractor who built the house learned much more than the contractor who remodeled the bathroom. With all this said, if you get an opportunity to work on a large, outstanding piece of software - say the Linux kernel, for example - you should go for it.
One final comment: this book is a revised edition of the book My Job Went to India: 52 Ways to Save Your Job. Naming a book is really important, just like naming software, classes, functions, variables, etc. With the original title, I would not have paid this book any attention. The revised title – and I assume content – made it really appealing. Naming is hard.
Overall, The Passionate Programmer is an inspiring, worthwhile read.