DEV Community

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

Collapse
 
nestedsoftware profile image
Nested Software • Edited

For team bonding, I think having the whole team do something fun together is a good idea. The particular thing really depends on what people on the team like to do. It could be bowling, or having lunch together, just about anything fun that no one on the team would object to.

For coding productivity, I think nothing beats pair programming. You may not want to do pair programming all of the time, and that's okay. However, I think it is very effective if you're starting a new project or bringing a new developer on board.

  • For a new team, it insures that there is a level of overlap in terms of the basic understanding of how the foundation of the codebase works. If you plan to stop pair programming, you can decide when to do that. My thinking is roughly 2 months as a start, and then re-evaluate.
  • For a single new member, it's a similar idea to the lunches you mentioned: Have the new developer work as a pair for a week or so with each of the other members of the team. It will help them to understand different parts of the codebase and build a rapport with the other developers. It's also a way for them to make small contributions without feeling overwhelmed.
Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

I dislike pair programming, but am in favour of pairing new team members with existing team members. I've often filled this role, but it was never pair programming -- it was more of a mentor and student role.

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.