Here's my way of explaining to managers why software developers need to be left undisturbed.
Software developers on average write only about ten lines a day. The reason the process is so slow is that for each new line of code, you are trying to accomplish a task, and their are a great many different specific ways to do it.
However, you can't pick just any way of doing it. That's because any line of code will impact on dozens of different things in the program, and generally in bad ways. So you have to figure out a line of code that will accomplish the specific thing you are trying to do, but without having any bad consequences for the rest of the program.
This is a complicated puzzle, and to solve it you have to have the whole program, or at least a lot of it, in your mind all at once.
But few if any programmers are smart enough to keep it all in their mind all the time, so for each new line of code they have to sit and think about the program, look up lots of specifics about it, and then get it all organized in their minds. That takes a whole lot of focused attention. Any interruption causes all this to disappear from the programer's mind, and they have to start all over again.
Now I am not a programmer myself, so I may not have this all right. Maybe someone could improve it. Also, it would be helpful to have an analogy for something similar the manager does.
> 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?
>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.
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.
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.
Software developers on average write only about ten lines a day. The reason the process is so slow is that for each new line of code, you are trying to accomplish a task, and their are a great many different specific ways to do it.
However, you can't pick just any way of doing it. That's because any line of code will impact on dozens of different things in the program, and generally in bad ways. So you have to figure out a line of code that will accomplish the specific thing you are trying to do, but without having any bad consequences for the rest of the program.
This is a complicated puzzle, and to solve it you have to have the whole program, or at least a lot of it, in your mind all at once.
But few if any programmers are smart enough to keep it all in their mind all the time, so for each new line of code they have to sit and think about the program, look up lots of specifics about it, and then get it all organized in their minds. That takes a whole lot of focused attention. Any interruption causes all this to disappear from the programer's mind, and they have to start all over again.
Now I am not a programmer myself, so I may not have this all right. Maybe someone could improve it. Also, it would be helpful to have an analogy for something similar the manager does.