Live data from Hacker News

A Short Rant About Working Remotely

ericfarkas.com

251–260 of 339 posts

Re: A Short Rant About Working Remotely

#251
post #132

Earlier quoted context omitted.

I think after reading the tone of your response I can determine that I would have a difficult time working with this type of personality. As a developer interruptions are a huge productivity drag. I have to stop whatever I'm doing, answer your question, and figure out where I left off and get back into the right mode to program which can take a while. Right now I have a few work-from-home days a week and I find I'm e…

Like a few others who have responded, you're not seeing the forest through the trees. That's somewhat alarming for a group of people who are supposed to be creative problem solvers. Team productiviy > your individual productivity. It's that simple. Do you think your team members interrupt you just for the fun of it? No, they interrupt you because they need your help to accomplish something. As a resource to the team,…

Are we really talking about "the team" here, or are we talking about a PM who interrupts developers multiple times during a day, in order to re-prioritize tasks, get status reports, etc?

Re: A Short Rant About Working Remotely

#252
post #191

Earlier quoted context omitted.

When they suddenly need a top-level engineer to solve a hard problem, they hire one who consults for three months, works remotely, and visits once or twice. You've essentially described every job I've had since college. That's exactly my experience of how companies actually work in practice.

How does one acquire the connections to be called in as this type of engineer?

produce a development library or product they can't live without. you then become an integration specialist.

Re: A Short Rant About Working Remotely

#253
post #191

Earlier quoted context omitted.

How does one acquire the connections to be called in as this type of engineer?

1. Time 2. Networking, Networking, Networking 3. Be willing to talk about yourself a lot. 4. Act Confident in the face of uncertainty.

If you have experience solving hard problems that helps. I had the good fortune of doing so in graduate school. That lead to a job solving another totally unrelated hard problem, with a technology stack totally unrelated to my graduate work. Once I had two gigs like that, the only people who responded to my resume's were people looking for someone to work with immature technology, or had a very hard problem to solve.

Also once you decide that you want to have a professional career jumping on technology grenades, do not work as an employee. I made that mistake. The nature of grenade jumping is that your are asked to solve a hard problem that needs to be solved in a short time, if you are an employee this amounts to massive hours, (70-90 hour work weeks), of unpaid overtime. Work as a contractor and be sure to bill for every hour. Or be sure to get a very healthy option grant if it is a promising start up. My life has been much happier once I started doing that.

Also be sure to work out, this sort of work takes a severe toll on your health if you do it for 20-30 years.

Re: A Short Rant About Working Remotely

#254
Right on ! I've often wondered the same. It's very annoying too. I can't stand working in offices but if you employee me as a remote employee you get a distraction free, self-motivated, 10+ years experience dedicated worker.. if you want me to come to your office so you can see me do exactly what I can do without coming to the office only with traveling and other distractions... I'll just say, "no thanks!" and find a company that gets it . (P.S. been telecommuting for 8 years and wouldn't have it any other way).

Re: A Short Rant About Working Remotely

#255

Earlier quoted context omitted.

1. How do you define group productivity? 2. I'm willing to bet that most of those studies looked at what happens when you take some "on-site" positions and simply hand them to remote team members. Why? Because that's what usually happens. Companies do not want to alter any processes, team structures or responsibilities to explicitly deal with remoteness. Naturally, if you pretend that someone from another state is si…

* I'm willing to bet that most of those studies looked at what happens when you take some "on-site" positions and simply hand them to remote team members.* You'd lose that bet. There are a variety of different methodologies and areas studied. Companies that embrace remoteness from the start (like GitHub) seem to be doing fine, precisely because they treat remoteness as an asses, not a minor concession someone had to…

These two seem to fall into the category I described:

http://possibility.com/Misc/p339-teasley.pdf

http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

This one does not seem to involve developing software:

http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

Remaining two articles are not publicly accessible.

Re: A Short Rant About Working Remotely

#256

(lightly edited copy of my usual plea for evidence on this topic ;-) Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal. (And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - person…

co-located teams in team-room like settings are much more productive Whenever I've seen this done, the very best employees leave. I am a firm believer that you can train yourself to hop in and out of a reasonable facsimile to the "zone" in much less than 20-30 minutes (I do it all the time)[1]; but the level of distraction of the warroom type environment massively favors your more extroverted engineers. My experience…

The most productive team I worked with, and one of the most senior teams within an organization of several tens of thousands with a very significant development staff, was approximately 50% remote, depending upon how one measured and when one included some remote developers and operations people (also very senior) who were intermittently present depending upon project needs. (Some of the operations people were often on site but located far enough away that much communication was as if they were remote.)

And its trend was increasingly remote. Members sought this once and as they could, because it increased their effectiveness so much. (And lowered costs and total time demands -- e.g. commuting -- in positions that were already delivering far more than 40 hours / week.)

This team outperformed the other teams by a fair margin. And some of the truly remote members were among the most efficient and effective I've seen.

Throughout my career, I've seen very little evidence that physical presence -- colocation -- makes a significant positive contribution in software development. I am biased, I will say, in that I both prefer and need a quiet work environment. I feel validated or "justified" in this need, for me at least, in that I've consistently been one of the most effective employees in the organizations within which I've worked. (And I've had numerous people in all sorts of roles tell me this.)

I don't mind colocation, if quiet offices are provided. However, cubes or worse are largely de rigueur, these days, and even in such open space environments, I've witnessed not just the destructive nature of noise and interruptions, but depending upon the staff member enormous amounts of time wasted on "socializing" of various (very off-topic and sometimes inane) sorts. Doubly bad in that context, in that it invariably distracts surrounding employees who are trying to work. And it builds a conflict between not betraying teammates and one's own need to have them quiet down or take it elsewhere.

As for who tends to "thrive" in such environments? Those who "multi-task", juggling lots of things shallowly to the point of making many mistakes and oversights. Those who are constantly "interacting", meaning most often that they are interrupting someone else to solicit knowledge that they should have or be able to look up themselves. Those who use the concept of "team" to disperse and deflect individual responsibility.

Granted, I and the people I've described may be a minority. But in my observation and perhaps in staid corporate environments, those who benefit from colocation tend to be those who need to be herded and hand-held. Those who want and are really able to get shit down, don't mind face to face but are greatly frustrated with pointless and distracting face to face.

(As an example of this latter, we got many of our meetings down to 15 to 30 minutes, when they were necessary. People knew and held themselves responsible for knowing what was up, and the meeting could quickly focus on problem solving and setting a specific course.)

Re: A Short Rant About Working Remotely

#257

(lightly edited copy of my usual plea for evidence on this topic ;-) Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal. (And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - person…

One thing this does not account for is that your potential developer pool increases by orders of magnitude with remoting. So, while a team might be more productive co-located, your ability to get much higher quality individuals working for you increases dramatically with remoting.

You potentially drive prices down, too, by exploiting cost of living outside your location.

There are plenty of good programmers living in relatively cheap places (Like the Midwest, for example). Pay someone in Minneapolis $10-15k less per year than what that same person would make in Palo Alto and that person could still end up above market for Minneapolis.

Re: A Short Rant About Working Remotely

#258

(lightly edited copy of my usual plea for evidence on this topic ;-) Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal. (And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - person…

co-located teams in team-room like settings are much more productive Whenever I've seen this done, the very best employees leave. I am a firm believer that you can train yourself to hop in and out of a reasonable facsimile to the "zone" in much less than 20-30 minutes (I do it all the time)[1]; but the level of distraction of the warroom type environment massively favors your more extroverted engineers. My experience…

Introvert programmer here. I find the opposite to be true. In an office situation, I'm much less likely to intrude on someone I need to communicate with, and they are much less likely to intrude on me. In an open environment, I get to overhear conversations that then demand my input. Yes, on occasion, I have been interrupted while attempting to formulate a very complex solution in my head, and yes this was frustrating. However, the benefit of all those overheard misconceptions and subsequent explanations vastly outweighed them.

That is why I firmly believe that given any team, it is best to have them collocated in a large but private room.

However, we are not talking here about the optimal location for any given group of programmers. We are talking about finding an optimal group of programmers without having to exclude those outside a 20 mile radius of your geographical location.

Re: A Short Rant About Working Remotely

#259

(lightly edited copy of my usual plea for evidence on this topic ;-) Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal. (And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - person…

What about this case study on the development of Windows Vista? -- http://macbeth.cs.ucdavis.edu/distributed.pdf

Granted, it doesn't study efficiency but defect rates, but having development distributed geographically was shown to have little negative effect.

Re: A Short Rant About Working Remotely

#260
Hi definition video conferencing provides the bridge for most of the challenges employers and employees face with remote working. Being the leader of Cisco's Telepresence and collaboration technology stack, I can say that remote working is entirely feasible and in fact sometimes even better than being there.
Post reply on HN