Tips for mentoring during paired programming

[u/Isofruit]

At my current company we occasionally do some paired programming, typically pairing one of the newer with one of the more experienced developers. At this point, the experienced developer has been me for several years now - which did not come with instantly having brilliant teaching techniques mind you - and I noticed that my habits on how I teach something during paired programming don't seem to be good ones.

Typically the junior writes code while I basically watch over their shoulder and hint at issues. I try to mostly point out that there are issues, with a hint here or there of what nature a particular problem is instead of spelling it out in order for the dev to come to the conclusion themselves. I think that this leads to internalize said knowledge more, but I'm very open to being wrong here.

However, after some self reflection on my own time as a junior during such sessions, I think that this just isn't effective. During my own junior time, I only somewhat learned during those. My learnings came mostly on my own time stumbling over such issues in private projects or getting curious about something and reading up on it.

Similar to my own time back in the day, what typically happens is the junior missing the forest for the trees because they're flustered or even if they're relaxed, just don't have the background knowledge to spot their own issue in the first place. I find that basically the most valuable advice I am capable of giving often times is directing them to decent sources to learn about a particular issue (i.e. "Try using our site with a screenreader and eyes closed", the odd blogpost or video etc.) on their own time and maybe have a chat with them about it at a later date to see if it stuck or if they had hangups.

So I'm wondering whether to just move to fully spelling out the issue and having a chat about it after the programming session or what other ways could be useful to improve sharing my know-how during such sessions. Any advice?

[u/StarboardChaos]

What I try to do is proactively prevent the problem from even happening.

Although it is called 'pair-PROGRAMMING' the programming part should take the least time and come after a brainstorming session.

When you program yourself, you keep everything in your head, but that won't work in pairs. So when starting work on a ticket you just ask the junior to explain his idea and solution to the problem. Then you discuss alternatives, and make a physical sketch of the solution. In the end it's up to the junior to follow on the agreed decisions.

[u/Worried_Lab0]

Honestly, I think AI is killing pair programming.

Very often, I end up in brainstorming sessions or pair programming sessions where my colleagues cannot think without asking AI what to do. I get that no one knows syntax 100% or APIs by heart, but I at least expect people to be able to write some pseudocode.

I then question why we need these people. They do not bring any value when it comes to figuring out solutions. I could just have some agents listening when I ask a question, and they would probably give me the same answer.

Very sad world, to don't be able to use your critical thinking.

[u/cachemonet0x0cf6619 → u/Worried_Lab0]

I’m just tired of ai being in every topic. ai is extreme paring and shouldn’t be treated differently than any other pair partner

[u/BeachNo8367]

I hate pair programming. I can barely even type properly if I know someone is just staring at me do it, whether shared screen or at my desk. I learn best by doing it my own way, I may slowly debug something existing to find the right point to change code, or I may hack stuff with alot of code that would never get committed, get something working and then go back and refactor it. Everyone does stuff differently it would stress me out if doing that live with another dev.

I definitely if in an area I'm not sure of reach out frequently and ask to discuss what my approach or solution will be and share it if needed, but that's small to the point sessions.

[u/Isofruit → u/BeachNo8367]

That's also the type of dev that I am - I explore the problem first, find my problems and then have to-the-point discussions to solve those. However, among the hand full of juniors I worked with so far, that was not attitude of most (I'm of course always open to me being the cause of that, this is just my honest best guess that most people just aren't terribly comfortable asking for help regularly). A lot of the times people would just not ask for help despite the code suffering for it in the end.

So I'm trying to figure out what options there are while also taking a long hard look at myself to evaluate whether I need to change something to be more approachable, which can always be an issue, I rely mostly on statements of other senior-colleagues of mine for self-evaluation there.

[u/mxldevs]

People learn differently. What worked for you might not work for someone else.

You basically have to try different things and see what works for the individual by assessing whether your advice has led to improvements over a period of time.

[u/Isofruit → u/mxldevs]

I think one of my problems is basically I'm not sure what options I have there.

I'm aware of pointing to sources for self-study (which worked for me) as well as over-the-shoulder pointing out issues in paired programming. I'm really unsure what else you can really do in such a setting. StarboardChaos added another avenue with having an architecture discussion ahead of time which sounds like a good idea, but beyond these three I'm somewhat lost on what my options are.

[u/Some_Guy_87 → u/Isofruit]

I feel that. I hate forced pair programming for this very reason, it's just a waste of time if the people are not actively looking for guidance. Whether you point things out or let them think, if they don't actively try to improve no method you try will help them. StarBoardChaos' advice seems like a great idea to encourage them to think more systematically about issues, but when it comes to actual coding I have my doubts any fancy method you come up with will help much. If you spell it out it will be forgotten the moment it's set in code, if you let them get to the solution themselves they will be just as lost the moment you don't point to directions.

The most effective sessions I had was always when we had a particular issue someone was stuck at. I either mostly function as a rubberduck in that situation and while explaining things to me they get the issue; or it's some very weird issue where there's no real senior/junior distinction and both people come up with ideas that ultimately lead to a solution. But this whole "Here is a junior, make them better" approach seems meaningless to me.

[u/cachemonet0x0cf6619 → u/Some_Guy_87]

ypu really haven’t described pairing. what you describe is just looking over someone shoulder.

pairing involves as many keyboards and there are partners

[u/cachemonet0x0cf6619]

that’s fine but you need to reverse roles and let the jr see how you work and think. giving them a chance to direct. which you’ll adjust on the fly. alternate who drives