Stepping away from the keyboard (or your phone) is one of those practices that work regardless of how you produce software. Sustainable pace is solidly in the category of things we should do, regardless of how we produce work.
Sustainable pace was on my list of practices to re-evaluate last year. In a sense, now more than when I read the eXtreme Programming book, it is more a pattern than a practice. It very much depends on the context - who am I working with, what is fluent for me, what needs practice? What is fluent for others? Is the work that comes out of my flow state making their life more difficult?
Whenever we increase the amount of new information we process, we need breaks. I’m learning to play the guitar. The first time I practised, I was exhausted after five minutes. Now I can play a bit longer. And still, practising in smaller intervals works better for me than practising all day. After a while, things fall in to place, magically, without thinking about them consciously.
You need that fresh perspective. Stepping away from your software, letting it rest for a couple of days. Going out for walks. Singing in a pub choir. Connecting with other people. My desk remains one of my favourite places in the world. As does the sofa, for writing. But going out and not doing “one more thing” is important. Not only for the quality of the work, but also for the quality of your life.
Deciding to move forward with a prototype or scrap it is better mulled over away from the keyboard. That code that didn’t look quite right? Let it rest for a couple of days, write it again. Use TDD as if you meant it while waiting for your pair to show up. Bask in the glow of focused, well tested code. And then merge it with the parts that came out of the coding agent that were good enough. Spike and Stabilise goes great when you’ve got a fresh perspective.
Step away from the prompt, and come back while your subconscious does work. Especially with iterative tools like Claude Code, you can make good progress if you know what you are doing, and pressing ‘Yes’ on the next question and waiting for the result is addictive. It will also lead you into trouble when you are not paying attention.
Further reading
I have better, incremental and iterative tooling, but still, having an opinion and making up your mind as to where to go with the product takes time. As Chris Parsons wrote last summer: Product work can not be parallelized. Taste does not come cheap.
While wrapping up editing for this post, I found Armin Ronacher on a similar note. Armin Ronacher writes: “Maybe the answer is that we need better tools — better ways to signal quality, better ways to share context, better ways to make the AI’s involvement visible and reviewable”. This is what we are working on through Moldable development. Armin also mentions stepping away.
I want to post more about recent experiments, and getting to what I feel is a good place with what Kent Beck calls ‘whishcraft’ - AI augmented development. I need a few more of what I call ‘anchor posts’ like this to not come across unmoored. Rob Bowley’s post on techno realists is good reading while I write the other ones. Working with coding assistants can accelerate. Accelerate positively and negatively.
Afterword
This post has been a long time coming. I saw people in spring last year complaining of informational overload, and a kind of mental whiplash. “What just happened?”. And not being able to stop was a common theme on the Claude Code Reddit. (I am not on there at the moment, I cut back on social media). And I wrote this post, because I need to remind myself of this. I got hooked on programming early, and burnt out early, in secondary school. I have occasionally learnt how to manage my energy better.
We need better tools, certainly. But as they say on Reddit: Touch grass. A clear head will get you the situational awareness you need.
Subscribe to our RSS feed