On the necessity of assholes

I just read Rusty Russell’s recent blog post about code written by assholes and Jacob Kaplan-Moss’s response. I’ll summarize Rusty’s point as “You don’t have to like assholes or agree with them, you just have to work with them in open source,” and Jacob’s point as, “No, I don’t have to work with assholes, and if we all worked together we could make it unacceptable to be an asshole in open source.” (Hacker News discussion here.)

At one time, I fully subscribed to the dogma that the only way to create high-quality, well-designed, reliable systems code (open source or not) was to be assholes to each other. But I’ve come to disagree with past-Valerie about the necessity of assholes for a number of reasons, starting with existence proofs to the contrary: successful well-designed projects run by non-assholes like Python and Perl.

Take just one argument for the necessity of assholes: Public humiliation is required for high-quality code. If you will be publicly mocked and humiliated for posting bad code, you’ll work harder on finding and fixing your bugs, and the overall code quality will go up. Sure, fear makes you review your code more – but is this the best way to create high-quality code overall? Are the costs higher than the benefits?

Research has shown over and over again that people experiencing fear are less creative in problem solving and less likely to find the optimum solution. Fear makes you more careful in your work, but it also makes you less willing to take risks, try new ideas, and make progress. Fear might be a good way to run a maintenance-mode project, but not one that needs active development and new ideas.

The more I look at the arguments for why assholes are necessary to good code, the more I have to wonder if some form of Stockholm syndrome is at work. As open source developers, our careers are to some degree hostage to project leaders. If project XYZ has an abusive leader, you either have to keep working on that project with that leader, or make a significant and risky career change. Change the leader or their behavior? Not really an option. There’s no manager or HR department to go to to deal with abusive fellow “employees” in open source, and it’s hard to move to a project far enough away not to work with that person but still be in your area of expertise. It’s a tough choice.

What I do know is that a lot of open source developers in asshole-heavy projects are unhappy with the current situation. Is it possible to change the social norms of these open source projects without lowering code quality? My guess is that the answer is yes, but only time will tell.

Update: People keep recommending “The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t” by Robert Sutton. I haven’t read it, but it sounds promising enough that I bought a copy and will read it this weekend.

8 thoughts on “On the necessity of assholes

  1. I think in the end one weighs the cost of suffering under an asshole’s project leadership against the benefit of having them as a collaborator.

    But it takes guts to fork a project, and I’ll bet my hat people rationalize their failure to fork by exaggerating the value of the asshole — especially if, as does happen, the asshole has some charisma as well.

  2. I agree with you about arsehole collegial styles or management styles, but Rusty’s post is a bit ambiguous to me. It’s not clear about whether he’s talking about people who are arsehole colleagues or people who are good colleagues who have (arguably!) arsehole political views or arsehole behaviour in areas of their life that don’t affect colleagues (at least, not obviously).

    In the second case his point of view is a bit stronger, at least for me. To pick just one example, I wouldn’t really consider it my business to act in any way if a colleague was cheating on a romantic partner. For a friend this would be more likely to affect our relationship. It’s not absolute though: there are definitely still cases where someone’s extra-coding arseholery is so awful that one is unconscionably enabling it by knowing about it and not speaking against it. And there are cases where someone might like to pretend that their arseholery is extra-coding, but in fact it affects colleagues too (eg, *-isms or use of slurs).

  3. Good post and it inspired me to have a look at the Robert Sutton thing, only to be greeted by the infuriating Amazon message “This title is not available for customers from: Australia”. This seems to happen with about two-thirds of the books that are recommended to me and it’s getting really old. I do see why people just decide to circumvent the ridiculous rules. Anyway, I like what you had to say.

  4. “Fear might be a good way to run a maintenance-mode project, but not one that needs active development and new ideas.”

    I wonder how this may be tested. How might one measure the due-to-fear-unmet needs of active development, especially for a project that thinks it’s doing great? If the leaders don’t think they have a problem, how to objectively convince them otherwise?

Comments are closed.

%d bloggers like this: