Introduction
I still remember the day I actually build something with MYSQL for client. it was 2007, and I was building an admin panel for a construction company's website. Nothing fancy, just a way to update their crew list, because the orignal site was pure html and I was manually editing it every time someone was hired of left.
back then I didnt know what MVC was, or anything about structural coding practices. But when the panel worked, I felt unstoppable.
In that moment, I thought, “I can build anything. Maybe even the next Hi5.” (For the younger crowd: Hi5 was a social platform that came before Facebook became famous.)
Over the years, my understanding of databases deepened. I discovered JOIN queries, stored procedures, indexes, database design principles and MySQL uses B+ trees for indexing. The world that once seemed simple suddenly became vast and complex.
If you had asked 2007 me whether I could design a database for ten million phone records, I would have said “No problem!” without hesitation. If you ask me today, I’d pause. I’d want to know the requirements, the scale, and whether MySQL is even the right tool for the job. That pause.. that humility.. that comes from realizing how much I don’t know.
That’s the heart of what psychologists call the Dunning-Kruger effect.
What is Dunning-Kruger Effect?
The Dunning-Kruger effect, described by psychologists David Dunning and Justin Kruger, is a cognitive bias where people with little knowledge tend to overestimate their abilities, while people with deeper knowledge often underestimate themselves.
it's that curve you might have seen online
- At the start, you feel like an expert after a little learning
- Then you discover how vast the subject is, and confidence drops.
- Over time, as you master more, confidence rises again But with more humility.
It’s like learning to cook. The first time you boil pasta, you feel like Gordon Ramsay. Then you discover sauces, spices, techniques and suddenly cooking seems overwhelming. Years later, you may actually be skilled, but you’ll still admit there’s so much left to learn.
Recognizing “Mount Stupid”
Most of us go through a “Mount Stupid” phase a time when we feel like experts after just scratching the surface. I’ve definitely been there. Early in my career, I wrote code I thought was a masterpiece, only to realize later how fragile or unscalable it really was.
I’ve also seen others hit that phase. Sometimes, with the best intentions, someone charges ahead with full confidence and implements a solution that looks great in theory but breaks under real-world use. It’s not laziness or malice, it’s simply not knowing what we don’t know.
The Challenge of Working Through It
The tricky part isn’t just the overconfidence, it’s the aftermath. A rewrite or “brilliant” shortcut can cause issues that take longer to fix than the original system ever did.
I’ve been on both sides of that. I’ve proudly introduced “better” solutions that didn’t account for scale or edge cases and I’ve also been on the team cleaning up after such changes. In both cases, the frustration is real: the gap between what we think we’ve solved and what actually works under pressure.
How I Deal With It
Over time, I’ve found a few approaches that make these situations easier:
- Give feedback as questions. Instead of saying, “This is wrong,” I ask things like, “What happens if this input is empty?” or “How does this scale under heavy load?” Questions open up dialogue instead of putting people on the defensive.
- Use data, not opinions. It’s easy to argue opinions. It’s harder to argue against performance numbers, bug reports, or clear benchmarks. Facts cut through ego faster than debates ever can.
- Pick your battles. Not every hill is worth dying on. Sometimes, you let small things slide so you can focus your energy on the big risks, the parts that really matter.
Why It’s Worth the Effort
Helping ourselves and others see blind spots isn’t just about avoiding bugs. It makes the whole team stronger. The codebase gets cleaner. People grow more comfortable admitting, "I don’t know." And that small shift changes everything.
I’ve seen engineers move from "I already know it all" to "I can’t wait to learn more." That’s when a team really starts to thrive.
At the end of the day, we’re all still climbing the curve of learning. The best engineers I’ve met aren’t the ones who know the most, they’re the ones who stay curious, humble, and open to growth.