5 Laws Every Builder & Thinker Should Know
When you build products, write software, or try to navigate work and life, you quickly realize that most of the friction you hit isn't unique to you. People have been running into the exact same traps for decades. Over time, thinkers and engineers condensed these hard-earned observations into simple mental models.
Here are 5 practical laws that changed how I approach problem solving, execution, and decision making.
1. Murphy's Law
"Anything that can go wrong, will go wrong."
In software development, if an edge case can fail at 2 AM on a Sunday, it will. Murphy's Law isn't about being pessimistic or living in constant anxiety. It’s an instruction for defensive design.
Instead of hoping production services never fail or network calls never time out, you assume they will. You build fallback handlers, write clean error boundary logic, handle null states gracefully, and test failure paths before your users hit them. Preparing for setbacks in advance is what lets you build resilient systems.
2. Kidlin's Law
"If you write a problem down clearly, it is half solved."
Have you ever spent hours banging your head against a bug, started writing a message to a teammate to explain what was broken, and figured out the solution halfway through typing? That is Kidlin's Law in action.
Unclear problems stay unsolved because they live in our heads as a jumble of assumptions and emotions. When you force yourself to put thoughts on paper—writing out the exact inputs, expected outputs, and current behavior—you strip away the noise. The moment a problem is clearly stated, the missing piece almost always presents itself.
3. Gilbert's Law
"No one tells you what to do at work or in life. You must take total charge of your own tasks."
Nobody comes with a step-by-step instruction manual for your project or career. Early on, it’s easy to wait around for detailed specs or explicit hand-holding. But real progress happens when you step up and take full ownership of your output.
Taking charge means not waiting for permission to fix what’s broken, unblock yourself, or learn a new tool. You diagnose what needs doing, outline your approach, and execute. Total ownership gives you momentum.
4. Wilson's Law
"Put information and intelligence first, and money and success will follow."
When people chase immediate rewards, money, or vanity metrics without building underlying competence, the results are usually short-lived. Wilson's Law flips the priority: focus relentlessly on learning, curiosity, and mastering your craft.
Knowledge compounds. When you build deep domain expertise, solve hard technical problems, and focus on genuine value, success and financial rewards come as a natural byproduct rather than something you have to force.
5. Falkland's Law
"When you do not have to make a decision, do not make a decision."
Premature decision-making is a hidden trap in engineering and design. We often try to lock down database schemas, framework choices, or abstract features before we actually have enough real-world usage data.
Falkland's Law reminds us to defer non-essential choices until we have sufficient facts. If a decision doesn't need to be made today, leave it open. Waiting gives you more context, preserves flexibility, and prevents you from building complex solutions for problems you don't even have yet.
Built with care by Dev Chauhan. Follow on GitHub or Twitter / X.