Our coach Eddie talks about getting feedback from your pair.
Hi, I’m Eddie and I work at Makers as a technical coach. Here at Makers, we love pair programming and there’s a lot of evidence to suggest that we are right to do so. Nevertheless, it’s hard to do well and, without clear feedback it’s hard to improve. So I wrote the below to get you thinking about how to gather useful feedback, from your pair.
If you try this approach, let us know how it went in the comments below!
Do you want feedback?
If you had food all around your mouth or smelled a bit unpleasant, would you want someone to tell you before you arrived at work and sat down for the day? If you had picked up bad pairing habits or perhaps not quite picked up good pairing habits, would you want someone to help you see that, before your next pair programming session?
If you answered yes to the second question, I challenge you to get useful feedback from 2 people you’ve already paired with. That’s right it’s your task to get feedback, rather than their task to give it.
Question: How can you ask for feedback in a way that will help someone give you useful feedback?
If you can nail this, you will open the door to an endless stream of useful information, that will help you to grow and improve!
I would not advise this approach
Hello pair programmer, please can you give me some feedback on your experience of pairing with me?
- What did I do well?
- What could I have done better?
- Anything else?
You’ve probably all been asked similar questions before and probably all drawn a complete blank for at least one question and / or thought of things you’d like to say, that you just couldn’t bring yourself to say, about what that person could have done better. Maybe there was even a time when you day dreamed about saying “You could have done EVERYTHING better!!”
These questions are way too vague and, even if someone finds something to say, they’re unlikely to give you the feedback that you’re really after.
Instead, ask specific questions
Asking specific questions will mean you get feedback about things you’re really interested in. You also prevent the respondent from drawing a total blank, because you’re asking them to think about a particular thing or event. Finally, by asking about a specific thing, you’re signalling that the respondent has ‘permission’ to give you feedback about that thing.
How will you come up with these questions?
I suggest that you use one of two approaches. The first is the hardest but potentially most rewarding. The second is easier so you might want to start there. You could also combine both approaches to end up with a list of 3–5 questions.
1. Come up with your own
Start by reflecting on your own contributions and behaviour as a pair programmer.
- What do you think you did well?
- What do you think you could have done better?
- Is there something that you’re already trying to improve?
- Have you received feedback from other people that you would like to validate?
Then read an article about how to pair program well — here’s a good one.
Based on your reflections and reading, come up with 3–5 questions that you’ll use to garner feedback.
For example, if you think you explained things well, ask for feedback to validate that but avoid asking loaded questions.
- Don’t ask “did I explain things well?”
- Instead you could try “what did you learn from me?”
2. Pick 3 to 5 of these
Make your choices on the basis of what you are ready and willing to hear, as well as what you think would help you the most.
Did you achieve a shared understanding of the task/s?
- What do you think of the code we wrote together?
- Could you summarise the work we did together?
- What would you have done next, had we continued to pair?
Atmosphere and engagement
- Were there any moments where I seemed to disengage?
- Were there any moments where you felt disengaged?
- Did you hold back any suggestions?
- Did I snatch the keyboard at any time?
- Was I too quiet, too talkative, or did I strike a good balance of speaking and listening?
- Did I move too fast, too slow, or at just the right speed, on the whole.
- How did you feel at the start and the end of the pairing session?
Learning outcomes
- What one thing did I explain well? What one thing did I explain not so well?
- What did you learn from pairing with me?
- Did you learn anything about pair programming?
- Was there a moment where we could have, but didn’t, use a diagram?
Question: What if the respondent wants to say something that is not captured by your questions?
Asking a broader question can work but there’s a knack to getting the wording right, such that people give you useful information. Companies will sometimes ask: “would you recommend our service to a friend?” rather than “how would you rate our service?”. This is because the former question makes people actually imagine recommending the service to a friend and the implications that brings.
In your case, you’re not looking for someone to recommend you to a friend (!) but you can ask questions that are equally powerful.
- If you were managing the team I was joining, what would you ask me to work on, so that I can pair well with the other team members?
- If you were managing the team I was joining, what advice would you to a junior member before they paired with me?
- I’m aiming to move into a more senior position in 6 months and would need to mentor junior developers. I want to be the best mentor I can be. With that in mind, what one thing should I start or stop?
- Who is the best pair programmer you know — what do they do, which I could add to my pair programming tool kit?
Get involved below
It would be awesome to hear about your experience of gathering feedback from your pair, in the comments below. Do you have any tips you’d like to share? Do you have some great questions you always ask? Have you received feedback that you felt was unfair? Did you try the process I’ve described? If so, what were your questions and did you get useful feedback?
Interested in training with Makers? Join our next Demo Day and Q&A here.
