{"id":374,"date":"2013-03-10T20:57:21","date_gmt":"2013-03-10T18:57:21","guid":{"rendered":"http:\/\/blog.adrianbolboaca.ro\/?p=374"},"modified":"2020-01-15T16:08:20","modified_gmt":"2020-01-15T14:08:20","slug":"taking-baby-steps","status":"publish","type":"post","link":"https:\/\/blog.adrianbolboaca.ro\/2013\/03\/taking-baby-steps\/","title":{"rendered":"Taking Baby Steps"},"content":{"rendered":"

Taking Baby Steps<\/h1>\n

I wrote a post on the history of Taking Baby Steps<\/em>, you can read it here<\/a>.<\/p>\n

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<\/em> appear in the code; some people tell them bugs<\/em>. 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.<\/p>\n

The rules are the following:<\/p>\n

\n

Steps<\/h4>\n
    \n
  1. \n

    Setup source control repository.<\/p>\n<\/li>\n

  2. \n

    Setup a timer for 2 minutes interval when you start.<\/p>\n<\/li>\n

  3. \n

    Write exactly one test<\/p>\n

      \n
    1. \n

      If the timer rings<\/strong> and the test is red<\/span><\/strong> then revert<\/strong> and start over<\/strong>.<\/p>\n<\/li>\n

    2. \n

      If the test is green<\/strong><\/span> before timer rings then commit<\/strong><\/span>.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n

    3. \n

      Restart timer (no discussions in between timers)<\/p>\n<\/li>\n

    4. \n

      Refactor<\/p>\n

        \n
      1. \n

        If the timer rings<\/strong> and the refactoring is not complete<\/span><\/strong> then revert<\/strong> and start over<\/strong>.<\/p>\n<\/li>\n

      2. \n

        If the refactoring is complete<\/strong><\/span> before the timer rings then commit<\/span><\/strong>.<\/p>\n<\/li>\n<\/ol>\n<\/li>\n

      3. \n

        Restart the timer (no discussions in between timers)<\/p>\n<\/li>\n

      4. \n

        Go to 3.<\/p>\n<\/li>\n

      5. \n

        When session time is up delete the code<\/strong>.<\/p>\n<\/li>\n<\/ol>\n<\/blockquote>\n

        <\/p>\n

        By creating this session constraint we wanted (me and Erik<\/a>) 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.<\/p>\n

        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.<\/p>\n

        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.<\/p>\n

        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?<\/p>\n

        Not refactoring enough. We were pushed by the timer to write bad code<\/em>. 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.<\/p>\n

        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!<\/p>\n

        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.<\/p>\n

        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 \ud83d\ude42<\/p>\n

        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.<\/p>\n

        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.<\/p>\n

        If you want to facilitate this session I can give you some tips:<\/p>\n