Practice

I recently read Chad Fowler’s The Passionate Programmer, a book broadly concerned with finding fulfillment through work in software development. The book had an unexpectedly strong impact on me. Many of Fowler’s key points aligned uncannily with recent experiences and observations of my own. One section that leapt out in particular to me concerned 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 the real performances. They let the ugliness happen behind closed doors—not when they’re actually working. In the computer industry, it’s common to find developers stretched to their limits. Unfortunately, this is usually a case of a developer being underqualified for the tasks that he or she has undertaken. 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.

! have worked on many teams that actively embraced practice of this sort in the workplace. Such teams celebrate opportunities to stretch far beyond the limits of their core competencies, experimenting with novel frameworks, tooling, and infrastructure solutions on production projects. More teams than ever seem to be disposed to do this today, with fashions in the JavaScript world turning over rapidly, fervor around novel infrastructure solutions like docker and kubernetes, and the simple fact that in many markets demand for development talent is outstripping supply, often leading to more junior team makeup altogether.

In the spirit of the Fowler passage, though, I’ve found that the teams I truly want to work with are those where members are exercising skills honed sharp as those of a working musician in New York. The mechanics should be second nature, like Ahmad Jamal on the piano. You should all be making music together, not racking your brains over the fingering. That’s when the magic happens.

To be clear, I don’t think we should all be working in J2EE – frameworks and tools evolve, and we should keep pace. I do, however, believe that the majority of the team working on a project should already have a strong facility with its tools. When I began working with Rails it was a young stack, but I did not take on contracts or introduce it to teams until I’d had a substantial amount of practice with it.

If people find gratification in practicing on the job and have a team that tolerates it, power to them. To speak for myself – I don’t want to practice on the job, I want to make great music.