3 ms·
I prefer open. I've never seen cube farms or offices that have a decent amount of natural light. Also, I seem to be the minority in comments, but I don't mind
by hatsix 10y ago
I prefer open. I've never seen cube farms or offices that have a decent amount of natural light.
Also, I seem to be the minority in comments, but I don't mind people talking around me. I don't use my ears/hearing to code, so it doesn't distract me nearly as much as chat windows or anything visual on my laptop. I suppose the real issue is people having interesting conversations around me... But I have headphones and music if I need to concentrate (I probably only wear them for 1-2 hours a week to block out conversations).
Every week one a new article like this is posted, and every week the comments are overwhelmingly "open offices are bad". Every week I meet more people like me who don't comment because they don't feel strongly about protecting open offices, and would like the people who are upset by open offices to find their comfortable place.
There really are quite a few of us who don't mind open offices... I'd guess it's probably a majority of people... We don't really want to impose on others...
My only real concern is that the people who want their own offices tend to also have seniority and want natural light... I've seen these people carve out their own personal paradise, while blocking other's ability to have a good working environment.
Context: Mid-thirties, Sr Engineer in Seattle who has worked for small startups (< 10) up to Amazon.
My solution: Ability to concentrate is a teachable skill. Every skill-based sport has to teach players how to focus on the goal and ignore the distraction (hence my assertion that Golf isn't skill-based). We use enough sportsball analogies in coding, so I'll add another.... Coding in an office is like batting against a pitching machine.
- fsloth 10y agoI think there are very different experiences and expectations on what the craft of software engineering is like. Different tasks and organizations require different time budgets for e.g. collaboration and deep work. My coding has very little to with sport-like activity and is more like the task of a lone clocksmith (although we have a team, individuals have quite large chunks of codebase carved for themselves). For some problems I am straining on the edge of my working memory capacity. The problem with the distraction avoidance is that it demands mental resources. If there is some benefit in training working in a stresfull environment there could be a sound proof room for such a purpose where employees could go for a limited time to train. The inverse of large open office/small quiet room pattern. At first level there could be just white noise in the room. Once that is mastered as an added stimulus the feet could be placed in a bucket of icewater. At the next level the room is filled with monkeys. Etc.
- hatsix 10y agoAs someone who has done lone-wolf development, let me tell you that so many issues go away once you develop a well-functioning team to work on problems collaboratively. My initial reaction is that there seems to be much bigger issues with the way your company is structured. The words you're using ("lone", "carved", "straining on the edge") suggest a stressful situation where each individual carries their own weight... If that's the case, I can certainly see why you'd be upset by someone else impeding your ability to work. I wouldn't last long in an environment like that, either pushing it to be more collaborative, or just leaving. I can't imagine any coding that isn't improved by adding collaboration (a great starting point is code reviews... make PRs early and get opinions on rough-cuts). If you don't have this in your current environment, I highly encourage trying to kickstart it... you're really missing out on a great way to remove stress, improve quality, and have more fun.
- fsloth 10y agoSorry, I was perhaps not quite precise enough. I agree that collaboration on complex technical topics is wonderfull. There is quite a lot of collaboration and we do have a great team. The system is divided to many components and each of those components has usually only one or two active developers. The inherent technical complexity of the components is such that sometimes a feature needs days of coding - thus the 'more locksmith, less of a ballgame' analogue. I should have perhaps pulled some other analogue.