Taking Baby Steps

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.
Support independent publishing: Buy this e-book on Lulu.

Taking Baby Steps

I wrote a post on the history of Taking Baby Steps, you can read it here.

Now I would like to tell you more about the workshop and the technique itself. While coding, for me it is very important to be focused on one idea. Why? Because this is how programmer mistakes appear in the code; some people tell them bugs. The other thing I am interested in is to have an undo button for every change. This is why I want to commit every 1-2 minutes.

The rules are the following:


  1. Setup source control repository.

  2. Setup a timer for 2 minutes interval when you start.

  3. Write exactly one test

    1. If the timer rings and the test is red then revert and start over.

    2. If the test is green before timer rings then commit.

  4. Restart timer (no discussions in between timers)

  5. Refactor

    1. If the timer rings and the refactoring is not complete then revert and start over.

    2. If the refactoring is complete before the timer rings then commit.

  6. Restart the timer (no discussions in between timers)

  7. Go to 3.

  8. When session time is up delete the code.

By creating this session constraint we wanted (me and Erik) to push programmers to commit during a coderetreat. After a couple of coderetreats I found that for most of the programmers is frustrating to put them in the situation of needing to commit every two minutes. I was expecting that, because we wanted to push people out of their comfort zone, but the frustration was a lot higher than I thought in the beginning. I saw programmers being enraged by this technique, others did not want to go on with this constraint, and so on. Usually a part of the coderetreat attendees will take it home, study it more and even apply it on their daily jobs. So from the reaction point of view there is a great diversity.

When facilitating coderetreats or this session separately, I saw some traps programmers fall into when attending this session. I also saw some unexpected positive effects.

The most often I see the pairs trying to finish in the time-frame without forcing themselves to focus on one idea. If my thoughts are scattered, then most obviously the program I write will lack the level of abstraction needed. So programmers hurry, rather than taking some time to think ahead which steps they should take. I hear often that “2 minutes are not enough to think ahead”. It may be true for a complicated business problem, but for Conway’s Game of Life or for Tic-Tac-Toe you should be able to decide which steps to take in less than 2 minutes. And this is another effect of the exercise: it shows me as a programmer where I am not that effective; what I should learn next. I found this extremely valuable.

Another trap is the idea that the programmers do not need to be fast typists. And connected with it that programmers do not need to know the short cuts of their IDE they can rather use the mouse. These two ideas are far beyond my comprehension. I am a programmer and I work daily with the mouse and with that IDE. I should know it inside-out. Imagine a surgeon not knowing what scalpel to use. Imagine a blacksmith not knowing which are the hammers he could use. Or imagine a politician passing laws… Can you be a professional in your domain if you do not use your tools efficiently?

Not refactoring enough. We were pushed by the timer to write bad code. Nobody says you need to write a lot of code. You need to write the best code you can. If you write a couple of lines of code and they are beautifully forged, then it’s great! You should take the time to refactor, because you can take as many 2-minute time-boxes for refactoring as you want. Being pressed by the timer is not an excuse not to refactor. During your daily job you are always pressed not to refactor. Now you can exercise that pressure so you can deal with it better during your work hours.

An effect I never imagined during this session was the pairs collaborating to make it in those two minutes. I often see some pairs working together, thinking together and helping each other when they see the other needs help. So for some people this session is very good also for getting a pair or a team closer to reach their common goals. Whenever I see a pair collaborating that well, I am very proud of them!

The most important effect of the session is that people have fun. It is a game, you need to commit in two minutes. Often the pairs enjoy this, they laugh loud when they made it with just a couple of seconds before the timer rang.

It is energizing, you should do this session after lunch. You need to stay focused on what you are doing and on the timer. There is no time for doing anything else but writing code, especially if the facilitator bugs you not to talk that much 🙂

Going back to this exercise as being a radar of my skills, I want to emphasize that you can test yourselves at home by using it. Just take 45 minutes, take a kata and try to commit every two minutes. Be honest with yourself and observe where you are not efficient. Note them down, prioritize them and in this way you can see, very fast, what you should learn next.

Whenever I am coding, I take baby steps. I commit often, every couple of minutes the least. If I do something wrong, I do not care about the change, I just undo all the changes and start fresh. This is on of the clear values of committing often. And that step back is not waste, I learned something during that short time, and I can use these learnings now.

If you want to facilitate this session I can give you some tips:

  • Explain the constraint well, go over each detail.
  • Ask the audience if they have questions before starting.
  • Make sure everyone has a local source control system before starting.
  • Make sure everyone has a timer ready on their desk before starting.
  • Ask the attendees to put a loud sound for the timer when the time has ended.
  • During the first 15 minutes go between the desks and push them to respect the rules; some will not restart the timer; some will talk too much.
  • During the retrospective ask
    • Was it useful for you?
    • Would you apply this during your daily job?
    • Would you change the two minutes? What duration would it be good for you? Why?
    • Did you find what you could improve so that you could be more effective?


UPDATE (25 September 2013): You can use a timer that Corey Haines wrote here and Bogdan Zaharia wrote here, especially for this session.

If you want to know some more, just drop me an email or a message here. I will be happy to answer.


If you want to receive an email when I write a new article, subscribe here:

Subscribe for new articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe for new articles