6

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?

5
  • 4
    This question would be better on Workplace.
    – Blrfl
    Commented Jan 6, 2014 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 ♦
    Commented Jan 6, 2014 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
    Commented Jan 6, 2014 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
    Commented Jan 6, 2014 at 14:53
  • 2
    Lucky is the junior who works remotely. Unlucky is the senior who has to manage him.
    – Reactgular
    Commented Jan 6, 2014 at 15:49

3 Answers 3

Reset to default
10

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.

10

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.

8
  • 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
    Commented Jan 6, 2014 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.
    Commented Jan 6, 2014 at 14:15
  • 3
    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
    Commented Jan 6, 2014 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
    Commented Jan 6, 2014 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.
    – user40980
    Commented Jan 6, 2014 at 16:51
-2

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.

6
  • 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
    Commented Jan 6, 2014 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
    Commented Jan 6, 2014 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.
    – JᴀʏMᴇᴇ
    Commented Jan 7, 2014 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
    Commented Jan 7, 2014 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
    Commented Jan 7, 2014 at 19:04

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