Is programming at work performance or practice?

Lessons learned from Peak: Secrets from the New Science of Expertise applied to software careers.

What does it mean to practice?

For professional software engineers, some would argue that we practice programming every day in our jobs. I’d argue that this isn’t necessarily true but that with some planning, it CAN be. In most cases, it’s more like a performance.

If you’re interested in practice and productivity, chances are you’ve heard of K. Anders Ericsson and his book Peak. Peak is an exploration in the science of getting better at any learned skill (music, sports, singing, programming, etc). He gets at the root of how highly skilled people got to where they are.

In Peak, Ericsson describes a few different types of practice. We’ll take a look at Naive and Deliberate Practice today to see how we can use some of his thoughts to become better programmers using the same amount of hours we currently work.


Naive practice

Ericsson explains that once we reach a level of performance that is adequate for our job or activity, we stop progressing.

In his words:

“Research has shown that, generally speaking, once a person reaches that level of “acceptable” performance and automaticity, the additional years of “practice” don’t lead to improvement.”

(Ericsson, Anders, and Robert Pool. Peak: Secrets from the New Science of Expertise 2017)

Naive practice is “practice” that doesn’t get you anywhere. It can propel you from being an absolute beginner to some level of confidence but the curve flattens out quickly. In essence, it’s a performance. You’re not learning much from the act of doing it, you’re just doing it.

At a certain point of competency, you have to be intentional to break out of this flattened curve. If you don’t you will sit on this plateau indefinitely.

I saw how this played out over someone’s career when I worked in the trades.

I was a maintenance technician for 6 years at a large privately owned gas station company. I worked with 10-15 other technicians to service over 75 locations in our area. We repaired everything from HVAC equipment, to submersible pump equipment, to low voltage security systems, to lighting systems, and much more.

In the trades, one of the worst insults was to be called a part-swapper. We hired a technician with over 20 years of experience who was terrible at troubleshooting. I was 2 years into the field when we hired him. He was a great part-swapper (the equivalent to the expert beginner programmer explained in the daedtech blog) but he wasn’t a great technician.

When he came across issues with an HVAC unit, he’d throw parts at it until it worked. He didn’t REALLY understand how the system works. If you asked him how the refrigeration cycle worked, he could stumble his way to a decent answer with some help.

He had 20 years of experience! Legitimate HVAC repair experience. I would often go behind him after he had updated a work order and found out that he troubleshot the system incorrectly. He cost the company a lot of money in wasted time, equipment downtime, parts, and also a decrease in morale.

How could I troubleshoot better than someone with 10x the experience? Troubleshooting was THE core skill we needed. He may have had 20 years of experience, but it was the first year of experiences repeated 20 times over. He didn’t actively think about how to be better at his craft, he was going through the motions, he was performing. He was participating in naive practice.

In general, I think a lot of programming done at work falls into the Naive Practice bucket. Performing isn’t how you get better. Practice is. As a software engineer, most of our day to day work is more akin to a performance, than practice.


Deliberate Practice

While naive practice is the default for the majority of a programmer’s day, it doesn’t have to be. Deliberate practice can be used instead. What does that mean exactly?

Deliberate practice is being intentional about the work you are doing. In short, with deliberate practice, you should:

  • be in a feedback loop

  • go through some plateaus and spikes in your learning

  • step out of your comfort zone

  • be focused

  • have a goal

With these in mind, how can we rearrange or change our workday to learn faster in the same amount of time?

I’m going to go much more in-depth in future posts, but for now, I’ll give some quick tips on how you can ease into incorporating deliberate practice into your routine.

  1. Be honest with your current skills. Use something like a programmer competency matrix to assess where you are. Choose a few topics you’d like to improve on.

  2. Make note of the 3 or 4 topics you want to improve on first.

  3. Each week/month choose one of the multiple topics to dive deeper on when you come across them. Spend 5-10 minutes in the mornings reading up on them before you dive into your work for the day.

Let’s explore how deliberate practice at work could play out:

John has been a software engineer for a few years and is pretty good at it too! He uses git daily —but when issues deeper than a basic merge conflict come up, his tendency is to just nuke the local repo and pull down from the remote to start over. This is his comfort zone and he’s ready to step out of it.

He decides to spend some time digging deeper into how git works and why he has the same issue with having to nuke his repo every now and then. The next time he has some “weird git issue”, he takes the extra time to figure out a more correct way to resolve it. He reads some git documentation. Maybe he watches a youtube video or two. He writes down what he learns.

John is intentional with learning more git throughout the coming weeks. He learns bits and pieces most days and he slowly starts filling in his knowledge. Over time the picture becomes clearer in his head. He’s a better programmer for it. He’s more productive, and he’s more confident. He no longer has to nuke his local repo anymore.

Soon, John becomes the go-to guy for git knowledge on his team. He’s finally known for something! He’s useful and it didn’t take that much extra work. Just some extra focus.

In this made-up but totally plausible scenario, John worked no extra hours. He spent the same time at work. Ultimately, slowing down and focusing on filling in knowledge gaps deliberately will save him time over the long run.

Do things that compound. Learn skills that will pay you dividends over your career. Start being deliberate with your programming at work.

The real lesson here is that you can use your existing time more effectively and reap great benefits from it.

If you’re interested in more content like this then subscribe now by clicking this button below 👇🏻

If you’d like to read more about deliberate practice, make sure to check out Peak: Secrets from the New Science of Expertise.

I’d love to hear feedback from y’all as well. Feel free to email me at kenneth@deliberatepython.com or leave comments below!