Even Sherlock Holmes was pairing. Are you? Let’s find some good practices in the talk below about Sherlock Holmes and Pairing! During my work I am used to pair with my colleagues on basically anything.…
Coding Games This is a video about Coding Games from xALEc where I am part of a conversation about how one could teach programmers to be better by using games and pair-programming.
Farsight Navigator Blog post series This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games. Purposes: Make experienced navigators become better Focus…
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
When working in pairs none of the pairs is allowed to delete the code of the other person. We are looking for a common solution, that both of the pairs will agree.
Why? Often I see that the more experienced programmers drive and give their solution as the best one (and sometimes as the only one). But even if you are not experienced, either with the specific language or framework or generally, you might have some good ideas for making the current solution better. In order to work on that attitude you can do ping-pong pairing with the rules Yes, and…
So the rules are:
Sessions on this topic should be short, around 30-60 minutes. The first sessions should be supervised by a coach who will make sure the rules are understood and well respected. These sessions might become tiring, so make sure you choose a period of the day when you do not have other hard things to tackle.
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
A very experienced and neutral person, ideally an external technical coach, will pair with the team members one by one.
The rules are that:
These sessions should have a specific, very clear topic. The technical coach needs to make sure that each member of the team understood the purpose.
The pair-programming session should not last more than 30-60 minutes as it is very tiring for both of the performers.
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
The two programmers are not allowed to talk.
All the communication is made through code.
They are not allowed to use paper or write comments in the code or other files.
This blog post is part of a series about pair-programming games. To read about more please click see more sessions on pair-programming games.
The roles driver and navigator change often inside the pair.
This activity is like a game of ping-pong of the roles between the two members of the pair. They both can take short time decisions while being a driver and can spot strategic design decisions while being a navigator.
Refactoring can be made by any of the programmers on their turn, but only when the code and the tests are stable.
I wrote a post on the history of Brutal Refactoring Game, you can read it here.
In this blog post I want to tell you more about the workshop and about my experiences while facilitating it. Also I will add some tips for facilitators that want to try themselves this workshop.
The purpose of this workshop is learn what refactoring is, why it is so important to do refactoring often and immediately after you spot some coding smells. Often I ask programmers “when are you doing refactoring?”. The question has a vast number of answers from “when I think I need to”, to “once a month” to something like “every couple of tests”. But seldom I hear that programmers do refactoring all the time, in the minute the tests had passed from red to green”. This is where the format comes into place.
Last year I was thinking about a session during which attendees would learn how to focus on refactoring. I had some thoughts about this: we would need a list of coding smells, and have some cards to give the attendees that had that coding smells in their code. Now the obvious question was: how can you have coding smells if you do not have a code base? I thought about it, and then I figured it out: during coderetreats I anyway see legacy code after 10-15 minutes. So if this session would take 90-120 minutes we would have no issue with finding coding smells.
The first thing was: of course I will ask people to do pair-programming. This is how you learn a lot!
I came with these basic thoughts to Alex, and we had a chat about this session. Initially I had wanted to print one index card for each of the coding smells. But Alex helped me simplify the concept by creating a numbered list of coding smells that would be projected on a screen. Then we thought: we could use index cards just to write the number of the coding smell.
Now the question was: how do we do this? How can we enforce the coding smells? We thought about it and we said “we love clean code, so we could be something like a dictator”. Then we both had in mind the concept of “Benevolent Dictator“. The sessions was starting to shape-up. The benevolent dictator was a key factor in the environment we wanted to create: learn and play.