Review: The Passionate Programmer
The Passionate Programmer: Creating a Remarkable Career in Software Development
by Chad Fowler
Publisher: The Pragmatic Bookshelf
I received a gift card to Border’s for Christmas and was perusing their voluminous computer section when I saw Chad Fowler’s The Passionate Programmer: Creating a Remarkable Career in Software Development. The cover of the book features a stylized rendition of a saxophone and immediately drew my attention. The fact that it was part of the Pragmatic series helped as well; I already have purchased The Pragmatic Programmer: From Journey To Master and Textmate: Power Editing for the Mac and thoroughly enjoyed both of them.
The saxophone on the cover is a reference to the fact that the author was a professional jazz saxophonist before becoming a software developer; this drastic switch in careers leads to some new insights I had never fully considered before. Before getting to an example of that, I’d like to talk a little about the structure.
This book is actually the second edition of what was originally called “My Job Went to India: 52 Ways to Save Your Job”, and it keeps the same format as the original: each chapter is numbered and presents a single focused idea for differentiating yourself as a software developer and to have a successful career. The book is divided into five large sections:
- Choosing Your Market (deciding what technologies you should specialize in)
- Investing in Your Product (how to gain real expertise with your technology of choice)
- Executing (combatting apathy, productivity ideas)
- Marketing… Not Just for Suits (hits on the fact that you can be the best coder in the world but if no one but you knows it, you’re not doing yourself any favors)
- Maintaining Your Edge (don’t get complacent; technology is incredibly fast-paced and you must keep up to date if you wish to remain relevant)
While a lot of the advice is similar to what you can find online for free, they are stated in ways I have never read before and truly made me think. For instance, the chapter “Practice, Practice, Practice” draws on his experience as a jazz musician. Here is a choice excerpt:
When you practice music, it shouldn’t sound good. If you always sound good during practice sessions, it means you’re not stretching your limits. That’s what practice is for…
Our industry tends to practice on the job. Can you imagine a professional musician getting onstage and replicating the gibberish from my university’s practice rooms? It wouldn’t be tolerated. Musicians are paid to perform in public—not to practice… If we’re going to try to compete based on quality, we have to stop treating our jobs as a practice session. We have to invest the time in our craft.
With that interesting lead in, he suggests some ways to meaningfully practice software development, while maintaining the metaphor of musicianship:
- Learn the core APIs and function libraries of your language of choice (roughly equivalent to gaining muscle memory with scales etc.)
- Code for an open source project, as well as reading the same (~ sight reading practice)
- Practice programming with self-imposed constraints, e.g. finding some problem like 99 Bottles of Beer on the Wall and implementing it in as few lines of code and as quickly as possible in your given language (~ improvisation)
This book was a very entertaining, useful, knowledge-rich book, and has my highest recommendation.