|Ben Trevett||Home | GitHub | Twitter|
Taken from Noah Gibbs’ talk.
Learning how to program from programming exercises, e.g. HackerRank, LeetCode, etc., is not ideal. However, once you’ve solved them, you’ve solved them, you constantly have to be finding new ones. Sometimes they rely on an algorithmic trick that you don’t yet know, which makes them difficult. They’re also only exercises in how to build something and not choosing what to build.
A better choice is “The Coding Study”, by Noah Gibbs. The technique has three steps:
Pick a tool.
Pick a task.
Pick a purpose.
Write down how long you’re going to work on it.
Work on it until the time runs out.
Reflect on how well, or badly, it went.
You tool here is your language or library or both. It can be either the thing you want to learn or, more commonly, the thing you’re using to do the learning.
Your task is what you want to build. There are two ways to choose a task:
The easy way: pick something simple, or that you’ve done before, or from a simple programming exercise from online.
The fun way: pick something in the world, anything, and turn it into a system of behavior.
This is the reason why you’re building what you’re building, and/or what you want to learn. If you’re implementing an algorithm that uses recursion then your purpose is learning recursion, etc. There are two ways to choose a purpose:
What skill do you wish you had? Choose something that takes you one step in that direction.
Do something that scares you. Pick something that you can’t do yet.
Pick the weirdest thing that might work, and do it.
Choose your tool, task and purpose first, before you begin coding. Make sure to write them out in words. This helps avoid feature creep.
Always stop at the end of the time limit. Without a time limit you either have long failures, where you don’t learn much, or long successes, where you’re still working on the problem but not actually learning anything.
Throw away the code after you’ve finished. If you have the goal of using it in production you won’t learn as much as you’re building to use, and not to learn.
Your purpose should be one idea, and no more. If your purpose is too complex then you won’t learn anything.
Start your code simply and build up with layers. Reduces the time taken to start getting something working.
Use tasks from the real world. You’ll be surprised by the hidden complexity, and it stops you recycling ideas that you already know.
Break the rules. Ignore these guidelines when it makes sense, or the rules to an extreme, e.g. set shorter and shorter time limits.
When doing pair programming make sure to brainstorm the idea and the interesting parts together. Have one person on the keyboard at once whilst the other debugs and designs.