Software developers are usually right. We have to be; it’s a fact of our trade. If you use the wrong syntax, even once, your code won’t compile. Forget the WHERE clause on your SQL UPDATE and you could spend the rest of your day restoring from backup. If only one config entry in your server setup is wrong, that server might crumble like bleu cheese when it’s under load. We learn early to mind the details and make good decisions about technology’s black and white building blocks. We learn to be right.
Unfortunately, the solutions to interesting problems are never black and white. As complexity increases, the right solution becomes harder to see. Maybe there are several right solutions… or maybe each solution involves a trade-off that benefits one goal at the expense of another. That doesn’t stop us from plowing ahead with the same confidence and enthusiasm we learned from making our code compile. We assume that since we’re usually right, we will be right again. This isn’t necessarily a bad thing.
When the path forward isn’t clear, simply making a choice may get things moving again. Confidence is contagious. There is a dark side to being right, however. There is a cost.
Imagine that a client hires you to fix one of its failing applications. You review the code and discover many reasons the application is fragile, doesn’t scale, and crashes daily. The only bright spot is a data layer crafted by a young, ambitious employee. Everyone on the project agrees it’s a step in the right direction. You scrutinize and decide it’s not up to your standards. In other words, the developer didn’t do it the way you would do it. You announce the data layer will be rewritten along with the rest of the app, and the client defers to your judgment.
Never mind that your decision will add thousands of dollars to the project in rewritten, re-tested, and re-integrated code. The worst outcome is that you will lose the trust of a truly talented software developer. That’s the first cost of being right: it leaves less room for others to be right, which makes it less fun to be on your team.
Heather Arthur recently described her experience with sharing code on GitHub. Several veteran software developer-pundits found one of her projects and publicly mocked it on Twitter. Why would they bother? Were they mean-spirited people? It’s more likely they mocked her because they were right. In fact, they were so right that they suspended their social graces to express how right they were. Given complex problems without obvious solutions, ideas compete to be the most right. Sometimes an idea competes on its own merits. At other times, it’s more efficient to attack and undermine a competing idea. You show how right you are by showing how wrong your competitors are*. That’s the second cost of being right: the need to be right can turn you into a competitive jerk. Again, this makes it less fun to be on your team.
The greatest cost of being right is the loss of possibilities. When a developer decides they’ve found the right way to do something, there’s no need to look further. Too often, being right is the end of learning. When you know you’re right, you stop asking your colleagues for their input, you stop experimenting, and you stop reading. In addition, it’s easy to add your solutions to your identity. That’s why Paul Graham warns us to keep our identities small. Once a programming language, development process, or tool becomes part of your identity, it’s impossible to think about the problems it solves objectively.
So how do we proceed? How do we minimize the costs of being right? First, we learn to admit when we’re wrong. This may actually be easier than admitting we don’t know. Catherine O’Neil (mathbabe) believes we need a macho way to say “I don’t know.” No matter how you say it, it takes a lot of guts in an industry obsessed with neatly packaged answers to deliver it with confidence. This makes the confession more important. When we don’t know what’s right, an admission of ignorance focuses our attention on the tender parts of a problem. It allows us to consider all of the possibilities.
Finally, when a decision must be made, it’s best to view the right solution as a probability or trade-off between goals. You won’t find a single, best solution. If you do, look again. Gather perspective from as many smart people as you can find. Look outside your industry, vendor community, and comfort zone for hints toward a disguised solution. Experiment and measure outcomes. When you’re comfortable with the odds, make a decision, confident that you did your best, and then get ready to do it all again, but better this time.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
*This reminds me of the joke about two campers who stumble on an angry bear. The first camper fishes his running shoes out his backpack and hurries to put them on. The second camper says, “What are you doing? You’ll never outrun that bear.” The first camper replies, “I don’t have to. I just have to outrun you!”