Live data from Hacker News

A Short Rant About Working Remotely

ericfarkas.com

311–320 of 339 posts

Re: A Short Rant About Working Remotely

#311

Earlier quoted context omitted.

Software changes in 7 years - people don't. [I mean the average person; individuals age and get more experienced, but new ones come in.] Today's homo sapiens brains function the same way as in 2006. Productivity of mental workers responds to disruptions in the same way as in 2006. A large majority of programmers and other people working now in IT are the very same people that were analyzed in 2006.

Yes, but haven't the tools for working remotely improved a lot since 2006?

Not really - no. I can't think of anything off the top of my head that I couldn't do six years ago.

There are a few more options maybe - but nothing fundamentally different.

Re: A Short Rant About Working Remotely

#312
post #202

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

Whether or not there are some measurable benefits to the company for telecommuting does not matter . What matters is this: (1) The software company needs your software skills more than you need the company. (2) You decided and plan your life around telecommuting. (3) So telecommuting is non-negotiable. Non-telecommuters tend to be wary of remote workers, not because they are any more or less productive. There's an un…

Whether or not there are some measurable benefits to the company for telecommuting does not matter.

I don't think that it's always this clear cut.

In other words, the managers, speaking for the company say they want more "productivity". What they really need is more control and reduction of risk. They feel a certain level of assurance when they can see people walking into the office on time, every day. It assures themselves of their own continued employment. Give the manager what he needs (the assurance), and this conflict goes away.

This isn't always true - or necessarily often true. Most managers I've deal with over the years are much more focussed on productivity than control. Some maybe think that control is the best route to productivity - but that's a different problem to solve.

For a start - everybody here who's building a startup. As soon as you get employee #1 - congratulations. You're a manager. Are you suddenly unconcerned about productivity ;-)

As somebody who is considering non-founder hires in the next year I'm thinking about ways that I can have them be local and co-located. Despite the fact that this may involve getting an office for the first time, possibly moving locations, hiring newbies and training up rather than hiring for skills, etc. Because, in my experience, the productivity gains could well be worth it. I'm going to experiment at the very least.

Re: A Short Rant About Working Remotely

#313

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

Yeah the biggest difference here is that this is about software development. A room full of people is great when you all need to talk a lot and discuss things and plans and exchange info really quickly and casually. But for programming, I find the best environment is an empty room, no distractions, headphones on, and NO ONE bothering you. That's not gonna happen at an office. Programming requires intense concentratio…

That's not gonna happen at an office. Programming requires intense concentration, hard to get in a room full of people

I'm willing to believe that, for some people, this is true. That they cannot work outside of environments like this.

There are also people who believe that they cannot work well outside of environments like this - but are incorrect (I used to be one of these).

There are also people and organisations who are very successful great developers who love and promote team room environments.

a) I'm not sure of the relative numbers of those groups

b) If the team room environments are a lot more productive then developers of the first sort are going to have long term problems getting work on projects that involve teams of developers

Re: A Short Rant About Working Remotely

#314

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…

This pretty much matches my experiences. I went from a sceptic to a believer in co-located team rooms after seeing this a few times.

Did you also see the incidence of "bad" interruptions drop as the team got more experienced? That's what I've seen pretty much every time I've worked in this sort of environment.

Re: A Short Rant About Working Remotely

#315

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

Here's a study that showed an increase in productivity with telecommuting employees: http://www.marketplace.org/topics/business/freakonomics-radi... A reduction in health risks and distractions are two of the noted benefits. If productivity depends highly on teamwork, telecommuting may not be ideal, but it should improve individual productivity for the right employees.

Thank you. Not come across that one before. Anybody got any references to the original paper?

I'd be interested on whether the comparison is to general open plan offices vs team rooms.

A reduction in health risks and distractions are two of the noted benefits

Health risks? I wonder why. Most accidents happen in the home and all that ;-)

Re: A Short Rant About Working Remotely

#316

Earlier quoted context omitted.

> Most importantly, not every project (nor startup, nor business) needs "the very best" engineers. This is highly underrated wisdom. If you focus on always hiring "Rockstar developers," you'll find yourself in a miserable situation of competition and egotistical conflict. Hire your team, not your developers. Get your team working like clockwork with good systems and good relationships, and your company will be rockst…

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....

Re: A Short Rant About Working Remotely

#317
post #267

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…

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 descending too far into life-hacker wankery here ;-)

* I TDD code, and always try and leave myself with a failing test. If I'm interrupted and don't have a failing test I will deliberately break something or hit undo enough times to get a fail so I have an easy win when I get back.

* I don't track time on task. I do block out time for tasks - and track non-relevant interruptions during that time and see if there are ways to stop 'em happening.

* I run a personal kanban board for stuff so I can keep that continual ping of reward happening during the day.

* I breakdown tasks as they come in so they I can get little reward pings on a regular basis.

* When I have real problems getting into flow I give myself automatic rewards (do 20m on X then you can do 5m of fun on Y). Similar to http://en.wikipedia.org/wiki/Pomodoro_Technique. Once I get started the normal task-achievements often mean I don't actually end up doing Y - it's just a personal hack to get me started.

Basically - fake the reward cycle until the real one takes hold.

Make vague sense?

Re: A Short Rant About Working Remotely

#318

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

I really like the "all things equal" part. Usually all other things are far from equal. You have companies having the entire culture of remote work, availability of skills that's not willing/able to relocate to wherever your company is located etc. etc.

Re: A Short Rant About Working Remotely

#319

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

Very relevant video from Gabe Newell about this topic. http://www.youtube.com/watch?v=t8QEOBgLBQU&t=22m30s

Thanks for that. The experiences he talks about of people naturally seeking co-working spaces is something I've seen too.

Re: A Short Rant About Working Remotely

#320
post #306

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.

Or if you're a startup you give your awesome lead enough equity to have skin in the game, and the authority actually to lead and shape the team.
Post reply on HN