TIL: Resulting

Today I was listening to an episode of the Productivityist Podcast, an interview with Annie Duke. Annie talked about a mental model/cognitive bias where people think the result of a decision is an indicator of that decision’s quality. Put simply, it is the assumption that a positive result indicates that a good decision was made, and a bad result indicates a poor decision was made. In reality, the result of the decision may have nothing to do with the quality of the decision made.

It got me thinking about how often we do this with our tech choices, such as language, stack, framework or programming methodology. Just because a unicorn startup like Canva used React and had great success, doesn’t automatically mean React was an excellent choice. It certainly doesn’t mean we should choose that language for our own Project. Yet, other companies’ outcomes can sometimes heavily sway our decision-making around selecting a framework for ourselves.

On the flip-side, it is easy to judge past decisions about tech as mistakes when we didn’t have a positive outcome from that choice. A personal example is when our team chose to use Redux and Immutable.js in our front end codebase in 2016. Today, the code written during that time is hard to follow and generally a pain in my ass. Does that mean choosing that tech was a poor decision at the time? Not necessarily.

So, if we shouldn’t use results, what should we use to engage in good decision making? Honestly, I don’t have the answers. It’s complicated, and I am now inspired to read more about this subject. After learning about resulting, I can at least catch myself when I’m being wooed by other people’s great results. And be a little easier on myself when I look back on decisions I’ve made in the past.