Where we're going, we don't need headphones
rradczewski.github.io
rradczewski.github.io
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.
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.
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.)
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.
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 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.
Just that there are often people who have their headphones on practically the whole time, and then expect to never be interrupted
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.
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.
p.s. tabs
> 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.
I think this is the crux of where most of these threads end up. Not everyone agrees with both the explicit and implicit premise of this point:
- Not everyone agrees that productivity should be the exclusive focus of office design decisions
- Not everyone agrees that spontaneous discussions should not be embraced as a core mechanism of enhancing team-wide productivity
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?
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.
p.s. tabs
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.
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.
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.
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.
Concentration is precious and fragile. If you can know just one thing about managing programmers, please know that.
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.
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.
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 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.
Or same genre but a little chiller: https://soundcloud.com/erraticnyc/erratic-podcast-128-hydran...
Not sure if it'll work for you but worth a shot. :)
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.
- 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.
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 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.
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....
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.
[1]: http://soundear.com/
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.
[1] https://www.joelonsoftware.com/2000/04/19/where-do-these-peo...
It's a good idea, but it might be counterproductive to message everyone that they're being too noisey; that might contribute to the noise
Good office design certainly helps with noise, but some people are simply obnoxious without realising it. Educating them can be helpful.
https://rradczewski.github.io/ymmv/assets/office_noise_noisy...
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.
If you are really that sensitive get earplugs, instead of cussing at others!
> We are like 15 people in our office
I wouldn't even be able to read comics with so many people talking, let alone do my job.
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.
[1] E.g., the Ohio river that caught on fire: https://clevelandhistorical.org/items/show/63
Sometimes when you're not there at the meeting in person, your point isn't taken as seriously.
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.
One can hope.