Deliberate Practice in Programming

2011/11/16 · by · in Self

The easiest way to improve your working habits and skillset is by deliberately practicing. For example, according to The role of deliberate practice in the acquisition of expert performance (1993, Psychological Review) what separates elite players from average players is (a) the regularity of practicing in your daily schedule and (b) the skills/techniques that your practice exercises. This held true even though both groups in the study practiced an equal number of hours during each day.

How can we apply this to programming?

Specific Resources you can use.

  • The Algorithm Design Manual, by Skiena
  • Effective C++, by Scott Meyers
  • 97 Things Every Programmer Should Know, by O’Reilly Publishing too abstract, not enough meat.
  • LeetCode
  • Introduction to Algorithms, CLRS
  • TopCoder

Mary’s talk on InfoQ (above) mentions The Cambridge Handbook of Expertise and Expert Performance, from which we see the following patterns:

  • Design focused exercises to develop specific skills. Like a music teacher creates a drill to practice a technique the student underperforms at.
  • Practice repeatedly (it’s how the brain learns).
  • Obtain immediate feedback (longer time delay => less chance for learning).
  • Focus on pushing limits. You aren’t extending your abilities if you have 100% success.
  • Practice regularly and intensely. Practice everyday, but at a level that you couldn’t sustain for more than 3hrs
  • Systematic improvement consists of 1. mentorship 2. challenge 3. feedback 4. dedication

Moreover, you have to pay close attention to what you are practicing.

  • Peter Norvig: The key [to developing expertise] is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes.
  • Mary Poppendieck: Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it’s not necessarily fun.

One idea this gives me: Build a non-trivial program (simple interpreter, parser-generator, into AI project, into DB project, etc.) in a new unfamiliar language. Learn the idioms of code organization in that language, and how it approaches important design issues such as flow control, error handling/reporting, and code re-use different from the languages you currently limit yourself to.