29

Elite developers can be 10x more productive than an average developer.

Clearly it's easier to find an elite developer around the whole world than in a company's backyard.

If a company is not located in a programming hot spot, should they consider hiring people who work from home?

3
  • 1
    If you can vote and think this is a useful question or it have useful answers below, please vote up. StackExchange sites need votes to build a good community. You can give 30 votes per day, don't waste them. Specially users with high reputation and low counting votes given please read this: meta.programmers.stackexchange.com/questions/393/…
    – Maniero
    Oct 5, 2010 at 19:22
  • 1
    Should? is hardly relevant. They usually will, whether you like it or not.
    – Job
    Nov 28, 2010 at 1:15
  • Please follow this proposal for that kind of question: Organization aspects
    – Maniero
    Dec 10, 2010 at 19:31

6 Answers 6

32

I have worked as, and managed staff in both situations, and combinations of both. I've made the following observations:

  • Junior staff do not work remotely. They require a good and personal working relationship with a mentor. I find my junior staff would rather wait for me to be available than to ask the rather senior (and good) remote developer anything.

  • Ensure anyone you consider for working remotely is effective when self-guided and doesn't go off on tangents.

  • Remote staff can get isolated really easily and not feel part of a team unless special effort is made to be inclusive of them. This isolation can lead to a misunderstanding of the specific business driver for a project, or to misinterpret events in a negative manner.

  • Never get a contractor working remotely, unless they have the right incentive to perform.

  • When working with a remote team member, make sure they get equitable access to resources, including source control, reference material, etc. Don't make them jump through hoops to get work done.

  • Arrange those face to face meetings as often as practical. This encourages far better team collaboration as people are more comfortable with those they have met.

4
  • I would add use the phone, it's almost always better than email alone. It adds to the inclusiveness thats so hard to get.
    – mattnz
    Dec 1, 2011 at 3:54
  • yup. Phone, Skype, whatever voice comms you can get. Add video if possible. And ++i for not making remote workers feel isolated, and including them in team activities (which is of course very hard if you're taking the team to the pub friday nights after work, as happened in several teams I've worked with).
    – jwenting
    Dec 1, 2011 at 6:50
  • 2
    I'm a contractor that works from home. The incentive to get the work done is loving what I do and always wanting to do the best I can. I think if anyone is hiring contractors that aren't enthusiastic and devoted to their craft, they need to reconsider their hiring policy. Apr 5, 2012 at 10:42
  • Remote contractor's have a terrific incentive to be perform because they are easier to let go. Dec 3, 2012 at 15:29
11

Maybe.

Your benefits are:

  • Access to a wider pool of candidates (as you point out)
  • Access to people who want to work at home

Your costs are:

  • More difficult communication- you can't just pull someone into a free conference room.
  • No guarantee of instant communication- if you're blocked and waiting for Joe Remote, you can't just go over to his desk and ask him what's up. If he's incommunicado, you're SOL.
  • Not all developers work well remotely. Some need the structured environment to be productive.
  • There's often no guarantee of matching schedules- eg, a work-from-home person might sleep in, or a person in another time-zone might be awake and working at different times than you.

Atwood had a decent article about it.

Edit, from Atwood's article:

The minimum remote team size is two. Always have a buddy, even if your buddy is on another continent halfway across the world.

Only grizzled veterans who absolutely love to code need apply for remote development positions. Mentoring of newbies or casual programmers simply doesn't work at all remotely.

To be effective, remote teams need full autonomy and a leader (PM, if you will) who has a strong vision and the power to fully execute on that vision.

2
  • Atwood is now working on an expanded team at SO. I wonder if he has changed his mind?
    – JeffO
    Sep 14, 2010 at 12:57
  • Hey!, who are they calling "grizzled"!? Nov 27, 2010 at 20:43
5

Companies that don't know what they're doing should not have remote employees. The most incompetent manager will only feel like you are working hard if they can actually see you sitting at your computer doing a lot of typing. Also, sitting in useless meetings is one of the best indicators of strong communication and time managment.

When you have people who know what they are doing and are managed by those who know what they're doing, it really doesn't matter when, where, or how they work. They get what's needed done when it needs to be done.

I'm at a company that pays someone to do a direct deposit for payroll AND print out a faux paper check (actual pre-printed check paper), puts it in an envelope and sticks it in our mailboxes. I guess internal email is not secure enough and what would we do with all those checks?. I believe this edict came from the Department of Redundancy Department. If anyone were to work remotely, there would be the extra cost of postage which is a good reason not to let people work remotely - too expensive.

1
  • 1
    Do we really need an equivalent of Slashdot's (+1, Funny) mod for programmers.se? Oct 19, 2010 at 14:49
4

It's okay to have remote people if two things are true:

  1. The people are senior enough and have a track record that means that you trust them to get things done without much supervision and to be proactive about asking for help or letting you know if they are stuck.
  2. The "pulse" of your project is short enough (preferably daily) so that any problems with the arrangement will be identified quickly. I don't just mean someone saying they've done something in a status report or checking an item off a task list, but actual, demonstrable progress with a feature. There are of course lots of ways to do this, but the main trick is to split tasks into small enough chunks that can be done in a day or less, and validate that these tasks are being completed.
2

There are awesome technologies today that make it easy to act as a team without being seated close to each other.

IRC, Jabber or similar chat-type software makes it really easy to keep everyone in the team aware of each other, what they're doing, and feeling free to discuss issues immediately. I use IRC with freenode's groups often and it's like having one big group of developers at hand, acting like a giant collective brain. Apple's got a nice chat client build into Mac OS that also supports video conferencing, especially effective with their laptops.

Imagine how it would be if the company had their own internal chat server, with groups for departments, projects, and work-related interest groups. A developer could ask a question where it would be seen across the company, so another developer anywhere else could see it and answer. The office walls disappear, communication skyrockets and best-practices and code sharing can happen all on their own without someone wielding a big stick.

One of our load-test engineers works remotely about 1/3 of the year, sometimes from his home which is about 30 miles from our office, other times from out of state. He is as effective in the office as he is outside it because he keeps his chat software running, and calls in for our conference calls.

My coworkers on my team sit down the hall so I can't see or hear them. I don't know when they are in their cubes so I send them a chat message, and they respond as soon as possible. I do team programming with one of our engineers at another site. The same thing occurs; We ping each other regularly with questions and/or inane thoughts, and if we need to pick up the pace we'll share a screen and get on the phone. I can't tell if he's in the office or at home, and it doesn't matter. We work the same either way.

Our QA department is split between two different cities in different states, our engineers are spread across our city at about four different locations, but it's difficult to tell because we use our phones and chat regularly. We're all working remotely from each other in reality, so what's the difference? The difference is the corporate mindset.

There are a lot of big advantages to working remotely, and mostly it takes a change in mindset for the employer to try and find out that employees respond positively to it.

-3

I think it also depends on what you want them to do.

If they're contributing to the architecture and overall design of the software, then it could be a problem.

If they're receiving detailed specs and churning out methods, then not so much.

Edit: To clarify, I'm trying to say that if the work can be isolated, then it's fine to give to a remote employee. If, however, it needs detailed discussion and architectural design meetings, then that's very hard to do from different countries.

7
  • Why the vote down? If you disagree, please explain. This answer seems valid. Sep 14, 2010 at 1:31
  • 1
    Yeah, gotta say I'm confused...
    – Damovisa
    Sep 14, 2010 at 4:53
  • 1
    Why do you think it's possible/advisable to do design remotely? Sep 14, 2010 at 10:56
  • 1
    If they can receive specs, they certainly can send new ones or give feedback (no I didn't down vote).
    – JeffO
    Sep 14, 2010 at 13:00
  • My point was that the high-level direction and architectural decisions of the product are better handled in-house. It's far easier to manage if you can just tell the external party what to write than to give them the freedom to decide how the product should fit together. As someone on the outside, they're unlikely to fully appreciate the business model or intended strategy of the organisation.
    – Damovisa
    Sep 15, 2010 at 1:45

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