Engineers Who Won't Commit

Summary

Some engineers think it’s a virtue to remain non-committal in technical discussions. Should our team build a new feature in an event-driven or synchronous way? Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side. This strategy is fine when you’re a junior engineer, but at some point you’ll be the person in the room with the most context (or technical skill, or institutional power). At that point, you need to take a position, whether you feel particularly confident or not. If you don’t, you’re forcing people with less technical context than you to figure it out themselves. Often that means somebody will take a random guess. In the worst case, the weakest-but-loudest engineer on the team will take the opportunity to push for a spectacularly bad idea. If you’re a strong engineer, it’s your responsibility to take a position in order to prevent that from happening, even if you’re only 55% or 60% confident. Why remaining non-committal is cowardly Like most forms of cowardice, remaining non-committal feels like sensible caution from the inside. After all, technical problems are complicated. There are always reasons to express uncertainty or to add caveats to a statement. If the right way to go really is unclear, then (they say) it’s strictly correct to express uncertainty. I think what’s often motivating this attitude is that many engineers (me included) really, really, pathologically hate being wrong. I get a sick feeling in my chest when I’m wrong about something, particularly in public. I think about it afterwards for a long time. This is useful, because it makes me put in the effort to be right. But it also makes it emotionally difficult to give an educated guess in a meeting that might end up being dead wrong. I’ve had to work to become OK with doing that, so I sympathize with people who can’t. But I also see it for what it is: cowardice. When people are relying on you to make a c...