I just read Nathan Marz’s argument against open plan offices, and this sentence leapt out at me as almost always wrong: “The primary task of a programmer is writing code, which involves sitting at a desk and thinking and typing“. I’ve been a big fan of Nathan’s since his Backtype days, but while his prescriptions make a lot of sense if you really are spending most of your time typing out new code based on clear requirements, I’ve found that a very rare position to be in. In my experience writing the code takes way less time than integrating and debugging it, let alone the open-ended process of figuring out what the requirements are. Most of my time goes on all those squishy bits. I look forward to the uninterrupted intervals when I get to just write code, but they’re not all that frequent.
When I started in games people who could write 3D software renderers were rare and highly-paid, but libraries and books came along that made their skills obsolete. Then it was folks who could program the fiendish DMA controllers on the Playstation 2, but soon enough they were sidelined too, followed by the game physics gurus, the shader hackers, and everyone else who brought only coding skills to the table. It turns out that we’re doing a pretty good job of making the mechanical process of writing code easier, with higher-level languages, better frameworks (something Nathan knows a lot about), and training that’s creating far more people who can produce programs. What I saw in games was that coding was the ticket that got me in the door, but improving all the other skills I needed as an engineer was what really helped me do a better job.
I learned to write a software renderer, but chatting with the artists who were building the models made me realize that I could make the game look far better and run much faster by building a tool in 3DS Max they could use to preview their work in-game. It reduced their iteration time from days to minutes, which meant they could try a lot more ways to reduce the polygon count without compromising the look. I would never have made this leap if I hadn’t been sitting in an open plan office where I could hear them cursing!
Since then I’ve seen the cycle repeat itself in every new industry I’ve joined. When the technology is new and hard to use, just knowing how to operate it gives you a high status position, but the tide of Moore’s Law and the spread of knowledge makes that a very temporary throne. The technical impediments always disappear, and graduates come out of college knowing what used to be elite skills. What keeps you in a job is the ability to be the interface between the precise requirements of software and the rest of the world filled with messy, contradictory and incompletely understood problems.
In passing Nathan mentions measuring productivity, but that’s one of the stickiest problems in software, with an inglorious history from counting lines of code to stack ranking. Most of my most useful contributions at the companies I’ve worked at have been when I’ve avoided producing what someone has asked me for, and instead given them what they need, which meant a lot of conversations to really understand the background. I also spend a lot of time passing on what I know to other people who are hitting problems, which hits my individual productivity but helps the team’s. The only meaningful level at which you can measure productivity is for the whole group tackling the problem, including the designers, QA, marketers, translators, and everyone else outside of coding who’s needed for almost any product you’re building. In almost every place I’ve worked, they would be able to make far more progress if they could interrupt the programmers a lot more, even though I’d hate it as an engineer!
I am actually ambivalent about open plan offices myself. Having my own room often seems like a delicious dream, and headphones are a poor alternative when I’m really diving deep into the code. What stops me from pushing for that is the knowledge that my job is all about collaboration, and an open arrangement truly does enable that. The interruptions aren’t getting in the way of my primary work, the interruptions are my primary work.
Pete Warden's blog 
Thanks for the great counterpoint. I certainly agree 100% on the value of tight feedback loops and collaboration. I think where we disagree is on whether an open floor plan really promotes that collaboration in a way that wouldn’t be possible without the open floor plan. Just because you have a non-open floor plan does not mean you can’t have exactly the collaboration you describe – you can still easily gather the programmers and designers into the same room and have them work together for an afternoon. The key is that the working environment should be dictated by those who will work in it. So if you need the focus and concentration you can have it, and if you need the tight collaboration you can have that instead. The problem with open floor plans is that environment for focus and concentration is never available to you. My current thinking around the ideal office layout is small 2-4 person offices with large “collaboration areas” where people can work together in bigger groups and be louder.
Now in terms of quantifying where programmers spend their time, I think that’s hard to say. As is clear from your post and mine we have very different backgrounds in that regard. But regardless of that I still think that we can do better than open floor plans. As I alluded to above I think a more flexible office environment would allow the best of all worlds. It would be a more expensive office, of course, but I think it would be well worth it.
This non-argument seems, to me, to be summed up best by the two statements: “Writing code is not most programmers’ primary task,” and, “The key is that the working environment should be dictated by those who will work in it.” Feelin’ it.
Also, get better headphones, Pete.
“In my experience writing the code takes way less time than integrating and debugging it”
Maybe if you had better working conditions (privacy for engineers), you’d write less buggy code and your engineer team would be forced to (gasp) plan how to integrate and organize every engineer’s code. 😉
…joking aside, this argument has logical errors. First, it infers that collaboration and private / quiet working conditions are mutually exclusive – they are not. You can have both. Take the NYC Google office for example. There are numerous big and small rooms. The team may be assigned a bullpen area, but you can get up and walk to a private / semi private room to work as well.
Guys, this topic has been talked to death (well over 10 years ago) and it’s decided: Engineers and creatives *need* quiet working conditions *available* to them. You guys are all arguing past each other b/c you’re talking in absolutes.
Here are better arguments done 10+ years ago.
http://www.joelonsoftware.com/articles/fog0000000043.html
http://www.joelonsoftware.com/articles/FieldGuidetoDevelopers.html
Pingback: Preventing Errors in Code | ebeab
Programming is only one function of a greater job, which is to allow other people to do their job more effectively, both by automating the boring parts and by allowing new insight.
Management thinks it does the second part well, and for some companies that may be true. In my experience, however, I’ve always seen myself as a helper of others who happens to be able to do it with programming.
Pingback: Five short links « Pete Warden's blog
I just wanted to comment on this briefly. The extent to which open offices are beneficial depend – very much – on a) how they are designed and b) what the work done in them is. I’ve done the same kind of work in two very different open offices. One worked very effectively, one was absolute hell. If the objective of an open office is to cram as many people into the floorspace as possible, you’re on a loser from day one. If you give people space, and an environment which is engineered to reduce noise clutter, then possibly you wind up with a workable system. But the either/or debate on open offices has to be coloured by the implementation of same.
“In my experience … let alone the open-ended process of figuring out what the requirements are.”
From what I have seen that last part is the real killer. Ever worked on a project that seriously changed direction after the coding cycle had started? Or, should I say, ever not worked on one?
Pingback: How to Make the Best of Website Development Trends, Circa 2014 - Olivier Travers
Pingback: Preventing Errors in Code | mkaz.com
Pingback: Preventing Errors in Code – mkaz.blog