Deliberate Practice for Software Developers

I frequently read and hear that software developers must take care to deliver the right solutions. It’s a waste of time, money, and effort to build the wrong thing. Customers aren’t interested in the wrong thing.

It’s true.

But it’s often misunderstood.

The Developers Who Don’t Do Anything

Many developers I’ve met interpret “don’t build the wrong thing” to mean they should literally do nothing at all unless and until “someone” figures out what the right thing is, and then tellsthem to build it.

Of course, they don’t literally do nothing. They play ping-pong, they eat snacks, they chat. They learn to look busy. But in many (most?) cases they don’t take the opportunity to practice their craft .

There’s a problem with that. When the moment comes for them to build the right thing, the developers don’t know how. They have to figure out how to build the right thing under conditions of delivery pressure. Those aren’t the best conditions for learning.

I would observe lack of preparation is a cause of poor quality software. It tends to lead people to copy and paste code from StackOverflow. It tends to result in the Works on My Machine problem. It tends to produce code that falls into the lower left-hand corner of this code quality matrix.

Not My Job

Notice in that link about copying and pasting from StackOverflow, the statement at the top of the fake book cover reads, “Cutting corners to meet arbitrary management deadlines.” Know what that means? It means developers don’t understand the real cause of last-minute delivery problems.

Sure, there are managers who set arbitrary deadlines, but for the most part dates are driven by market considerations and business strategy. They aren’t arbitrary. A more common reason for these issues is that the developers are not prepared to do their work when the time comes. They haven’t practiced.

If you think it’s okay never to practice your craft, and you can just wing it when the pressure is on, then you also think it’s okay to buy a ticket to a concert to hear a band that never practiced the music (or any music) before they went on stage at the concert. You also think it’s okay to live in a house that was framed by people who never touched a hammer before the first day of construction. You also think it’s okay to be operated on by a surgeon who never cut anything until it was time to cut your belly open. You also think it’s okay for your kids to be taken to school by a bus driver who is sitting behind the wheel of a vehicle for the very first time.

Clients and employers don’t want to pay us to figure out how to do our jobs. They expect us to know how to do our jobs already. That means during the “in between times” we need to invest some of our time and effort into keeping our skills sharp.

Deliberate Practice

A colleague of mine at LeadingAgile, Rick Austin, recommended the book Peak: Secrets from the new science of expertise. The authors describe research into the ways people develop stong expertise in a variety of fields. Key findings are that mindful practice or deliberate practice accelerates and enhances the development of skill, and that setting stepwise, short-term goals helps us direct our efforts.

Those points reminded me of a blog post dating from 2012 entitled, Why should we do code katas?. Practicing our craft as software developers means setting a short-term learning goal and then practicing mindfully – with deliberate attention to detail – over and over agin. Not mindless repetition – mindful practice, with a specific goal in mind and with close attention to detail.

Many developers tell me they don’t want to spend all their spare time writing code. If that’s their excuse not to practice their craft, I suppose it means we are faced with exactly two choices: Spend 100% of your spare time writing code, or spend 0% of your time writing code.

But here’s a little secret: You can spend more than 0% and less than 100% of your time investing in your own career. If you practice mindfully and deliberately, you won’t need to spend nearly as much time as you will if you practice “randomly.”

How to Do It

Think of something you’d like to get better at. Set a goal. A small one. Something you can achieve in an hour.

What if you’d like to become more proficient at refactoring? Set a goal like: “Use Extract Method to remediate a Long Method code smell.” Then find some code that offers an opportunity to practice doing that, like the Gilded Rose refactoring kata. Then, practice a specific sequence of refactorings again and again until it becomes second-nature to you. If one hour isn’t sufficient for that, then do it again another day. When you feel confident in the skill, find another chunk of code and repeat the exercise.

What if you’d like to become more proficient at functional style programming in Java? Set a goal like: “Convert a loop into the equivalent functional-style code.” Look for or write some code that can support that goal. Here’s an article about Java 8 idioms. Consider the examples under the subheading, “The power of function composition.” You could convert that code snippet manually, over and over again, without referring to the solution after the first attempt. Repeat for an hour. If that doesn’t make it second-nature, then do it again another day. Pick another example that’s somewhat different, and practice converting it.

You don’t have to learn everything in one day. You don’t have to get it right the first day. You don’t have to spend 100% of your spare time doing this. The keys are to set small goals and then practice mindfully and deliberately. Over time, you’ll become proficient with any skill.