I have first hand experience with mentoring a junior dev and he is dead on about it not working remotely. In my experience it quickly devolves into the senior dev answering a continuous stream of emails or instant messages to help troubleshoot some simple issue. Interestingly, one of the biggest issues I have seen is an inability to succinctly communicate the facts around the issue that the individual iss struggling with. A lot of time is spent interrogating them for more info to find out what exactly the problem is. These are the kinds of situations where you really must be able to sit down next to the person to efficiently bring them along and not being able to quickly becomes an exercise in frustration for both parties.
I've found that it takes more preparation from both parties but is still doable.
Each interaction should be treated like a mini presentation. I have a toolbox I use for this that includes:
1. screenshot software
2. screencast software
3. screensharing software
4. videoconferencing with an HD webcam
5. a whiteboard I can point my webcam at
6. note taking (I use evernote)
7. remote assistance software like logmein or teamviewer that lets me take control of the other persons PC or vice versa.
it's not completely seamless, but if everyone is using the same toolbox and is capable of starting a video call, snapping screenshots and sharing them, switching to the whiteboard to brainstorm posting a quick video of the issue/prototype whatever in the shared space then it works pretty well.
The biggest barrier to good remote teams or mentoring that I've found is when no one has the same tools or is willing/knows how to use them. Also, if either side has a resistance to learning knew remote processes or has a grudge against the remote person for being remote or for the need to hire remote (because of lack of talent in the local area) then there's more problems than just not being able to collaborate remotely.
Wow, you go all out! I've mentored remotely and been mentored remotely with nothing beyond email, text chat and (rarely) phone. I'm not sure how that couldn't be sufficient given all of the open collaborations successfully occurring.
Of course it helps if the junior developer also has a project (or any other tasks) matching their current skill set to work on so issues don't have to be solved in real-time to prevent idle+frustrated engineers.
I've actually had more trouble with local mentoring. It is hard to get people thinking deeply about how something works and how to solve problems when they know an answer is a few grunts away.
well I don't use all the tools all the time but I've certainly used all of them at one time or another.
It's not so much having all the tools, but standardizing on a certain set of them and making sure everyone uses them and knows how to. Then if I say, "Let's collaborate on this, I'll send you the document link" my co-worker knows I'm talking about a google doc or a whatever we use.
Sometimes you need feedback but it's not urgent. Could be for a problem your having or maybe just on a new interaction or UI element you're working on. That's an ideal case for grabbing a short video clip rather than trying to describe in an email, "The drop-down panel re-sizes the entire parent element to 100% but only when I . . .etc".
Videoconferencing should really be the default for team interaction remotely. It's takes no additional work over a phone call but you can read the other person better. Over time this makes a big difference in team cohesion.
I keep notes on my work process regardless of whether I plan to share them or not. Being able to share them and even collaboratively edit them is another big time and bandwidth saver as both of us can add debugging notes to a running log or brainstorm together on a new idea complete with screenshots of mockups or grabs from a similar webpage or app.
Interestingly, one of the biggest issues I have seen is an inability to succinctly communicate the facts around the issue that the individual iss struggling with. A lot of time is spent interrogating them for more info to find out what exactly the problem is.
Over 15 years helping people on IRC has taught me that dealing with this is a mentoring skill. There are lots of shortcuts that both get to the root of the problem and foster skills in the junior to suss things out for themselves, or at least formuate their problem better. Streamlining two-headed troubleshooting is a form of pairing and can totally be done remotely.
What's even worse , is that your manager is not aware that you are spending the first hours of your day troubleshooting other's problems and answering questions.
In the office environment the junior dev will come to your desk and everyone sees it, in the remote work he will ping you privately because he is too shy to ask it in the general chat...
Allowing only public chats will not help but just pollute the general channel of communication.
If I get email questions from a junior dev, I try to cc my boss when I respond, just to keep them in the loop and make it clear that I am spending some cycles helping him or her.
