Passionate Programmer book review

9 minute read

Every once in a while I get an email like this:
Sir, I am a beginner to python and programming. I started with the C++ and found it hard so one day via google I found your perfect tutorial “A byte of Python”. I read the whole tutorial in one day because it is so interesting and helpful. Sir, I have created the script to backup files from directory as you mentioned. Please see the script once and tell me if I have chances in programming career. Sir I am final student and I love programming. But I was rejected by every company during campus placement because of my poor communication skills and due to this my confidence level is very low. Sir I have also created a web based application using PHP, MySQL and Kannel on Debian based server for intra-college communication. Sir, I am regular reader of your blog and I respect what you are doing to help freshers like me. Sir I would like to know if you have any advice for me.
And like this:
I want to thank you about this great book ;-). I am a 20-years-old student in computer science from Bulgaria and i found this book very interesting and helpful. I’ve been programming in python for half a month. I had little experience in C from the university and I wanted to learn a high level language with simple syntax like Python and then learn C++ and start writing useful programs. I send you a solution of the problem in the end of the book that is just a demo version. Can you give me a hint what i got to improve to make the address book program better and give me the source code of your solution? I really want to become a programmer so any advices especially from a man with your knowledge would be highly appreciated! Thanks.
For a long time, I used to scratch my head for every such email because I really didn’t know what advice I have to offer. I did end up writing How Fresh Graduates Can Grow which a lot of students have liked.

In the past couple of years, I have started replying with just one line - I ask them to read The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler. I happily  recommend this book knowing that if they actually do read and apply the principles in this book, they can’t go wrong.

I had read this book in its first edition when it was called My Job Went to India and I read it again when the renamed second edition came out.

The title of the book is self-explanatory but what makes the book special from other regular career books is that it is geared specifically to the art of software programming as well as explaining networking and many soft concepts/human aspects in a for-geeks “53 recipes” style.

Some of my favorite recipes/lessons are:

4. Be the worst

Legendary jazz guitarist Pat Metheny has a stock piece of advice for young musicians, which is “Always be the worst guy in every band you’re in.” Being the worst guy in the band means always playing with people who are better than you. Being the worst guy/gal on the team has the same effect as being the worst guy in the band. You find that you’re unexplainably smarter. You even speak and write more intelligently. Your code and designs get more elegant, and you find that you’re able to solve hard problems with increasingly creative solutions.

6. Don’t listen to your parents

I remember talking to a friend about potentially moving out of this company, and he said, "Is it your destiny to work at $bigcompany for the rest of your life?"Hell no it wasn’t!_ So, I quickly found another job and left. This movement marked the clear beginning of a nonlinear jump in my success in the software industry. I saw new domains, I worked on harder problems, and I was rewarded more heavily than ever before. It was scary at times, but when I decided to be less fear-driven and conservative in my career choice, the shape and tone of my career - my life - changed for the better.

15. Practice, practice, practice

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. The same is true in sports. Athletes push themselves to the limit during workouts so they can expand those limits for real performances. They let the ugliness happen behind closed doors - not when they’re actually working.

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. As an industry, we need to make time for practice.

Practicing may include learning more about your programming environment (APIs, libraries, methodologies, etc.), sight reading (reading new pieces of open source code to improve your ability to read and understand code), improvisation (introduce new constraints in small projects to improve your thinking abilities) and so on. [paraphrased]

32. Say it, Do it, Show it

You should start communicating your plans to your management. The best time to start communicating the plans is after you have executed at least one cycle of the plan. And - this is an important point - start doing it before they ask you to do it. No manager in his or her right mind would be unhappy to receive a succinct weekly e-mail from an employee stating what was accomplished in the past week and what they plan to do in the next. Receiving this kind of regular message unsolicited is a manager’s dream.

Start by communicating week by week. When you’ve gotten comfortable with this process, start working in your thirty, sixty, and ninety-day plans. On the longer views, stick to high-level, impactful progress you plan to make on projects or systems you maintain. Always state these long-term plans as proposals to your manager, and ask for feedback.

The most critical factor to keep in mind with everything that goes onto a plan is that it should always be accounted for later. Every item must be either visibly completed, delayed, removed, or replaced. No items should go unaccounted for. If items show up on a plan and are never mentioned again, people will stop trusting your plans, and the plans and you will counteract the effectiveness of planning. Even if the outcome is bad, you should communicate it as such. We all make mistakes. The way to differentiate yourself is to address your mistakes or inabilities publicly and ask for help resolving them. Consistently tracing tasks on a plan will create the deserved impression that no important work is getting lost in the mix.

43. Making the Hang

Speaking for myself (and extrapolating from there), the most serious barrier between us mortals and the people we admire is our own fear. Associating with smart, well-connected people who can teach you things or help you find work is possibly the best way to improve yourself, but a lot of us are afraid to try. Being part of a tight-knit professional community is how musicians, artists, and other craftspeople have stayed strong and evolved their respective artforms for years. The gurus are the supernodes in the social and professional network. All it takes to make the connection is a little less humility. Of course, you don’t want to just randomly start babbling at these people. You’ll obviously want to seek out the ones with which you have something in common. Perhaps you read an article that someone wrote that was influential. You could show them work you’ve done as a result and get their input. Or, maybe you’ve created a software interface to a system that someone created. That’s a great and legitimate way to make the connection with someone.

44. Already Obsolete

You have to start by realizing that even if you’re on the bleeding edge of today’s wave, you’re already probably behind on the next one. Timing being everything, start thinking ahead with your study. What will be possible in two years that isn’t possible now? What if disk space were so cheap it was practically free? What if processors were two times faster? What would we not have to worry about optimizing for? How might these advances change what’s going to hit? Yes, it’s a bit of a gamble. But, it’s a game that you will definitely lose if you don’t play. The worst case is that you’ve learned something enriching that isn’t directly applicable to your job in two years. So, you’re still better off looking ahead and taking a gamble like this. The best case is that you remain ahead of the curve and can continue to be an expert in leading-edge technologies. Looking ahead and being explicit about your skill development can mean the difference between being blind or visionary.
P.S. This lesson was the reason why I started admiring DHH even more after seeing he is not afraid to include CoffeeScript and SCSS in Rails 3.1

51. Avoid Waterfall Career Planning

The important thing to realize is that change is not only possible in your career but necessary. As a software developer, you would never want to pour yourself into developing something your client doesn’t want. Agile methodologies help prevent you from doing so. The same is true of your career. Set big goals, but make constant corrections along the way. Learn from the experience, and change the goals as you go. Ultimately, a happy customer is what we all want (especially when, as we plan our careers, we are our own customers) - not a completed requirement.
I probably put more excerpts from the book here than I should, but I wanted to drive home the point on some of the non-obvious-but-critical points that the book raises that every software developer should ponder about.

Go buy the book / ebook now!

Update: Also see Top 5 Developer Skills That Will Get You Hired or Promoted


Prakash Murthy says:

I am around 75% done with the book; it has given quite a bit of new ideas, as well as make me anguish over the many mistakes I have made in my career so far by bringing in a new/outsider's perspective.

Definitely recommend the book highly to anyone working with software in any capacity anywhere in the world.

Akshay says:

I can vouch for this line "Say it, Do it, Show it" I've seen so many initiatives in organization where people are asked to submit ideas and nothing ever comes of it. The lone crusaders or the really innovative teams actually build a prototype or a bare minimal product and then demonstrate it for an approval. These are the only ideas that gather support and the only ones likely to lead to a faster career growth, along with a lot of learning and thrill of doing something different/new.

Swaroop says:

@Prakash Yes, much of the book is the kind of experienced talk that I wish I could have read when I was a fresher.

@Akshay Yes, reminds me of the good ol' Yahoo Blr days. But then again, majority of people won't be able to relate to that, just another case of Sturgeon's Revelation.

The Passionate Programmer « Memories Of My Beautiful Life says:

[...] I picked up this book after reading Swaroop CH’s review. here is the review. [...]