Deliberate practiceReading time: 3 mins
What is this idea of deliberate practice and how does it differ from plain old regular-practice?
Sticking to the fundamentals is a common advice that people give out but what is it about those fundamentals that makes us better? The answer seems to revolve around the idea of emergence. Complicated results or answers emerge from simpler questions. Emergence is poorly understood in this fashion because it’s a search problem. You already have to have a large pool or knowledge to search from, after that making connections to the higher-truth becomes much easier. This is analogous to a doctor diagnosing a patient: An immense pool of symptoms to pick from make it easier for her to diagnose what went wrong and link the other symptoms in a story-format to point at a disease. Deliberate practice brings the latter half out and polishes the art of making connections, but to be successful at it there is no substitute around acquiring that vast pool of knowledge may it be disease symptoms or programmatic techniques.
Deliberate practice in programming is the same as deliberate practice in any other field of endeavor, except that programmers have available to them all sorts of feedback to improve their practice, in the form of books, techniques, software patterns, code examples, programming paradigms, blogs and advice from very smart people.
What distinguishes the best from the rest?
They deeply understand the fundamentals, including their programming language of choice and all of the data structures and fundamental algorithms available to them in that programming language. This obvious first step is building that pool, everything from here on out is just searching into it.
They have enough intellectual curiosity to constantly ask themselves “Can this be done better?” and will try different things to see if it can (e.g. optimizing the time, refactoring the fundamental idea in a new way).
They “deep dive.” Average programmers learn a technique; the deliberate practitioners find out what the performance characteristic of that technique are, study the source code if it’s available, and will write their own implementation just to understand it better.
They write code. Lots of it. Ask any musician who performs at a virtuoso level, and they will tell you that they practice at least 4 to 5 hours per day.
K. Anders Ericsson suggests that there are four components of Deliberate Practice:
You can’t focus on a non-trivial project without being really excited about knowing how it works inside out. This also means keeping the number of those projects to a manageable number.
In order to work with active code bases you need to have good understanding of the language/apis/tools that it uses. The same applies to any other project: Think of the project requiring you as an input, along with all the other components that make it complete. You have to interact with all of those components to make sure that you can contribute successfully. If you don’t have a working knowledge of all those tools, first acquire all that background before digging any further.
Immediate informative feedback
The best thing to do when you have an ambitious task is to split it up into smaller and manageable components. This might seem like a waste of time, but it is one of the best things you can do. The whole of sharpening your axe before striking. Once you start doing that you will gaining deeper insights into the project. This is really just to minimize the time you spend learning about the higher-level overview of the project and you can just jump right in. You can start contributing back with anything else that validates that you indeed have a good grasp of how the sub-tasks that you just created actually fit into the bigger vision of the project.
Repeatedly perform the same or similar tasks
As you become more and more familiar with the project, you can increase the time you take and the breadth of your contribution pushing it towards your final goal. These similar repetitive tasks will make you get closer and closer to your final goal.