Slow is smooth, and smooth is fast
When I was first learning how to ride a motorcycle, I was so nervous about stalling the bike that I would try to execute gear changes as quickly as possible. The result was that I would cause the transmission to make the most horrifying sounds…and then stall.
Worse still, I found that it was impossible for me to improve on my own. Every gear change was such a frantic scramble to pull and push every lever I could find (and hope that I did it in the right order), that I could barely keep track of my movements, let alone inspect and improve my technique!
My instructor – with the patience of a thousand saints – helped me overcome this problem by drilling a mantra into my head: Slow is smooth, and smooth is fast. By making slower, more deliberate movements with the controls, I was able to feel the bike respond, which then allowed me to adapt my technique and execute gear changes smoothly. And even though at first I had to go painfully slowly in order to get it right, I got faster and faster with practice…until one day I was shifting gears even faster than my original frantic scramble, and with far fewer complaints from the transmission.
The same principle applies to writing software, especially when you’re first starting out.
Junior developers feel tremendous pressure to solve problems quickly. They have heaps of imposter syndrome to overcome, they are worried about being a burden on their teammates, plus there’s a natural pressure that everyone feels to “prove themselves” when they start a new role.
As a result, junior developers often get fixated on trying to get the desired result (i.e., the correct sequence of characters typed into the editor) as quickly as possible, and they avoid any activity that they perceive would slow them down (i.e., debugging).
I’ve seen it time and time again: The developer writes some code and tests it out, and they see that it doesn’t get the result they expected — but instead of stopping to figure out why it didn’t work, they instead dive straight back into their code to try something else. Unfortunately that something else doesn’t work either, and round and round they go. It doesn’t take long before the developer is completely out of ideas, and now they’re well and truly stalled.
Fortunately, it’s very easy to coach junior developers out of this. The key is to teach them how to make slower, more deliberate changes to the code, observing how the programme responds as a result, and adapting their approach in order to find the solution in fewer iterations:
Teach them where to set the breakpoints in their process. Pair program with them, and when you see them neglecting to analyse the results before diving back into the code, gently interrupt them and point them in the right direction. It shouldn’t take long before they pick up the habit themselves.
Get them to internalise the Two Questions™ when there’s an error message. When the code generates an error, ask the developer the two key questions:
“What does it say is the problem?” — get them in the habit of reading and understanding the error message…and in particular, not ignoring the complicated-looking parts (I’m looking at you, TypeScript).
“Where does it say the problem is happening?” — get them in the habit of analysing the stack trace.
It should only take a few iterations before the developer starts hearing the sound of you asking these questions in their head every time they see an error message. And also in their nightmares, but I’m told that goes away with time. Usually.
Ask leading questions instead of giving answers. Pair programming often feels slower than working individually because many of its outcomes (cross-training, code quality, upskilling) are invisible and come at the cost of raw coding speed. When the junior developer gets stuck or overlooks something, you will be tempted to tell them what to do to get things back on track quickly — but this will only make them more dependent on you. Instead, challenge yourself to come up with leading questions that will foster their curiosity and help them to learn the way to the right solution themselves.
Reinforce takeaways at the end of the session. Before you close out a pair programming session with a junior developer, take a moment to reinforce the learnings you want them to take away from the session. In particular, be sure to call out any progress that you’ve observed, not just suggestions for improvement!
This process is going to feel uncomfortably slow at first, and especially during the first few pair programming sessions you might feel like you’re not making much progress in terms of the actual coding. That’s OK — the primary outcome you want here is for the junior developer to develop a more systematic approach to analysing and solving their own problems. Once they have that down, they’ll get faster and faster with practice.
Slow is smooth, and smooth is fast.