DEV Community

Discussion on: What cool ideas have you seen for integrating new team members?

Collapse
 
nestedsoftware profile image
Nested Software • Edited

Is there a significant difference between the two cases? When I mentor someone in this way, I will generally start coding, and explain what I am doing and answer questions as I go along. After about an hour, I'll hand over the keyboard to the mentee. As they are working, I'll try to nudge them in the right direction if they need help. But it's still ultimately pair programming. After all, even if you're the mentor and they are the mentee, they may hit on a good idea you haven't thought of. It's still a process of give and take, as with "regular" pair programming...

Thread Thread
 
kenbellows profile image
Ken Bellows

@mortoray can correct me if I'm wrong, but it sounds like he's talking about pairing up a new dev with an existing team member who will show them around the codebase, help them get set up, maybe assign them a few starter tasks, check in on them periodically, and generally be available for questions, but won't sit down next to them and literally code with them.

Thread Thread
 
mortoray profile image
edA‑qa mort‑ora‑y

Yes/No, as Ken says I'll be assigned to a person and help them along, but not sit with them all day. I will however sit with them as they need it, and watch them code, or code with them.

As to Nested Software's reply, no, what I'm doing is not pair programming. Pair Programming is a specific philosophy to coding that involves an equal relationship where both parties are actively contributing to the code at the same time.

If you are "nudging" somebody, then it isn't an equal relationship, you are acting as the dominant party and trying to help the person learn. That's not what "pair programming" is about. I'm all for coding in pairs and groups, it's the specific "pair programming" which I dislike -- as do many people, and thus the term tends to be applied loosely to many things.

Thread Thread
 
dinsmoredesign profile image
Derek D

Agreed. I've not found "pair programming" in this aspect to be useful. You end up just telling the person what to type when they get stuck and no one learns anything. I have a few people at work who want to work this way and I hate it, because I always feel like I just end up doing their work for them, it just ends up taking way longer because they're the one typing.

I, however, enjoy pair programming when it's with another dev who's equally adept at the task. It helps us work through architectural decisions quickly and if one of us notices a better way to do something, the other understands it quickly and follows through, or a discussion happens to hash it out, not just me telling them what to type.

As a mentor, I think it's more important to show a new dev around the codebase and let them get a feel for it, then let them at it. If they have questions, they can come to me after they've tried to figure it out themselves, but babysitting them all day does no one any good, they will never grow as a developer because they never learn to think for themselves.