Limiting interruptions and finding creativity

This is from our vendor of e-mail services, emma. Find them at myemma.com

Imagine a developer’s brain as a bucket and over the course of a few hours of cod­ing, all these lit­tle per­ti­nent pieces of infor­ma­tion are being poured into that bucket. Eventually, the bucket fills up and infor­ma­tion starts to flow out. This isn’t spillage. This is the good stuff. This is the cre­ativ­ity that hap­pens after the rudi­ments of the lan­guage and the tools are grasped. Unfortunately, in a mod­ern office, some­one or some thing is con­stantly com­ing around kick­ing over the developer’s bucket. Then, he or she spends all that time fill­ing the bucket up with details of vast arrays of vari­able names, method sig­na­tures, and class prop­er­ties and very lit­tle time enjoy­ing that over­flow of creativity.

These inter­rup­tions come in many dif­fer­ent forms. Some are insid­i­ous (Growl noti­fi­ca­tions) and pro­claim to be help­ful while oth­ers are out­sized (“OMG, the servers are on fire”) and are clearly rea­son­able inter­rup­tions. Here at Emma, we’ve been attack­ing what we con­sider to be the mid­dle ground of that spec­trum. Everyone works a lit­tle dif­fer­ently, so out­side of shar­ing sug­ges­tions, we are cer­tainly not going to demand that folks close Twitter and turn off Growl. We’re also not going to say that “only these peo­ple in this office” are respon­si­ble for some­thing as seri­ous as a ser­vice out­age. What we can do is man­age the office envi­ron­ment in a way that pro­vides for the most pro­duc­tiv­ity given our cur­rent work­load and sup­port processes.

Lost time is just that

Chief and most recent among these changes is a pol­icy where the devel­op­ment teams each have from 1pm-5pm in their respec­tive time­zones declared as interruption-free. We’re lucky enough to have a sup­port team and a QA team that can accom­mo­date this sched­ule and still give our cus­tomers the level of ser­vice they deserve. Essentially, we are all turn­ing off our IMs, clos­ing our emails, and dis­con­nect­ing in any other way we like so that we can fill up our buck­ets and slosh out some fan­tas­tic work. We’ve also com­mit­ted to being more avail­able in the morn­ing hours for sup­port and the like.

This change is only about a week old and there has been some great feed­back thus far. Most of the devel­op­ers feel like sig­nif­i­cant increases in pro­duc­tiv­ity are hap­pen­ing and that they feel more con­fi­dent about the code they are pro­duc­ing. The sup­port team feels that cus­tomer needs are still being met with the same speed and qual­ity as they were before. So, it’s been a pos­i­tive shift over­all. We cer­tainly haven’t increased the num­ber of hours in the day and the sup­port load hasn’t decreased, so for there to be any ben­e­fit, those four evening hours must be nec­es­sar­ily more pro­duc­tive. We’ll have some burn-down charts and more anec­do­tal evi­dence in the com­ing weeks to show us if what we feel is indeed what’s happening.

One inter­est­ing side effect that I’ve noticed is that in the morn­ing I’m a bit more likely to wait to dive into some intense code know­ing that I’ll have all that glo­ri­ous quiet time in the after­noon. However, instead of keep­ing me from get­ting more done, it helps me to look at that bloated inbox in the morn­ing and deal with the emails and such that accrued over the course of the pre­vi­ous afternoon.

Personal and com­fort­able is bet­ter than institutional

We’ve been doing some other things to increase our pro­duc­tiv­ity as well. You may have read Josh’s blog post about our Git work­flow. One of the things that I like about that work­flow 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 con­sid­ered done must merge with prod cleanly and what­ever is pushed to the server should be a fea­ture branch off prod. Past that, one can rebase, merge, amend com­mits, branch of branches, etc. as one sees fit. Being able to cus­tomize your work­flow means less time try­ing to remem­ber and adhere to some process instead of creating.

We also have no stan­dard edi­tor. While we are all Mac users, some of our devel­op­ers are using vim, some are using emacs, oth­ers love Textmate, and one is even sport­ing his Komodo pride. Again, this is all about cre­at­ing a com­fort­able envi­ron­ment for the devel­op­ers so that they can do what they do best. Yes, we are steadily improv­ing the cod­ing stan­dards we want to adhere to, but how one gets that code from one’s head into the machine is not some­thing we need to dictate.

One of my per­sonal goals is to build a library of books and other resources for devel­op­ers to bor­row, use, and talk about. We’ve begun a mea­ger book­shelf (mostly from our own col­lec­tions), but I hope to see it grow soon. I’ve been look­ing at a lot of new tech­nolo­gies and lan­guages, and it would be great to have books about those at hand for any devel­oper to read. Perhaps, some­thing like a group account at O’Reilly’s Safari makes sense as opposed to the printed books, but either way, con­stant learn­ing is some­thing I want to nur­ture within our dev team. You’re prob­a­bly think­ing that these books are more than likely going to become dis­trac­tions as opposed to help­ing devel­op­ers 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 loca­tion to a new office later in the year. I’ve been lucky enough to be included in a lot of the dis­cus­sions about office lay­out and desk choices and light­ing needs. That’s one aspect of our devel­op­ment envi­ron­ment that we prob­a­bly haven’t paid the clos­est atten­tion to, but which will be improv­ing greatly in the future. After all, I spend more wak­ing hours in this office than I do in my home. It needs to be con­ducive to cre­ativ­ity, pro­duc­tiv­ity, and success.

All of these things — time man­age­ment, inter­rup­tion man­age­ment, ready resources, devel­op­ment tools, and even where we sit — are extremely impor­tant as we endeavor to not only bring about a great new API, but also make foun­da­tional changes in our ser­vice. It’s an excit­ing time for us, and I would love to hear about ways you’ve made your devel­op­ment envi­ron­ment more pro­duc­tive, more fun, and a hap­pier place to be.