Reading Time: 11 minutes

In this series, I’m exploring the influence of white supremacy culture on tech (and broadly, professional) culture, following Kenneth Jones and Tema Okun’s list of characteristics as a guide. Here’s the introduction and the full series so far.

Let’s talk about the sixth element of white supremacy culture: only one right way.

Here’s the description of Only One Right Way, verbatim:

Only One Right Way

• the belief there is one right way to do things and once people are introduced to the right way, they will see the light and adopt it
• When they do not adapt or change, then something is wrong with them (the other, those not changing), not with us (those who ‘know’ the right way)
• Similar to the missionary who does not see value in the culture of other communities, sees only value in their beliefs about what is good

As you might know, I began my programming career at a company with a reputation among codeslingers as an evangelical extreme programming cult.*

* I joke about the cult thing. Full disclosure: I had a relatively positive and overwhelmingly valuable experience working there. I still think most companies with software could stand to learn from stuff they do. That said—the synchronized clapping at the end of standup really didn’t support our “we’re not a cult” argument, did it?

And, to be sure, we had projects where we slathered on pair programming, test-driven development, and continuous deployment to a degree far beyond what would benefit our client—let alone take hold when we left. When a company makes “Do the right thing” 44% of their motto and then applies a single set of practices to every project they land, it becomes a parody of the “One Right Way” mentality.

But you know what? I’m not convinced our clients were any better about this. Sure, our “right way” maybe wasn’t so universally right, but I also can’t tell you how many client developers I saw walk through our doors, resentment etched into their faces, hell-bent on learning absolutely nothing here. They were already looking forward to their plane ride home at the end of the month, where they’d plan their rant to their bosses and their bosses’ bosses about how our way was useless, that the company should really just do things the way they have been saying to do it all along.

In some cases, they were right. But in every case, there were at least two ways to do it: our way and their way. And somehow, rarely did someone seriously consider them both.

By the way, tech isn’t accidentally like this: it’s encouraged.

Have you heard of Uncle Bob? Figured you might’ve. His book, Clean Code (no, I won’t link it; check the footnotes here to see why) still gets regularly cited in computer science classes. Uncle Bob’s willful ignorance about injustice systems and the people they devour is long-lived and consistent, in part because he doubles down when dragged onto the carpet about it.

That problem with Bob—his refusal to see perspectives other than his own as legitimate—has, compounded over years, noticeably hindered the accuracy and utility of his programming instruction. I already dragged him for this (again, the footnotes). So today I’ll change it up for you and tag in Hillel to drag him instead.

Hillel Wayne, “Uncle Bob and Silver Bullets“:

Uncle Bob is okay with software correctness: after all, he uses the phrase “unit testing” like a smurf uses “smurf”. But what about every other correctness technique?

• End-to-End Tests: ‘Don’t test through UIs’.
• Safer Languages: The ‘Dark Path’.
• Data Integrity: Just ‘a detail’.
• Type Systems: ‘You don’t need static type checking if you have 100% unit test coverage’.
• Formal Methods: Only a ‘shiny’.
• Property-Based Testing: Probably hasn’t heard of it.

In other words, any correctness technique that isn’t unit tests can be dismissed.³

Wanna know how well “unit tests are all you need” tends to go? I can tell you, because in the aforementioned cult company, that was our whole software verification strategy. I anchored half a dozen mobile projects for that company, and I’ll tell you what: there’s a reason mobile shops have quality assurance teams. Unit tests didn’t catch all the things a user might try that developers didn’t anticipate. Unit tests also didn’t save us when eleven million users couldn’t log in because the authentication mechanism had been supplanted by a check for whether the user’s password entry equalled “test1.” This was both the password for the test account and the password for the happy path in the unit tests, so the suite passed with the line changed, and it got to prod.

Reliance on one method to the exclusion of all others is not a uniquely Uncle Bob problem. Let’s look at another famous proponent of this: Linus Torvalds, who “created git” (not exactly accurate, for reasons we have discussed) and now blatantly tells auditoriums full of programmers that he is smarter than all of them and his way is the obvious choice in a field of other non-ways, apparently.

The field, by and large, listens to people who think and talk like this.

So what happens next? Well, everybody else emulates that. Three words for you: The Definitive Guide.

Definitive (adj.) – decisive and with authority. “This is the resource to consult for the final say on this topic.”

The preponderance of tech books and articles with this phrase in the title boggles the mind, but my favorite has to be JavaScript: The Definitive Guide, 7th Edition. Because no phrase builds credibility quite like “The Book With All The Answers, Attempt #7.”

Hopefully I’ve satisfied you that tech loves its one right way. When we focus on one solution to the exclusion of all the others, though, we cut ourselves off from the opportunity to improve our thinking and programming.

We’re forced to reckon with this when faced with evidence that a different approach would have served us better than the one we took. This hurts our pride, so we try to put it out of our minds—which prevents us from reflecting on it to change our behavior. I call this the “Last Unknown” Fallacy: acting as if the most recent mistake came from the last piece of knowledge on Earth that you didn’t already have and continuing thereafter to approach every question with absolute confidence in your one way.

What if we instead practiced imagining a collection of ways, instead of just one?

The antidotes for this element provide some examples of that.

Antidotes:

• accept that there are many ways to get to the same goal;
• once the group has made a decision about which way will be taken, honor that decision and see what you and the organization will learn from taking that way, even and especially if it is not the way you would have chosen;
• work on developing the ability to notice when people do things differently and how those different ways might improve your approach;
• look for the tendency for a group or a person to keep pushing the same point over and over out of a belief that there is only one right way and then name it;
• when working with communities from a different culture than yours or your organization’s, be clear that you have some learning to do about the communities’ ways of doing;
• never assume that you or your organization know what’s best for the community in isolation from meaningful relationships with that community

I see three themes among these antidotes. We’ll go over each in turn.

1. Disconnect your current perspective from your identity.

I used to feel debilitating defensiveness when I came across statements on the internet that differed from my approach to software development. I could feel my throat muscles tighten and my jaw clench. I took offense at the mere suggestion that I might be uninformed or under-informed about the code I was writing.

Sometimes it still happens, but I taught myself a series of steps for when it happens.

1. Recognize the defensiveness
2. Inquire as to whether it’s coming from an insecurity of mine about my own skill, rather than anything inherently inflammatory about the idea itself
3. Approach the discordant perspective with curiosity rather than fear and anger, asking questions like:
   1. Where can I learn more about this approach?
   2. What circumstances might affect whether this approach or my approach is right for a situation?

Following these steps helped me start to bypass (or at least speed through) the emotional upset associated with realizing I might be wrong. Then I get selfish: how can this perspective make me more skilled, more knowledgable, and more right? Maybe I want to adopt this perspective, or adopt it only in certain circumstances, or refute it altogether. In any of those cases, I can learn something from it.

2. Recognize the “One Right Way” mentality in…others, I think, though I can’t personally sign off on that approach.

So, I think it can be an illuminating exercise to look for this behavior in other people, but I think it’s more illuminating (and useful, frankly) to look for this behavior in ourselves.

I also wouldn’t “name” this behavior in other people, unbidden. My experience does not suggest, by and large, that people respond productively to being publicly called out on their behavior, particularly if it’s not immediately glaringly obvious how changing that behavior would help them achieve any goals they already have for themselves (we did a whole series on this and will talk about alternatives to confrontation later in future pieces).

3. Approach new situations with curiosity rather than prescriptions.

When I’m not the expert, I tend to lead with that before I make any suggestions. That does a few things. First, it builds my credibility: I say I’m not the expert, so folks know that when I tell them I know what I’m doing, it’s true.

Second, it helps me explicitly shift into a curiosity mindset. I find that I learn more and build better solutions by taking time explicitly to name and question my assumptions. That’s the case for debugging, for code review, and for system design.

Third, it provides an explanation so folks are sympathetic when I want to take time to listen and ask meaningful questions, rather than make assumptions (whole series on this). That sympathy proves especially helpful in situations with deadlines where folks feel a sense of urgency to get something done and temporarily lose sight of how much it will cost us if the thing we do ends up being wrong.

Conclusion

As you might know, I began my programming career at a company with a reputation among codeslingers as an evangelical extreme programming cult. When a company makes “Do the right thing” 44% of their motto and then applies a single set of practices to every project they land, it becomes a parody of the “One Right Way” mentality.

But you know what? I’m not convinced our clients were any better about this. Sure, our “right way” maybe wasn’t so universally right, but I also can’t tell you how many client developers I saw walk through our doors, resentment etched into their faces, hell-bent on learning absolutely nothing.

By the way, tech isn’t accidentally like this: it’s encouraged. Programmers with massive platforms, like Robert Martin and Linus Torvalds, model this approach for a doting community that then copies them and writes crapola titled “The Definitive Guide.”

But when we focus on one solution to the exclusion of all the others, though, we cut ourselves off from the opportunity to improve our thinking and programming. What if we instead practiced imagining a collection of ways, instead of just one? The antidotes for this element provide some examples of that.

I see three themes among these antidotes. We’ll go over each in turn.

1. Disconnect your current perspective from your identity.
2. Recognize the “One Right Way” mentality in…others, I think, though I can’t personally sign off on that approach.
3. Approach new situations with curiosity rather than prescriptions.

If you liked this piece, you might also like:

The rest of the posts in the (brand new!) inclusion category

The series about reducing job interview anxiety (especially for folks with a little experience)

The cost-effectiveness of pair programming (for folks who feel strongly drawn to working with others!)