tangentalizingly delicious

Wednesday September 9, 2009

I’ve been thinking lately about the different factors that helps developers (specifically, but I think it probably applies to creative workers in general) do their job well.

Physical Environment:
By this I mean, well, the actual physical environment. The desk, the chair, the walls (if any). I’ve long been in favour of private offices (ideally soundproofed so music can be played on speakers instead of headphones), but I’m gradually coming around on the complete opposite – a wide open bustling environment like a coffee shop. I’m still rabidly against cubicles, as you end up with the worst aspects of both worlds and few of the good ones.

The interesting thing to me about the open and bustling environment is that in its way it offers the same sort of privacy as a closed office (though without the benefit of using speakers, generally). With so many different things going on, no one is especially concerned with any one person’s activity. People are floating freely between different places and collaborating as need be.

My ideal environment affords people the choice: Private offices for when they need to retreat and to give them a sense of ownership over their space, but loud and heavily trafficked communal areas for collaboration and interaction.

I’m moderately torn about where computers go, but for the time being I’m going to put them here since they are a physical beast and their physical nature impacts how well and to what extent one can work. My ideal setup is a laptop that has enough oomph to drive multiple monitors and external peripherals but is light enough to be portable. 15” laptops are on the very upper threshold of this for me, but I think I’m a little weird in my strong preference for 12” or 13” form factors.

Logical Environment:
By which I mean the tools available for work. The software and technical resources for people to use.

Operating systems arguably don’t matter, but they only don’t matter to people who aren’t in one all day. It’s possible to get the same work done in basically any operating system but the simple truth is that peoples’ preferences and experiences do have an impact.

The larger environment, the network to which everything is attached, shouldn’t matter. It’s possible now to share network space in ways that work well for every client OS and so each person working should be able to use the tools they prefer. For programming work, cross-platform and shared development is controlled well by enforcing style guides, but there’s a bit of collision when it comes to other tools such as version control.

It may be possible to have a master version control system that each user can access with the software of their choice (there are various ways to integrate git with svn, for example) but I’m inclined to think that there are situations where everyone needs to use the same tool. IDE or text editor? Whatever you do best. Version control? Everyone should be in sync with the same tool. If I were starting an environment from scratch I’d be starting with some form of distributed version control, but any is better than none.

Cultural Environment:
Corporate Culture may be an oxymoron, but I like to think not. It does seem to be a difficult thing to create and nurture though, especially when there are differences of opinion.

I don’t really know much about managing a culture but I do know that the culture impacts how people work.

There’s different ways for being open, you can either be completely transparent to everyone or you can be opaque but open within the walls of the organization. For me I think the key is to build an air of cooperation. It’s very easy for people to get pigeon-holed into specific tasks and knowledge domains and to start throwing things over the walls in between.

This tends to lead to passing-the-buck (“Oh, that’s a design issue.” “Oh, that’s a javascript issue.” “Oh, that’s a database issue.”) and adds process overhead. Not everyone is going to have the knowledge to perform every task of course (nor should they, specialization has its advantages) but as soon as someone considers a problem someone else’s, a barrier is raised.

I don’t have a clear handle on what a collaborative way to own problems is, but I’ve definitely had experiences where two (generally, sometimes more) people are working together at the same desk to solve a problem. Not full-on paired programming all the time, but working through a problem that bridges knowledge domains together. It is for problems like this that I like the communal physical environment, as it becomes much easier to work together. I like the split private/shared environments for this, as being in the communal environment is an indicator of openness for collaboration, where being in one’s private space is an indicator that deep thinking and flow is afoot.

There’s a lot more to the cultural environment. I’ve touched on it in the deep past here but I think most of my thinking on the matter has been spent in the Physical and Logical environments. I do think that those two have serious impact over the third. It’s possible for Culture to get past Physical and Logical limitations,
but it’s much easier to cultivate Culture when the ideas are supported by the other two legs.