Stop Trying to Reduce the Number of Complaints

People stop complaining when they’ve given up on complaining, not when they’re truly satisfied.

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

At Redfin, I work on the Platforms team. Part of our job is to improve the software environment in which we develop software. When our build scripts, Java IDEs, or web server infrastructure are slow or unreliable, we investigate.

Even before I worked on the Platforms team, I’d always done the job of general developer support in my spare time. Sometimes the build scripts just won’t work, the IDE just won’t hit breakpoints, or a developer can’t manage to launch a test instance of our website, even when building from the latest stable version of our code, where we know the build scripts work and the website can start up. When this has happened, I’ve always tried to pitch in and help.

(Not everybody does that, I find. Many developers—smart people, maybe smarter than I—avoid investigating developer environment issues, in favor of doing “real work” like fixing bugs and implementing features. That work definitely matters, and I’m not going to say anybody’s “wrong” for trying to avoid working on environment issues. I chalk it up to a difference in personality.)

Around 2012 or so, as it became clear that we had enough budget (and enough need) for people to work full time on infrastructure, I took it upon myself to interview people about what was working well and what wasn’t working well in our developer environment. I already had my own personal list of “Developer Annoyances,” but I forced myself to ask open-ended questions. I wanted to add new ideas to the list, or discover areas that lots of people would independently complain about.

I found that I was having this really weird conversation, over and over again.

Me: What annoys you about your development environment? What’s especially slow or broken that we should focus on?

Them: I don’t know. I can’t think of anything.

Me: Wait, really? Nothing?

Them: I know there must be something, but…nothing’s coming to mind.

Me: Well, what about Eclipse? Doesn’t it randomly fail to compile from time to time? I fixed it on your laptop just last month. [We use IntelliJ IDEA now. It’s better, but still not perfect.]

Them: Oh, yeah! That! I hate that.

Me: OK, now we’re getting somewhere. What else?

Them: (shrugging) I don’t know.

Me: So, what about…restarting Tomcat?

Them: Yeah! That, too. I guess I’d forgotten how much that bothers me.

I found this conversation deeply weird. The first time, I thought it was a fluke. The second person I interviewed—a habitual complainer—recalled clearly what wasn’t working for them (or at least what was annoying them that day) and gave me a bunch of ideas, so I wrote off my first interview.

But the third person I talked to also couldn’t remember anything that annoyed them. And the fourth. And the fifth.

“I guess I’d forgotten how much that bothers me.”

What on earth was happening?

Learned Helplessness

In the 1960s, Martin Seligman performed a cruel experiment on learned helplessness in dogs.

In Part 1 of this study, three groups of dogs were placed in harnesses. Group 1 dogs were simply put in a harnesses for a period of time and were later released. Groups 2 and 3 consisted of “yoked pairs.” Dogs in Group 2 were given electric shocks at random times, which the dog could end by pressing a lever. Each dog in Group 3 was paired with a Group 2 dog; whenever a Group 2 dog got a shock, its paired dog in Group 3 got a shock of the same intensity and duration, but its lever did not stop the shock. To a dog in Group 3, it seemed that the shock ended at random, because it was his paired dog in Group 2 that was causing it to stop. Thus, for Group 3 dogs, the shock was “inescapable.” In Part 2 of the experiment the same three groups of dogs were tested in a shuttle-box apparatus. All of the dogs could escape shocks on one side of the box by jumping over a low partition to the other side. The dogs in Groups 1 and 2 quickly learned this task and escaped the shock. Most of the Group 3 dogs — which had previously learned that nothing they did had any effect on shocks — simply lay down passively and whined when they were shocked.

The dogs in Group 3, dogs that had been unable to prevent painful electrical shocks in the past, learned that nothing they could do would prevent shocks, and so were unable to learn to escape when the circumstances changed.

When the build scripts are unreliable, it seems like a totally random unpreventable life event. It may not be as painful as an electric shock, but it’s certainly frustrating. You just can’t get to work until you defeat this random bridge troll, again.

And when the build randomly just works the fourth or fifth time you try it, eventually you learn to be helpless about the build scripts. This is just how things are; you have to keep trying and eventually it will randomly work.

Unpredictable unpreventable negative shocks are the perfect environment for learned helplessness.

But it’s worse than that. When the build scripts are working, we don’t have to think about them at all. The philosopher Martin Heidegger writes in Being in Time that when a tool (like a hammer) functions correctly, we lose consciousness of it as a separate thing; it almost becomes a part of ourselves.

The less we just stare at the hammer-thing, and the more we seize hold of it and use it, the more primordial does our relationship to it become, and the more unveiledly is it encountered as that which it is — as equipment. (Heidegger, Being and Time, section 15)

When tools are damaged, when they’re almost (but not quite) fit for their intended purpose, we’re forced to think about our tools, instead of what we’re trying to accomplish. Broken build scripts force us to remember something that we need to forget.

Broken build scripts force us to remember something that we need to forget.

Do you remember how hard it was to learn how to code? Do you remember how frustrating it was, trying to squash your sixth or seventh inexplicable syntax error? After a few years, most coders can no longer remember this frustration. We have to forget our frustrations in order to remain productive.

Hope Is the Belief That Things Can Improve

Sunrise, or sunset? (source: pixabay)

My interviews with engineers, in which nobody could remember what it was that bothered them, reminded me of the one engineer who could remember what to complain about.

Previously, I’d thought of this engineer as a complainer. All of the other engineers I talked to seemed to exhibit a lot more general cheer.

But the “complainer” was the one who still had hope that things could get better. All of those “happy” engineers had just forgotten about the stuff that makes them sad and unproductive. They needed to forget that stuff in order to stay productive.

Sometimes my job on the Platforms team is just to remind people that we can fix things, that life can get better.

But I learned one lesson from those interviews: our goal is not to reduce the number of complaints. Our goal is to make our engineers happier and more productive.

(Happiness and productivity are essentially the same thing, in my opinion.)

P.S. Redfin is hiring.