Deliberate Practice for Programmers

How do you apply it then? The question bugged me since the first chapter of Peak: Secrets from the New Science of Expertise. For the past year, I’ve been looking for an answer, experimenting with the deliberate practice technique as outlined in the book in different domains, from writing and programming to public speaking.

Repeating tasks at your comfort level takes your skills no further. A lack of feedback guides you nowhere. That’s conventional practice.

Upon discovering “deliberate practice” and having perused dozens of research articles on expert performance, I was convinced that the deliberate approach was the best one out there. Let me convince you, too. This story — among several — is a summary of how I applied deliberate practice to my self-teaching programming journey.

But first, here are some reasons people point out when arguing against applying deliberate practice in learning to program.

1. No mentor for feedback.
2. Programming (technology in general) is a baby domain.
3. No curriculum, so it’s challenging to craft SMART goals.
4. An unclear definition of “practice”.

The following are anecdotal solutions for each point.

1. No mentor for feedback. Reach out to more experienced self-taught programmers. Follow their footprints: the projects they worked on, the progressions they took. For feedback, write out code from memory AND compare it with the original source. It can be an open-sourced project that you aspire to build, or an ideal solution to a programming question, If your logic deviates from the author’s, mark it wrong and test your understanding by explaining it in written words. (Again, more writing). It is through this type of comparison and repetition that you observe your weakness and strengthen it.
2. Programming is a newborn domain that’s only a few decades old. Whereas we’re not adding a new key to the piano anytime soon (classical piano is one of the few domains on which expertise research is based), technology is a constantly evolving field. But this is what drives innovation. And the best way towards innovation is to learn AND consolidate AND apply an array of topics in real life. This is where deliberate practice shines — it goes beyond conventional practice and can help you achieve what most people can’t.
3. No crucciulun, no SMART goals. “Understand OOP” is NOT a SMART goal. Change it to: “Apply OOP in this x project.” By building a project, you’re prompted to look for resources that highlight the necessary concepts. Extend it with: “… by following these y and z projects/tutorials. ” Be careful though, a common beginner mistake is to follow along in its entirety a crash course or textbook that introduces one new concept after another. A more time-efficient approach: learn and drill out the concepts necessary for the goal project; disregard everything else. A final extension: “… after which I’ll consolidate the concepts by rewriting and applying.”
4. What even is “practice” in programming? Take these two scenarios. Coding along with a tutorial vs. Writing out a project and comparing it against the original code. One is learning something new; the other is practice/consolidation. What we need is a balance of both — with a spice of experimentation. The first case can lead to tutorial hell. The second follows the principle of consolidation over novelty. A better alternative to chasing one tutorial after another is honing in on the core concepts from a few good projects. Consolidate those concepts by rewriting. Apply them in personal projects to further consolidate.

So, how exactly do you consolidate the code from a project?

Simple. Write down code from memory. I prefer pen and paper over typing. (Of course, there are other uses for typing out code, too.)

Emulate what Benjamin Franklin did with his writing practice.

1. Craft hinted pseudo-code from the most significant code snippets.
2. After writing, compare your code with the author. Observe your mistakes and correct them.
3. Write more often the snippets that you struggle with the most.

This is feedback.

This is the missing piece of the puzzle for many self-taught aspiring programmers.

This is crucial.

As a self-teaching programmer, coming up with a deliberate practice routine is a challenging task in itself. A lack of guidance, the ever-changing nature of tech, and a lack of understanding of what practice really is — no wonder the majority of beginner programmers quit before realizing their full potential.

But I believe deliberate practice, strategically coupled with other principles and habits, is the way.