Programming and Practice

I’ve been thinking about practice lately—and about growth. Here are some thoughts:

Programming is a complicated job. Many people see it as a craft, and as craftsmen, programmers must spend countless hours honing their skills and improving their expertise to reach a level to compete at the level they desire to be at. For example:

• If I want to build web pages at an amateur level, I simply need to know HTML, some CSS, and maybe some jQuery. For every question that might come up, there is usually a hundred answers on Google.
• If I want to do the same thing at an expert level, I must know about usability, cross-browser compatibility, form validation, race-condition debugging, and a host of other things—most importantly, however, I should be able to find answers to problems that are not Google-able.

So if you’re shooting for your “A” game, you need to practice, right?.

But there’s a problem too. If anyone has an issue with repetitiveness, it must be programmers. We have actually been taught that the sole purpose for our job is to reduce repetitiveness. So where does that leave practice and doing things multiple times?

A lot of the programmers I know, who are really good, attribute their success to the fact that they spend hours at home every night building cool stuff or researching—I think the same could be said of artists and writers as well.

This is great, but let’s consider the following quote by Geoffrey Colvin (emphasis added).

For example: Simply hitting a bucket of balls is not deliberate practice, which is why most golfers don’t get better. Hitting an eight-iron 300 times with a goal of leaving the ball within 20 feet of the pin 80 percent of the time, continually observing results and making appropriate adjustments, and doing that for hours every day – that’s deliberate practice.

So let’s make an assumption—perhaps an incorrect one, but bear with me.

Most programmers are not deliberate about what they practice or how they grow. They do not set clear goals, they do not continually measure results, however they are spending the necessary time.

Why are we just like the golfers?—”simply hitting a bucket of balls.”

• Programmers don’t get out enough. In particular with other that practice the same craft.
• It’s still a fairly new craft. Many outsiders (your family, bosses, etc.) still think that we just “know computers” and they come to us for everything relating to computers. To them cleaning viruses and building web-pages are the same thing. So, to cater to their needs, we are often forced to become jacks-of-all-trades.
• The web it too noisy. How do we judge what is important given the thousands of new articles written every day? The best thing we can do is probably unplug from the web and go for a walk.

Here are some possible solutions. Certainly not an exhaustive list, but something to get started with.

• Local user groups. These allow for interaction, they expose people to higher-level talks and foster an environment for learning beyond amateur.
• Set clear learning goals like “I want to understand exactly how Object Oriented CSS works” or “Find out mathematically if database XYZ can scale for a certain use-case”.
• Continually measure results. Progress is important and it might seem daunting that understanding CSS in 13 browsers is a huge task, but every time you check one off, you’ll feel good about it.

And although I don’t follow my own advice fully yet, I’ve determined to move forward with some of my own goals:

• Develop a system for building web UI applications that actually simplifies things.
• Start a user group to empower other developers and designers.
• Build tools that empower people.