News for hackers. Stuff that matters.
Re:Remote work requires communicating more, but less frequently by whateverman23 on Friday August 04, 2023 @11:53AM (#37001717)
> 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.

Re:Remote work requires communicating more, but less frequently by belval on Friday August 04, 2023 @12:04PM (#37001858)
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.

Re:Remote work requires communicating more, but less frequently by pnutjam on Friday August 04, 2023 @01:50PM (#37003376)
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.
Re:Remote work requires communicating more, but less frequently by whateverman23 on Friday August 04, 2023 @03:59PM (#37005070)
> 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.

Re:Remote work requires communicating more, but less frequently by pnutjam on Friday August 04, 2023 @04:13PM (#37005225)
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.

Re:Remote work requires communicating more, but less frequently by whateverman23 on Friday August 04, 2023 @04:22PM (#37005370)
Everything you can do remotely, you can do in person as well. I don't know why you think you can't screen share or send links and commands in a chat if you're in person.

So at minimum, in person would be the same. So I can't possibly see how in person could be worse.

Re:Remote work requires communicating more, but less frequently by pnutjam on Friday August 04, 2023 @04:33PM (#37005499)
So you're just ranting, no data and looks like no experience. OK

In person is worse. I've done both. It's noisier, you're crammed into a cube taking notes, etc. If you're going to use remote tools, what's the benefit of in person?

Re:Remote work requires communicating more, but less frequently by whateverman23 on Friday August 04, 2023 @05:18PM (#37006021)
> looks like no experience

Got it, I see you're in the "make up stuff about the other person" phase of the discussion. No point in continuing here.

Re:Remote work requires communicating more, but less frequently by pnutjam on Friday August 04, 2023 @05:35PM (#37006212)
Sure, all you ever said was you could believe and you could do remote stuff in person. Way to support your statements.
Re:Remote work requires communicating more, but less frequently by asyx on Friday August 04, 2023 @12:22PM (#37002144)
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.

Re:Remote work requires communicating more, but less frequently by x86x87 on Friday August 04, 2023 @12:29PM (#37002245)
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.

Re:Remote work requires communicating more, but less frequently by criddell on Friday August 04, 2023 @01:19PM (#37002936)
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.

Re:Remote work requires communicating more, but less frequently by commandlinefan on Friday August 04, 2023 @01:21PM (#37002980)
> learning how to go about your work

There are whole college degree programs designed to teach this, in fact.

Re:Remote work requires communicating more, but less frequently by throwawayfear on Friday August 04, 2023 @12:05PM (#37001880)
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.

Re:Remote work requires communicating more, but less frequently by malfist on Friday August 04, 2023 @11:55AM (#37001746)
Who suggested checking in with juniors every 30-60 minutes? GP certainly didn't. You're arguing against a strawman.
Re:Remote work requires communicating more, but less frequently by whateverman23 on Friday August 04, 2023 @11:57AM (#37001759)
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.

Re:Remote work requires communicating more, but less frequently by x86x87 on Friday August 04, 2023 @12:32PM (#37002280)
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.

Re:Remote work requires communicating more, but less frequently by lambersley on Friday August 04, 2023 @12:57PM (#37002627)
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.
Re:Remote work requires communicating more, but less frequently by ta1243 on Friday August 04, 2023 @01:47PM (#37003343)
> 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.

Re:Remote work requires communicating more, but less frequently by mejutoco on Friday August 04, 2023 @05:39PM (#37006244)
Pair programming sessions.
Re:Remote work requires communicating more, but less frequently by lukeschlather on Friday August 04, 2023 @05:49PM (#37006325)
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.