Work environment - open spaces, noise, and distraction [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
21
down vote
favorite
I recently turned down a job offer at what seemed like a great company because of their work environment. They have a large, open workspace, and it's fairly noisy. There's not much personal space, and no privacy. People are walking around constantly.
I'm an introvert. I need a quiet, distraction-free space to be productive. I read a lot of things online about other programmers needing the same, but in practice, I rarely see workplaces that offer this kind of environment.
Did I do something wrong by declining a job just based on a noisy and public work environment? Perhaps most software development offices are now arranged for more collaboration, and I am just going to have to learn to deal with it.
I'm looking to find out what the norm is in this industry, if there is any, and what kind of expectations I should set for a quiet, private work environment.
software-industry work-environment office-layout
closed as not constructive by kolossus, yannis, gnat, bytebuster, Rarity Nov 7 '12 at 14:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
21
down vote
favorite
I recently turned down a job offer at what seemed like a great company because of their work environment. They have a large, open workspace, and it's fairly noisy. There's not much personal space, and no privacy. People are walking around constantly.
I'm an introvert. I need a quiet, distraction-free space to be productive. I read a lot of things online about other programmers needing the same, but in practice, I rarely see workplaces that offer this kind of environment.
Did I do something wrong by declining a job just based on a noisy and public work environment? Perhaps most software development offices are now arranged for more collaboration, and I am just going to have to learn to deal with it.
I'm looking to find out what the norm is in this industry, if there is any, and what kind of expectations I should set for a quiet, private work environment.
software-industry work-environment office-layout
closed as not constructive by kolossus, yannis, gnat, bytebuster, Rarity Nov 7 '12 at 14:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
2
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
2
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
1
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18
add a comment |Â
up vote
21
down vote
favorite
up vote
21
down vote
favorite
I recently turned down a job offer at what seemed like a great company because of their work environment. They have a large, open workspace, and it's fairly noisy. There's not much personal space, and no privacy. People are walking around constantly.
I'm an introvert. I need a quiet, distraction-free space to be productive. I read a lot of things online about other programmers needing the same, but in practice, I rarely see workplaces that offer this kind of environment.
Did I do something wrong by declining a job just based on a noisy and public work environment? Perhaps most software development offices are now arranged for more collaboration, and I am just going to have to learn to deal with it.
I'm looking to find out what the norm is in this industry, if there is any, and what kind of expectations I should set for a quiet, private work environment.
software-industry work-environment office-layout
I recently turned down a job offer at what seemed like a great company because of their work environment. They have a large, open workspace, and it's fairly noisy. There's not much personal space, and no privacy. People are walking around constantly.
I'm an introvert. I need a quiet, distraction-free space to be productive. I read a lot of things online about other programmers needing the same, but in practice, I rarely see workplaces that offer this kind of environment.
Did I do something wrong by declining a job just based on a noisy and public work environment? Perhaps most software development offices are now arranged for more collaboration, and I am just going to have to learn to deal with it.
I'm looking to find out what the norm is in this industry, if there is any, and what kind of expectations I should set for a quiet, private work environment.
software-industry work-environment office-layout
edited Feb 12 '13 at 9:42
gnat
3,23273066
3,23273066
asked Nov 6 '12 at 22:34
Tim Snyder
65311015
65311015
closed as not constructive by kolossus, yannis, gnat, bytebuster, Rarity Nov 7 '12 at 14:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as not constructive by kolossus, yannis, gnat, bytebuster, Rarity Nov 7 '12 at 14:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
2
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
2
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
1
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18
add a comment |Â
2
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
2
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
1
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18
2
2
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
2
2
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
1
1
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
14
down vote
accepted
You're not alone -- according to the Joel Test, quiet working conditions are a key to better code.
Having said that, it seems to me that open workspaces are becoming the new normal -- they can be immensely distracting, but they encourage collaboration, and make it more likely that team members will ask questions of each other.
It doesn't hurt that open workspaces are cheaper to set up and maintain, can hold more people, and allow easier supervision (harder to watch youtube).
I personally can usually zone it out, and if not, I throw on the headphones.
There's nothing wrong with declining to work in an open workspace, but you'll most likely find jobs somewhat harder to find.
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
add a comment |Â
up vote
16
down vote
Unfortunately (IMHO) open office has become the norm for most software development shops during the past decade or so.
It is one thing to host one dev team, working on a single project, in the same room. This arrangement, one may argue, increases synergy within the team while isolating them from the noise and interruptions of the rest of the world. So for certain types of projects and people, it may be better than individual rooms.
It is an entirely different thing to host dozens or more developers working on unrelated projects - or even mixed with people doing totally different work - in one huge space. There you almost inevitably get constant noise and interruptions by other people which breaks your concentration but hardly brings you any information relevant to your work. This may be suitable for certain types of jobs, but IMHO definitely not for creative jobs like sw development, where you need - at least part of the time - to focus on and immerse into a subject deeply. However, most companies never make such distinctions - open office is open office for everyone, period.
The classic book on this (and much more) is Peopleware, which discusses some research findings too, and argues strongly against open office. It states that open office was never proven to bring any benefit other than the obvious immediate savings in real estate costs. Any other claim about increasing productivity in general - and specifically for software development work - was only founded on "proof by repeated assertion". Of course, companies liked being trendy and getting immediate cost savings. OTOH (to my best knowledge) noone at these companies has ever estimated / calculated the potential loss of programmer productivity and quality due to noise and interruptions in an open office space - not to mention indirect losses like higher turnover - which (IMHO) most likely dwarf any savings on real estate costs.
A personal story
More than ten years ago, the internal newsletter of the company I worked for published an enthusiastic article about how wonderful it was that everyone, including my team, was moving into an open office space, how that would boost productivity, increase creativity etc. etc. I personally didn't feel like it. To be sure, I interviewed my teammates and noone among the twentyish persons in our team liked the new scheme. On the contrary, all of them complained about the noise, the interruptions from the phone calls and discussions held by the product management and marketing teams and other totally unrelated folks, and the difficulty of actually discussing any issue with our coworkers in the open space without disrupting others. So I sent a mail to the company newsletter, telling all this.
In the next issue, I got a standard response repeating the same claims about how great open office is supposed to be, without any evidence or concrete answer to my statements. I got angry so I did some research on the web - that's how I actually learned about Peopleware :-) - then sent another mail, asking for any concrete evidence about the claimed productivity boost of open office, and citing the opposing research results published by Peopleware. Guess what - the next issue of the newsletter was missing the "readers' letters" section :-/
add a comment |Â
up vote
7
down vote
There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
14
down vote
accepted
You're not alone -- according to the Joel Test, quiet working conditions are a key to better code.
Having said that, it seems to me that open workspaces are becoming the new normal -- they can be immensely distracting, but they encourage collaboration, and make it more likely that team members will ask questions of each other.
It doesn't hurt that open workspaces are cheaper to set up and maintain, can hold more people, and allow easier supervision (harder to watch youtube).
I personally can usually zone it out, and if not, I throw on the headphones.
There's nothing wrong with declining to work in an open workspace, but you'll most likely find jobs somewhat harder to find.
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
add a comment |Â
up vote
14
down vote
accepted
You're not alone -- according to the Joel Test, quiet working conditions are a key to better code.
Having said that, it seems to me that open workspaces are becoming the new normal -- they can be immensely distracting, but they encourage collaboration, and make it more likely that team members will ask questions of each other.
It doesn't hurt that open workspaces are cheaper to set up and maintain, can hold more people, and allow easier supervision (harder to watch youtube).
I personally can usually zone it out, and if not, I throw on the headphones.
There's nothing wrong with declining to work in an open workspace, but you'll most likely find jobs somewhat harder to find.
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
add a comment |Â
up vote
14
down vote
accepted
up vote
14
down vote
accepted
You're not alone -- according to the Joel Test, quiet working conditions are a key to better code.
Having said that, it seems to me that open workspaces are becoming the new normal -- they can be immensely distracting, but they encourage collaboration, and make it more likely that team members will ask questions of each other.
It doesn't hurt that open workspaces are cheaper to set up and maintain, can hold more people, and allow easier supervision (harder to watch youtube).
I personally can usually zone it out, and if not, I throw on the headphones.
There's nothing wrong with declining to work in an open workspace, but you'll most likely find jobs somewhat harder to find.
You're not alone -- according to the Joel Test, quiet working conditions are a key to better code.
Having said that, it seems to me that open workspaces are becoming the new normal -- they can be immensely distracting, but they encourage collaboration, and make it more likely that team members will ask questions of each other.
It doesn't hurt that open workspaces are cheaper to set up and maintain, can hold more people, and allow easier supervision (harder to watch youtube).
I personally can usually zone it out, and if not, I throw on the headphones.
There's nothing wrong with declining to work in an open workspace, but you'll most likely find jobs somewhat harder to find.
answered Nov 6 '12 at 23:40
mcknz
15.7k55468
15.7k55468
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
add a comment |Â
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
But the Joel Test is a tad-bit idealistic, right? And not exactly based on decades of empirical research.
â pdr
Nov 7 '12 at 1:03
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
@pdr agreed -- mainly using it here as an example of the popularity of the idea.
â mcknz
Nov 7 '12 at 1:57
1
1
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
Have you any evidence to back up "they encourage collaboration" and "more likely that team members will ask questions of each other"
â Mark
Aug 20 '14 at 11:59
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
@Mark just anecdotal and personal. Jury's still out on whether or not the collaboration outweighs the distraction. :)
â mcknz
Aug 22 '14 at 20:50
2
2
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
"They encourage collaboration" is certainly a popular sentiment among management types. But I would expect that there's much less collaboration than non-work-related socializing going on.
â Dr. Funk
Apr 12 '17 at 17:08
add a comment |Â
up vote
16
down vote
Unfortunately (IMHO) open office has become the norm for most software development shops during the past decade or so.
It is one thing to host one dev team, working on a single project, in the same room. This arrangement, one may argue, increases synergy within the team while isolating them from the noise and interruptions of the rest of the world. So for certain types of projects and people, it may be better than individual rooms.
It is an entirely different thing to host dozens or more developers working on unrelated projects - or even mixed with people doing totally different work - in one huge space. There you almost inevitably get constant noise and interruptions by other people which breaks your concentration but hardly brings you any information relevant to your work. This may be suitable for certain types of jobs, but IMHO definitely not for creative jobs like sw development, where you need - at least part of the time - to focus on and immerse into a subject deeply. However, most companies never make such distinctions - open office is open office for everyone, period.
The classic book on this (and much more) is Peopleware, which discusses some research findings too, and argues strongly against open office. It states that open office was never proven to bring any benefit other than the obvious immediate savings in real estate costs. Any other claim about increasing productivity in general - and specifically for software development work - was only founded on "proof by repeated assertion". Of course, companies liked being trendy and getting immediate cost savings. OTOH (to my best knowledge) noone at these companies has ever estimated / calculated the potential loss of programmer productivity and quality due to noise and interruptions in an open office space - not to mention indirect losses like higher turnover - which (IMHO) most likely dwarf any savings on real estate costs.
A personal story
More than ten years ago, the internal newsletter of the company I worked for published an enthusiastic article about how wonderful it was that everyone, including my team, was moving into an open office space, how that would boost productivity, increase creativity etc. etc. I personally didn't feel like it. To be sure, I interviewed my teammates and noone among the twentyish persons in our team liked the new scheme. On the contrary, all of them complained about the noise, the interruptions from the phone calls and discussions held by the product management and marketing teams and other totally unrelated folks, and the difficulty of actually discussing any issue with our coworkers in the open space without disrupting others. So I sent a mail to the company newsletter, telling all this.
In the next issue, I got a standard response repeating the same claims about how great open office is supposed to be, without any evidence or concrete answer to my statements. I got angry so I did some research on the web - that's how I actually learned about Peopleware :-) - then sent another mail, asking for any concrete evidence about the claimed productivity boost of open office, and citing the opposing research results published by Peopleware. Guess what - the next issue of the newsletter was missing the "readers' letters" section :-/
add a comment |Â
up vote
16
down vote
Unfortunately (IMHO) open office has become the norm for most software development shops during the past decade or so.
It is one thing to host one dev team, working on a single project, in the same room. This arrangement, one may argue, increases synergy within the team while isolating them from the noise and interruptions of the rest of the world. So for certain types of projects and people, it may be better than individual rooms.
It is an entirely different thing to host dozens or more developers working on unrelated projects - or even mixed with people doing totally different work - in one huge space. There you almost inevitably get constant noise and interruptions by other people which breaks your concentration but hardly brings you any information relevant to your work. This may be suitable for certain types of jobs, but IMHO definitely not for creative jobs like sw development, where you need - at least part of the time - to focus on and immerse into a subject deeply. However, most companies never make such distinctions - open office is open office for everyone, period.
The classic book on this (and much more) is Peopleware, which discusses some research findings too, and argues strongly against open office. It states that open office was never proven to bring any benefit other than the obvious immediate savings in real estate costs. Any other claim about increasing productivity in general - and specifically for software development work - was only founded on "proof by repeated assertion". Of course, companies liked being trendy and getting immediate cost savings. OTOH (to my best knowledge) noone at these companies has ever estimated / calculated the potential loss of programmer productivity and quality due to noise and interruptions in an open office space - not to mention indirect losses like higher turnover - which (IMHO) most likely dwarf any savings on real estate costs.
A personal story
More than ten years ago, the internal newsletter of the company I worked for published an enthusiastic article about how wonderful it was that everyone, including my team, was moving into an open office space, how that would boost productivity, increase creativity etc. etc. I personally didn't feel like it. To be sure, I interviewed my teammates and noone among the twentyish persons in our team liked the new scheme. On the contrary, all of them complained about the noise, the interruptions from the phone calls and discussions held by the product management and marketing teams and other totally unrelated folks, and the difficulty of actually discussing any issue with our coworkers in the open space without disrupting others. So I sent a mail to the company newsletter, telling all this.
In the next issue, I got a standard response repeating the same claims about how great open office is supposed to be, without any evidence or concrete answer to my statements. I got angry so I did some research on the web - that's how I actually learned about Peopleware :-) - then sent another mail, asking for any concrete evidence about the claimed productivity boost of open office, and citing the opposing research results published by Peopleware. Guess what - the next issue of the newsletter was missing the "readers' letters" section :-/
add a comment |Â
up vote
16
down vote
up vote
16
down vote
Unfortunately (IMHO) open office has become the norm for most software development shops during the past decade or so.
It is one thing to host one dev team, working on a single project, in the same room. This arrangement, one may argue, increases synergy within the team while isolating them from the noise and interruptions of the rest of the world. So for certain types of projects and people, it may be better than individual rooms.
It is an entirely different thing to host dozens or more developers working on unrelated projects - or even mixed with people doing totally different work - in one huge space. There you almost inevitably get constant noise and interruptions by other people which breaks your concentration but hardly brings you any information relevant to your work. This may be suitable for certain types of jobs, but IMHO definitely not for creative jobs like sw development, where you need - at least part of the time - to focus on and immerse into a subject deeply. However, most companies never make such distinctions - open office is open office for everyone, period.
The classic book on this (and much more) is Peopleware, which discusses some research findings too, and argues strongly against open office. It states that open office was never proven to bring any benefit other than the obvious immediate savings in real estate costs. Any other claim about increasing productivity in general - and specifically for software development work - was only founded on "proof by repeated assertion". Of course, companies liked being trendy and getting immediate cost savings. OTOH (to my best knowledge) noone at these companies has ever estimated / calculated the potential loss of programmer productivity and quality due to noise and interruptions in an open office space - not to mention indirect losses like higher turnover - which (IMHO) most likely dwarf any savings on real estate costs.
A personal story
More than ten years ago, the internal newsletter of the company I worked for published an enthusiastic article about how wonderful it was that everyone, including my team, was moving into an open office space, how that would boost productivity, increase creativity etc. etc. I personally didn't feel like it. To be sure, I interviewed my teammates and noone among the twentyish persons in our team liked the new scheme. On the contrary, all of them complained about the noise, the interruptions from the phone calls and discussions held by the product management and marketing teams and other totally unrelated folks, and the difficulty of actually discussing any issue with our coworkers in the open space without disrupting others. So I sent a mail to the company newsletter, telling all this.
In the next issue, I got a standard response repeating the same claims about how great open office is supposed to be, without any evidence or concrete answer to my statements. I got angry so I did some research on the web - that's how I actually learned about Peopleware :-) - then sent another mail, asking for any concrete evidence about the claimed productivity boost of open office, and citing the opposing research results published by Peopleware. Guess what - the next issue of the newsletter was missing the "readers' letters" section :-/
Unfortunately (IMHO) open office has become the norm for most software development shops during the past decade or so.
It is one thing to host one dev team, working on a single project, in the same room. This arrangement, one may argue, increases synergy within the team while isolating them from the noise and interruptions of the rest of the world. So for certain types of projects and people, it may be better than individual rooms.
It is an entirely different thing to host dozens or more developers working on unrelated projects - or even mixed with people doing totally different work - in one huge space. There you almost inevitably get constant noise and interruptions by other people which breaks your concentration but hardly brings you any information relevant to your work. This may be suitable for certain types of jobs, but IMHO definitely not for creative jobs like sw development, where you need - at least part of the time - to focus on and immerse into a subject deeply. However, most companies never make such distinctions - open office is open office for everyone, period.
The classic book on this (and much more) is Peopleware, which discusses some research findings too, and argues strongly against open office. It states that open office was never proven to bring any benefit other than the obvious immediate savings in real estate costs. Any other claim about increasing productivity in general - and specifically for software development work - was only founded on "proof by repeated assertion". Of course, companies liked being trendy and getting immediate cost savings. OTOH (to my best knowledge) noone at these companies has ever estimated / calculated the potential loss of programmer productivity and quality due to noise and interruptions in an open office space - not to mention indirect losses like higher turnover - which (IMHO) most likely dwarf any savings on real estate costs.
A personal story
More than ten years ago, the internal newsletter of the company I worked for published an enthusiastic article about how wonderful it was that everyone, including my team, was moving into an open office space, how that would boost productivity, increase creativity etc. etc. I personally didn't feel like it. To be sure, I interviewed my teammates and noone among the twentyish persons in our team liked the new scheme. On the contrary, all of them complained about the noise, the interruptions from the phone calls and discussions held by the product management and marketing teams and other totally unrelated folks, and the difficulty of actually discussing any issue with our coworkers in the open space without disrupting others. So I sent a mail to the company newsletter, telling all this.
In the next issue, I got a standard response repeating the same claims about how great open office is supposed to be, without any evidence or concrete answer to my statements. I got angry so I did some research on the web - that's how I actually learned about Peopleware :-) - then sent another mail, asking for any concrete evidence about the claimed productivity boost of open office, and citing the opposing research results published by Peopleware. Guess what - the next issue of the newsletter was missing the "readers' letters" section :-/
edited Nov 7 '12 at 18:24
answered Nov 7 '12 at 9:55
Péter Török
3,7401124
3,7401124
add a comment |Â
add a comment |Â
up vote
7
down vote
There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
add a comment |Â
up vote
7
down vote
There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
add a comment |Â
up vote
7
down vote
up vote
7
down vote
There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
There are a couple of dominant theories on developer workspaces, and which one you'll see at any given employer tends to indicate their general attitude toward programming.
The traditional model is to give each dev a cube, or an office, in which they can get their work done in solitude. There are advantages, to be sure; it's just you and your keyboard, so you can get "plugged in" more easily without needing to actively shut out the rest of the world. However, this approach tends to create "lone wolves"; coders who go off and code for hours and hours at a time in more or less a vacuum. The solitude can also be a distraction in itself for a lot of the personalities that are drawn to coding; when the isolation and sterility of your environment is very noticeable, it becomes its own distraction (or, more accurately, you tend to invent your own distractions to make up for it).
The newer theory is a more collaborative approach. Put coders in a common, open space that's easy to move around in. Encourage people to move, and they tend to do so, to pair up on a problem, discuss a design, etc etc. It's more of a "lab" environment than an "office" environment. The idea is to improve synergy by increasing the dev team's exposure to each other, while maintaining a focus on the job(s) at hand. In such an environment, it's still possible, and perfectly acceptable, to "tune out" everybody else; a pair of headphones hooked up to your computer (or cell phone or music player) is a very effective way to lose the distractions when you need to focus on what's in front of you.
My experience is that most companies are moving toward the newer arrangement of a team room with no walls. First off, it's what the more team-oriented coders want, and second, it's cost-effective; a few long tables is much cheaper to put into a room than a pre-fab cubicle system. However, in those environments, it's usually good to provide some empty offices as "private rooms". You go in there to answer a personal cell call, or if you need to hash something out with other team members vocally (personal or professional), or if you just need a few hours to close the door, put your head down and code (with laptops or a hosted-desktop environment being a requisite for this ability). The expectation for any of these, however, is that it is a temporary state of affairs.
In contrast to what I just said, my last job switch was from a more Agile-oriented environment with large, open team rooms, to a more traditional cube farm. While both of them took some getting used to, once I did I was productive either way. The difference was more in what I was expected to do; in the team room I was one guy out of a dozen working on the same codebase. In my new job, I've created several new applications with little or no involvement from other devs; collaboration is mostly by request.
edited Jul 3 '13 at 18:18
answered Nov 6 '12 at 23:41
KeithS
2,085912
2,085912
add a comment |Â
add a comment |Â
2
I think, you should change your question a bit. Instead of asking, "what's your experience," which is not constructive, you should rather focus on what particular steps can you take in order to stay productive in a distractive environment.
â bytebuster
Nov 7 '12 at 6:53
No. While I'll admit most answers would be anecdotal, I'm looking to find out what the norm is, if there is any in this industry, and what kind of expectations I should set. I already know how to deal with a (reasonably) noisy work environment.
â Tim Snyder
Nov 7 '12 at 8:00
2
One of the tennants of Agile is to have a collaborative team sitting close to one another and over-communicating. Agile is really picking up steam, so the environment that you have described is becoming more common.
â MrFox
Nov 7 '12 at 15:47
1
@Tim76 I modified your question a bit to remove some questions that I think were the main cause of your question getting closed, and have voted to reopen. Feel free to rollback the changes to your question is this is not what you meant to ask. :)
â Rachel
Nov 8 '12 at 17:33
A very interesting, very related question: workplace.stackexchange.com/questions/60787/â¦
â José Luis
Feb 8 '17 at 12:18