A “Slow Code Retreat” to be less in a hurry

8 minute read

“Developers will always have more work than time” We can race our TODO lists or accept and slow down NOW. The “Slow Code Retreat” helps us do that!

First slide of the Slow Code Retreat workshop. It shows a snail crossing the street, with the title of the workshop written.

The team is good, but the organization mainly pushes them for output!

Developers have as much difficulty changing their habits as anyone else. Besides, we’re too busy.

This manager was in my interview and kept asking me questions like: “what if devs feel they are being slowed down?”.

We all know this story. Learning new practices or taking on new habits takes time. And developers always have something more urgent to do.

Lately, my colleagues and I almost worked with a team struggling with onboarding. We helped define knowledge-sharing actions, trained seniors to run team mobs or katas, etc. Yet, at the moment of setting up team sessions, senior developers were too busy!

There is no workaround: Sustainable pace starts NOW!

In its most trivial formulation, it’s as simple as this. To go from doing A to get to doing B, we have to unlearn A and learn B. That takes time. If we don’t have time, we can’t afford to change. (Slash the Load, Mike Hill).

Teams only have so much control over their time! There are always urgent and valuable projects to deliver. Even productivity and sustainability improvements only add more work in the short term! Very often, management will not grant the team some time for learning.

Sometimes, it might look like there are no ways out!

At every moment, we have the choice to step back and take it easy! Nothing prevents us from injecting some ‘sustainable’ seconds into work. It’s not about what happens. It’s about our state of mind and how we live what is happening.

At first, it can be only a few seconds here and there during the day. With time though, we can train our minds to do this more regularly.

How to slow down at work as developers?

“Inject sustainable instants throughout our day of work” might sound a bit too vague… So let’s see how to do this more practically.

First slide of the Slow Code Retreat workshop. It shows a snail crossing the street, with the title of the workshop written.

The Slow Code Retreat is a workshop I ran at XPDays Benelux. The idea is to let people experience different ‘slow working’ techniques.

Photo of the feedback I received when I ran the slow code retreat workshop at XPDays Benelux Here is the feedback I received at this workshop.

Here is how the workshop is structured:

  1. Welcome
  2. Connect with the topic and other participants with these 4 questions:
    • What did you say no to to attend this session?
    • According to you, what could slow code be?
    • From your experience, list a few situations where slow code could have been helpful.
    • What is the big question you bring to this session?
  3. Present 6 slow code practices (see below)
    1. One or two rounds of slow code practice on code katas
      • Participants pick 1 or 2 practices they want to experiment with
      • They self-organize in solo, pairs, or mobs
      • For 30 minutes, they go through the simplest katas like Fizz Buzz or Pascal’s Triangle
  4. Takeaways
  5. Q&A

The complete workshop lasts between one and a half and 2 hours.

6 slow working practices

Drawing of a mind map with the 6 slow-code practices. The structure is the same as that of the following sections. With 2 extra links from Slow Navigating to Slow Self-Retro and Slow Code Reviews.

Participants can try the 6 slow working practices during the workshop. I’ve split them into 3 categories: coding, communication, and mobbing.

Slow Coding

We can use these whenever we are programming solo, in a pair, or in a mob.

Slow TODO List

Take the time to focus only on the present task:

  • Keep a TODO list while you code
  • Keep track of everything that remains to be done
  • Check or strikethrough steps as you do them
  • Indent sub-tasks
  • Can use a .txt, a .markdown, a shared online doc, or a mind map
  • Reorganize your tasks when needed
  • If you revert steps that you cannot do yet, it becomes the Mikado Method
  • This removes all the mental load involved with keeping track of the status of work
  • The map serves as a communication tool for handovers, pairing, or mobbing
  • Helps us to drop things that we eventually decide not to do!

Slow Baby Steps

Photo of stairs with "Step by Step" written on the first 3 steps. By itself, pushing TDD to the extreme, like when using TCR for example, is a way to go slow!

Take the time to practice egoless programming and baby-steps programming with TCR:

  • Start coding with TCR
  • Whenever you get reverted
    • Notice the feelings you experience and accept that error is humane.
    • Practice humility and Egoless Programming
    • Try again with a smaller step
  • As the day goes by, notice how your capacity for flawless work decreases!
  • With time you’ll learn how much you can do without mistakes
  • This teaches you to do extra small steps that cannot go wrong!
  • This helps to understand when to call it a day and leave
  • This avoids writing low-quality code when you are too tired

Slow Self-Retros

Take the time to observe what happens inside us:

  • Set a timer to ring every 5 minutes
  • Every time it rings, take a short pause and fill out this log individually:
ROTI Did Learnt Puzzles Feelings Need Decision
  • Helps us to spot our non-constructive reactions to events like:
    • “I don’t know how to do that!”
    • “Damn, I was sure this test would pass! I’ve got no idea why it’s failing!”
    • “How stupid I am!”
    • “I don’t understand anything about this code!”
  • Develops our knowledge of inner feelings and needs.
  • Provides plenty of data for continuous improvement and retrospectives of all kinds.

Slow Communication

For the sake of organization, I put only Slow Code Reviews in the category of slow communication. Yet, Slow Navigating could also go in this section.

Slow Code Reviews

Take the time to offer non-violent feedback to your colleagues:

  • When writing reviews
  • When voicing feedback in the mob
  • Follow the Non-Violent Communication pattern:
    • List the facts
    • Share your feelings
    • Share what needs you have
    • Suggest a new way of doing things that meets everyone’s needs
  • It prevents conflicts from building up for the wrong reasons
  • It improves teamwork, psychological safety, but also the efficiency of reviews
  • It leaves the door open for more creative solutions
  • It builds our feelings and needs fluency and self-awareness
  • It is a way to start learning Non-Violent Communication

Slow Mobbing

Finally, here are two practices specifically suited to mobbing or pair programming.

Slow Driving

Photo of a road with a road sign written "Slow Down". Slow Driving in the Mob is a very easy and free way to inject some slow in your day.

Take the time to be aware of your feelings and thoughts when driving:

  • Accept, or even better, relax into being navigated!
  • Stay focused on typing and do what you are asked to do
  • Focus on the touch of the keyboard and what displays on the screen
  • Don’t judge what you are asked to do
  • Breath while compiling or running tests
  • This driving ‘pause’ makes the mobbing more sustainable
  • It helps to take a step back:
  • Let your creative mind work in the background
  • Come back to navigation with a new perspective
  • [Mindfulness For Programmers. 3 simple exercises to be more present… by Julia Di Russo Towards Data Science](https://towardsdatascience.com/mindfulness-for-programmers-da6f92147b8f)

Slow Navigating

Take the time to practice egoless programming while navigating in the mob:

  • When other mobsters seem to be struggling with something you’ve figured out:
    • Observe any criticism or judgment that you may feel.
    • Instead, try to be patient and compassionate.
  • When you struggle to understand or solve something:
    • Observe any self-criticism or self-judgment that you may notice
    • Instead, try to accept these feelings and let them go.
  • When other mobsters come up with different solutions than you: - Strive towards egoless programming and humility by welcoming their solution 

Here is a variant:

  • Take a step back in the mob:
    • Strive to remain a neutral observer of the mob
    • Keep a log of what is happening and the mood of the mob. (a bit like Slow Self-Retro)
  • A compassionate behavior builds psychological safety, improving decision-making and team performance.
  • A “mob log” can be handy for continuous improvement and retrospectives.

Try the workshop!

Here are the slides for the workshop I gave at XPDays Benelux.

Picture of a stack of slides for the "Slow Code Retreat". This contains all the material needed to run the workshop.

My first recommendation is to try the workshop yourself. My first try at “slow self-retro” was mind-blowing. I was dumb-struck to see the emotional roller coaster a simple kata would get me through! If you have close peers to try it with, slow mobbing will teach you even more!

Also, next time you face a team with no time for coaching, don’t try to force it into their calendar. Has the team got “down time” in its calendar: Scrum slack-time, SAFe Innovation & planning? (Or August in France 😉?) Suggest volunteers try this 2 hours workshop during this downtime:

  • “Slow Driving” and “Slow TODO List” make work more sustainable and productive from day 1!
  • The other techniques need more time to install (that might be a topic for a follow-up post)
  • All practices will get them to explore an ignored facet of software development

Whatever you try, I would love to read your feedback!

Here are other articles that might interest you:

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment