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.
This is a good reminder for engineers debugging. I'd love an LLM assistant to bring this up periodically if we're debugging something together. What's the simplest cause?
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 😅
This is a brilliant example, Anton, and the most straightforward explanation—even though sometimes it’s challenging to explain.
Thank you for your perspective!
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ł!
Well deserved shoutout, great article Samuel!
This is a good reminder for engineers debugging. I'd love an LLM assistant to bring this up periodically if we're debugging something together. What's the simplest cause?
I can imagine that LLM-based copilots will improve over time.
Here, the simplest cause represents the most obvious cause.
(Sorry for the delay, Colton! I missed your comment)
Simplicity is a sign of elegance. Loved reading about the mental model Michal.
Also thanks for the shoutout to Leadership Letters.
I’m glad you liked Akash. Indeed, simple solutions are more elegant. I reckon we perceive things that consist of fewer elements as more elegant.
It was a great article of yours to keep the balance of engineering.