Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Our company is looking to introduce remote working as an option for its developers.

This book (Remote: Office not required) has been offering some valuable guidance.

However one issue that is not addressed is the employment and management of junior level developers.

In a remote working environment, how do you ensure that junior developers receive the same standard of guidance and experience that they would gain from being around more senior developers in an office environment?

share|improve this question

closed as too broad by gnat, Blrfl, Glenn Nelson, MichaelT, Ozz Jan 6 at 16:47

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
This question would be better on Workplace. –  Blrfl Jan 6 at 13:46
    
Would your staff distant from the office? Could some combination of remote and in-office time be possible for everyone to provide some amount of time in the office and schedule their out-of-office days to conform to a regular schedule instead of being remote 100% of the time? Perhaps with consideration to senior staff members who work closely with mentoring junior staff? –  Thomas Owens Jan 6 at 13:47
    
It's all up for discussion at this point. The book actually states to provide a permanent place of work so that the choice is up to the developers how much remote working they wish to do. –  Brett Postin Jan 6 at 14:45
1  
@Blrfl I did consider it but I wanted to gauge the opinions of the software community specifically, so felt this would be more appropriate. –  Brett Postin Jan 6 at 14:53
1  
Lucky is the junior who works remotely. Unlucky is the senior who has to manage him. –  Mathew Foscarini Jan 6 at 15:49
add comment

3 Answers

up vote 10 down vote accepted

The same way you do in a non-remote working environment: code-reviews, code-reviews, code-reviews. Use headsets and a good collaborative software which allows two people to work together virtually on the same screen.

Of course, for things like making a sketch on a piece of paper or a physical whiteboard you need an electronical pendant, but that should not be much of a problem.

EDIT: of course, there is also a lot of truth in what @JayScott wrote: having junior devs completely out of your local office introduces some risk that you loose some effectiveness in guidance and quality, that's unavoidable. But IMHO this depends a lot on the actual people involved.

share|improve this answer
add comment

In my opinion, not possible. Doc Brown's outlined the main way you can ensure as much progress and quality as possible, but I don't think this will equate to the quality of guidance and progress monitoring a junior would receive whilst working in an office.

To address your question - mimic an office environment as much as possible using conferencing and collaboration technologies, but I do think even with this you're taking a risk.

NOTE: I say 'not possible' because you've stated they're junior, and I'm very aware of how much extra guidance is needed in any scenario with a junior developer. For what it's worth, I think senior developers benefit from having the space to work remotely over an office environment.

share|improve this answer
1  
I agree. The modern office has become an interruption factory and the huge number of benefits introduced by remote working are making it an attractive option for us. We can see how it would work for senior devs, but are concerned with how junior devs would cope in such an environment. –  Brett Postin Jan 6 at 13:33
1  
What makes having your jr. devs in the office more managable? Is it the ability to peak in on them? The Jr Dev's access to team members? I think that both of these issues are resolvable with passive collaboration tools. With the current culture in most corporate environments I agree it probably isn't possible. The culture of the technical staff would need to shift in order to allow for this to work. –  Seth M. Jan 6 at 14:15
2  
The main benefit to employers is the increase in talent pool, and the threat reduction of losing your best employees just because they may have to move from the area. Add to that the cost savings etc there are many benefits to both employers and employees. Richard Branson certainly believes that one day offices will be a thing of the past. –  Brett Postin Jan 6 at 14:49
1  
@JayScott, While I'm not an employer, my mother worked remote for over a decade after moving away from her company's office. She once commented to me that her company's remote employees (including herself) took much fewer sick days than those who worked in the office. Her conclusion was that it's a lot easier to feel too bad to drive 30-60 minutes to work, than it is to feel too bad to walk from bed to computer. –  Brian S Jan 6 at 15:40
3  
@SethM. There is a great deal of information transfer in the banter between two Sr. developers working on a problem that even just listening in on can help a Jr. developer grow (understanding of the code, problems in architecting solutions, design considerations) even if they aren't an active participant. The remote workplace loses much of this valuable resource that Jr.s wouldn't be able to get. –  MichaelT Jan 6 at 16:51
show 3 more comments

The reason usually given for having remote junior developers is cost savings. People in the decision-making chain needs to understand the effort involved to make the cost savings possible and not assume that offshoring automatically equals big cost savings.

I (based in North America) got a successful team of junior developers in Bangaluru to be self-sustaining as a remote entity, but it takes work. I went to India and trained a team of eight developers for three weeks. During this time I got a sense for how each worked on their own as part of the larger team (helping their co-workers, taking leadership roles, etc.). Then I whittled down the team to the four who made the strongest team. When I returned to North America I committed to pairing with remote team members via web conference during their business hours (middle of my night). The other US-based senior developer and I did code reviews of all changes made for several months, always requiring robust unit tests for any committed code.

So it was a lot of work but we were able to retain the team for a few years and it probably saved a little bit of money.

As stated in other comments/answers, mentoring less experienced resources is important, and doing so remotely is more difficult than doing so in person. But it is possible.

share|improve this answer
1  
For us this wouldn't be a cost saving exercise. Our main reason would be to tap into the global talent pool instead of being restricted to that within commuting distance. The concerns we have revolve around being able to offer this option to both existing and future junior developers. –  Brett Postin Jan 6 at 16:42
    
Motives for remoting aside, I think investing time of senior developers to help with mentoring (on- or off-site) in the form of pairing and code reviews is valuable. I have not read this remote pairing book but it may be worth looking into if you decide to use remote pairing as one of your tools. However my answer seems pretty unpopular, so take it with a grain of salt :). –  eebbesen Jan 6 at 16:57
    
I didn't downvote eebbesen, and I agree with most of what you said - I think you may have been downvoted because it doesn't really address the question asked in the OP. –  JayScott Jan 7 at 12:06
    
I think its important to point out that there is a difference between offshoring to save costs and building a global team of peers who all share the same benefits regardless of location. –  Brett Postin Jan 7 at 17:34
1  
@BrettPostin -- agreed. I mistakenly assumed motivations for the junior remotes, but I think (hope) my execution insights are relevant: basically, focus on fostering and enforcing what you feel are key best practices for your development team. In my case that was tdd of code that adhered to strict design pattern implementations. I found that proactive (pairing) and reactive (code review) enforcement of test coverage and pattern adherence were key. (continued in next comment) –  eebbesen Jan 7 at 19:04
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.