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.
- You have very stubborn programmers in your team and you want to make his views softer.
- To any problem, your team says there is only one solution, and that is their solution. You want to let them see there are always alternate solutions, which sometimes are better.
- You had issues in the past with architectural or design decisions, just because the problem was not understood sufficiently.
A very experienced and neutral person, ideally an external technical coach, will pair with the team members one by one.
The rules are that:
- the team member will be the driver
- the technical coach will be the navigator
- the technical coach is allowed to always ask beginner, even basic and stupid questions like “what are you doing”, “why are you doing this”, “tell me what is happening in this code”
- the driver is not allowed to be angry by the beginner questions of the technical coach; the driver needs to always explain what is their current idea, how they can implement it and why they chose this path.
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.
After a couple of sessions like this the team will understand that they should question their solutions like beginners would.
The team will be more attentive when choosing a specific solution for a problem.
This session triggers learning. As a consequence to beginners questions a lot of the team members will find about themselves that they need to learn more about a specific subject.
When thinking about a solution the tone will change from “the solution” to “some of the solutions”.
Feel free to use it, with care and in adequate situations, during dojos, coderetreats, trainings, etc. You should take extra care when facilitating it on two areas: the programmers respect the rule and they do not get annoyed so they would want to rip the other person’s eyes.
This game should be organized and performed by a very experience technical coach, with a lot of communication knowledge. Otherwise it could get messy…
Most of the team members in this context will get annoyed at the beginning, but after a while they will understand the purpose.
The questions the technical coach asks need to be chosen carefully, with a specific goal, which is the expressed goal of the pair-programming session.
Even if the team member will become annoyed or angry, the technical coach needs to keep their calm and continue with the exercise until the time has ended.
During my trainings and coaching I observed different types of behaviors between senior programmers and junior programmers. Some seniors are very blunt, and they express their ideas in black and white. Some seniors are more attentive to the juniors and they want to teach the juniors more about the background behind some programming decision. Following this observation I studied the behavior some more, and I saw that seniors become better at explaining what they are doing, just because juniors ask them basic questions.
Often seniors know they are doing something well, but they do not know why. Sometimes they are right, but they forgot the background, but sometimes they are wrong and their approach is wrong.
Following this idea I thought about a game that could trigger this consciousness of decisions while programming. So this is where the game comes from.
When will you try to think like a beginner? What about trying to be questioned by a beginner?