While I can understand some of the arguments made about juniors getting some extra benefit from having everything close to hand, the sheer pace of the hit pieces against remote the last month or so is hilarious and very telling.
Disclaimer: I have an acquaintance who works there.
It's not all pink, and our mission is very much to remove the roadblocks, so we need to acknowledge the issues that prevent remote from being seen as a no brainer by some teams today.
I'm a bit older and I couldn't imagine going through this as a fresh grad out of college. I would have loved to have had my hand held in my first days as a dev. I was constantly demoralized by not having the domain knowledge (and not having any comprehensive documentation to learn it), being assigned complicated stories (that even the mid/senior devs had trouble with), and by not having anyone just regularly check in with me and make sure I was doing ok. I would like to continue working remote indefinitely, but man it was really tough starting out as a dev remotely. I say all this to say I do think it's possible to successfully onboard a new dev remotely, but there has to be a plan and resources available to do it and I think your article is a good template.
I agree this isn't a hit piece, but it is definitely lacking substance to arrive at a controversial conclusion.
1. It is now vitally important to have a clear, mutually agreed upon 30/60/90 program the junior is aware of. These need to be measurable, achievable goals, with specific seniors to reach out to to accomplish. The seniors should also be aware and consenting to play as mentor.
2. Senior engineers should proactively pair program, review, or otherwise attend to the junior as much as the junior is comfortable with. (If the junior's discomfort with mentorship gets in the way of their growth, we need to manage the junior. This shouldn't be mistaken for a junior that doesn't need the mentorship and would understandably find this intense attention to be smothering.)
3. The entire team needs to be aware of onboarding the junior. Expect velocity to slow noticeably for a little bit, until the junior is able to do minor bugfixes and tool building, then slow again when the junior takes meatier projects like features.
I see this claim thrown around frequently as if finding great managers or building a great management culture is an easy thing to do. A great manager in engineering needs to be good at engineering and good at management. It's hard enough to hire for one or the other, let alone both.
Being in an office also made it clear how much I worked. I was there on most weekends and people noticed.
I'm not saying that that's more important than the benefits of remote, but people absolutely do act like it's a black and white scenario.
Imagine thinking that a Zoom meeting with a few french people is the same as moving to Paris.
Randomness frequently generates uniform subsequences that feel like they can't possibly be random.
PR firms and middle managers are working over-time to ensure that we go back to the previous model where we all commuted in daily. But the labor market is dictating things atm.
Junior workers will always struggle at a place that doesn't support Juniors to find their own way. some people picture juniors as half seniors. forgetting those roles are completely different in their own way. It's the same reason mid level developers are so much in demand
More likely articles like these are just a response to the immense swell of pro-remote sentiment that's been growing over the last few years.
This article was published by a remote-only org whose product is tooling for remote teams. It's not some anti-remote hit piece.
I have a working theory for why this is, which also explains why tech companies hire unsustainably. But that’s a much longer post.
what? do you think those of us in remote roles just....dont work?