Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Short Rant About Working Remotely

ericfarkas.com

Post reply on HN
Print view View original

321–330 of 339 posts

Re: A Short Rant About Working Remotely

#321

Post by calinet6 »

alexko wrote: post #306
greghinch wrote: post #284

Earlier quoted context omitted.

Exactly. This is where having good engineering leadership can come in. A "mediocre"* developer can often be coaxed into producing great product with a little support from things like paired programing and code reviews. You'll probably increase his/her value and abilities in the process. So you need your lead to be awesome. But the rest can just be good people who know how to code. * this would be someone who may not…

The problem here is that the awesome lead will not stay long in a company where all other people are mediocre. Awesome people want to work with other awesome people. There should be a critical mass of them to keep them from leaving.

This is relatively true, but at a small company (< 5 programmers) some people do like the role of "lead" and will stay with it as long as the people they work with aren't total idiots.

Re: A Short Rant About Working Remotely

#322

Post by calinet6 »

justincormack wrote: post #316
lifeisstillgood wrote: post #155

Earlier quoted context omitted.

Totally agree - imagine you could hire Linux Torvalds. He is a great programmer but his best work was sending emails to others for 12 years. This leads to an interesting thought - if you hired Linus and he started spending all his time emailing sarcastic notes to the other developers, how quickly would he get fired for "not focusing on developing code"? Perhaps the key for CEOs is not to grow culture but to hire peop…

And then he goes and creates a version control system when you just wanted a kernel....

... and also he created the kernel, and a way to manage its development better.

I don't see the problem. People who make cool stuff and solve problems in their spare time are the ones you want working for you. Even if they waste time sometimes going off on tangents, it's probably honing their skills and improving something relevant to your company or their own work abilities. No problem, you want that. Trust them to do the right thing.

Re: A Short Rant About Working Remotely

#323

Post by adrianhoward »

falcolas wrote: post #281
adrianhoward wrote: post #43

(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…

"interruptions were greater in number but shorter in duration and more on-task" Given recent studies on multitasking, and the time it takes to get back on task, this does not sound like a positive thing. "an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders" Most "work artefacts' in software development are digital (and easily shared with the modern internet),…

Given recent studies on multitasking, and the time it takes to get back on task, this does not sound like a positive thing.

The question is when does an on-task interruption stop being something that switches modes. Also while the cost of task switching for an individuals productivity may be bad - it may be a net good for the team as a whole.

(BTW which recent studies? Interested in this since most of the multitasking research I'm aware of is pretty old and has the same general message of "it sucks". Would be interested in newer angles on this. Been away from academic cog-pych libraries for a while ;-)

Yes, I'm cherry-picking problem quotes from your cherry-picked quotes, and don't have any studies to back up my beliefs (other than my own experience, which is frankly enough for me).

My experiences have been mixed, but much more positive for co-located team rooms as I've seen folk try different alternatives.

Personally I'd say that the most productive teams I've seen have been co-located - and I've seen several teams who have deliberately moved (temporarily in some instances) to co-locate because they find it works better for them.

That said, most of your citations are old, don't take into account research into human multi-tasking on complex projects, and don't take into account the tremendous advancements in remote communication that didn't exist as little as 5 years ago (github, google+, skype group calls, Trello, Bitbucket, Facetime, etc.)

Most are old - but not all. I also think we tend to overestimate how much things have changed technology wise. I was using video chats, distributed source control, etc. five years ago. What we have now seems to be incremental improvements not game changers.

When I first started looking at this sort of thing six or seven years ago people applied the same arguments about email / internet / web....

Yet another anecdote: the last open office I applied to was definitely a war room... Warmachines, that is. I can't imagine getting anything of value done in that kind of environment.

My experiences have been different. An anecdote battle would probably be pointless - but some other folk in the thread seem to have had similar experiences.

I find it interesting that there's been no newer work showing clear benefits - which is why I'm looking.

Re: A Short Rant About Working Remotely

#324

Post by adrianhoward »

pasbesoin wrote: post #256
SoftwareMaven wrote: post #63

Earlier quoted context omitted.

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…

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.

I too don't know what the numbers are like. I've seen great teams do great things remotely. I've seen great teams do great things co-located. Some of the very best teams I've seen have been co-located. I've also seen some distributed teams fail miserably. I've seen teams co-locate, try remote working, found it didn't work, and co-locate again. And so on.

I wish I knew the relative spread of how these things work out for people in different contexts and on different projects. I just find it suspicious that remote work is often presented as all upside since:

a) In my experience things are rarely all upside - I always start looking for the downside ;-)

b) For whatever reasons a chunk of the dev world tends to be a tad asocial. I know I can be like that. So when something comes up that supports that tendency I wonder if I may be overlooking problems because I would like something to be true.

Re: A Short Rant About Working Remotely

#325

Post by nXqd »

adrianhoward wrote: post #317
insom wrote: post #267

Earlier quoted context omitted.

I'd be interested to know what your 'getting back into the flow' techniques are?

Generally I think about flow in terms of setting up intermittent reward cycles where I need to put in a little bit of effort, but not too much, to get the reward. So I think about ways I get get back into those cycles quickly. To do that I try and cut up my work into the right size chunks, have a plan, and leave work with an "easy win" so I can get back into the loop again quickly. Some examples. Hopefully I'm not de…

The reward technique never works with me. Because, to me, there is not 5m doing something fun. I cannot have something really fun in 5m. So I rather finish all the things in limit time and enjoy the rest of the day, it's the biggest motivation. My only work solution to get back to the flow quickly is leaving something undone. Depend on which task, it will have different ways. Btw, I really love the idea of leaving failing test :D

Re: A Short Rant About Working Remotely

#326

Post by lifeisstillgood »

numbsafari wrote: post #287
tedunangst wrote: post #273

Earlier quoted context omitted.

Very few pieces of the kernel were actually developed by teams. One guy writes this subsystem, another writes a driver. The interactions between components are well established. Approximately 0% of the linux kernel consists of interdependent components simultaneously developed by different people.

I think he's implying the kernel as a whole. Clearly, the whole kernel is developed by a very distributed "team". That said, you get right to the heart of the matter: the interactions between kernel components are well established. Sufficiently so that one person can work independently on a subsystem and another on a driver. In my own personal experience, designing component interfaces is the most important aspect of…

perfect perfect perfect

  In my own personal experience, designing component interfaces is the most important aspect of building a system, especially when you are working with a team. Very often, I have found that the "all in one room" development model is implemented because the team lacks the ability to define those interfaces first.

Re: A Short Rant About Working Remotely

#327

Post by adrianhoward »

darkarmani wrote: post #234
Irregardless wrote: post #162

Earlier quoted context omitted.

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,…

> 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. Team productivity is the sum of individual productivity though. Having all of the individual productivity disrupted is going to lead to lower team productivity. I think Joel said it best 13 years ago: http:…

Team productivity is the sum of individual productivity though. Having all of the individual productivity disrupted is going to lead to lower team productivity.

This is generally untrue in my experience. Team productivity is usually limited by a bottlenecks and silos where progress stops. It seems counter-intuitive but you really can go faster as a whole by slowing some folks down. You don't get faster as a whole until you get your critical bottlenecks in the process faster.

Re: A Short Rant About Working Remotely

#328

Post by adrianhoward »

destraynor wrote: post #219

Jared Spool did a good study on how remote vs colocated affects design. His conclustion is simple enough The best set up, in order, for design work * Best: Everyone in the same room * Good: Everyone remote but in the same time zone * Bad: Some people together, some people apart, in the same time zone * Worst: Some people together, some people apart, all in different time zones. Now the one thing that his work, and in…

++ for linking to some actual research ;-)

Re: A Short Rant About Working Remotely

#329

Post by vsync »

Irregardless wrote: post #33

Who are you to say they don't understand their own business process and culture well enough to determine that remote employees aren't a fit for them? I've worked with several remote team members, and it's always been frustrating. Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello??? Communication is extremely important…

> Why aren't you answering your phone? Why haven't you responded to that email I sent you 5 minutes ago? Are you even at your computer right now? Hello???

That sounds like an incredibly frustrating work environment.

I mean for them, not for you.

Re: A Short Rant About Working Remotely

#330

Post by cloverich »

lotyrin wrote: post #223
adrianhoward wrote: post #163

Earlier quoted context omitted.

This sort of thing is the thing I'd love to see more evidence about. Getting interrupted kills my flow. I'm less productive as I get back into flow (although I have techniques now that let me get into flow much quicker - but that's a separate post). However - is that drop in productivity outweighed by the increase in productivity of the interuptee not having to wait / switch tasks / fumble on and make a mistake / bui…

Times when I've been put in a war room were absolutely infuriating for me, but the tighter loops in bringing people in on what you're doing got the "why not just do X" questions answered much faster. As much as I disliked the interruption, I'm more thankful for all the code that didn't get written because we talked it over first. If I were to estimate, this probably doubled efficacy of our junior devs while halving t…

> If I were to estimate, this probably doubled efficacy of our junior devs while halving the (direct) productivity of senior folks. In my cases, it was immediately apparent that we came out ahead: the former outnumbered the latter by several times.

I really like this. I consider myself an intermediate developer, and can't even count the times a 5-10 minute conversation would have saved me an entire day - or week! - of wasted effort. I think this is easily overlooked because its not totally obvious that interrupting a highly productive, highly skilled developer could result in higher team productivity.

Post reply on HN