5 ms·

> Instead of properly adapting the onboarding and mentoring But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically t

> Instead of properly adapting the onboarding and mentoring But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience. The best mentoring results for me as the mentee and for me as a mentor have been when we're sitting next to each other. The mentor can visually tell when the mentee is stuck, and mentee can tell when the mentor isn't focusing on anything important and is more willing to ask for help. No matter how many times you tell junior engineers to ping you at the first sign of trouble, they're not going to do it. They're going to toil for way longer than needed, unless you're sitting right next to each other.

malfist 3y ago
Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.
- whateverman23 3y ago
  Sorry I edited to include my point there. If you don't have 30-60 minute check-ins with juniors, they're not going to have the same rapid feedback that they'd get from in person mentoring. And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented. I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
  - x86x87 3y ago
    Lol. Are those juniors in the room with us right now? How about letting them figure it out and provide opportunities to chat and ask questions from time to time. Everyone wants superdevelopers but everyone expects that you're going to put a complete noob in a room with a senior developer, they're gonna rub hand and in 2-4 days you're going to have another senior developer. That's not how it works.
belval 3y ago
I like to do virtual desk with Slack, where I will have a channel where I'm always in a huddle and they can drop by when they have questions, just like they would in-office. I have to say as a counter point though that I've had a lot more trouble with coworkers coming to my physical desk for questions that they could have Googled than with Junior getting stuck for extended period of time remotely. It's all a matter of culture and relationships.
- pnutjam 3y ago
  100% this. Keep an open channel for IM and setup regular shadowing. I've been on both ends, learning and teaching. It's way preferable to have your own computer, shared screen vs trying to look at another screen and taking notes. Remote is better for collaboration and training. Proper documentation is a big part of it, and open channels for IM, like slack.
  - whateverman23 3y ago
    > Remote is better for collaboration and training. Oh come on... I get arguing that there are ways to make remote training good enough. Maybe even similar. Maybe even a net-positive when you look at the entire picture (including the productivity and happiness of your senior staff). But saying remote is better for training specifically? No way. That makes no logical sense.
    - pnutjam 3y ago
      Please elaborate how it's better in person? Remote: I can see and hear the person. I can see their screen. I can copy past back and forth (as can they) through the screen sharing app. I can invite others into the training pretty much instantly. I can send links and commands typed properly in the chat. User can record session for later. In person: Usually have to face the person or the screen, can't see both. I have to write down commands and pass them, or type them myself. There is a delay finding others if we need to talk to them. More chance to transpose commands incorrectly by the user. Harder to record the session without losing parts.
throwawayfear 3y ago
The juniors will have to read documentation and spend long hours writing and reading code and understanding what has already been built. Just like all of us who did that and had to do it in order to move up. The idea of spending time "mentoring juniors" has always ended up being an euphemism. It's just a way for non-technical people, at the end of the day, to consume as much time as possible from other people so they can pretend to be doing work. It's clear which juniors are motivated and will make the most of the mentorship and which ones are not. Some are just there for the check and you cannot compromise your senior and higher talent on people who don't want to learn and grow and just want the prestige and check of a high-tech job. It's the same situation with someone who is drowning not listening to orders and taking down their rescuer with them too. If a junior needs someone to sit next to them because they toil for way longer than needed on clear simple requirements and goals, this may not be the field for them. I never needed anyone right next to me that couldn't have been a direct message or a brief remote call to clarify something specific, clear, and to the point. You're describing a reality where the people who don't do are just trying to take as much time for themselves as possible to hide the fact that they don't want to think.
asyx 3y ago
It's really not an issue to have a junior bang their head against the wall for a few hours and then telling them that they should have gotten help sooner. They won't do that every single time. At some point they'll realize that asking for help isn't an issue.
x86x87 3y ago
Yew, if only we could assign a senior engineer to watch over every new person that joins /s Part of learning to be a sw developer is learning how to go about your work. Learning when to ask for help. If someone is doing this for you, you'll never going to learn.
- criddell 3y ago
  Why the /s? I happen to agree with that statement. Part of being a senior engineer is to use the mentorship skills you developed along the way and make judgements about how much struggle is right. Every new person should have a more senior partner with whom they can ask the dumb questions and not be made to feel dumb.
- commandlinefan 3y ago
  > learning how to go about your work There are whole college degree programs designed to teach this, in fact.
lambersley 3y ago
Agile environments are much better at this. Its inherent frequent touchpoints and "fail fast" mindset can help to ensure the juniors are getting as much information and direction as required.
ta1243 3y ago
> But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience. We've used day long zoom windows or slack huddles. Keep muted until you want to say something. Slack is the same thing, just send a message.
mejutoco 3y ago
Pair programming sessions.
lukeschlather 3y ago
Effective use of group chat works well. The most effective remote teams, there are little conversations happening in the team Slack, often more than once per hour that can go for 5-10 minutes. Some people are bad at communicating over text but some people are also bad at communicating in person and in-person just biases for the latter, it's not inherently better. It can be helpful to hop on video but there's a ton of ways to communicate, often more effectively and less disruptively.

malfist 3y ago

Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.

whateverman23 3y ago
Sorry I edited to include my point there. If you don't have 30-60 minute check-ins with juniors, they're not going to have the same rapid feedback that they'd get from in person mentoring. And very importantly, I'm saying 30-60 minute remote check-ins are an absolutely insane idea that should never be implemented. I don't know any kind of remote system that provides for anything even close to the power of in-person mentoring.
- x86x87 3y ago
  Lol. Are those juniors in the room with us right now? How about letting them figure it out and provide opportunities to chat and ask questions from time to time. Everyone wants superdevelopers but everyone expects that you're going to put a complete noob in a room with a senior developer, they're gonna rub hand and in 2-4 days you're going to have another senior developer. That's not how it works.

belval 3y ago

I like to do virtual desk with Slack, where I will have a channel where I'm always in a huddle and they can drop by when they have questions, just like they would in-office. I have to say as a counter point though that I've had a lot more trouble with coworkers coming to my physical desk for questions that they could have Googled than with Junior getting stuck for extended period of time remotely. It's all a matter of culture and relationships.

pnutjam 3y ago
100% this. Keep an open channel for IM and setup regular shadowing. I've been on both ends, learning and teaching. It's way preferable to have your own computer, shared screen vs trying to look at another screen and taking notes. Remote is better for collaboration and training. Proper documentation is a big part of it, and open channels for IM, like slack.
- whateverman23 3y ago
  > Remote is better for collaboration and training. Oh come on... I get arguing that there are ways to make remote training good enough. Maybe even similar. Maybe even a net-positive when you look at the entire picture (including the productivity and happiness of your senior staff). But saying remote is better for training specifically? No way. That makes no logical sense.
  - pnutjam 3y ago
    Please elaborate how it's better in person? Remote: I can see and hear the person. I can see their screen. I can copy past back and forth (as can they) through the screen sharing app. I can invite others into the training pretty much instantly. I can send links and commands typed properly in the chat. User can record session for later. In person: Usually have to face the person or the screen, can't see both. I have to write down commands and pass them, or type them myself. There is a delay finding others if we need to talk to them. More chance to transpose commands incorrectly by the user. Harder to record the session without losing parts.

throwawayfear 3y ago

The juniors will have to read documentation and spend long hours writing and reading code and understanding what has already been built. Just like all of us who did that and had to do it in order to move up. The idea of spending time "mentoring juniors" has always ended up being an euphemism. It's just a way for non-technical people, at the end of the day, to consume as much time as possible from other people so they can pretend to be doing work. It's clear which juniors are motivated and will make the most of the mentorship and which ones are not. Some are just there for the check and you cannot compromise your senior and higher talent on people who don't want to learn and grow and just want the prestige and check of a high-tech job. It's the same situation with someone who is drowning not listening to orders and taking down their rescuer with them too. If a junior needs someone to sit next to them because they toil for way longer than needed on clear simple requirements and goals, this may not be the field for them. I never needed anyone right next to me that couldn't have been a direct message or a brief remote call to clarify something specific, clear, and to the point. You're describing a reality where the people who don't do are just trying to take as much time for themselves as possible to hide the fact that they don't want to think.

asyx 3y ago

It's really not an issue to have a junior bang their head against the wall for a few hours and then telling them that they should have gotten help sooner. They won't do that every single time. At some point they'll realize that asking for help isn't an issue.

x86x87 3y ago

Yew, if only we could assign a senior engineer to watch over every new person that joins /s Part of learning to be a sw developer is learning how to go about your work. Learning when to ask for help. If someone is doing this for you, you'll never going to learn.

criddell 3y ago
Why the /s? I happen to agree with that statement. Part of being a senior engineer is to use the mentorship skills you developed along the way and make judgements about how much struggle is right. Every new person should have a more senior partner with whom they can ask the dumb questions and not be made to feel dumb.
commandlinefan 3y ago
> learning how to go about your work There are whole college degree programs designed to teach this, in fact.

lambersley 3y ago

Agile environments are much better at this. Its inherent frequent touchpoints and "fail fast" mindset can help to ensure the juniors are getting as much information and direction as required.

ta1243 3y ago

> But... how? Remote check-ins with juniors every 30-60 minutes? That's crazy. But that's basically the only way to replicate the in person experience. We've used day long zoom windows or slack huddles. Keep muted until you want to say something. Slack is the same thing, just send a message.

mejutoco 3y ago

Pair programming sessions.

lukeschlather 3y ago

Effective use of group chat works well. The most effective remote teams, there are little conversations happening in the team Slack, often more than once per hour that can go for 5-10 minutes. Some people are bad at communicating over text but some people are also bad at communicating in person and in-person just biases for the latter, it's not inherently better. It can be helpful to hop on video but there's a ton of ways to communicate, often more effectively and less disruptively.