The more I learn about software development, the more I notice the things I don’t know. Each tactic I pick up or lesson I learn just leads to more questions. It’s like lighting a candle in the dark and realizing that you’re in a room full of doors. Then, as you open each door and turn on the light, you find more rooms to explore. When I started out, I was so sure of myself. Each problem had the “one right way” solution. Now, when I see a problem, I see several imperfect solutions, each with their own trade offs.
This seems like a common problem.
John Sonmez feels the same way:
Simple Programmer: The More I Know, the Less I Know
So does Scott Hanselman:
I’m a Phony. Are You?
They aren’t the only ones either.
Psychologists call this the Dunning–Kruger Effect.
The Dunning-Kruger Effect is when unskilled people overestimate their abilities and skilled people underestimate their abilities. As you become better at something, you realize how little you know. It’s like getting to the top of the mountain only to find that you are at the bottom of a way bigger mountain. It sucks.
This concept has huge implications in software development. Software development is a complex field filled with people who have strong opinions. This creates situations where confident, unskilled people have an advantage when determining technical direction. This can lead to poor choices and technical debt. It’s easy to trust someone who’s confident over someone who isn’t sure of the right answer. Even when not being sure of there is a right answer is the right answer. (This explains most of politics, but I digress…)
What can we do to counter this effect during technical discussions?
If you’re unsure of yourself, don’t be afraid to present the facts and make your case anyway. It’s better to be wrong than to allow bad ideas into your project. You probably know more than you think.
If you’re confident of a particular solution, look for alternative view points. Let the other side make their case. Realize that the person who has a few years of experience on you may know something you don’t. Even if they have trouble articulating that knowledge, it’s your responsibility to listen. You may learn something.
If you’re a manager trying to decide between two viewpoints, don’t let the louder person automatically win. It’s easy to side with people who are confident or articulate, but it’s important to hear out both sides.
What about when you’re just feeling unskilled?
For me, the best way to feel competent is to write code. The code doesn’t care how smart you feel that day. If it works, you win. For me, adding value makes me feel competent. If I can pull off some complex functionality or learn something new, I feel like I know what I’m doing.