Just want to add that I only became (at least in my opinion) a good programmer by sitting next to a very good and passionate one that I was able to question from time to time and may have interrupted his work some days.
I also probably helped him brainstorm ideas with me and debugging, since he would just say what's on his mind while doing it, and I'd do the same, and sometimes this kind of ping pong debugging/brainstorming together yields way better results than solo work. I really like one time he was trying to see how to open the chrome debugger to debug the chrome debugger, and I just knew how to do it (same shortcut while focussed on open debugger) since I had done it by mistake :D
I am convinced that you get more in a collaborative environment having a few devs sitting next to each other in pairs/small groups that they enjoy being with than anything else. IMO with remote work you get hidden inefficiencies that the company can attempt to fix by just hiring more people in the team (and a culture of let's do less meeting, less face to face, more work) takes over and that 1+1=more than 2 environment I was very excited about is gone..
Can someone who is a fan of remote work tell me how a new grad excited about writing code could find a mentor and really up their game in the remote world with what's becoming "standard" way of doing meetings etc?
A counterargument to what I describe is how successful open source projects have always been remote with passionate people working on them
I am a huge fan of mentorship; I benefited from it early in my career, and I strive to offer it to others now. I don't think that requires an open office at all, though. I think mentorship works even better if you're in a quiet environment where you can talk comfortably and not worry about bothering the people around you.
That said, I can attribute one positive effect in my career to having worked in an open office. Early in my career, I happened to overhear someone on the phone dealing with an Open Source licensing issue (and I genuinely do find Open Source licensing interesting), went over to chat with them afterwards, ended up finding out about the company's Open Source review process, one thing led to another, and not long afterwards I co-ran that process company-wide (for a 100k+ person company), which I really enjoyed and which provided a great deal of visibility into all the work happening in the company.
I don't think "happened to overhear one side of someone's phonecall and strike up a good conversation about it" is a "benefit" I'd say is worth the pain of an open office, but I still want to acknowledge it.
Well... I have a counter example of a failure in FOSS, because of remoteness of the responsible department:
At IBM working in a satellite office, I wanted to contribute to Jenkins. The fact that any person with the authority to allow me to do that was "behind an office door". Multiple emails back and forth - I ended up ditching the idea of getting the approval and quit IBM.
Closed doors should be for focus time, which should not be "all the time". Having small team offices and quiet rooms - can contribute to people's ability to focus. But personal offices is just another door that stops people from collaborating will inevitably stop a lot of valuable collaboration.
＞ how a new grad excited about writing code could find a mentor and really up their game in the remote world
Everyone's different, you wanted a mentor next to you, many don't enjoy that relationship. To answer your question, looking at the fresh graduates we take, extremely detailed code reviews, a lot of chat and some pair coding on the overly difficult parts seems to be working good enough for them to reach a decent level within about half a year.
When I onboarded a junior engineer in 2021 I had a one hour scheduled Zoom call every morning for the first three or four months, and we'd Zoom usually at least another hour ad-hoc in the afternoon. He would screen share, I would screen share, and we got a lot of learning and programming done that way. You have to have a culture of people dropping Zoom links at any time and being ready to respond within say, five minutes most of the time. Or at least that's what worked for me.
In the past I've participated in weekly pair coding sessions or group coding sessions, say 2-4 hours on a Friday afternoon. That was with an open source project. The meetings included both maintainers and newer contributors.
Maybe look around for an active open source project you'd like to contribute to, and ask around its community and propose a regular pair/group coding session?
Edit: Crucially, we all took turns "driving", even during a single meeting. Sometimes someone wanted help on a branch, and they started driving and then someone else "took the wheel" for a few minutes then passed it back.
I found our interactions were similar to session-style sports, like skateboarding or bouldering. We all attempted a challenge together and could see how each other approached the problem. As in sports, sometimes even knowing something is possible is all you need.
> I am convinced that you get more in a collaborative environment having a few devs sitting next to each other in pairs/small groups that they enjoy being with than anything else.
Like an open zoom meeting where people unmute themselves only they need to ask something?
With the additional focus-aiding utility provided by services like focusmate?
Similar to people gaming online with audio chat but more disciplined.
Combining home office with virtual open floor communication on demand.
The primary means I've seen it happen by is by being part of a team that does pair programming rather than code reviews. In general I've seen it do wonders for team alignment, integration speed, and ramping up new colleagues, junior or otherwise. It does take a concerted effort to learn and do well though. There are best practices, and putting two random programmers behind the same computer does not necessarily mean they'll find and apply those.
I'm curious to see if there's been studies on its efficacy, and whether or not those studies agree with my entirely anecdotal experience.
Mentorship doesn't have to be interactive. My first boss mainly mentored me over email. In fact, my first job largely worked over email and it was a bit of a culture shock when the next one was largely instant message based and also had daily meetings as well. I felt a bit like I had gone back to infant school.
It may be a bit harder now because as programming became more high level, the cadence of development went up. However I think the skill set that you gain when you are force to work at a lower cadence (and spend more time "sharpening the axe") is still valuable.
I think the interruptions in a group setting have huge disastrous effects as nobody really ever gets into a good flow state.
I'm sure it's useful for training and mentorship, but that's frankly not your employer's problem these days. People switch jobs every year, and if you train up staff only their next company is really going to reap the benefits. If learning on the job raises retention then it's only marginal. If anything it makes people "worth more" and they more easily find the next gig that comes with a pay bump
You can easily skill up by:
- watching conference videos on YouTube
- during code review
- go on your lang subreddit or forums and read about how other people skin their cats
What you want is basically unstructured interruption based code review ~ which is nice for the junior but horrible for productivity over all
I highly, highly disagree. Getting advice on the spot is often critical. And rarely will you get good practical advice like "always do a dry build locally from the command line" on the forums.
I can't even count how many times I had to tell other engineers, that they have to run a clean build locally...
Not to mention, that mentorship can be useful just for the processes that are present within the company.
Too much interruption is bad, I agree, but there are some type of skills / mindset that are 100x times simpler to gain by contact with colleagues than by training on your own (even when looking at forums). Especially on the things that you wouldn't not think about improving.
I had the luck of working with a dude who was extremely good at analyzing data, simply by loading json files in sublime text, doing a mix of pretty-printing, multi-cursors changes (with usually 1000+ cursors), regex-foo, playing with buffers and other linux commands. It was a weird set of skills that was truly magic to behold, and not amount of Youtube conference or code review could have replaced that.
There are some coding livestream that can help with that, but it's not as efficient as being in the room as talented peoples.
The most in sync i've ever been with a team was playing end-game raids in MMO's using ventrilo. huddles, meet, and zoom just aint the same. I've never tried discord though.
The bad: it's a little too cutesy, a little too "gamer" targeted. It's a little tiresome.
The fantastic: In a call, you get individual volume sliders (and mute buttons) for every single participant. I cannot use Zoom after experiencing this, it's simply intolerable to be at the mercy of the person with the loudest and most obnoxious mike/background noise
You got more, maybe the company got more, the senior got less: two jobs, only one pay. Now with remote work, companies really have to carve out budget and time to train people. They don't like that.
> I am convinced that you get more in a collaborative environment having a few devs sitting next to each other in pairs/small groups that they enjoy being with than anything else.
You're confusing collaboration with physicality. Too many people make the mistake of thinking that they need to be sitting next to somebody in order to ask them questions, or have a quick chat, or get them to teach you about a project. Those are all things you should be doing in remote work as well.
They consistently happen at greater frequency with proximity.
Three years of wfh with terrible results before we started returning to the office one day a week, has shown me that proximity is a deal breaker for anyone who wants to progress into roles that require mentorship of others.
A DM will never be as compelling as asking someone something in person. People can and will entirely ignore DMs about topics that they would never ignore in person.
You could reach "generals effect" by being a listener to skilled dev's musings - sometimes all one needs to unblock is to tell somebody else about what the problem is and the solution suddenly pops up without any contribution from the listener. So you could form a symbiotic relationship with a skilled dev - you'd learn their tricks and they'd use you as their "unblocker".
Biggest thing is changing cultural dynamics to make maximal efficiency of remote work. Which includes that sometimes, you get a team of people together temporarily in person to really focus and iterate on issues, but we all know the majority of time, this isn't needed for proper collaboration.
As far as excitement and collaboration goes: this is a culture and communication problem. If your company hasn't done a good job of training people to use the proper tools of collaboration they're not doing it right.
Same with mentorship, it should be done as a (possibly rotating) thing by people who are trained to do just that: be good mentors. This is not a burden that should fall on the uninitiated. This should also have concrete expectations for everyone involved. Its a job in and of itself, after all.
All of these things point to cultural company deficits, they're not an inherently immutable thing that is a downside of remote work.
> Which includes that sometimes, you get a team of people together temporarily in person to really focus and iterate on issues, but we all know the majority of time, this isn't needed for proper collaboration.
Some remote workers here dismisses even that, because it disallows them to take residence at the other side of the world from the office. Mileage truly may vary.
I also probably helped him brainstorm ideas with me and debugging, since he would just say what's on his mind while doing it, and I'd do the same, and sometimes this kind of ping pong debugging/brainstorming together yields way better results than solo work. I really like one time he was trying to see how to open the chrome debugger to debug the chrome debugger, and I just knew how to do it (same shortcut while focussed on open debugger) since I had done it by mistake :D
I am convinced that you get more in a collaborative environment having a few devs sitting next to each other in pairs/small groups that they enjoy being with than anything else. IMO with remote work you get hidden inefficiencies that the company can attempt to fix by just hiring more people in the team (and a culture of let's do less meeting, less face to face, more work) takes over and that 1+1=more than 2 environment I was very excited about is gone..
Can someone who is a fan of remote work tell me how a new grad excited about writing code could find a mentor and really up their game in the remote world with what's becoming "standard" way of doing meetings etc?
A counterargument to what I describe is how successful open source projects have always been remote with passionate people working on them