Lately I’ve been really interested in developer happiness. Initially it was because now I have to worry about more than just my own happiness as a developer, but I remain fascinated for a much different reason now.
I’ve always been an unhappy developer, and diving through a lot of writing on the subject over the past half decade (especially out of the Rails world) is starting to explain why. Don’t get me wrong, I really enjoy writing code. But writing code in the Corporate World sucked — and not just because of some stupid policies, standards, reference architectures, or that guy in the cube across from me. I think those are just scapegoats.
It wasn’t until I watched Chad Dickerson (the CEO of Etsy) that I have a deeper insight into why I hated it (but doesn’t explain why I stuck with it for almost two decades). This is from a 2011 RailsConf, and you need to watch it. Do it again if you’ve already seen it.
Dickerson says a lot, but there are two themes I want to explore. First, he believes happy developers are part of a community. Before you cringe (like I did when I wrote that), he makes an import point about “community”: he seems to mean that you’re in a community when you’re in an environment where people watch each others’ backs. As in you know people in a New York City would help you up if you tripped and fell on the sidewalk. In Phoenix, where I’m from, nobody would have even seen you.
That’s a very minimal definition of community, I know, but it’s a lot more than I’ve had at almost all my corporate coding gigs. For example, I’ve been coding too long to make (too many) really stupid design mistakes, so mostly I was paranoid about some stylistic code choice. I would either have some alpha geek call me out on a code review tool, I’d get a bunch of apathetic shrugs, or most often absolute silence (which of course, I would always interpret as just them silently judging me). Call me obsessive, overly sensitive, or whatever you want but mostly it’s because I wanted to be accepted and valuable as part of the developer community where I was and I rarely ever felt that way. And that’s just the developers. When you add in the QA folks, the architects, the scrum masters who challenge you for trying to move your card too early (or, more likely, for why it’s still in the in progress lane), the product owners who hate your error message coloring… a lot of environments hardly met that minimal standard.
And even though it’s pretty minimal, my feeling is that — now that I’m more accountable for community than I was — I should probably be spending a huge amount of my time getting only that much right. Everything else that might happen to make a richer community will rest entirely on that kind of foundation. Indeed, by focusing on higher order community stuff (like, let’s all go play paint ball together) is just going to feel contrived. I can’t attest to how community is formed, but I know a great deal about the little things that cause developer communities to fail.
Dickerson’s other big theme is craftsmanship (not a surprise from the chief of Etsy, I guess). He talks about some of the obvious things like tooling (text editors, etc.) how easy it is to deploy code, but his point about craftsmanship is letting developers connect to their work. Easy for a startup to say, and easy for a big corporate environment to mess up — true. That’s easy, easy to criticize, and I think pretty straightforward to fix.
What he doesn’t mention about craftsmanship is how community (or a lack of it) can really disrupt your connection to your work — especially if you’re touching each others’ code.
Anyway, just some initial thoughts… lots more thinking and reading to do on this subject.