Cal and Scott’s Top Performer Course

Bubble

In an earlier post, I mentioned a pilot course I took a couple of years ago on applying deliberate practice to various types of jobs. Well that original pilot, and a subsequent pilot in 2014, has resulted in a course called Top Performer (not an affiliate link). As part of the homework for the second pilot, I came up with the idea for Project 462 and this blog. So as people are considering the course this week, I thought I would add my thoughts to the mix.

Building a Custom Process

As I suggested in Results Not Guaranteed, it’s tricky for anyone to give you a productivity process that is exactly right for you, unless they’re spending a lot of one-on-one time figuring out your exact needs. Top Performer addresses that problem using a process the authors call “simulated coaching.” The idea is that the next best thing to a personal coach is a set of general principles that you can use to coach yourself. One suggestion from the pilot courses was to interview experts to come up with metrics associated with your career goals. This is a reasonable alternative to personal coaching, but it does rely a lot on which experts you pick and how well you internalize their advice. To increase the chances of success, the course provides interview guidance based on Cal’s experience interviewing people for his books.

Finding individuals and extracting advice from them requires a certain personality, or at least a strong desire for answers. If the ideas in this course take off, maybe people will create custom processes for specialized fields. These could could be used as a starting point for others interested in the same type of work, without the need for everyone in those fields to go through a research process. One of my goals on this blog is to do that for skills like programming language fluency and algorithmic problem solving. I think these areas are both useful for programmers, and amenable to a Top Performer-style improvement process.

Which Skills are Important?

One of the most important parts of the Top Performer process is deciding which skills to work on. Clearly there’s no point in building a great process and following through with it if the skills you end up with won’t get you the results you’re looking for. This is where the advice of a specialized expert is especially important. Someone who has gone through the process you want to emulate can provide their opinion on which skills are the most critical.

Nevertheless, experts can disagree on this point. A common choice that programmers have to make is whether to focus on coding skills or on another area like communication or design. Many programmers end up in a job through some combination of chance and a general idea of what they’re interested in. A goal of Top Performer is to make these decisions less subjective. If a programmer has a long-term goal of rising in the technical ranks within a software development organization, there are some skills that are more likely to lead to that outcome. There’s no guarantee that any particular expert will give you accurate advice about what those skills are, but the Top Performer process tries to make the process more predictable.

Is Any Process Better than No Process?

Here’s an idea: If you want to improve your skills, look for a process and start using it. Don’t worry too much about whether you’re using the right process. When you follow a process, you have to reflect on what you’re doing, as opposed to letting inertia carry you along.

At its most basic level, Top Performer is a process. But unlike most self-improvement processes, it’s a process for creating processes. Since different careers require different processes, the course doesn’t start with a solution that fits everyone. Instead, students build their own processes using process-building guidelines. This puts a lot of responsibility on the students, since they’re building their own curriculum. But if you agree that any process is better than no process, then the risk is low: Thinking about how to build a career mastery process is beneficial on its own. You can then experiment with changes to the process to see what works best.

I think it makes sense to get started, and then adjust and experiment. A corollary is that executing on an average process is better than reading about an ideal one. Scott and Cal address that issue in the course by setting the expectation that each of the modules require at least five hours of active work to complete. Spend any less time, and you’re just browsing. But I did find an interesting variation on this idea deep in the Study Hacks archives. In Dangerous Ideas: Getting Started is Overrated (from 2008), Cal points out a danger of the idea that anything is better than nothing when it comes to self-improvement. The problem is that if you have too much of a bias towards action, you could distract yourself from the single-minded focus on one activity that is necessary to become an expert. So while it may be true that any process is better than no process in one specific area of your life, you also have to procrastinate in most areas to free up time for one or two areas that are most important.

Top Performer starts with a few weeks of research and project design work, to make sure that students think through what they’re getting into. It also emphasizes small, part-time projects, so even if students end up going off in the wrong direction, there’s not a huge cost. And the class’s career focus means that students are likely to pick a project that is at least in the right ballpark. In the pilots, most students already had some experience in the area they were experimenting with.

Here’s a quote from Cal’s 2008 article that could come from the course:

I’ve noticed that people who succeed in an impressive pursuit are those who … [h]ave built an exhaustive understanding of the relevant world, why some succeed and others don’t, and exactly what type of action is required.

Clearly these ideas have been percolating for a while.

Should You Try to Avoid Mistakes?

The Top Performer sales page promotes the idea of using the course information to avoid making the same mistakes that Scott and Cal have as they developed expertise in their fields and coached others. This is a reasonable idea. There’s no need to figure out everything from scratch. But making mistakes is also part of the process of learning. So although the course can help students avoid some general mistakes, each student will likely make many mistakes as they build their custom process. And there’s nothing wrong with that. Like the child who is warned about the hot stove but decides to check for themselves, some lessons are best learned through experience. So it’s unclear how much benefit there is in being steered away from mistakes.

Project 462

A key part of Top Performer is a hands-on project that students design and then use to try out the advice presented in the class lessons. In both of the pilots, my project was related to coding mastery — i.e., getting better at the coding part of a programming job. In the second pilot, I worked on refining the initial version of my programming puzzle practice steps. Here are a few things I found helpful as I was going through that pilot:

  • Pick a small skill, and then focus on an even smaller part of it: The Top Performer course is 8 weeks long, less than the length of a college quarter. And the scope is intended to be much more focused than a college class. The idea is to pick an area that you can measurably improve in just a few weeks. By the end of Week 5, I was using this description for my project:

Create and document a process for writing correct, efficient, and maintainable code for a software component given well-defined requirements.

This type of project is known as a “process improvement project,” where the focus is developing an effective process rather than directly getting better at a skill. Based on my experience in the course, I think an even better project would be improving just one step in that process, like understanding the requirements or writing pseudocode. However, it’s more challenging to isolate that type of skill. More on that shortly.

  • Measure as many results as you can: Top Performer emphasizes measurable results as a way to verify that you’re getting better. But it’s not always clear what to measure. For example, an obvious goal for my coding project is that improvements to the process should result in finding puzzle solutions faster. But I found that although this is a good long-term goal, it is too big to be useful for short-term experiments. Just as it’s helpful to break up a large skill, you can also break a large measurement into its constituent parts. In this case, you could measure things like misunderstood requirements, compiler errors, and functional bugs. Reducing those should have the effect of improving the overall target metric in the long term, but the smaller measurements are easier to track over short time periods.

Marginal Gains

The key idea in both of those lessons is that it’s more effective to make targeted improvements in small areas than to improve a large area all at once. But that doesn’t mean it’s easier. In his article on process improvement, James clear writes: “improving by just 1 percent isn’t notable (and sometimes it isn’t even noticeable).” He uses the example of Dave Brailsford, the British cycling coach who led athletes to Tour de France and Olympic wins by making many 1% improvements in varied areas like nutrition, tire weight, and hand-washing technique.

“You probably won’t find yourself in the Tour de France anytime soon, but the concept of aggregating marginal gains can be useful all the same,” James Clear writes at the end of the article. There are plenty of areas in programming that are amenable to small improvements: practicing the syntax of a language to become more fluent; doing typing practice for special characters; learning the keyboard shortcuts for an editor. Each of these skills can be practiced directly.

Degrees of Freedom

What about skills that aren’t as amenable to direct attack? Scott Young provides an answer in an article he wrote as he finished up his own project in the second pilot course. His suggestion is a technique called reducing degrees of freedom. Some skills are difficult to separate from other skills. So you end up practicing a whole set of skills together when you would rather focus on one. For my programming puzzle process, reading and understanding a problem statement, coming up with a high-level solution, writing pseudocode, writing real code, and testing a solution each require different skills.

Let’s say you decide that what is holding you back is your ability to solve a problem at the pseudocode level. You don’t have much trouble thinking of a high-level solution, and you’re fluent in a programming language syntax, but you get lost in the details during the coding step because your pseudocode doesn’t give you enough guidance.

It’s hard to practice pseudocode in isolation. You can’t run it directly, so you have to convert it into real code if you want to check your work. You could just practice pseudocode as part of solving puzzles, but then you’re only practicing it as much as you’re practicing the other steps in the process. If it really is a bottleneck, it would be more efficient to focus on it specifically.

To address this challenge, Scott recommends going through your practice routine twice. The first time, you run through the entire process as usual. The second time, you only work on the target step (since the other steps are done already). Here’s how that might work for the pseudocode example: Solve a puzzle all the way through, including verifying your solution with an online judge. Then translate your real code (which you now know is correct) back into pseudocode. Finally, compare your translated pseudocode with your original pseudocode to see if there are areas where you could improve. I use that process when I write an editorial for a contest problem. For example, my post on UVa 11572: Unique Snowflakes contains a lot of pseudocode. But it’s not the pseudocode that I wrote while solving the problem. It is based on my accepted solution, so it’s cleaner and more accurate, a better example of the type of pseudocode to strive for when first solving a problem.

Final Thoughts on the Top Performer Course

Top Performer takes the themes that Cal and Scott have been writing about for years, and collects them into a course format. There are modules on deliberate practice, productivity techniques, deep work, and other useful topics. I found the pilot versions of the course to be helpful for designing learning projects. Like any class, what you get out of it depends a lot on what you put into it. The ideas in the course are all top-notch, but deliberate practice is really hard (that’s actually part of the definition). In another article on the second pilot, Scott recommends adjusting your productivity expectations to account for this. That suggestion informs the pacing of the course, which is designed for working professionals. But even with this course as guidance, deliberate practice is still hard. Just less hard than it would be otherwise.

(Image credit: Jeff Kubina)