Optimizing for developer happiness

Posted by Chad Dickerson | Filed under engineering, philosophy, video

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.


15 responses to Optimizing for developer happiness

  • Alex Ezell says:

    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.

  • Cherian Thomas says:

    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?

  • Peter says:

    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?

    Thanks

  • 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 [...]

  • Leave a Response

    Recent Posts

    About

    Etsy At Etsy, our mission is to enable people to make a living making things, and to reconnect makers with buyers. The engineers who make Etsy make our living with a craft we love: software. This is where we'll write about our craft and our collective experience building and running the world's most vibrant handmade marketplace.

    Code as Craft is proudly powered by WordPress.com VIP and the SubtleFlux theme.

    © Copyright 2012 Etsy