The Passionate Programmer - by Chad Fowler

ISBN: 1934356344
Date read: 2012-01-15
How strongly I recommend it: 7/10
(See my list of 360+ books, for more.)

Go to the Amazon page for details and reviews.

Wonderful book about the art, craft, and passion of being a great computer programmer. Loved the analogies to being a musician: sight-reading, being the worst member of the band, understanding new styles of music, practicing just for improvement, etc.

my notes

The stuff you read in this book? Act on It!

Always try to be the worst musician in the band.
Find a “be the worst” situation for yourself.

The addition of Smalltalk to the requirements list yielded a candidate pool that was tiny in contrast to our previous list. These people were diamonds in the rough. They loved to program!

People say, “I haven’t been given the opportunity to work on that”
Given the opportunity? Neither was I! I took the opportunity to learn.

Ask old-timers to review your code and make suggestions that would make it more idiomatically correct.

Try a small project, twice. Try it once in your home base technology and then once, as idiomatically as possible, in a competing technology.

Programming: I was addicted, but in a good way. My drive to create had been ignited in much the same way that it had when I started writing classical music or playing improvisational jazz. I was obsessed with learning anything and everything I could. I wasn’t in this for a new career. In fact, many of my musician friends thought of it as an irresponsible distraction from my actual career. I was in it because I couldn’t not be.

This was the difference between me and my overeducated, underperforming colleagues at work. Passion.

The greats in various fields, this same pattern of addictive, passionate behavior surfaces. Jazz saxophone great John Coltrane reportedly practiced so much that his lips would bleed.

Letting the (automated) wizards have their way leaves your knowledge shallow and leaves you limited to what the wizards can already do for you.

One body of knowledge is neither technical nor domain-specific and won’t be outdated at any time soon: the basics of business finance.

A mentor is someone you can trust enough to ask, “What should be different about me as a professional?”

Not only do you create a personal attachment and responsibility to your mentor, but the reverse happens as well. If my role in a relationship is to help someone, I become invested in that person’s success.

Nobody has to explicitly ask someone to be their mentor.

Your mentor may not even know they are serving that role for you.

Think of the person in your field whom you admire most.
List the ten most important attributes of this role model.
Choose the attributes that are the reason why you have chosen this person to be your role model.
Rank those qualities in order of importance.
You have now created and distilled a list of attributes that you find admirable and important.
These are the ways in which you should strive to emulate your chosen role model.

For each item on the list, imagine how your role model would rate you on a scale of 1 to 10
Subtract your rating in each row from the importance level you gave it.
That gives you a final priority score

Martin Fowler said that whenever he wants to really learn about something, he writes about it.

To really learn something, try teaching it to someone else. There’s no better way to crystallize your understanding of something than to force yourself to express it to someone else so that they can understand it.

We internally work through the reasons why one analogy seems to work but doesn’t and another analogy would seem not to work but does. When you teach, you have to answer questions that may have never occurred to you.

Helping someone is a job you can’t be laid off from.

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.

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.

I started experimenting with programming exercises modeled after my musical practice sessions.
Rule number one was that the software I was developing couldn’t be something I wanted to use.
I didn’t want to cut corners, rushing to an end goal.
So, I wrote software that wasn’t useful.
I cut no corners but was frustrated to find that a lot of the ideas I had while practicing weren’t working.
Though I was trying to do as good a job as possible, the designs and code I was creating weren’t as elegant as I had hoped they’d be.
Looking back on it now, I see that the awkward feeling I got from these experiences was a good sign.
My code wasn’t completely devoid of brilliant moments. But I was stretching my mental muscles and building my coding chops.

Practice at your limits.

Are there dusty corners of your primary programming language that you rarely visit?
- Regular expressions are extremely powerful and tragically underutilized.
- Multithreaded programming
- stream libraries
- network programming APIs
- utilities available for dealing with collections or lists?

Got any favorite pieces of open source software? How about trying to add a feature?
Go look at the to-do list for a piece of software you’d like to practice with, and give yourself a constrained amount of time to implement the new feature.

Sight reading:
download the source code for the software, and start exploring.
How do you know where to look?
What tricks do you use to find your way around a significant body of code?

This is an exercise you can practice often and in short periods of time. You don’t actually have to implement the feature. Just use it as a starting point. The real goal is to understand what you’re looking at as quickly as possible. Be sure to vary the software you work with. Try different types of software in different styles and languages. Take note of issues that make it easier or harder for you to find your way around.
What patterns are you developing that help you work through the code?
What virtual bread crumbs do you leave for yourself to help you navigate as you move up and down the call stack of a complex piece of functionality?

A great way to sharpen the mind and improve your improvisational coding skills is to practice with self-imposed constraints.
Pick a simple program, and try to write it with these constraints.
My favorite exercise is to write a program that prints the lyrics to the tired old song “99 Bottles of Beer on the Wall.“
How could you write such a program without doing any variable assignments?

How fast can you code this program?
How about practicing small, difficult problems with a timer?

TopCoder - TopCoder.com offers a practice room with a large collection of practice problems

Code Kata, which are small, thought-provoking exercises that programmers can do in the language of their choice. Each kata emphasizes a specific technique or thought process, providing a concrete flexing of one’s mental muscles. Work through all twenty-one kata.

Listening to music, therefore, is not a passive activity for a jazz musician. It is study. Furthermore, the ability to understand what you’re hearing is a skill that you develop over time.

Studying the work of masters is an essential part of becoming a master.

How do others strategically use variable, function, and structure naming?

There is no hidden source code for a painting or a piece of music. If you can hear the music or see the piece of art, you can learn from it.

As you look at this code with a critical eye, you will start to develop your own tastes, just as you would for music, art, or literature. Various styles and devices will amuse you, amaze you, anger you, and (I hope) challenge you.

You will learn more about what already exists.

Pick a project, and read it like a book.
Make notes. Outline the good and the bad.
Write a critique, and publish it.
Find at least one trick or pattern that you can use from it.
Find at least one bad thing that you observed that you will add to your “What not to do” checklist.

“Work expands so as to fill the time available for its completion.”

The sad thing is that even when you don’t want it to be this way, you can fall into the trap, especially when there are tasks you don’t really want to do.
In the case of a weekend coding race, you don’t have time to put tasks off, so you don’t.
You can’t delay making a decision, so you don’t.
You can’t avoid the boring work, and you know that you have to do it so quickly that nothing can get too boring.

A sense of urgency, even if manufactured, is enough to easily double or triple your productivity. Try it, and you’ll see. You can do it faster. You can do it now. You can get it done instead of talking about getting it done. If you treat your projects like a race, you’ll get to the end a lot faster.

He had this uncanny ability to predict what you were going to ask him to do and do it before you thought of it. It was like magic. He was only doing things that I had already said I wanted. I had just said them in ways that were subtle enough that even I didn’t realize I had said them.

Mind reading not only applies to your managers but also to your customers. If they’re giving you the right cues, you might be able to add features that they’re either going to ask for or would have asked for if they had realized they were possible.

Start making some notes about what you think your users and managers are going to ask for. Be creative. Try to see the system from their points of view.

Keeping your mind focused on the present will get you further toward your goals than keeping your mind focused on the goal.

If you’re always walking around with your head in the clouds, You’ll always be waiting for the big one while ignoring the little things that happen every day.

What if you tried to do the boring stuff perfectly?

The more successful you are, the more likely you are to make a fatal mistake. When you’ve got everything going for you, you’re less likely to question your own judgment. When the way you’ve always done it has always worked, you’re less likely to recognize a new way that might work better.

Software developers are typically creative, freedom-loving people.

Martin renamed forty-hour workweek to “eight-hour burn.” The idea is that you should work so relentlessly that there is no way that you could continue longer than eight hours. When you have too much time to work, your work time reduces significantly in perceived value. If you have seventy hours available, each hour is less precious to you than when you have forty hours available. Eight-hour burn places a constraint on you and gives you a strategy for dealing with that constraint. You get to work and think, I’ve only got eight hours! Go, go, go!

If you work intensely every day, you’ll find that the work doesn’t follow you home. Not only are you deliberately stopping yourself from working after-hours, but your mind will actually allow you to stop working after-hours.

Every wrong note is at most one step away from a right one. What makes improvisations bad is when the improviser doesn’t know what to do when the wrong note pops out.

“I don’t know” is not a phrase for the insecure.

Heroes never panic.

Chris would actually plan down to how he was going to use the fifteen minutes between classes to fit in practice routines that could be done quickly.

You should read good code.

You have to actively copy, widely and unashamedly. This applies to a lot of things, of course. Hunter S. Thompson didn’t just read good books; he typed out Hemingway and Fitzgerald.

Copying builds muscle memory. You get a feel for the nuance and form of the original - the kind of detail that’s lost in a quick scan.

Don’t let yourself just be the best in the bunch. Be the person and do the things that people can’t not talk about.

He was just a high-school kid. But, he was already playing gigs, substituting for Little Rock’s most respected jazz pianists. Chris was pretty good - especially for his age - but he wasn’t that good. It didn’t take me long to understand what was happening. When the band we were watching took a set break, Chris would break mid-sentence and just walk away from me to go talk to the band members. He was pushy as hell and would always ask if he could sit in with the band, no matter how inappropriate it seemed to me. He would also ask the musicians for lessons, which meant that he would go to their houses, listen to music, and chat about jazz improvisation with them.

I’ve seen the same pattern in people I’ve met in classical music, the American Tibetan Buddhist community, software development.

Really good people won’t mind if you want to know them. People like to be appreciated, and they like to talk about the topics they are passionate about. The fact that they are the professional or the guru or the leader or the renowned author doesn’t change that they’re human and like to interact with other humans.

The gurus are the supernodes in the social and professional network. All it takes to make the connection is a little less humility.

Carve out weekly time to investigate the bleeding edge.

Research new technologies and to start to develop skills in them. Do hands-on work with these new technologies.

Watch the alpha geeks.

Rigid values make you fragile.

The big problems I have successfully solved in my life. The secret is to focus on making whatever it is you’re trying to improve better today than it was yesterday. That’s it. It’s easy.