Choose your step size
Everyone has a skill level
👨🏫 No office hours this week. I’m retooling and figuring out the format. Stay tuned.
🇧🇪 I’ll be speaking this week at Heart of Clojure in Belgium. Get your tickets for 10% off with this magic coupon link. This looks like one cool Clojure conference.
🇺🇸 Clojure Conj is happening at the end of October outside of Washington, DC. Check out the schedule and get your tickets.
📖 Grokking Simplicity has passed 14k copies sold! That’s not bad for a programming book. If you want a copy, please buy it on Amazon because it boosts the rank so people who want it find it. Leaving a review will help, too, because it will help people decide whether to buy. You can also find Grokking Simplicity on O'Reilly Online.
📖 I would love any comments you have on Runnable Specifications. The latest “chapter” is the Composition Lens Supplement. It’s a twenty page reference detailing ten important algebraic properties. My questions are: Is it useful? What’s missing? How’s the presentation?
Choose your step size
My mom once bought me a french cookbook—you know, one from France—translated into English. I’ve read quite a few american cookbooks, so I thought I knew what cookbooks were like. But this French cookbook blew away my preconceived notions.
The american recipe works like this. Each recipe is a full page, often with a lovely picture of the dish on the facing page. There might be a paragraph describing the dish, in case you’re not familiar with it. Then there’s a list of ingredients with quantities. And then there’s a detailed explanation of every step to take, including preheating the oven, chopping vegetables, and how to cook staples like rice or potatoes.
The french recipe was very different. It was a short paragraph that briefly described the process. For instance, mashed potatoes was :
Smash boiled potatoes without peels and mix with butter and cream.
Um, excuse me? Where are the quantities? How do I boil potatoes. Do I peel first? What size bowl should I use? In short, it felt like there was a lot of information left out—especially concerning the steps.
If you’re not good at cooking, the french recipe doesn’t provide enough detail. You’d prefer the american one. But if you’re an expert cook, the french one gives you just the right amount of guidance—basically the structure of the dish. You need to find the step size for your level.
The last two issues, I’ve talked about two thought technologies that experienced programmers use that can really help you level up. Case analysis and “givens + needs” are not hard, but they do require a little bit of discipline to apply. This week, I want to focus on another, similar discipline. This issue is about choosing the size of the step you’re going to take.
In the “Givens + needs” post last week, I went through the function one line at a time. Even the conditional test was attempted before even considering the then expression. I did that for pedagogical reasons, but it’s also important for beginners: You need to develop the skill of picking the right size of step to tackle next.
My biggest coding failures have been trying to do too much. The problem is too large. It doesn’t fit in my head. I can’t handle all the corner cases. There are too many parts unknown to me. I would code 200-1000 lines of code without testing it, then spend many days trying to debug it. Now that I’m more experienced, I see three problems:
I wasn’t skilled enough to tackle this problem all at once.
I wasn’t aware of my skill level vs the the skill required.
I wasn’t disciplined enough to break down the problem.
Notice these are three different levels of work: Skill, Awareness, and Discipline. The skill to tackle a problem will come with time and experience. And everyone has a level. Even after programming for 30 years, you’ll have a level of problem that is beyond you.
The awareness is actually quite easy. I notice the anxiety from my students when the problem gets hard. There are so many unknowns (to them) that they could recognize. You could see their nervous system reacting. And it should! They really don’t know how to do it.
The answer is #3: Stop and break down the problem. Is there a small piece of the problem that you can solve? Can you test that it works? Can you remove that unknown? You’re trying to cook from a french recipe when you need the american one. The real skill here is to stop, think, and carve off something small you can do. And here’s the thing: Everyone needs to do it—even really skilled developers. We all get anxious when we face a problem we don’t know how to face. It depends on your skill and the problem you’re facing. The discipline is to be aware of that anxiety and use it to find the right step size. If it’s easy for you, take bigger steps. If it’s hard for you (you start to notice anxiety), take smaller steps.
That disciple can itself be practice. Test Driven Development can help with this. I think it helped me. It forces you to take really small steps. It forces you to break problems into small steps. It gives you feedback that you’re making progress. Once you’re good at it, you don’t have to test all the time. But still, use the REPL. Use it more frequently than you think you should, because why not? It’s just a keystroke to run an expression.
So that’s my recommendation: If you’re beginning, learn to be aware of your anxiety about the difficulty. Use it to gauge the size of the steps you should be taking. Get lots of feedback that you’re on the right track. Find the step size where you’re comfortable and aim just slightly bigger than that (to keep it fun). Don’t worry about your skill level. That will take care of itself with time.