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.)

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.

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.

>Certainly less easy than joining in on a conversation you overhear while sitting at your desk.

Great! No more distracting me with conversations while I'm trying to work! If you want me in the conversation, ask me. Don't take my choice away.

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?

>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.

> 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.

Just one line dev's two cents.

>> 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.

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.

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.

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 : )

Just wait at the coffee machine

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'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.

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.

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.

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.

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 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.

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.

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.

Some concrete examples:

- Fixing or writing unit tests

- Performing (low risk) operational + maintenance tasks

- Refactoring

- Design tweaks and improvements

- Deployments

- Building simple features

- Reviewing code

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.

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.

Meanwhile, when I actually need to fully concentrate, even music can be distracting, so there's loss and no gain.

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.

- 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.

this is silly. a person should have the freedom to relax every so often throughout the day - we're not soldiers standing watch.

>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.

this is the correct answer

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.

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.

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.

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.

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).

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?

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. =)

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 ;)

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.

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.

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.

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.

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.

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.

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).

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.

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.

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 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.

That was 20 years ago.

-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.

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.