Achieving Peak Performance in Competitive Programming

Peak

Last week, I wrote about the concept of mental representations, an important topic in Peak by Anders Ericsson and Robert Pool. According to the authors, learners seeking expertise should have as their goal a virtuous cycle between mental representations and deliberate practice: Deliberate practice should produce more effective mental representations, and more effective mental representations should drive better practice.

This week I’ll be covering the other half of that virtuous cycle, deliberate practice.

Three Types of Practice

Ericsson and Pool define three types of practice. From least to most effective, they are:

Naïve practice

Naïve practice is simply practice. If you’re learning tennis, naïve practice is playing tennis games. If you’re a software developer, it means coding and testing and otherwise doing your job. If you’re studying competitive programming, it means solving puzzles.

There’s nothing wrong with naïve practice for some goals. You can have fun with friends playing tennis. You can earn a living at a programming job. And you can get somewhat better at competitive programming just by solving practice problems.

But the inevitable result of naïve practice is the OK plateau, where you’re good enough at what you’re doing, but you’re not getting any better. You’re good enough at tennis that you can enjoy the game. You’re good enough at programming that you can get hired and keep your job. You’re good enough at competitive programming that you can enter contests and have fun.

If you’re not happy with just being good enough, you need a better type of practice.

Purposeful practice

Purposeful practice is hard. Consider what you need for effective purposeful practice:

  • Clear and specific goals, both short-term and long-term, so you know what you’re working towards.
  • An actionable plan to reach those goals, so it’s clear what you need to work on during each practice session.
  • Complete focus during your practice sessions, so you can critically observe your performance. Getting in the zone, or into a state of flow, is not the goal.
  • Feedback about specific aspects of your performance, from your own observations or from someone else observing you. This feedback provides things to work on, which you can use to update your training plan.
  • Practicing at the limit of your current ability. If your practice is too easy, you won’t get any better. The goal is to get out of your comfort zone.

That’s a challenging list. It takes significant effort to design a training plan that covers all of those requirements. But it’s still not deliberate practice as defined by Ericsson.

Deliberate Practice

According to Peak, what mainly distinguishes deliberate practice from purposeful practice is the source of the training plan. Purposeful practice works for any skill, and with any plan that meets the criteria above. Deliberate practice is only possible when someone else has gone before you and blazed a trail. You need an expert who has proven that there’s a way to get where you want to go. Then you use that expert’s methods, combined with purposeful practice techniques, to reach the same destination.

Some activities lend themselves to this strict definition of deliberate practice. Music, chess, ballet, and some sports have a long history of instruction to draw from. Peak uses the term highly-developed fields for these types of activities. There’s a lot of competition in these fields, which drives improvement. They have a well-defined and proven practice methodology. And they use objective measurements, which makes it easy to identify the most skilled practitioners.

In contrast, it’s more difficult to apply deliberate practice techniques to other activities. For example, in knowledge work (e.g., software development), there isn’t a long history of practice. Once out of college, most knowledge workers focus on doing their jobs, not practicing job skills. And knowledge worker performance is notoriously difficult to measure objectively.

Deliberate Practice for Competitive Programming

While it may be difficult to apply deliberate practice techniques to software development in general, what if we targeted specific software development skills? As I have written before, I believe that most software developers could benefit from practicing their coding skills. One way to practice coding skills is through solving competitive programming questions. It’s not the only way, but there are a number of reasons to prefer it over other options.

Chapter 4 of Peak includes a list of the characteristics of deliberate practice. Let’s see how they match up with competitive programming practice.

Skill type

DP: To use deliberate practice to get better at a skill, someone else must have already mastered the skill and invented effective training techniques for it.

CP: Competitive programming contests have been taking place as early as 1970. Since then, thousands of programmers have participated in contests, and a smaller number have demonstrated mastery of the sport. Two books, Competitive Programming and Programming Challenges, have been written to advise future competitive programming experts.

Teachers and coaches

DP: Deliberate practice requires a teacher or coach who is familiar with the state of the art in practice techniques, and who designs a training plan specifically for each student. Peak emphasizes the importance of private lessons for serious students in any field.

CP: Colleges with serious competitive programming teams have coaches who advise students on how to practice. That’s less common for post-college competitive programmers, but it is still a popular question.

Getting out of your comfort zone

DP: Chapter 2 of Peak explains the power of the adaptability of human minds and bodies. The idea is that pushing the body or mind slightly past its current limits forces it to adapt and get stronger. This is the basis of mental and physical training.

CP: Collections of competitive programming puzzles, like those on uHunt, are often arranged by topic and difficulty. This provides a convenient way to ensure that you’re always pushing your limits by working on problems that cover new topics, or harder problems on topics that you already know about.

Goals

DP: Deliberate practice requires well-defined goals that students can use to focus their training on their way to a long-term goal.

CP: Competitive programming practice is full of intermediate goals. Students learn aspects of a programming language, algorithms and techniques, and the mindset required to solve problems quickly. Eventually these combine to create the ability to solve many of the problems that come up during contests.

Concentration

DP: Using deliberate practice effectively requires fully concentrating on practice. It isn’t enough just to do the work.

CP: Timed programming problems are one way to practice concentration. You can’t let your mind wander when you’re racing against the clock.

Feedback

DP: An essential part of the deliberate practice process is getting feedback about how your practice is working and what you can improve. This is one way to avoid getting stuck on a training plateau.

CP: Competitive programming naturally provides some feedback in the form of compiler output, program output, and results from an online judge. But it’s also important to observe your own practice. Part of my goal in splitting my problem-solving process into well-defined steps is to encourage reflection at the end of each step.

Mental Representations

DP: Mental representations help improve the effectiveness of deliberate practice, and deliberate practice helps improve the quality of mental representations.

CP: Last week, I wrote about the areas in which competitive programmers need good mental representations.

Fundamentals

DP: Deliberate practice works best when you start by learning the fundamentals, and then gradually build on them.

CP: The process of learning competitive programming involves building more complex skills on simpler skills: first a programming language, then basic algorithms and easier problems, then more advanced algorithms and harder problems.

Deliberate Practice for Software Developers

I first wrote about deliberate practice for software developers at the beginning of last year, when I was starting this blog. That post was structured around five elements of deliberate practice as identified by Geoff Colvin in Talent is Overrated. That book, published in 2008, drew from Ericsson’s 1993 paper on deliberate practice. Eight years later, it’s good to have a detailed exposition on the topic from Ericsson himself, including a response to the now somewhat infamous 10,000-hour rule.

On Quora, the most frequent question in the Competitive Programming topic is some variation of, “How do I get started/get better at competitive programming.” And the most popular answer to that is some variation of, “Practice, practice, practice.” But that answer is somewhat misleading. Naïve practice (find an easy problem, solve it, and go from there) can get you started, but it’s not a long-term strategy for success. Effective practice requires more planning.

(Image credit: solarisgirl)