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?

gnat
  • 21,442
  • 29
  • 112
  • 288
Brett Postin
  • 178
  • 1
  • 5
  • 4
    This question would be better on Workplace. – Blrfl Jan 06 '14 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 06 '14 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 06 '14 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 06 '14 at 14:53
  • 2
    Lucky is the junior who works remotely. Unlucky is the senior who has to manage him. – Reactgular Jan 06 '14 at 15:49

3 Answers3

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
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.

JᴀʏMᴇᴇ
  • 2,361
  • 4
  • 22
  • 25
  • 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 06 '14 at 13:33
  • I've always wondered about the benefits of remote working from an employer's point of view; I get the impression it's a perk for those remotely working as opposed to the employer. Unless, of course you mean outsourcing to somebody offshore. I think your main concern is the fact that you'll have to have self-motivation near the top of your list of criteria when employing juniors. For a good developer to reach a senior status, you can assume they have a willingness to learn and deliver. But your junior dev must now be someone who wants to get there and progress whilst under a less watchful eye. – JᴀʏMᴇᴇ Jan 06 '14 at 14:00
  • 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 06 '14 at 14:15
  • The latter in my opinion. I'd like to think I'm slowly but surely creeping up to senior status, but even I benefit from quick conversations I have with the team now and then. If this can be catered for quite easily with conferencing technology then you're halfway there, but I think another benefit, for juniors in particular, is more of a 'learning life skills' thing; being among senior developers can acquaint juniors with a good way of working and managing tasks. To give access to TFS task lists remotely is one thing, to have them observe the more experienced devs manage themselves is another. – JᴀʏMᴇᴇ Jan 06 '14 at 14:19
  • 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.](http://www.virgin.com/richard-branson/one-day-offices-will-be-a-thing-of-the-past) – Brett Postin Jan 06 '14 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 06 '14 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. –  Jan 06 '14 at 16:51
  • @MichaelT that was my point. current culture doesn't really having this kind of passive interaction enabled for remote employees. This certainly doesn't mean that it would not be possible to have such passive interactions. Open source software, online games, and many other applications perform complicated tasks and training all the time without ever meeting in person. – Seth M. Jan 07 '14 at 15:23
-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.

eebbesen
  • 137
  • 1
  • 8
  • 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 06 '14 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](http://pragprog.com/book/jkrp/remote-pairing) 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 06 '14 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ᴇᴇ Jan 07 '14 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 07 '14 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 07 '14 at 19:04
  • (continued) To your question "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" my short answer is what I expect you're doing for co-located junior devs: pairing and reviewing all/more of their code than you would for more senior devs. – eebbesen Jan 07 '14 at 19:04