Optimizing for developer happiness

Posted by on June 6, 2011

A few weeks ago, I gave a talk at Railsconf in Baltimore about how we optimize for developer happiness at Etsy. In the talk, I go into the philosophical reasons why continuous deployment makes engineers happy, how radically decentralizing authority and thinking of your team as a community optimize for happiness, and the how our approach to tooling makes everything work.

Here’s the video:

. . .and here are the slides.

A big thanks to Ben Scofield and Chad Fowler for inviting me! It was loads of fun putting the talk together and chatting with folks at the conference afterwards.

A big tip of the hat to Charlie Chaplin, Peter Drucker, and Jane Jacobs for the inspiration of their work.

Posted by on June 6, 2011
Category: engineering, philosophy, video


Nice presentation. I appreciate the analogy of the assembly line and how some of us haven’t strayed as far from that as we probably think we have.

Have you ever had a situation where a developer feels a bit of paralysis in committing code because they know that there’s not a buffer between them in production. They would seem to be flying without a net. Ideally, you’d hope this would focus a developer’s attention and enforce some greater sense of responsibility. The darker side of that might be an anxiety-based paralysis. Has this ever been an issue?

    Thanks for the comment, Alex. We don’t really see that kind of paralysis because there are a number of safeguards along the deploy path and the nature of our deployment patterns (lots of small changes that are typically easier to understand than large ones) make the individual changes lower-risk. Developers also have their own environment where they can test their code in isolation from the production environment before deploying. We have an array of automated tests, too (all described here). We’ve also invested a lot in gathering metrics in the deploy process, which protects us, too.

    At the end of the day, though, we expect developers to be careful and check their work all long the way, so in that sense there is a greater sense of responsibility for folks on the team. That’s where the community aspect comes in — no one wants to be the person who disappoints their community.

Nice presentation. Thanks for the opening up your culture.
How do you do branching and merge. With 25 pushes, who maintains the pristine version of the site? What are you failover plans if a push breaks.
Can you help me address this?

Great talk. I am also a fan of Drucker and I feel that his message to build corporations that support the communities they live in on a human level is often ignored.

It’s funny how we can get caught up in the technology or what programming language we use when the common denominator is us – people.

I wonder.. does the community have a say in who is a part of it? I mean, how do you involve them in the hiring process?


Interesting talk. Thanks for the insight into life-at-Etsy and what is done there to keep people happy and invested in their work. I was expecting a reference to Marx/Engels and their accounts of “alienation from production” (an apt phrase!). There are some great ethnographies of the industrial workplace that I’m sure you’d find interesting, if you haven’t already read any.

[…] particular blog post is targeted towards people who work in code on a day-to-day basis, but I think it and the blog is […]

[…] I’m working on, not just the easiest one to get digitally. In the course of putting my “optimizing for developer happiness” keynote at Railsconf, for example, […]

[…] Though we did not move to Git for its branching capability, our tools weren’t capturing some of the work we were already doing with patches and pushing changes directly between team members for review and testing. We also felt that re-examining and adding new tools to the mix seemed like a healthy trait to have in our culture, and felt the switch to Git would increase engineer happiness. […]

[…] It didn’t stop there either.  Etsy has continued this tradition of optimizing for the employee and driving all their decisions by real data.  Chad Dickerson sums it up nicely in a talk he delivered at railsconf. […]

[…] difficult to teach as it is important. To get a sense of how we think about culture, take a look at Optimizing for Developer Happiness, which includes a 24-minute video of a talk I did and a link to the accompanying […]

[…] performance problems plague Valentine’s Day shoppers.- Etsy’s Chad Dickerson describes his philosophical approach to continuous deployment.- Daniel Doubrovkine documents New Relic performance instrumentation with […]

[…] el evento Railsconf en Baltimore, Chad Dickerson platico sobre como optimizar el proceso de trabajo en su empresa, para facilitar que los […]

Hi Chad, I’m a retired SW eng that dates way back about 10 years before the first ATT Unix V6 release. Now I mess around with copper and silver smithing and am an Etsy seller. I relate completely with the craft aspects of code development but now as an end user ( Etsy shop owner ) I have to tell you how disappointed I am with the interface and tools that Etsy provides. Imagine using VI without any type of global functions or regular expressions – not to interesting or productive. Etsy shop creation and maintenance is an endless stream of mundane repetitive operations much like what Chaplin endures. You have created a factory environment for Etsy sellers to the point where 3rd party sites exist just to help sellers edit their shop listings. That should tell you something. Your deployment methods and philosophy have fostered an endless stream of trivial mostly cosmetic changes that do little if anything to enhance the sellers experience.

Sellers have submitted some 45,000 ideas to improve Etsy. Granted most are duplicates, absurd or too narrow in scope to be considered. For those ideas that have true merit, there is no system in place to effectively log or track status – thus the repeated requests for changes and no feedback mechanism to even acknowledge consideration.
Consider the environment and philosophies you promote and how they can be extended to your users through creative tools, interfaces and simple changes that save precious time through the entire process of listing and selling a product.

Etsy growth is truly impressive and in many respects commendable but now there are 400,000 users struggling under the antiquated interface and hundreds of oddities that waste time and cause frustration. It’s my impression that the Etsy developers are completely out of touch with the needs of the seller community every day aspects of life on Etsy.

[…] focus). Some of the key points of the talk. Etsy trusts employees. Etsy’s strategy is to optimize for developer happiness. Etsy has lunches twice a week where employees build […]

[…] had about the structured chaos of Etsy’s deployment process, which I detailed in my Optimizing for Developer Happiness talk from Railsconf last year (see the bit about the “push train” starting at 17:58 in this […]

Awesome presentation!

Question about the Push Train… Are developers deploying specific files only? Say I have 1 fix in 1 js minified file, would I get in line for just that file to be pushed? and not some other files also committed to Trunk?


    How much to deploy is entirely up to each engineer. If you have an urgent fix that needs to go out, or if you just want to clear your plate before moving on to some other work, then yes you could get in line to push your one file. If that change logically lives with some other set of changes, you can wait to push until that work is finished and push a bunch of changes at once. The basic aim is to push small(ish) chunks of code regularly. Smaller changes are easier to test, which makes deploys quicker (less time spent manually verifying that the change is good in production) and more reliable (less chance of suddenly finding some bug during a deploy).

    The “train” metaphor is because we don’t want too many people with changes in any given deploy (it makes things slower as you’re trying to get everyone organised, and the more changes in a given deploy, the harder it is to work out what went wrong if something does go wrong). So you join the train at the end, and you’re put into the last open “carriage” (I think we max out at eight people per carriage right now). The people at the front are the ones actively deploying their code – everyone in there does a git push to master, and then the first person in the list (the “driver”) pushes the buttons in Deployinator to actually deploy the changed code. Once everyone’s verified that they’re OK in production, the next carriage of deployers is up and the process repeats. So, even if you have only one changed file to deploy, the actual deploy you’re in may have many files since you’re pushing with multiple colleagues.