Passionate Programmer book review
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 B.tech
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.
Update: Also see Top 5 Developer Skills That Will Get You Hired or Promoted