During my Electronics labs at university, one group could not get the oscilloscope to work so they asked for help. The professor went over to them and said "electrical devices work best when connected to power" — and he was right, they had not turned on the power.
Occam's Razor looks for the simplest explanations, which is what the professor did when asked for help.
Occam's Razor is the problem-solving principle that encourages searching for explanations constructed with the smallest possible set of elements.
It is used as a reminder that:
The simplest explanation is often the best one.
Tech support checklists are a good example: when looking for the cause of an issue we should start with the most likely one. When a user cannot log in to a website, tech support will tell you to double-check your password as it is the simplest explanation as to why users cannot log in.
Origin
The origin of this rule can be traced back thousands of years, to Aristotle:
Nature operates in the shortest way possible.
— Aristotle
In philosophy, a razor is a principle that cuts through unlikely explanations, and this particular one is attributed to William of Ockham, a 14th-century English philosopher and theologian.
Practice
Deciding on the simplest option does not necessarily mean choosing the first one that comes to mind.
To apply Occam's Razor when seeking explanations or solutions:
Evaluate possibilities.
Use the simplest one that works.
Engineering Simplicity
In the IT world, Occam's Razor can be valuable in many scenarios:
When debugging, begin with the simplest possible cause.
When there are multiple ways to implement a feature, choose the simplest one that works.
Follow the YAGNI (You Aren't Gonna Need It) principle — avoid implementing features that are not currently needed.
Embrace the KISS (Keep It Simple, Stupid) principle — simpler solutions are easier to understand, develop, and maintain.
Start with a simple app to validate your business idea, create an MVP, and iterate from there. There's no need to begin with a distributed microservices architecture capable of handling 1M requests simultaneously.
Summary
Occam's Razor has been a helpful tool for me throughout my career, reminding me to start with the most obvious potential cause of an issue and then attempt the simplest solution.
It is a valuable tool to have in your decision-making toolbox.
However, it will not replace critical thinking. Use it, but keep in mind that it is not the ultimate solution for all problems, just like any other mental model.
What are your favourite examples of applying Occam's Razor?
Thanks for reading!
Michał
PS My interest in mental models has been growing over the years thanks to Farnam Street. Their podcast, The Knowledge Project, and their books. Occam's Razor was one of the first mental models I learned.
Post Notes
Discover Weekly — Shoutouts
Articles that might help you explore new perspectives which I have read this week:
“5 Critical Mistakes Every Data Engineer Must Avoid for Career Success” from
— shared great advice on career, focusing on taking ownership of one’s growth, discussing salaries, and the mindset for acquiring skills. I found it relatable to every engineering career.“The Sweet Spot Between Too Much and Too Little” from
— Great leadership insights from “Trillion Dollar Coach: The Leadership Playbook of Silicon Valley’s Bill Campbell” prepared by .“How Netflix Delivers High-Quality Streaming to 269 Million Viewers” from
— If you ever wonder how Netflix can play a selected video right after your selection, check out ’s article.“The Sweet Spot Between Too Much and Too Little” from
— described his balancing act on over/under engineering, with insights from his work at Google with Chrome.
I’m most often reminded of this during production incidents. If you changed something near the time of the incident - in 99% of the cases it’s the cause, even if you have absolutely no idea how it’s related 😅
Software engineers often forget about this principle. We work with complex systems, solving multi-faceted problems, and therefore expect to create similarly complex solutions. And many times, simple solutions work better.
Also, thanks for the shoutout, Michał!