It seems to me that the issues you raised could be addressed through simple technological solutions or better management, assuming your company actually wants to embrace remote work.

New hires afraid to ask for help? Make it clear that it's part of their job. Developers need to see another developer's screen? Screen share over Zoom. Multiple employees don't know how to use a tool? Provide a one-hour presentation. Rinse. Repeat.

If the senior developers are grumbling about not wanting to be in the same room as their coworkers, I wouldn't be surprised if the junior devs feel nervous about asking for a few minutes of their time.

It is the job of senior devs to make new employees feel like part of the team.

Even worse when you're in an isolated zoom meeting with a senior dev, and they're talking trash about other developers on your team. There's constructive criticism, and there's macho posturing by fucking douchebags. Even worse when you mention it to management, and they do nothing.

In addition to this, I can wholeheartedly recommend 'screen control sharing' (maybe there's a better name for the category of software I'm referring to?) such as Tuple or Drovio. Being able to pair program with two sets of input devices for the same screen is kind of revolutionary, actually, and has been a key part of collaborating remotely for our team.

They can be solved, but they often aren't. A lot of things that happen implicitly and organically in person need to be explicitly planned and scheduley in a virtual environment.

There should be no hesitation to ping via email. The recipient can respond as quickly as they're able. If they aren't busy that should ideally be within a couple minutes, and the response given will frequently be of higher quality than an off the cuff answer, since external resources can be consulted.

There are many situations in which synchronous feedback won't be possible, wfh or not. For example, when the coworker in question is in a meeting or on vacation. All developers must be able to handle this situation and avoid blockages by switching to another task or an unblocked portion of the same task. The sooner new devs learn to juggle their time and attention in this way, the better.

For sure. The job I had during March 2020 was difficult because my boss came off as unwelcoming to questions at points (even in the office I could see him open my slack messages and ignore them), which made working much more difficult when you're adapting to new systems. Thankfully, I had some great coworkers who were very welcoming and helped me a lot. If there is anything I learned from that, it's that being welcoming and open to questions from a coworker is extremely important. Sometimes it's easy to get frustrated with a coworker, but being able help them kindly is such a huge skill I will continue to appreciate and reciprocate.

Interesting...I'm not a fan of read receipts and typing indicators for messaging applications for reasons like this. If I need to craft a lengthy reply, it could take a day depending on the schedule. If someone never replies though when it is the de-facto-company messaging platform, that is highly problematic. A coworker even mentioned how anxiety-inducing typing a lengthy reply is that involves some lengthier research.

I'm not exactly in that position, but I am in the more junior side of things

In my opinion, what helped me the most is: when an issue arises, like something during an on-call, have the person resolving the issue share their screen and talk through the workflow/debugging process, to whomever is being mentored. The tools/logic/reasoning they use during a live debugging session is invaluable knowledge for incoming engineers.

Honestly I don't see this (and I'm currently working in a large organization onboarding many newer developers every week). It feels easier to communicate knowledge and practices via Slack and Zoom shared screen sessions than it would be trekking around some cube-farm to find someone who probably isn't there because they're playing roller hockey in the parking lot.

> They're missing out on so much institutional knowledge transfer.

What this sounds like to me is your organization isn't documenting things properly. I know, because I've run into this exact same problem on projects at my organization.

"Send me your coding standard."

"Uh, we don't have one."

"Okay, well what's your code review process for integrating changes?"

"It's not written down, I'll have to walk you through it."

"What's my tasking?"

"I'll need to sit down with you in person to discuss that."

The lack of communication skills in software people has never been more obvious than during the quarantines. It's a serious deficit that needs to be addressed. I mean, what happens when one of these people leave, either for greener pastures, something happens to them, or they just simply retire?

I think that this is something senior devs/admins need to try and influence. I've made it a goal to actively mentor the less experienced on my team (and even some senior admins) during COVID. Sometimes I phrase this as "Check out this stupid thing I did." That lowers everyone's guard, and then you can explain how you solved an issue, or how you dealt with a stakeholder in a professional manner. If us senior folks want to have WFH, then we have an obligation to other employees to help them adjust and learn.

> They're also hesitant to ping coworkers and ask for screen sharing time because they can't sense if the more senior developers are working on something.

My team's solution is for one developer to just ping another when needed and if they don't reply for a while, they are busy. Don't be afraid to ask, but don't take a lack of a quick reply personally.

With Slack, whether they are currently working on something is not important. If they are busy, the message can just sit there until they have time.

My $BIG_CO has access to third-party online training materials for things like Git. I've shamelessly used them to learn quickly about new topics, like GraphQL. They'd be a great tool to fill the gap for junior developers. Even for mid-level developers who want to brush up.

While those are useful. I've learned so much from watching more senior developers use their tools. The things you couldn't ask about because you didn't know it existed. Productivity hacks, IDE shortcuts, custom key mappings, codebase traversal, git commands/shortcuts.

management should explicitly invest senior developers' time

build tutorials for things like git

allocate hours of their week to pairing

encourage juniors to ping seniors. and encourage seniors to respond promptly in efficient ways (written communication compounds over time)

etc

It almost sounds like this has exposed flaws in co-working, where nothing gets written down, people are not inviting others to request help/collaboration, and training has to be done manually.

> where nothing gets written down

This is a big problem. More often than not "institutional knowledge" is short hand for "I'm too lazy to write this down, hope I don't get hit by a bus!"

People pretend like writing wasn't invented thousands of years ago.

I agree that this seems to be an issue for new hires that I've seen.

But I think the blame for this lies in management and the seniors on the team. If a fresh out of college grad feels hesitant to ping a coworker then that coworker is doing something wrong. I'm seeing a lot of companies and teams seem to shift this blame to the WFH situation, where really it is a failure of the team to not integrate and work well together in a shifting situation.

Plenty of companies that are remote first have no issue mentoring junior engineers, so I don't see what the excuse is for companies that are not.

> the blame for this lies in management and the seniors on the team

It absolutely does. Point is a lot of industries never formalized training, instead relying on osmosis across teams. That creates a--hopefully temporary--disadvantage for new hires. Again, in some fields.

Management are fixing it - they are requiring everyone to go back to the office.

There’s no shortage of git training available, go send them on a day or two. I guarantee that they’ll be much better teachers than your senior engineers.

> Covid WFH is a real issue for our new developers

I'm seeing this across the board. Learning curves are shallower. Matt Levine commented on it with respect to the Goldman Sachs B.S.:

"...it's usually that 100 hours of work for a first year analyst is probably closer to 80 hours of work for a second year analyst. But first years aren't learning as quickly working remotely, so the time isn't being shaved down, it's just staying at 100 hours a week."

https://www.bloomberg.com/opinion/articles/2021-03-25/matt-l...