Imagine a developer’s brain as a bucket and over the course of a few hours of coding, all these little pertinent pieces of information are being poured into that bucket. Eventually, the bucket fills up and information starts to flow out. This isn’t spillage. This is the good stuff. This is the creativity that happens after the rudiments of the language and the tools are grasped. Unfortunately, in a modern office, someone or some thing is constantly coming around kicking over the developer’s bucket. Then, he or she spends all that time filling the bucket up with details of vast arrays of variable names, method signatures, and class properties and very little time enjoying that overflow of creativity.
These interruptions come in many different forms. Some are insidious (Growl notifications) and proclaim to be helpful while others are outsized (“OMG, the servers are on fire”) and are clearly reasonable interruptions. Here at Emma, we’ve been attacking what we consider to be the middle ground of that spectrum. Everyone works a little differently, so outside of sharing suggestions, we are certainly not going to demand that folks close Twitter and turn off Growl. We’re also not going to say that “only these people in this office” are responsible for something as serious as a service outage. What we can do is manage the office environment in a way that provides for the most productivity given our current workload and support processes.
Lost time is just that
Chief and most recent among these changes is a policy where the development teams each have from 1pm-5pm in their respective timezones declared as interruption-free. We’re lucky enough to have a support team and a QA team that can accommodate this schedule and still give our customers the level of service they deserve. Essentially, we are all turning off our IMs, closing our emails, and disconnecting in any other way we like so that we can fill up our buckets and slosh out some fantastic work. We’ve also committed to being more available in the morning hours for support and the like.
This change is only about a week old and there has been some great feedback thus far. Most of the developers feel like significant increases in productivity are happening and that they feel more confident about the code they are producing. The support team feels that customer needs are still being met with the same speed and quality as they were before. So, it’s been a positive shift overall. We certainly haven’t increased the number of hours in the day and the support load hasn’t decreased, so for there to be any benefit, those four evening hours must be necessarily more productive. We’ll have some burn-down charts and more anecdotal evidence in the coming weeks to show us if what we feel is indeed what’s happening.
One interesting side effect that I’ve noticed is that in the morning I’m a bit more likely to wait to dive into some intense code knowing that I’ll have all that glorious quiet time in the afternoon. However, instead of keeping me from getting more done, it helps me to look at that bloated inbox in the morning and deal with the emails and such that accrued over the course of the previous afternoon.
Personal and comfortable is better than institutional
We’ve been doing some other things to increase our productivity as well. You may have read Josh’s blog post about our Git workflow. One of the things that I like about that workflow is that within a developer’s local repo, he or she can work any way they like. The only rules we have are that code that is considered done must merge with prod cleanly and whatever is pushed to the server should be a feature branch off prod. Past that, one can rebase, merge, amend commits, branch of branches, etc. as one sees fit. Being able to customize your workflow means less time trying to remember and adhere to some process instead of creating.
We also have no standard editor. While we are all Mac users, some of our developers are using vim, some are using emacs, others love Textmate, and one is even sporting his Komodo pride. Again, this is all about creating a comfortable environment for the developers so that they can do what they do best. Yes, we are steadily improving the coding standards we want to adhere to, but how one gets that code from one’s head into the machine is not something we need to dictate.
One of my personal goals is to build a library of books and other resources for developers to borrow, use, and talk about. We’ve begun a meager bookshelf (mostly from our own collections), but I hope to see it grow soon. I’ve been looking at a lot of new technologies and languages, and it would be great to have books about those at hand for any developer to read. Perhaps, something like a group account at O’Reilly’s Safari makes sense as opposed to the printed books, but either way, constant learning is something I want to nurture within our dev team. You’re probably thinking that these books are more than likely going to become distractions as opposed to helping developers focus, but I’ll remind you that all work and no play makes Homer go crazy.
Success can become a location
As some of you may know, Emma has plans to move our Nashville location to a new office later in the year. I’ve been lucky enough to be included in a lot of the discussions about office layout and desk choices and lighting needs. That’s one aspect of our development environment that we probably haven’t paid the closest attention to, but which will be improving greatly in the future. After all, I spend more waking hours in this office than I do in my home. It needs to be conducive to creativity, productivity, and success.
All of these things — time management, interruption management, ready resources, development tools, and even where we sit — are extremely important as we endeavor to not only bring about a great new API, but also make foundational changes in our service. It’s an exciting time for us, and I would love to hear about ways you’ve made your development environment more productive, more fun, and a happier place to be.