Hacker News Reader

> That's because any line of code will impact on dozens of different things in the program

I'd say that's something to avoid whenever possible.

But that's just pushing the metaphor back a level: in order to know how to design your codebase so that it's well-organized and extensible, you have to have a pretty good understanding of what it does, what it needs to do, and how it does it.

For me... once I get into the zone on that, all the noise in the world can't distract me. But conversations by my desk, other people's music, drive-bys by the boss, all those things make it harder to get into the zone. (Though, for me, this means it's way easier to work around strangers in a truly shared space than around co-workers who I'm more likely to talk to.)

On the other hand: Foosball, ping pong, video games -- all those are obviously distractions. They're there to make it easier to take a break without checking out and going home for the day, but I've seen many people (shared office or no) fall into the trap of letting the job be the distraction from the play.

>But that's just pushing the metaphor back a level: in order to know how to design your codebase so that it's well-organized and extensible, you have to have a pretty good understanding of what it does, what it needs to do, and how it does it.

There's also the risk of design paralysis. Where you focus so much on perfect program design that adding a new feature or making a change is offset by excessive, obsessive time spent making sure it fits the design absolutely perfectly. Some programmers think more about the aesthetics and organization of their code than the actual function. They may make large refactors with every minor change or spend hours thinking about the design when just implementing their first intuition would be way more efficient for both their present and future selves.

So, in some cases it may actually take more time to make a change to a well-designed codebase vs. someone who's just plugging things in as they go and refactoring later when they need to. But I would agree the opposite problem of poor design is far more common and that it's usually much faster to make changes to a well-designed application.

Ok, but the purpose of my explanation is not to be technically correct, but to get a manager to understand why programmers need to be undisturbed. So if it is a little inaccurate, but accomplishes the goal, then I think developers should use it as needed.

I've heard variants of this before, and while it's not wrong, I feel that once you're done telling a 200-word story to explain something, you'll have lost most of your audience. It's no longer an easy metaphor. They're not going to go back to their managers and tell a 200-word story, so you're limited to people you can talk to directly for a couple minutes.

What I would say, to anyone old enough to have lived through the HD->SSD transition, is: "Quiet offices are an SSD for programmers' brains."

It's short, it's simple, it's repeatable, it's understandable. I think it's more or less true, and it's hard to argue against SSDs. We buy our programmers SSDs for their computers, so why wouldn't we want them for their brains, too?

PG penned this a couple years ago about the manager's schedule and the maker's schedule; it's still just as true today.

http://www.paulgraham.com/makersschedule.html

>why software developers need to be left undisturbed

I've tried explaining this to manager and business type of people. I've even shown them articles and papers about this topic. All I've ever gotten is mocking and scoffs about how we aren't special snowflakes and how every job requires thinking and concentration. Maybe they are right. I've never been a manager or business person. But it seems to me they spend an awful lot more time talking and creating powerpoints than they do thinking.

> But it seems to me they spend an awful lot more time talking and creating powerpoints than they do thinking.

As far as I can tell, that's how they do their thinking!

In comic form: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-... ("This Is Why You Shouldn't Interrupt a Programmer")

Reading this comment. I have to admit the reason I write 10 lines of code on average is because I spend 95 percent of my work time browsing hackernews or slatestarcodex or dare I say r/the_donald. I also strongly suspect a lot of people are avoiding work in a similar way based on relative productivity.

> Software developers on average write only about ten lines a day

That is far too low of an estimate for any productive programmer. Perhaps when trying to solve some sort of insanely complex bug perhaps?

Depends on the type of software you are writing. If you are hooking up a bunch of libraries you installed with NPM on your node project you will be much more productive than if you are debugging a compiler or working on a hardware level device driver.

If anything, good programming may result in a negative amount of avg. lines/day.

Depends on job though, of course.