A common topic I keep hearing in discussions about interacting with engineers who are more senior by rank is the fear of “looking dumb” by showing lack of knowledge, asking a question that is not formulated well enough or which is too straightforward to answer. While all of this is true when adding comments to a pull request, replying to a Slack thread or asking a question in a meeting (kudos to all who do that, it often takes courage to do so 👏🏻), this problem presents itself in the most biting way when it comes to a pair-programming session. It is understandable that being “in the spotlight”, sharing your screen and writing code while talking about it at the same time, can easily make up for a rather stressful and unwelcome experience. But even when it is the more senior programmer who shares their screen and performs the simultaneous writing + talking exercise, it might make us feel we’d rather not be in the pair-programming session at all. But why is that?

What is it that may feel uninviting, scary, stressful, when at the same time a great pair-programming session can be creative, knowledge-extending, even really fun?

My take on this question is that it’s the job of the more senior person in the pair to create a safe space. That’s not a tangible advice, you might say. You’re absolutely right, and that might also be part of the reason why so many people don’t create it even if they’d perhaps like to. I don’t think I can offer a reproducible how-to guide, but I’ll try to share a few principles I try to follow in situations I’m the more senior person of the two.

First of all, I’m very careful to quickly create an atmosphere that shows I appreciate any idea at all, especially if the other person hasn’t yet been through a pair-programming session with me and they might not yet know this about me. Whenever possible, I’m trying to build on something the other person said, and even when the idea itself is not really applicable, I kind of stretch it to become applicable - as if the person did jump in the perfect direction, just not far enough. It’s then my job to carry them the remaining part of the way to finish the jump, and I’m also careful to keep giving them credit for the idea during the rest of the session, emphasizing how it contributed to the end result. A little “trick” I also use is remembering what they said, even if it might not have been applicable in the specific moment they said it, and then I reference it in a context where it becomes applicable. This not only makes them feel really heard = show that I really pay attention to them and what they say without being dismissive or inattentive, but also contributes to increasing their knowledge because I show them in what contexts they can think of it.

At this point it is probably becoming clear that in a pair-programming sesion with a less senior colleague, the code that we need to produce during the session is only my secondary goal. The main goal to me is to mentor the person, show them their contribution is valuable, emphasize that I consider this culture and mentality very important in a programmer’s job, and hopefully, as a side effect, make their day a bit more enjoyable. The effect such a session might have on the other person’s growth, is easily understated but can be really immense - as I can confirm not only from feedback I received about myself, but also what I’ve gained by taking part in sessions with more senior engineers who successfully managed to create the safe space for me.

Another important part is showing that mistakes are an inevitable, common and perhaps even healthy part of a programmer’s job. I think it’s one of the biggest debts we have as a society that we somehow manage to ingrain in so many children the notion of seeing mistakes as failure. Demonstrating that we see mistakes as something normal can go a long way, because being afraid to make a mistake is a very common source of frustration in programming and can greatly slow us down, because as my favorite Czech saying goes, one learns from mistakes. (I used to wonder why some paid video courses about programming often show the presenter typing an error or saying something wrong and correcting themselves later - only recently did I realize that the reason why they don’t re-record the video is not their slopiness but the demonstration that not being perfect is something perfectly normal in programming.)

Hand in hand with mistakes goes ignorance. Over time, I’ve found the phrase “I don’t know” to be a big relief - philosophically speaking, it helps me understand my limits, and practically speaking, it fosters my eagerness to learn. The more you know, the more you know you don’t know. The more senior you are, the better it is when you show that you don’t know everything: your less experienced colleagues who look up to you might feel intimidated if you seem to know everything and they might be discouraged to take a part in discussions, because their contribution might be seen as invaluable if “you already know everything anyway”. Moreover, if they already look up to you, they start seeing you as less distant and are thus encouraged, because “maybe I might get as good as you someday after all”. An important note for pair-programming sessions though: always try to ask the question “Do you know XYZ” in a way that does not make the other person feel like in an exam - they need to feel that you’re asking them in order to tailor the perfect answer for them, to fill some gaps or on the contrary to save time explaining something they already know.

You might have noticed that I haven’t mentioned the “stupid questions” from the title yet. That’s because I saved the best for last: whenever someone says to me “This might be a stupid question, but …”, I get excited the most. For one, because it’s a proof that they feel safe enough to ask it. But for two, in my opinion it is exactly in these moments when you can help the person grow the most - or make a leap instead of a step. My assumption is that when a person considers their question possibly stupid, it’s probably because something hasn’t quite clicked for them. They feel they might be missing some core piece of information. Of course, many a time the answer is “No, it’s not like this, …”. While this is fine because it helped them anyway (=the “step”), a true teacher superstar can actually put themselves in the inquirer’s shoes, ask themselves “What would lead me to ask this question?”, thus grasp the underlying big question that might not be actually fully apparent to the inquirer and is in fact the key to make them really understand - it might very well be an “unknown unknown” for them which you can turn into a “known unknown” or even better “known known”. Thereby, you connect the dots for them (=the “leap”). It is in these moments where I think the greatest chance of an “aha moment” lies - and being a witness to a person experiencing one is truly enriching.

I encourage you to want to be the programmer with whom less senior colleagues are eager to have a chat. It’s more rewarding than you might think. ✨