I came across this tweet from a couple days ago and it really struck a chord with me:
// Detect dark theme
var iframe = document.getElement...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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...
@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.
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.
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.
I find having build instructions helps a lot. These should be detailed enough that a new programmer can get your system up and running by following the steps.
If there are any errors, assign another dev who will promptly assist the newcomer, as well as update the instructions.
For me, it's always most frustrating to not be able to get the project running. I find this continues to contribute to divisions between teams and team members as time goes on. If you can't all run the code, there's no way you can properly contribute to it.
Yeah, that's nice and incredible for sure. The problem is that I don't think that this would help with the getting to know idea of the previous comments...
For me i made a game for him like mission impossible :).
When he arrived:
I helped him to discuss with them with some meeting or coffee.
At the end of the game we made a lunch. It was cool :)
When i start in the new team my Scrum Master has made a "game".
He asked to answer in 3 minutes with the collegue beside at that question: "what we're worried about"
Then we spoke in a group of 3 person, and in the end every person explain the concerne at all the team.
It's generate empathy in the team.
There is also this site:
gamestorming.com/
You can find a lot of "Games" for facilitate the integration of new team members
I love this idea! I always try and learn something about my new coworkers, usually just by finding them on a break and trying to start a conversation. I find even just talking to someone for a minute or two is enough for me to get a feel for them, and a good jumping off point for more discussions in the future!
At MousePaw Media, we often get compliments on the onboarding process. But instead of describing that all again in a comment, I'll just link you to my article on the topic...
Onboarding New Developers
Jason C. McDonald ・ Mar 14 '17 ・ 9 min read
There's one thing I've started doing that I didn't describe there, however: Every single intern is pair programming (via VS Code Live Share) with someone at least once a month. I assign different pairs each month, to keep things fresh. I also remind interns that the monthly pair programming is a minimum. They're encouraged to pair program with teammates as often as they (and the other person) likes.
This is definitely awesome!
I feel like it is common in smaller companies (where I have seen it happen), but lost when you go to larger organizations in general, where many people work in silos and don't really know what the other person does 5 cubicles away even after working for said company for half a year.
Mob programming is the best way to onboard people.
Having a 1:1 Coffee break seems like a good idea, but an entire lunch seems too much to me.