Have you ever found yourself thinking thoughts similar to these?
- “This project deadline is too short so I don’t have time to dig into this issue.”
- “This is the way we’ve always done it, so we should keep doing it.”
- “This is what happens when I do
X, so I’ll move on. There’s no reason or time to dig into the code or find out why it happens.”
I’ve certainly thought all of the above and many more thoughts of their kind. The problem with this chain of thinking is that it puts you into an artificial trap. When you accept the way that things are on the surface, you are stuck in a paradigm of your own creating and it’s incredibly hard to break free.
Daniel Kahneman touches on this topic in his epitomal book, Thinking, Fast and Slow. In the book, he introduces the two stages through which our brain processes, System 1 and System 2. System 1 is emotional, quick, and handles most of our decisions and System 2 kicks in when System 1 can’t decide or solve a problem.
System 2 is vastly better at questioning and solving complex problems, but oftentimes delegates these to System 1 out of laziness. This becomes a problem because System 1 is also inherently lazy and follows the path we’ve already walked down and we end up doing the same thing over and over again.
When we don’t stop to question the status quo and accept assumptions that we don’t even know are assumptions, we lose the ability to find the real solution.
Luckily, we have Rigorous Thinking to help us break out of this cycle.
The below is from Stripe’s cultural document and I believe that it perfectly summarizes “Thinking Rigorously”.
Many behaviors are blindly copied and repeated far beyond their useful lives. We make a habit of trying to tease out the best version of an opposing argument. When criticized, we try to seek the truth in the accusation rather than activating our defensive shields. We invite people who many of us disagree with to come speak at Stripe and we welcome views that don’t obviously mesh with our own.
Rigor doesn’t mean not-invented-here syndrome. We’re interested in the world around us and think that other companies, industries, and academic fields have much to teach us. We actively hunt in other fields for inspiration and ideas that challenge our assumptions and that we could learn from.
Thinking rigorously has many natural applications to our daily work. For example, we think the traditional way that candidates are interviewed in the technology industry is suboptimal. We’ve invested significant effort in fixing it, by introducing work-sample tests, dispensing with whiteboard programming, de-emphasizing credentials, and actively working to combat unconscious bias, among other changes. But that doesn’t mean we’re satisfied with our current process either. We suspect that there are a lot of significant improvements still to be made.
Part of being rigorous is being judicious. Stripes have measured reactions to things. We engage in testing and strenuous discussions with colleagues — but we don’t yell.
https://stripe.com/jobs/culture
Rigorous Thinking is a tool that we can use in our daily lives to ensure the best possible work. This means questioning decisions, diving deeply into the code, talking to our colleagues about why an architecture was chosen. It also means identifying and examining our mistakes and sharing the findings so that others do not repeat our mistakes.
A good example of Rigorous Thinking is Project Retros. You take a whole project (or substantial portion of one), examine it deeply for what went right, what could change, and what needs to be addressed and carry those lessons forward.
Just to be clear, Thinking Rigorously could just as easily lead to you agreeing with the status quo as it could disagreeing with it. Diving more deeply into a problem or decision isn’t a guarantee that you’ll come out happy – but you will come out with the truth and a deeper understanding of what you do every day.
Break Free, Think Rigorously and Question the Status Quo
Question why something happens. Question why historical decision were made. Question why we use whitelist/blacklist instead of clearer terminology. Question why we make the technology decisions that we do.
When you get an obtuse error out of a library, dive into the code and find the source of it. When you get unexpected results from code you wrote or some library’s API, strive to understand the architectural decisions that led to this behavior.
You may that decisions which were made 5 years ago are no longer relevant and you can improve your daily work vastly. Your life will improve, your teams will have a better product, and everyone will benefit from your Rigorous Thinking.