Hacker News new | past | comments | ask | show | jobs | submit login

In my experience open spaces are preferred by those who are less competent and want to bother me all day with questions.



You never ask people questions when coding?


My favorite argument comes from http://www.joelonsoftware.com/articles/fog0000000068.html : "Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds)."

If a question isn't an emergency, I queue it up by sending email. If it is, I ask in person, fully realizing I'm fucking up their day and hoping that doing so really is in the best interest of the company. I also only check my email a couple of times per day and wear heavy closed headphones for coding, because those elusive moments of flow are about half of what I live for.


"fucking up their day"

This is interesting--I would never feel this strongly about being interrupted unless someone was being overtly rude or annoying. I want to be productive, but I don't feel obligated to plow forward relentlessly hour after hour. If someone breaks my flow to ask a reasonable question, I don't think of it as a big deal. I think true flow is a lot less fragile than many give it credit for. It doesn't vanish anytime a pin drops nearby.

I think there's something to be said for the benefits of a less serious and more relaxed mindset. Working steadily, but not getting all caught up in "how productive am I?" like you're an assembly line robot. Coding is as much an art as a job and often you can be more productive by playing ping pong and chatting for 6 hours then having an insight that saves you 100 hours in the long run because your mind makes a lateral leap about the architecture that almost definitely wouldn't have happened if you had just sat at your desk typing all day.

I still see the benefits of private offices because it can be very beneficial to have the option of silence and intense focus when that is what you need to get over a hump, but it also seems like a lot of programmers are missing the great potential rewards of real creative collaboration--probably because they are used to collaborating in an uptight business-guy kind of way. Instead, they should take a cue from other creative people like artists, poets, and musicians, and allow their minds be free a good portion time through relaxation, speaking freely, and gasp having plenty of thoroughly unproductive fun. The gains in inspiration will easily outweigh the lack of perspiration, and life will become more enjoyable to boot. Isn't that ultimately the point of all this toil anyway?


I'll admit to sometimes getting annoyed when I'm interrupted and lose my train of thought. I like to code, damnit, it's hard when something keeps me from coding. :-/

But I've also found that my stress level just dropped so much when I acknowledged that I get nothing done during business hours, and so ought to just go in and accept the fact that my job is to help other people get things done. I can still fit in 2-3 hours after dinner, once everyone's gone home, and I found when I was doing my startup that 3 hours is about the maximum time per sitting that one can spend doing high-level intellectually creative work without getting totally burnt out. The unfortunate part is that it time-shifts my day (I go in to work around 1:00 PM and work till 9 or 10 at night), which means I only see the sun for half the day. But with enough practice (obviously failing now, since it's almost 3:00 AM), maybe I could swing my sleep schedule around and just have the mornings off to do whatever I want, then go to sleep as soon as I get home from work.


I don't mean to sound like I'm chaining myself to the oars, and it's all a matter of degree. Talking design or shooting the breeze with the other guys is great and all, but sometimes I already know what I need to build if only everyone would just let me keep it in my head long enough to get anywhere on it. I find Joel's "15 minutes" optimistic. When a dozen people need immediate answers about stuff I haven't thought about since last year, and I try and fail a dozen times to actually write some code only to go home exhausted without a single commit to my name, it's utterly demoralizing. I go out of my way to respect others' time in the zone as an overreaction to how rarely mine is.


For me it really depends on what the question is - if I was in the middle of coding and someone asked me a coding related question (especially about whatever we were working on) then that really wouldn't require a context switch.

However, if someone non-technical comes and asks me something (which usually requires a lot of parsing) then that will require a context switch and I will loose a chunk of productivity.


Some of it for me is pure selfishness. I just care a lot more overall about having an interesting day than being productive. An interesting day includes work and solving problems, but it also includes conversation on both technical and random human topics, connecting with people on a deeper than working level, and just plain screwing around. Luckily this all tends to balance out (at least), because maintaining high spirits and an active imagination gives a boost to productivity that's at least as strong as having a private office and slogging away in it stoically every day for 10 hours.


I am not opposed to all questions. I am opposed to the questions that are typically asked by those who prefer open spaces. I am also not opposed to basic questions asked by those who are new to the field, but I am often asked basic questions by those with 3+ years of experience.

Read a book.


It's possible we just know different people who prefer open spaces, but the questions I'm frequently asked are more specific variations on "How does Google's serving and indexing pipeline work?" and "What are the best practices for building JavaScript-heavy webapps in an environment where latency matters?"

There are obviously no books about those topics (well, there are some about the latter, but they're all wrong, and we have experimental data to prove it). And even if they were, they'd be out of date before they were published. Google's indexing system changed completely when Caffeine was launched last year - the only way to get information about it is to ask the people who're responsible for developing it. And the ecosystem surrounding the web is continually changing, and we keep running new experiments to keep up with it, because things that we were absolutely certain were true 5 years ago no longer are.


Most companies are nothing like Google.


> What are the best practices for building JavaScript-heavy webapps in an environment where latency matters?

Well, what are they?


At the moment, confidential. Google derives a competitive advantage from being fast.

I've toyed with the idea of getting permission to release some of the results we've discovered, in maybe a blog series like what Crockford did for JavaScript at Yahoo. Google also derives a strategic advantage from the rest of the web being fast, and IMHO the benefits of making everyone else fast outweigh the benefits of being faster than everyone else. But I've already got a 20% project that takes up like 50% of my time, so I don't have time to organize something like that. Maybe later.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: