I agree with the same concerns that Raimo and Markus have. It's not just acoustic noise, it's also visual noise. I face the entry to our open floor plan office and every time someone walks in I can't help but look to see who it is.
One man offices are cheap and by far the most productive work environment for software development. Any software development organization that's not investing in them isn't thinking strategically. Engineers should be able to face somewhere that's not distracting, and have a quiet work environment without requiring headphones (music can be a distraction too). If you want to collaborate, do it in your office, it should be big enough for a couple people to join you, or a conference room if you need more.
The only criticism I have for one man offices is that it makes it too easy to goof off and surf the web, but that's a different managerial problem. You should make sure all the offices have glass walls so you can see if someone is in their office and have an idea what they are doing. But mainly you should review all code as it's checked in for quality, and it should also give you a good idea of their productivity.
I think Apple has the best idea for this. Their work pods at the new campus have all glass walls facing the hallway, sliding doors to maximize room in the office, and built in storage. There looks to be plenty of room for a couple of coworkers to join you and help collaborate when need be.
I think it's easy to severely underestimate the value of having people overhear conversations and interactions of others beyond their obvious scope of work. If you set things up so only explicitly opted-in collaborations occur, then those are the collaborations you will get: people who all agree they should work together on something. This is a subset of the types of interactions that I believe result in great teams. Many collaborations begin when one person overhears another person they had no idea was working on something relevant to them, or that they could give valuable input on.
As with anything, there is a balance, and I believe there is no silver bullet to designing good offices. But I question those who think there is, and that siloing humans into isolated offices (a fundamentally unnatural state) as the default is objectively the best option.
(And before citing the various studies showing the impact on productivity of doing this, I feel productivity is only one characteristic of what I personally consider to be a good measure of a healthy work environment.)
Offices do not mean having each person locked in their room never interacting with anyone else. They mean you can close the door and be able to focus on something.
In my experience you get a lot more interaction when people have private offices, or at least cubes. It's easy to walk into someone's office and have a discussion. Easier than let's go find a meeting room so we don't disturb everyone. It's also pretty easy to call other people in as needed and have an impromptu meeting without needing to book a room for that and without disturbing others. Not to mention other technologies like e-mail, messaging etc.
The most collaborative places I worked in are those where people had offices and the least collaborative ones have open plans. Anecdotal but there you have it.
Let's face it, open plan offices are about reducing cost and pretending to be collaborative. It's the "Agile" of offices and I don't mean it in a good way.
>It's easy to walk into someone's office and have a discussion.
Certainly less easy than joining in on a conversation you overhear while sitting at your desk.
What we have here is disgreement over the optimal 'activation energy' for social interactions that produces the best work. This parameter depends on all kinds of factors, e.g. the type of work and work culture. What we need is a workflow that optimizes this parameter for a given office.
IOW, somebody needs to come up with a cost function and run gradient descent on it.
It's a little out there, but I think VR workspaces will potentially provide such a method. Currently the iteration cost is too high. (For example it could involve rearranging desks, tearing down walls, buying equipment, etc.) VR opens the door to a malleable workspace that still comes close to pairty with face to face communications (it is not there today but most likely will be in a few generations.)
For large companies, I can imagine using new branch offices for a/b testing.
A while ago I read a comment here about a university that, instead of paving roads to a new campus, just had grass everywhere. A semester later they paved over all the parts where the grass died from all the foot traffic.
I wonder if something like that would be workable? Have easily reconfigurable panels and furniture, encourage the staff to arrange it however they like, wait six months, then standardize/remove pain points/make permanent?
>>It's easy to walk into someone's office and have a discussion.
>Certainly less easy than joining in on a conversation you overhear while sitting at your desk.
If you overhear a conversation and even understand what it is about you clearly aren't focused on your(!) work. So you are in an unproductive state. It's not your duty to think about other peoples problems. If they can't manage it without help they have to ask you (or everybody, in an broadcast) explicitly over an asynchronous communication channel.
There is also no question about whether disturbances are good or bad: They lower productivity and induce stress. This things were shown many times by different scientific studies. This point isn't for debate.
If you want productive cooperation, you have only to encourage people to ask when they are stuck, and also encourage people being as helpful as possible when they are actually asked something. I think that's the true magic formula.
I cannot speak for yakult, but be careful with generalizations like:
> If you overhear a conversation and even understand what it is about you clearly aren't focused on your(!) work. So you are in an unproductive state.
I find it extremely difficult to work alone in an office. When I was still agency-side, before we moved to open workspaces I would often go to coffee shops to work because I found it very difficult to focus unless there was a certain level of conversational white noise. Once we finally did make the move it was great to be able to jump into a conversation on a project I wasn't a direct stakeholder in just because I had something to add (or vice versa). There are any number of day to day things that aren't covered in stand-ups that simply pop up organically.
> There is also no question about whether disturbances are good or bad: They lower productivity and induce stress. This things were shown many times by different scientific studies. This point isn't for debate.
Of course there is a question and of course it's open for debate. We know this because we're not all robots - different people are different. Now, that being said, I absolutely agree that open offices aren't for everyone, which is why in my opinion the magic formula isn't to stick everyone alone in a room and say "talk more", but it's to offer a combination of both open spaces and solitary offices to fit the needs of the individual.
> I cannot speak for yakult, but be careful with generalizations like:
>> If you overhear a conversation and even understand what it is about you clearly aren't focused on your(!) work. So you are in an unproductive state.
That is not an generalization. Explanation follows:
> I would often go to coffee shops to work because I found it very difficult to focus unless there was a certain level of conversational white noise.
Listening to other people is distraction. When you listen and think about what somebody is talking you can't think about your task at the same time. That's the opposite of being focused.
I know there are people having problems to focus on something and need distraction every few minutes. But that's another problem. That people often even think they are productive when they think about several things at once and make jumps in their head from one thing to another, but they simply don't even know what it means to be focused (because they don't have that ability at all).
> it was great to be able to jump into a conversation on a project I wasn't a direct stakeholder in just because I had something to add
From a project management viewpoint that's not great. When somebody is assigned to a task he has to dedicate all the time he is paid for to that task. And not using this time to solve other peoples issues by chance. It also makes tracking the time which was spend for a task imprecise. When e.g. two people where assigned but actually three people where doing it the next time estimate can go wrong because the time someone just jumped in can't be tracked correctly (and on the contrary that time is missing on the other task).
There is a time you sit together and discuss how to make something and then there is the time you actually do it following the agreed plan. In the second phase you need to concentrate so you shouldn't get distracted. Distraction in the second phase is a killer to productivity. Thinking about other peoples problems is distraction.
> There are any number of day to day things that aren't covered in stand-ups that simply pop up organically.
That isn't a problem, that's normal. Send an email, use the chat channel or open a ticket... The small things that pop up can be discussed asynchronously or even later. When you can't do any further work without getting feedback the ahead of time planing was bad and you have to discuss things in more detail the next time. Simply use more time for discussing and planing so disruptions of the working time of others afterwards can be avoided.
>> There is also no question about whether disturbances are good or bad: They lower productivity and induce stress. This things were shown many times by different scientific studies. This point isn't for debate.
> Of course there is a question and of course it's open for debate. We know this because we're not all robots - different people are different.
That question is already answered by scientific studies.
People are indeed different and like I said there are even those who think they can do multitasking. But that's an illusion. The difference between people is only in the amount of drop of productivity. When you try to do several things at once you will have accomplished less at the end of the day. That's a proven fact.
> in my opinion the magic formula isn't to stick everyone alone in a room and say "talk more", but it's to offer a combination of both open spaces and solitary offices to fit the needs of the individual.
Of curse there must be space for both collaboration and focused work. You have to have both. So open offices alone are bad. Individual offices alone are bad, too. You shouldn't be in one of the areas all the time. When you discuss your teams next steps it's much simpler when sitting together. But when you work on the execution of the agreed plan, you have to have a quiet place on your own.
When you can't stay focused in solidity and without distraction you have to work on your ability to concentrate. Maybe it is even a medical condition like ADHD.
Reading through your comment I can't help but think "this is a junior person who has never actually worked in an office."
Offices are complex setups full of complex people, and to think that you can extrapolate your few experiences or a study to cover any office, ever, anywhere is hopelessly naïve.
"But when you work on the execution of the agreed plan, you have to have a quiet place on your own" <- This is simply not true for everyone, as much as you (for some reason) wish that it was. I'm similar to the person you replied to in that I work best in "busier" environments. (Also, just to cut you off at the pass, I don't have ADHD - what a very strange comment to make). It has nothing to do with multi-tasking, I just enjoy and am far more productive working amongst other people than I am working alone in an office. I don't need to "work on my ability to concentrate", as my technical directors can attest to, it's just who I am.
I think you would be well served by understanding that not everyone is like you, and that people have different needs and abilities. It will help as you progress in your career.
> Reading through your comment I can't help but think "this is a junior person who has never actually worked in an office."
Wrong assumption. Almost ten years in professional software development.
> I work best in "busier" environments.
Can you then explain the contradiction how being distracted by visuals, noise and human speech should help to concentrate?
> It has nothing to do with multi-tasking, I just enjoy and am far more productive working amongst other people than I am working alone in an office.
It has a lot to do with multi-tasking. Your brain uses some capacity to process all the distracting inputs. Even if you try not to get distracted by them. That's a subconscious process. Nobody can do anything about it. (Even when you sleep you brain processes inputs from the outside world!)
When you are in a distractive environment your brain loses processing power for the actual task. That's something that can be measured. (A simple test is to let people solve math exercises under time pressure in different environments)
I don't say that working only on your own is the most productive thing to do in every situation, it isn't. Discussing things is much easier when people come together. But when you have to be focused on only one task you have to be in a non distracting environment.
> When you are in a distractive environment your brain loses processing power for the actual task. That's something that can be measured. (A simple test is to let people solve math exercises under time pressure in different environments)
No. This (might) measure the impact of an environment on a specific individual solving math exercises under time pressure...nothing more. If you actually have 10 years of dev experience than you should very well know that this isn't what development is!
> But when you have to be focused on only one task you have to be in a non distracting environment.
I'm standing in the rain telling you it's wet outside and you're pointing to a weather report telling me it's sunny. Not every person is built to a factory spec - we're all individuals. I, and apparently other people in this thread like me, do not do our most proficient work in non distracting environments. It's really that simple : )
I'll ignore your armchair diagnosis that I may have ADHD and just say that it seems like we're largely in agreement on the efficacy of mixed spaced offices.
I think it's better to work on making people better collaborators, than to ruin productivity on the off chance someone will hear something important in a conversation not meant for them. For example, I'm working on using Slack more to cc people on questions I have or things I'm doing so they have a chance to help/stop me or at least be aware of what I"m doing.
If you want a flexible collaborative environment without it's horrible effects on productivity, you could build Apple like pods surrounding an open area. Those who want to work in open areas would work in the middle. Those who need privacy to concentrate can still leave their sliders open during times they are open to collaborate.
I don't believe that ambient information ruins productivity. At least for me, the problem is noise, not signal.
I've spent quite a while working in spaces where the space is devoted to a team. If people are having quiet, focused discussions about what we're all focused on, I rarely find that distracting. The thing that drives me bonkers is when people are having loud, emotional, or off-topic conversations. Then part of my brain wanders off to process it and the rest is compelled to follow.
I also think Slack is rarely a good solution to trying to avoid interruption. If I turn it off for a few hours of coding, I'm far too late to participate. And if I leave it on, there are distractions right there on my screen. There's no way to overhear the useful bits and let the rest go; it requires full visual attention to process. The workplaces where I've felt least effective are the ones with big IM cultures.
I've spent quite a while working in spaces where the space is devoted to a team. If people are having quiet, focused discussions about what we're all focused on, I rarely find that distracting. The thing that drives me bonkers is when people are having loud, emotional, or off-topic conversations. Then part of my brain wanders off to process it and the rest is compelled to follow.
While I'm not good at tuning out any kind of noise, I'd say I'm pretty much the opposite, in that an argument about football or (building) architecture is easier to work through than a "team" conversation that I'm reasonably sure isn't pertinent but contains enough relevant keywords to keep pinging me for attention. My point is that distraction is such a personal thing that the only way to mitigate it is to give individuals a fair bit of control over their environments.
Yes, IM can be a horrible distraction too. If you've got a question that needs some thought from everyone -- as opposed to chatter or ephemeral questions -- then truly asynchronous communication (yes, e-mail...) is probably a better bet.
Could the difference here be that you're in environment where team boundaries are poorly drawn? To me, a team is a group of people who are playing the same game, who win and lose together.
Often I see "team" mean to use something much hazier, like "group of people with same skills" (e.g., design team) or "group of people in the same office". But I mean it more like "basketball team" or "soccer team".
In that environment, there is no team conversation that isn't pertinent, because we're all working to the same goal, and we're all jointly responsible for the same outcome.
That isn't to say that team members shouldn't work to be respectful. E.g., a team conversation over by the whiteboard is easier to let pass by than one where people are standing right behind me. But if we're on the same team, their problems are (eventually) my problems. I'd rather know sooner than later.
100x yes, I think people are often conflating "background conversations" to all be the same thing. I feel bad for people who work in offices where people are so inconsiderate that they start yakking about their kid's baseball game behind some software engineer trying to get some shit done. Or where a topic becomes heated or emotional and they don't take it elsewhere. But rich, constructive conversations that are happening about the work but possibly tangential to the concrete task that that engineer is doing can be immensely valuable in so many ways.
You are right about Slack, but I find most people aren't immediately responding to it so I'm hoping they've turned off notifications and just check it like email most times. Or they use it's Do Not Disturb feature when they need to focus.
> I think it's better to work on making people better collaborators, than to ruin productivity on the off chance someone will hear something important in a conversation not meant for them.
I think this trivializes OP's point a bit. It's definitely a lot more than 'off chance', and make people better collaborators is far from easy. Not saying that you're wrong, but whatever 'building Apple-like pods' is, doesn't sound like this is an option available to many (especially small) offices.
Respect what people communicate about their needs.
Measure the results.
Don't prescribe.
And, in "our" field, presumably you are dealing with "professionals." Treat them as such. If they say they need a resource (including, peace and quiet to concentrate), provide it.
Finally, as others state and I agree, offices do not necessarily mean isolation. If your offices are really soundproofed, impromptu meetings are frictionless with regard to timing and space. Socializing can also take place without people constantly looking over their shoulders to see whether they're being noticed or surveyed.
Provide some common spaces --separated from the offices, so that their are no "losers" who are unwillingly stuck in the noisy offices adjacent.
And if people want to work in a shared space? If you have the room, provide that, too. Let them work in the common spaces, if they like.
Let them do what works for them. Monitor the output.
Lose the ego (speaking generally, not to the parent post nor anyone in particular, here). Open the eyes. (And ears, as it were.)
P.S. In my case, people were repeatedly pleased and sometimes astounded with my work. But I could never get past "the way we do things" and the separation from Management who kept to themselves the actual authority to make any changes that might vary from "the way we do things."
In retrospect, and if my life hadn't deal me a series of crippling blows, early on, I should have become a consultant. Better pay, and the built-in ability to walk away from bad environments. If you need to; sometimes, since you aren't part of the organization, they will just give you what you ask for. Not part of those internal politics.
> I think it's easy to severely underestimate the value of having people overhear conversations and interactions of others beyond their obvious scope of work.
I used to feel the same way, but after trying to balance focus and eavesdropping, I've come to the conclusion that it is too dependent on circumstances. Sometimes the conversations aren't happening in the right places at the right times.
I think this is an unrecognized business problem, probably an unrecognized managerial responsibility. Some developers handle it by cultivating office social relationships with people in various parts of the company, but that's a burden than you can't put on everyone. Not only does it not make sense, but some people will be averse to it or simply not good at it. Rather than put the burden on developers, a good manager should keep the pulse of the rest of the company and keep everyone connected and oriented.
Of course a manager can't do a perfect job, but they should do well enough that their engineers won't feel paranoid about not eavesdropping or gossiping enough.
> siloing humans into isolated offices (a fundamentally unnatural state)
I don't know that it's any more unnatural than asking people to complete demanding individual tasks while other people in their social group have conversations nearby. We're so wired to be social that having conversations nearby virtually compels multitasking, which we're not very good at, which is probably why historically people who have been able to afford the expense of quiet, private workspaces seem to prefer them. "A room of one's own" has become symbolic of the material and social conditions that enable difficult intellectual work.
> I think it's easy to severely underestimate the value of having people overhear conversations and interactions of others beyond their obvious scope of work.
But only if you are not doing any work at that moment.
If you are constantly expected to be able to 'overhear' conversations while coding, I don't see how you could get anything done.
The trick is to make it so people have control. That said, I take issue with the claim people often make that all coding requires complete sound and visual isolation from other humans.
In my experience there are large swaths of software engineering tasks that involve transforming code that are not negatively affected by ambient noise and conversation, and that are relatively easy to context switch in and out of. I realize this probably is heresy to some people but it is the reality I find for myself. That does not mean there are not also large categories of tasks that require dedicated focus and isolation, but I take issue with the claim that all coding needs to occur in a sound proof chamber.
I find myself (and I'm sure many others do) doing these types things in an office environment that often has some ambient conversational noise and do not feel it negatively affects my work to the point where I decide to put on headphones. And no, I'm not talking about a case where someone is yelling in my ear or someone is blasting death metal behind me. I'm talking about a normal open office where people are generally respectful of each others' space and conscious of distractions.
It's great that you don't find conversations distracting, the problem is that others do. The best solution is to offer a work environment that both meets yours and their needs. An open office environment is death to productivity for lots of developers, they don't have the option to shut a door. It simply doesn't and can't work for a large portion of the work force.
A single person office environment is more productive for almost everyone. But it doesn't have to be forced on you, for example there is no reason why center areas can't be left open for those that prefer them.
But in reality the best way to collaborate is to do it in pieces. You come to my office. I come to yours. We invite the team to a conference room.
Yes, note my first sentence "the trick is giving people control." I was countering the commonly held view that for all people, all the time, no coding can be done with ambient noise. This was the claim of the post I was replying to "If you are constantly expected to be able to 'overhear' conversations while coding, I don't see how you could get anything done."
Let me add a third perspective: like you, I have no problem doing those tasks in some light talking in the room. But the reason is because my brain is quite effective at completely shutting them off. Unless you directly address me, I can be right by your side and not actually hear a word you said to someone else. Hence the benefits of overhearing are completely lost on me.
Meanwhile, when I actually need to fully concentrate, even music can be distracting, so there's loss and no gain.
Most people need to concentrate on their take, especially the ones you mentioned. Code reviewing is difficult as you have to look at what the other person is doing, and on the fly try to understand it, unlike the code you've been writing on for sometime
Unit tests sighs have your undivided attention to make sure you are making the test directly and that you aren't missing anything.
It might be easy for you, but not for others
Perhaps the sweet spot is a hybrid between the two, with mandated "shared" hours where you fraternize with peers in a lax environment in addition to your time spent hacking away in the office free from distraction.
If you really need to get something done, bring your laptop or speak with your supervisor about temporary exemption.
Even if "work" is not being produced in the narrow sense, fraternization has undeniable benefits to a company's culture, productivity, and overall cohesiveness.
To me for software engineering I think right now a good local optimum is:
- Ensure portability of workstations with no loss of productivity (powerful laptops, devices, etc)
- Counteract any dynamics that may inhibit opt-in WFH or remote time. (poor tools, cultural perception that it is not productive to wfh, etc)
- Provide in-office tools to opt-in to better isolation (headphones, private 'plug and play' workstations, etc)
- Try to develop some form of cadence where remote time is the norm on regular intervals. For us it's Tu/Thurs, but you could imagine lots of configurations. People I believe tend to then backlog work which requires dedicated focus for these days.
Ideally as a manager you should trust your employees. But I also know when I was self employed it was really hard to get started every day relying entirely on myself, too easy to get distracted surfing the web or working on some side project.
When I'm in an office working with others I have zero problems getting started or working on the right stuff, and never surf the web.
So the question naturally occurs to me. If being visible to others helps make me more productive, would it help others. It's not a question of a manager watching them, but giving them the best environment to work in.
It's horrifying to me that you don't check all of your team's commits. How do they and you improve as developers if you don't discuss how they and you implement things?
Most of software development is spent finding and fixing bugs. Doing a little work up front in validating that code is written well and correctly saves a lot of work on the back end.
In my team, people have responsibility for their code. If they're not sure about something they can ask. If they think it's fine, they can commit and deploy without waiting for a review. If it blows up, they have to fix it, too. For new people to the team, there's usually some amount of frequent code review to start, but once you have shown you know what you're doing, you can just do it.
Knowing if something is likely to cause problems is an important skill, and experience with making bad pushes is probably the best way to learn what is risky and what isn't. (You can and should also learn from other's bad pushes too)
I'm a big believer in making it easy to push, because if it's easy to push, it's easy to push fixes, and you don't have to spend a lot of time with prerelease testing. Clearly you can't push a major change to storage libraries on Friday afternoon, but if you can't trust your engineers to make good decisions, you have the wrong engineers.
I think a significant benefit of my job is that I get to spend part of every day discussing why I or a coworker wrote some code in a specific way. This means I and them are regularly learning and communicating new ways to do things, and improving as engineers.
It's also an important part of our QA process. We test our own code, then we test each others code, then we code review each others code. That adds an important layer of quality that we need. In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review.
> In my job, once an app is on the store it's too late, hundreds of thousands of people are going to be using it in the next 24 hours and you can't stop them or push a fix without at least a 24 hour delay in app review.
Yes, that's absolutely true -- I'm coming from the server side (mostly). On the client side, there are barriers to pushing that can't feasibly be removed -- in that case, it makes a lot more sense to hunker down and make sure every build is good; some users only rarely update for whatever reason, and you don't want them to be running a bad build for months (or to abandon your product because their first download was a bad build).
Sure that's fine if the applications you're working on aren't mission-critical, and if the potential consequences for failure don't involve safety risks, large financial losses, or unrecoverable data corruption. Some of us have to be a little more careful with quality control.
Also a good team should have collective code ownership. No single person can be responsible for any piece of code. What happens when that person is out on vacation?
Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process.
Waiting for code review is frustrating sometimes (and for that reason, it's important to have a culture of prioritizing code review) but it really helps produce higher quality code, which is a major time-saver in the long run. It also has the side effect of keeping other team members informed about what you're doing, which is important for the overall effectiveness of the team.
I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =)
> Not all contributors to a project know all aspects of that project equally well. People also come from a variety of different backgrounds that lends them different insights into the code. Beyond that, it's easy for even experts to make mistakes that they don't recognize in their own work - we've all had the experience of coming back to a piece of writing after a day or two and noticing errors and typos that we couldn't see during the writing process.
I expect contributors who are working on an aspect that they're not familiar with to ask for a review; my policy isn't zero reviews, but just like zero reviews is crazy, I find 100% reviews crazy. Experts will make mistakes too, and sometimes a review would have caught it, but you have to think about the cost to the organization for reviewing all changes, along with the cost of mistakes and consider the amount of mistakes that would be found with pre-push reviews. It really depends on the organization, what the cost of mistakes is: I wouldn't be such a cowboy if I were developing self driving cars instead of communications software; it also helps that there are constant failures beyond our control, that need to be handled -- proper handling of those failures often also handles failures within our control, reducing the impact.
> I agree with you, though, that knowing if things are likely to cause problems is an important skill. If you asked me to give you some examples, not requiring code review would be at the very top of the list. =)
Well, we'd order our lists differently, and have different content in it, but at least we have the same title on our list ;)
What are the downsides to code review? I don't buy that it is a velocity thing.
The only category of changes that I'm willing to accept that may not benefit from code review are small, trivial, low risk changes. (If you think large patches would not benefit from a review process, that's a deeper question but it something if feel 100% to be the case.) But, lucky for us, it turns out that small, trivial, low risk changes are also extremely fast to review. (Like, less than 5 minutes often.) And, haha, sometimes these 'trivial' changes turn out to be not so trivial once a second set of eyes lands on it!
The idea that "developers can take responsibility for their changes" is a tautology: if engineers knew up front that a review was unnecessary, then they would know what to expect in the review. But by definition, the point of review is to catch issues and get feedback that are inaccessible to the author. Therefore, it's impossible for an engineer to self-assess if a change requires review: it would mean they could predict the outcome of a review as well.
The amount of time a review takes wrt to velocity is a self-regulating function, in my experience. If you are dragged on by a review, it probably means the code warranted review. If the review is rapid, then the review was probably less necessary. But it was fast to do anyway, so doesn't meaningfully impact velocity.
Situations like critical bugs and fixes actually are even more important to review, even if they are small patches, because in a incident response situation people are more likely to cut corners, skip steps, or make mistakes due to stress.
So what exactly is the point of skipping code review, given that regardless of patch size, there are clear benefits? The benefits are large enough that I consider the burden of proof to be on those who suggest code review be an optional step for deploying changes.
The one exception I will raise are externally enforced deadlines, where review is not possible in time due to mitigating factors affecting the reviewer. (For example, the reviewer is a domain expert but is out sick, and the software has a necessary delivery date.) But even in these cases, the review should happen in-full post-deployment, and it should be acknowledged that this is a risk-laden move. And often these are showing secondary flaws in the process (why do we have only one domain expert who could review this? why didn't we have more time allocated for review? etc)
In practice, I think a lot of aversion to reviews originate from the frustration of thinking you are finished with a piece of work but having those expectations have to shift after review raises criticism. Everyone wants to ship, especially when they themselves have checked the box that 'it works and I made it as correct as I know how to do.' Addressing reviewer feedback is fundamentally one where you have to draw upon the higher goal of improving code quality and improving your own skills, and like most things that cause real improvements, it can hurt. Honestly, I don't think anyone is free of guilt of feeling this way at one time or another.
Beyond that, other fundamental problems can lead to an aversion to code review, such as reviewers missing the forest for the trees, causing reviews to devolve into pedantry, reviewees misjudging the value of others' feedback, mistrust between team members wrt their feedback being valuable, external pressures due to misaligned expectations about delivery, etc. Counterintuitively, strong aversion to code review, an engineering task, can sometimes stem from all kinds of messy, complex problems with team dynamics. So keep in mind that if people are continually complaining about code reviews, this might be telling you something much deeper going on!
I think in general a solid code review from a peer you trust is one of these things that generally speaking, hurts in the way pushing yourself in exercise does. I personally feel it fosters a kind of skill growth you cannot get otherwise, except perhaps through deliberate practice. In other words, no pain, no gain.
> What are the downsides to code review? I don't buy that it is a velocity thing.
Without code review, my flow is:
a) do the work
b) test it locally until i'm happy with it
c) check it in
d) changelog the change
e) push the change
f) check logs
g) if it works, great; if it doesn't work, consider rolling back, or rolling forward -- either way, go back to a for the code changes to fix the fix
With code review, it becomes:
a) do the work
b) test it locally until i'm happy with it
c) push it to the code review tool
d) wait a while to see if anybody sees it
e) ping somebody, because everyone else is doing work, or eating lunch or whatever
f) wait for them to actually review it
g) if they approved it great; if i have to address things, that's great too, but I have to go back to step a
h) check it in
i) changelog the change
j) push the change
k) check logs
l) if it works, great; if it doesn't work, consider rolling back, or rolling forward
I hate waiting around, and I hate interrupting people, and I hate switching tasks. I want to do my work, and get it pushed out there. Mandatory review for every change means I have to wait around or interrupt people. While I'm waiting, I need to be doing something else productive, but I also need to be watching for a notification that my code was reviewed so I can go push it and see if it works (or address any comments), and switch tasks again. Meanwhile, I have to be prepared to be interrupted to review other people's changes, or I'm blocking them from getting their work finished.
In a world where pushing takes a long time, reviewing everything is more acceptable. When you're pushing to an app store, it's not really possible to have multiple releases in a single day or fast feedback loops, so it makes sense to get more eyes on every change.
My team practices continuous delivery (multiple pushes a day) and code review of all patches. These two practices are not fundamentally incompatible.
Once an author completes a patch, the next stage is to ask for a review. This is not considered an interruption or an annoyance, but a part of the role of being a software engineer on our team (on both sides of the equation.) If the fix is a small fix, then this exchange and an ACK from the reviewer can take less than 5 minutes via slack and a github PR. Modulo things which are extremely urgent, it's normal for an author to bake in an expected ~24 hours turnaround on small/moderately sized patches out of a courtesy for the reviewer. In general, we consider making changes to the application to be a team effort, and as such, having a "buddy" on every change you make isn't an interruption or an annoyance, it is an important part of being a member of the team and working together.
Working within this approach, it's important to break work into digestible PRs (to make it easier to review quickly) and to pipeline other tasks. If code review acts as a lock on your entire body of work, and you literally have nothing to do while a single patch is in-flight, it probably means something else needs to be addressed, not the code review process. At the very least, while your code is being reviewed, most likely there are other bits of other team members' code for you to review anyway :)
For example, if you need to push code to have enough confidence in it to surface it for review, that is a problem to fix. If you have no other tasks to work on while your code is being reviewed by a peer, that is a problem to be fixed. If your teammates consider it an interruption and an annoyance when you ask for peer review, or you are annoyed by having to wait for them to give you honest and thoughtful feedback, that is a problem to be fixed.
I can empathize with the idea that having to pipeline and multitask your work may not be something you are used to, but if you accept the premise that code review is a necessary step in the software development process, this is the norm not the exception. Also code review is just one of many reasons why in practice it's pretty much certain, in my experience, that pipelining work will result in more throughput as a software engineer. (Other examples include similar things which require time to 'bake', like running A/B tests, rolling out software upgrades, and so on. If I had to stop working on everything until a single A/B test converged, I'd have most of the week off :)) Also, pipelining work does not necessarily mean you are rapidly jumping from task to task, which is damaging to creative work, but it means you expend concerted effort in chunks of a few hours at a time and keep moving concrete pieces of work through the pipeline.
> Working within this approach, it's important to break work into digestible PRs (to make it easier to review quickly) and to pipeline other tasks.
Ok, so here's the trade-off. You can do all these things, if you're willing to pipeline your tasks, and pay the context switching costs. It's much simpler to not pipeline when possible, and not context switch.
I do have plenty of things to do, I just prefer to finish one, when possible, before I start another. I don't like keeping track of several different pending patches, and I really don't like having to do the tedious merging that happens when multiple things are in flight around the same places at the same time.
By all means, run your team with 100% reviews; but please accept that not reviewing everything is a valid option for other teams. Just like some people will run screaming from an interview when they hear there are no code reviews, some will run screaming when they hear everything is reviewed.
You answered it yourself: reviewers missing the forest for the trees, causing reviews to devolve into pedantry. Also: unpredictable code reviews where expected style changes every commit, because the dude do it by guts and feel different every day. Also: reviewer repeatedly forcing me to make changes that make code worst and reviewer changing requirements because he likes that better. It is super annoying when your code is "wrong" because you read best practices article reviewer did not, reviewer wont listen and still blocks commit till you change, only to have the very same reviewer forcing the same on you three months later when he found article and don't remember former discussion. I would much rather fixed a bug then went through above again.
The sort of people the most eager to do code reviews are developers with "every detail my way or the highway" unable to convince others they are right if they dont have ability to block commit. That and insecure people covering fear by aggressiveness. When I was in team with bad code reviews, review of a small patch could end in hours long arguments over variable name. Which of the two synonyms is better?
The thing is, code reviewing is supervisory function as any other. It is very easy to screw it up and especially people on the spectrum are likely to screw it up despite being good programmers when working alone. The usual "if you disagree with reviewer you have huge ego and cant take criticism" paradigma people push when talking about code reviews makes things only worst.
Of course code reviews can be done in good way too, but many of them are not and people have bad experiences with that.
Well sure, if you have a dysfunctional team code reviews being toxic is just one symptom. My point above is just that. Beyond that I can't form a cohesive argument around how a healthy, jelled team encouraging all code be reviewed by internal peers has any solid negatives, particularly velocity. Having to pipeline work, I guess, but I guess I am not convinced that this is a strong negative, since generally speaking I find that I'm pretty much always pipelining work anyway since it results in more throughput.
In other words, if your team is full of people like the above, any software engineering practices are going to come with a huge "YMMV" sign, code reviews being just one of them.
Does that require checking all commits though? That sounds like micro-management which is a massive morale killer.
Also; the team should self-organise on quality and help each other improve. I set the quality expectation and get enough data to understand their progress against that expectation (FWIW: I've always found a teams expectations sit higher than mine - which is as it should be to help motivation).
>>>That sounds like micro-management which is a massive morale killer.
I could see that if all commits go through your boss or something, but lots of places do peer-based code review. So have another developer check on your stuff and you check on theirs (or round robin it, or two on one, or whatever).
This helps in a lot of ways - maybe they'll catch something wrong, maybe it'll trigger a good idea in them, maybe they'll just be more familiar with a part of the code they hadn't seen much of before. And it honestly doesn't take that long; code that can be written in an hour can usually be checked in five or ten minutes.
I might not belong to the majority, but I prefer sharing an office with about 2-4 people. I don't get distracted by that, it rather makes me feel I'm actually working in a team, while sitting in a single room leads more to the feeling of being an anonymous coding monkey.
What helps however is that I'm really good at almost zoning out of the real world when I'm focusing on something to the point that people have to repeatedly call my name for me to notice someone wants my attention. And usually if it's not important they will just leave me be instead of interrupting me for some chitchat.
I can actually do that myself to a degree. But my bigger problem is the visual noise like the traffic coming in and out of the office. I'm guessing you are facing a window or a wall, which should help a lot.
I prefer having an office with just my team. I work on a team with 3 other devs and 99% of the time they're the ones I need to talk to. Everything beyond that is a massive distraction.
My team can't even "collaborate" because the 70 people in the room makes it so loud that we all wear noise cancelling headphones, completely negating the purpose of the open office layout.
When you look around in the main room 90% of employees are wearing headphones. Open office layouts are a joke.
>I think Apple has the best idea for this. Their work pods at the new campus have all glass walls facing the hallway, sliding doors to maximize room in the office, and built in storage. There looks to be plenty of room for a couple of coworkers to join you and help collaborate when need be.
I visited AutoDesk HQ about 20 years ago and remember seeing this office layout. Every single software engineer (coder, intern, localization specialist, release engineer) had a separate, enclosed space.
There was glass wall facing the hallway, with a door. It wasn't a sliding door but there was enough room for it anyways. Each office had a desk, swivel chair. And There were even 2 non-swivel desks in each office so that visitors could come in, sit down and have a chat. I think each office also had a tall bookshelf?
I was told some people brought in a sleep bag to sleep on the floor in their office during crunch time.
> You should make sure all the offices have glass walls
-1. Privacy is a huge component of focus. It's much harder to focus if I feel like people are watching me. Glass offices also don't help blocking visual stimuli.
I"ve worked in that have glass walls facing the interior. This is important to ensure that outside light gets in. And I've never felt like I was in a fishbowl, any more than I'd be in an open or shared office.
But I'm also motivated when my peers and subordinates can see what I'm doing. It's something that causes my productivity to lag when I work from home.
Yes please! At least this. For some reason there has been this huge trend with new buildings to just have exposed concrete ceilings and HVAC plant. Why? Seemingly because it's "cool" and how the "start ups" do it. (Back when a start up meant working from a low cost warehouse.) But ceiling baffles were there for a very good reason, to dampen and prevent reflection of noise in office spaces. How did we forget this?
EDIT: (At the last place I worked like this their solution was to install white noise generators on the ceiling. So the whole place was like being on an aircraft and very sleep inducing.)
Oh man as a traveling consultant, I purposefully trained myself to fall asleep on an airplane and anytime I hear anything resembling white noise I'm instantly asleep. Having it in a building would just lead to an increase in naps from me.
I have an app that plays noise that sounds like a jet engine that I play as I'm falling asleep. After a few weeks of that, being on a plane just knocks me right out.
I'm not sure the problem is with the physical decibel level of office noise at all. My workplace is silent as a tomb, we all have our own offices with closing doors, and I still bring headphones to work.
Sure, even something little as phone chatter can be distracting, but the main distractions come from people just passing by and saying 'hi', or worse, actually needing something from me and interrupting my work. Headphones and a closed door tend to signal that I'm busy, but even then someone will knock on the window and see if they can come in.
People are intentionally distracting, and I think it's something that's way harder to fix than just a stop light indicating noise level. It has to be "fixed" on multiple levels. Having an office culture of "just stop by their desk" is a huge problem, but I can't imagine being unavailable because there's so many distractions that really are urgent and need my synchronous interaction right now. That's a tough thing to fix.
>> but even then someone will knock on the window and see if they can come in... People are intentionally distracting,...
I think it is, like most things, about balance. I would not like it if the workplace had an implicit culture that strongly discouraged people from going and talking to other people without going through red tape (set up a meeting or similar). What's the point of being in a common space then? Might as well just work from home.
I think there is value in those spontaneous conversations (sometimes all you need is a one line response for what would otherwise have wasted your whole day), and I think people who assume that sitting with headphones on all the time means they should never be 'disturbed' are being a bit uncharitable.
> I think people who assume that sitting with headphones on all the time means they should never be 'disturbed' are being a bit uncharitable.
I stop feeling charitable when I start missing deadlines and can't get any work done because of constant interruptions.
Is there a more clear way that I can signal I need fewer interruptions than a closed door and headphones? Just a couple hours each day without being interrupted would be great.
What do you work that you as a single person have deadlines? Usually in SW development those are as a team. So it doesn't matter if you help your teammates?
I agree with this, I am fortunate to have the opposite situation at work.
We have an open office with lots of visual and auditory noise. But I am rarely interrupted by other people, we have a good culture of asynchronous communication, and I do most of my work alone. So I'm pretty productive in my shared cubicle with headphones and dual monitors.
Similarly, when I get on a plane the first thing I do is put on my headphones. I don't often listen to anything though, most times I'm reading comic books. But the signal to the person sitting next to me is "don't bother me", and most times people understand it immediately.
Something about this doesn't feel right, I want to call it "passive aggressive" but that doesn't feel right either.
In an open office I've always felt that headphones were the best solution to the need for peace. I feel like spontaneous dialog would be cut short by this solution more often than being moved.
I guess what works for one may not work for another, and the frequency and varying views on this topic reminds me of the "tabs vs spaces" discussions.
I think you missed the point. It's not about headphones, it's about needing headphones to block disruption. If you need something like that then it's a poor office design.
> I feel like spontaneous dialog would be cut short by this solution more often than being moved.
Good. Spontaneous dialog is far more often disruptive to productivity than it is helpful.
People who work in open floor plans or individual office plans can have spontaneous discussions. The floor plan doesn't limit that, the open floor plan just makes it easier.
But it's impossible to be as productive in an open floor plan as it is in individual offices. So isn't the better choice to have the more productive environment and teach your employees to organize their "spontaneous" conversations better?
If I run into the product manager in the hall, or she comes into my office, and we suddenly have this great conversation the team would benefit from, isn't the better choice not tearing down walls but having us slack the team to meet us in my office or the conference room so we can whiteboard it out with everyone's input?
The problem with the argument for/against "serendipity" is that 95% of these spontaneous conversations are useless and created solely to kill boredom, but the remaining 5% do end up helping out.
My dream scenario would be private rooms surrounding a common working area. But the CEOs/MBAs see Facebook brag about their largest open office ever and tell themselves "I wanna be like that!!!" and follow suit.
These discussions focus on productivity because the main arguments in favor of open floor plans are that they're cheaper and supposedly improve team productivity. Studies show that more people prefer offices, and above all people prefer having a choice.
We should all embrace intersectional office space personalities and that no office of the future can belong to the future if it doesn't accommodate different types of people, work, social and personal needs.
I've always been confused that people will set up 6-7 different kinds of areas in their house, but expect an office to be wall-to-wall cubicles with a restroom tacked on.
Let's see if we can list out some of the things to do in an office:
* Focused solo work
* Focused small group work
* Making phone calls - one person
* Making group phone calls and teleconferences
* Small group meetings
* Large group meetings
* Handling documents and records
* Food preparation
* Eating areas for individuals and small groups ("cafe")
* Eating areas for large groups ("cafeteria")
* Relaxation
* Reference and reading
* Loose teamwork e.g. sales and support
* Client/vendor meetings - small and large scale
* Shipping and receiving
* Maintenance
* Storage
I wish there were names for these kind of spaces beyond agglomerating descriptions onto generic terms.
I think if you say "Living room", "Kitchen" or "Bedroom" most people have an idea of what happens in that room. "Medium conference #3" is less descriptive.
Outside of the startup culture where they throw tons of money at renovating a floor/building I've not seen anything very diverse. Typically it's individual offices with conference rooms, open spaces, or cubicles.
We are asked not to lead with negativity on HN, but once in a while an article comes through that just screams out as requiring an exception.
Asking people to reduce the noise level is straight up a horrible idea. Especially the obnoxious /noisy command and the nanny state thinking it encourages.
I thrive and get in the zone when there is plenty of noise and varied conversation around me. I know that many people feel the same way. A quiet office is the worst for maintaining focus, as then any little conversation will stand out and catch my attention.
And I say all this not as a loud person. Quite the opposite.
I almost never use headphones; don't need to because the office is noisy enough to stay in a good coding zone. But having some social stigma about wearing them, that would be bad.
I believe your anecdotal evidence is wrong. Studies have shown that developers are much more productive when they have quiet and private offices.
In fact, studies have also shown that listening to music reduces productivity, with instrumental music the least bothersome. Our brains have highly developed communication abilities, language processing is a function that requires a significant part of our brains to work. Whether you are consciously aware of it or not, whenever you hear words, whether spoken or sung, your brain starts decoding them. That's reducing the amount of brain power you have remaining to work on your conscious tasks.
> Asking people to reduce the noise level is straight up a horrible idea.
It's about as horrible as an idea as the open office was. Forcing everyone to be in a compromised position when they feel like they can't get work done in a distracting environment is a straight up horrible -- borderline inhumane idea.
> and the nanny state thinking it encourages.
About as nanny state as HR policies are these days with what you can and cannot say/browse/view/post on social media these days. It comes with working for a company I guess. No reason to object now.
> I thrive and get in the zone when there is plenty of noise and varied conversation around me.
Current knowledge of how our brains operate and evolved show that you are the statistical anomaly. To do deep work that requires concentration, you need quiet and minimal distractions.
I wouldn't have to wear AirPods beneath 30dB landscaper earmuffs to get shit done if management would do something about the 5% of noisy people polluting the common space we all have to sit in. The best office layout would be the one that puts the inconsiderate primates behind soundproofing.
Because one cellular telephone conversation can disrupt the concentration of 30 engineers hours-deep into complicated debugging jobs, especially when it's one side of a lengthy dramatic argument. It takes each engineer about 15 minutes to recover concentration, in my estimation. So that's about 7.5 hours lost, or about a programmer day.
Concentration is precious and fragile. If you can know just one thing about managing programmers, please know that.
Slightly OT, but any recommendations for an alternative to music with headphones?
The reason I'm asking is because I don't think I could concentrate with any form of music. I tried some "fake cafe sound" and I still felt distracted (more than I do in a real cafe). White noise? Ear plugs? Binaural beats?
I actually work from home with my wife across the desk. We have a relatively quiet environment, with no or very low volume music playing.
I'm not hyper sensitive to noise at all. But I would still like to be able to isolate myself completely some time to focus. So just wondering if there are any tips.
I've tried so many things. Many styles are out of the question because I focus on the words too much.
As far as music goes electronic like Daft Punk or Neelix is my favorite but it also has its drawbacks.
So finally I think asoftmurmur.com is best.
But even with the perfect noise, or lack of noise with active noise cancelling headphones, not everyone can wear headphones 4 hours in a row. Some people hurt from being built differently around the ears.
And this article focuses a lot on noise level but that's not the problem for me. The office could be totally quiet but if one person is having a phone conversation I focus on everything they say. Depending on the person my mind might even start to wander and think about what the person on the other end might be saying.
So for me working from home has been a god send. And we didn't have an acceptable culture of working from home. I simply forced it and said damn to the consequences.
But I have no kids and live alone. When I'm at my gfs place her daughter and her friends are too much for me. I can only work 3-4 hour sprints because wearing headphones longer than that is uncomfortable.
I've found the in-ear headphones to be better in that case.
Thanks for that. Never tried any noise cancellation headphones before.
I did find that it's not so much the pressure, but rather that my ears get really hot with those big headphones. So I can't wear them for longer than 20 minutes or so.
Are there / can anyone recommend in-ear headphones with noise cancellation?
I got a recommendation from a friend that his Bose in-ear active noise-cancelling phones were really good. Haven't tried them myself, can only forward his recommendation.
No, but I can recommend in-ear phones with excellent noise reduction: Etymotic HF5, on discount until the end of June for $99. These have noise reduction on par with good earplugs (another thing that Etymotic makes).
The thing I can't work with is human voices. If a song has words or voice at all, my concentration is gone. Low volume white noise is the only thing I can work with at this point.
mynoise.net has a whole bunch of carefully-crafted sonic environments. Fake cafes, all colors of noise, binaural beats, spaceship control consoles, ever-shifting chords, gardens, forests, desert caravans... those plus noise cancelling headphones/earbuds can put you in a tranquil world of Shit Getting Done.
This is highly subjective stuff, but I like the ship's engine noise videos, like this one: https://youtu.be/vuZ4uP279oc
I also used the generation and effects features in Audacity to make my own tracks, a few years back. I quickly ended up with some things I liked. Mix in some recordings from Freesound and you can arrive at professional results quickly.
Finally there are some apps that function like mixers of existing sounds, and you can mix up your favorite combinations. I have used the Ambient Mixer app as well as some others and they offer a great range of sounds.
Edit: And if your neighbors are partying too loudly, any of this stuff plus a reasonable pair of speakers will often immediately cancel the sound.
I've found myself using myNoise (https://mynoise.net) more than music lately. It has a lot of very high quality natural sound recordings as well as a bunch of synthetic options.
Active noise cancellation headphones (without playing music). Bought ones recently and can't be happier. Works both in office and when working from home, and are great in cancelling the background noise (like HVAC) and lowering the overall volume of speech to the extent it doesn't bother.
I do, however, usually combine noise cancellation with a —
now pretty quiet — background electronic music with no voice, which I've found helps me concentrate.
I use http://listentothe.cloud/, the mix of ambient electronic-y music and barely intelligible airport radio chatter is very pleasant to me. Also, I use http://rainymood.com/ for writing.
You can buy tons of classical music off iTunes super cheap (like 99 songs by mozart for $5), most has no singing so I believe it's less distracting. I can turn it on and forget about it for hours.
Rain noise helps me sleep and it helps me focus. ASMR is strangely helpful sometimes too. I've found it's never a silver bullet, but trying different white noise sounds to fit the moment.
I have read dozens of articles like this and as a developer, it would be great to work at a place like that: WFH option, non-open plan layout / 4-man offices. But the people who want that are rarely the ones in a position to implement that sort of environment. So nothing ever changes.
As a software engineer, unfortunately, the sound sources that drive me to the edge of insanity are things like loud typing, or hands fishing around for chips in a bag. While I feel totally comfortable asking people to quiet down a conversation, there is something too personal about asking someone to consider, specifically, how must force they drop down on the space bar. I like the idea behind /noisey, but I feel like I may be alone in being concerned that no one would register these fringe noise sources when considering their contribution to a soundscape. There probably isn't a good solution, so headphones will have to do.
Depending on roles, it can make sense to do the following:
- have reservable floating offices and various sized-conference rooms w/ doors
- some dedicated offices w/ doors
- some open layout for pair coding, but not exclusively
- some casual multipurpose hangout/couch meeting/work/relax areas
- remote work from home, coffee-shop, beach, mountain top, etc.
- perhaps an discreet workspace indicator (web + IoT physical) that says (perhaps using color codes):
- out for the day
- out temporarily
- free to socialize (which auto-suggests people to chat with in this state)
- working
- do not disturb, unless it's an emergency
This way, there's more choice and people can self-select some common-sense and have enough variety to not get stuck in open floor-plan, panacea, audio-visual-social distraction hell.
My current office is pretty ideal for me. We have 6 devs, and we sit in a room with a door. It's quiet, but we can hear if there is a concern or something going on that requires attention. The issue with single person offices is that you'll miss when somebody is discussing an issue they're having, maybe they mention it offhandedly, and you know the solution.
That said, I would still vastly prefer an office to myself than a god awful open-floor bullshit abomination. How anybody can work in that kind of environment boggles my mind.
I've worked in 2 man offices that were super distracting. The product manager on the product I wasn't working on would come in to talk to the other engineer, and I could not filter it out, even though it was entirely unrelated to my work.
I think the key to a shared work area is that everyone should be on the same team working on the same project, so the distractions are at least pertinent to your job. But I also think you are probably reaching the limits of that with 6 devs.
It is similar where I am working. We have a 4 person office with most of the time only ever places in use. That really contrasts to open plan I had before.
I increasingly suspect visual and auditory noise are symptoms rather than problems. The underlying problem may boil down to this: while easy collaboration helps us be productive, having our own space also helps us be productive.
Here's an idea: every worker should get their own big desk, maybe an L-shaped one, with file cabinets and ample storage, and even shelves and walls behind the desk that they could put up memos, calendars, whatever. But they don't have to be completely walled-off little offices. Don't give them doors; don't make the walls go all the way to the ceiling. This would greatly reduce visual noise, and combined with good acoustic design for the rest of the office (as the article touches on), it would at the least cut down on auditory noise--and more importantly, it would make it so going over to talk to a coworker in person required just a little more effort than it does in an open office. Collaboration would still be pretty easy, but raising a little more barrier than the current fashion might improve concentration and, dare I say, the little bit of emotional boost that comes from having your own perceived space.
I'm not sure what we would call these purely hypothetical half-wall workspaces--these "cubicles," if you will--though....
The traffic light reminds me of SoundEar [1], noise monitors which were popular in Swedish classrooms fifteen years ago (and might still be). It worked well in my seventh grade classroom.
I'm not so sure about the red light being manual trigger only. I think it's better to decide objectively on what the desirable noise level should be.
The company I work for has open plan offices — it's a US company with multiple offices worldwide. The specific one I work from is small, and devs and non-devs are _mixed_ together.
Whenever I tried to bring up noise-related issues and made specific proposals, I felt I was ignored because of
a) clash of cultures (non-devs might not understand/value "being in the zone" [1]),
b) spending money in sound-proofing is seen as a cost, not an investment.
What worries me the most is that in the course of a few years I haven't heard any internal voices putting open plan offices in doubt. This office layout looks to be seen as a good default with problems that are either ignored or that people have to learn to live with.
So I wonder if the situation is similar in other companies with open plan offices, and whether people see there's any trend to question the given default or not.
That just sounds like passive aggressively leaving angry postits on the fridge. If you're being obnoxiously loud and keeping me from working, I will assertively tell you to keep it down (or aggressively, if you're the annoying salesperson who spends most of his time making loud, personal calls).
Good office design certainly helps with noise, but some people are simply obnoxious without realising it. Educating them can be helpful.
I don't think this chart demonstrates your point. Don't you want people to eventually stop needing to use Noisy at all? As of now the chart just shows that more people are familiar with the Slack command.
I would also be interested in knowing how large the team is that this is being tested on.
I often have the opposite problem. We are like 15 people in our office, and some are very sound sensitive.
I feel like I can't even properly discuss things with my other colleagues or even peer program out of fear of disturbing the others.
If you are really that sensitive get earplugs, instead of cussing at others!
I'm a big fan of this. Work environments should be optimized for productivity. Most software is a team sport, so they should generally be optimized for team productivity.
What that means will be different for everybody. But for me I've had the best results with team-specific spaces that have some visual and noise isolation from other teams and wandering interruptions. I also like to have clear separate space for non-whole-team discussions and for hanging out.
Places where everybody gets in and cranks up their headphones to protect from the madness strike me as the modern noise equivalent of the 1960s/1970s rivers that were basically open industrial sewers. [1] If that's what it's like, you might as well let people work remote, as you've already lost most of the productivity gains that come from close collaboration.
But those gains really can be amazing, so personally I'm going to keep pursuing them.
> GitHub, Slack, Screenhero, Hangout etc will make sure nothing gets lost and we stay up to date. Except for that you miss being challenged at the soccer table … just sayin’.
Sometimes when you're not there at the meeting in person, your point isn't taken as seriously.
I like the idea of acoustic padding and visual blockers. My desk is in a darker area with lots of conversation and visual noise. Can anyone recommend how to set up padding and simulate sunlight without being weird/blinding others?
Simulating sunlight is relatively easy; look for lamps characterized as "full spectrum". Point them down from high places rather than up from low.
Noise reduction is hard. The fastest, most efficient solution is to wear a pair of reusable, washable earplugs. If you buy them with a brightly colored cord connecting them, people will usually notice when they approach you. Next best is external ear defenders, the kind used for shooting sports. People will definitely notice that.
The downside to both methods is that most people do not like having things inside or on their ears for hours at a time.
Definitely agree on the downside.
Another problem is that such hearing protection doesn't work very well against the human voice or similar sounds such as throat clearing, sniffing, etc.
I've read so many articles about people who can't stand noisy offices, but the only complaint I've ever heard from co-workers IRL is the office being too quiet. If it's quiet, no one is collaborating.
One man offices are cheap and by far the most productive work environment for software development. Any software development organization that's not investing in them isn't thinking strategically. Engineers should be able to face somewhere that's not distracting, and have a quiet work environment without requiring headphones (music can be a distraction too). If you want to collaborate, do it in your office, it should be big enough for a couple people to join you, or a conference room if you need more.
The only criticism I have for one man offices is that it makes it too easy to goof off and surf the web, but that's a different managerial problem. You should make sure all the offices have glass walls so you can see if someone is in their office and have an idea what they are doing. But mainly you should review all code as it's checked in for quality, and it should also give you a good idea of their productivity.
I think Apple has the best idea for this. Their work pods at the new campus have all glass walls facing the hallway, sliding doors to maximize room in the office, and built in storage. There looks to be plenty of room for a couple of coworkers to join you and help collaborate when need be.