Companies that want that sort of environment need to structure the entire business process around spontaneous collaboration, not just pay lip service to it.

The reason I didn't hit deadline X? 5 "spontaneous collaborations" happened at my desk in 3 days. Wait... I don't get my bonus because we missed the deadline? But... my collaborations helped the marketing dept hit their goal ahead of time, and they did it by coming to my desk and asking me questions. Oh... that'a a different budget?

If you want to foster that sort of behavior, make sure all of the aspects of the business line up in support of it, not just the facilities budget because "open plan" is cheaper than private offices with doors.

This seems fairly anecdotal. Do you believe this is a larger issue that the spontaneous collaboration is causing you to miss deadlines? Ultimately if the marketing goals are met through your efforts why not use this as leverage?

I feel that TheOtherHobbs covered most of the points really well, but I feel that this point needs a bit more direct discussion:

> you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

If you value developer productivity at all, that little bit of friction is a _good_ thing. It means that you have to think for a second about the most appropriate forum for that discussion. And if you decide that you do need to talk to someone, the friction isn't really that high. Click on a user, click on the green button with the camera on it, and you're talking.

In-person spontaneous collaboration is, in my experience as both a developer and a development manager, highly overrated, and the value is very rarely worth the costs. Those costs include lost productivity, developer stress, bikeshedding, and an implicit culture of hostility to anything that doesn't _look_ like productivity (like thinking).

Taking a moment to put on my development manager hat, one of the things I never want to do to my developer employees is interrupt their flow. I go to meetings, so I can give them a brief summary which contains only the information they need to do their job. I work with the customers and listen to 50 minutes of rambling so I can glean the 5 minutes of information my employees need to do their work.

I've hired them, and I'm paying them ludicrous amounts of money, to create programs; to create value for the customer. Anything that gets in that way is up to me to address and remove. And based on my experience as both a developer and a manager, those "spontaneous collaboration" interruptions are usually something that needs to be addressed and removed.

This still doesn't refute the point timr was making: sometimes the most productive thing you can do is stop a programmer from writing code. As a programmer (and an employee), what you're ultimately responsible for is happy customers and solved problems. If your code solves the wrong problem, it has negative value to the organization, as it's just something that all the other programmers will have to trip over later.

The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem. Whether that outweighs the increased individual productivity from eliminating distractions is very much case-specific, which is perhaps why there's so much heat and so little light on this issue. You'll never capture all the complexities on a web forum.

> sometimes the most productive thing you can do is stop a programmer from writing code.

I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP).

> The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem.

How does colocation solve this where remote does not? Do you expect that your co-workers would somehow notice this from looking over someone's shoulder, as opposed to when you pull in a branch of code from your VCS?

Once you've pulled in the code and notice the problem, you can bring it up in the next scheduled standup or hit the little green button next to their name in Hangouts/Skype/...

I can not see how being colocated would do anything to help speed the discovery of this particular class of problem in a way which is not practical using modern telecommunication software. As a point of reference, I have personally pair coded (with anywhere from 2 to 5 people) with folks in England with great success.

From personal experience, the most common way this comes up is that you have a casual hallway conversation with a colleague, they ask "So what are you working on these days?", you tell them, and they respond with "You should talk to so-and-so, he worked on that a year ago and may have some insights" or "Have you heard about technology Foo that's designed just for that problem?" And then you follow up on that lead and realize that the project you just budgeted a week for (and will end up spending a month on, given all the unexpected problems that come up) can be solved in a couple days if you approach it slightly differently.

These are not hypotheticals - there have been numerous points in my career, ranging from being a sole technical cofounder to working in a 50K+ employee company, where a chance meeting has saved me weeks-to-months of implementation effort. And in each of those cases, the solution they suggested was not something I would've thought to look for on my own, because my starting assumption was that it needed code to solve. And similarly, it probably would not have been spotted until the feature was done and the time spent, because usually your coworkers' assumption when you embark on writing a solution is that the solution is necessary.

it's very easy to make sure that it doesn't happen - for example in Scrum there is a term called "morning meetings", where team is talking about what they are planning to do, what they did previously, and talks about some issues if there are any.

I've seen many examples that exactly the same problem as you've written happens even in co-located team, so it's a problem of lack of communication, not of being co-located (or not).

This still makes the assumption that these kinds of watercolor conversations are unable to occur online. They do, either in the form of chat logs, or voice calls prior and after meetings, or just as two people get the desire to BS for awhile after coding.

These behaviors are simply not constrained by the environment, not anymore.

>whereas organizations want to get a bunch of people working at a group optimum.

It's an exceptional and rare organisation where this is even remotely realistic as a goal.

The appearance of productivity is usually far more important than the reality - especially in mid/late corporations, where the most significant outputs are primate status plays and politics.

>what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity.

No sane manager is going to want to do that without a really good reason.

>programmers nearly always err on the side of too little communication

That's because programmers like to be left in peace to work on small, relatively well-defined problems. Communication can be limited to progress and code reviews and goal-setting by team leaders. Everything else is noise.

The real problem with remote working is that too few corps understand it, and too many managers believe employees aren't functional adults who can work without constant supervision.

It's a management issue, not a programmer issue.

I think at some point we're going to see some faddy Harvard Review type write a faddy Harvard Review type book about remote, and it's suddenly going to become the new outsourcing. Because cheap.

But meanwhile - Paul Graham's problem is that he has a nostalgic hankering for a vision of SV and start-up culture that's already well on its way to being disrupted by the global talent he wants to move to the US.

If you're a world-class five percenter, why on earth would you want to move somewhere with insane living expenses and in-bred VC culture of the Valley when you can bootstrap and innovate around it elsewhere?

Does he really believe all that funding and schmoozing and presentation is essential to getting a business up and running on a planet with an Internet?

Graham maybe needs to consider the possibility that those five percenters aren't his future employees - they're his future direct competitors.

Pretty much nothing you've written here refutes what I'm saying. You're a programmer, so naturally, you assume that your optimal use is programming, and you draw conclusions starting from that assumption. But if you moderate that assumption a bit (you're also well-used as a planner, an organizer and as a communicator, among other things), you arrive at a different set of conclusions.

"The appearance of productivity is usually far more important than the reality"

No, that's just cynicism talking. Larger organizations care about your personal productivity, but they care less than small organizations. Part of the brilliance of modern corporations is that you don't always have to be at peak productivity as an individual in order for the company to profit. Which means, in turn, that you can do things like get sick or have a family without having to give up your job. The flip side of feeling less efficient is that you have some cushion when you actually are less efficient.

"I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity."

You obviously don't want to interrupt someone gratuitously, but the point is that your perspective on what's important can differ wildly from your employer's perspective. Keeping someone in "The Zone" is not the only goal. An employee in "The Zone" who is churning out "The Wrong Thing" is worse than no employee at all. So you need communication. And as soon as you need communication overhead, people are going to be interrupted. It's a cost of doing business.

The 5% thing in the original article doesn't add up for me at all. The top 5% of the programmers that I have come across are able to do things that the typical YC company doesn't need at all. He talks about someone who would hire 30 of them if they could. Really? What kind of team would that be? Could you keep them motivated doing all the bits and pieces a startup needs to do? Maybe they are building a new OS. (I doubt it)

It sounds a bit like people shooting the shit about great footballers or something where you up the ante to large it up ;)