đšâđ« 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.