Beat The Dunning Krueger Effect To Propel Yourself As A Developer

Throughout my career as a developer, I’ve exhibited varying degrees of hubris — the good bulk of it at the beginning of my journey. I was the cocky junior dev, filled with over-confidence, and somewhat overly zealous advocation of things I thought I understood.

It happens to all of us — especially in our early days when we think we know it all. In reality, it is just the Dunning Krueger effect doing its glorious cycle on our egos and readjusting us towards reality. This is because when we start out as developers, we’re like children — full of fantasies, hopes, dreams, and potential. Then somewhere between the initial spark and growing up, we realize that we’re not as on top of the world as we think we are.

We look back at our old code and cringe at our clunkiness, nested loops, and sloppy logic. We look forward and realize that in our current state, we are mostly incompetent and unable to do anything much except pick up the next set of tools, technology stacks, and whatever else is needed just to make something work. We become beginners — over and over again.

While we can’t escape the Dunning Krueger effect, we can at least soften its impact on our mental health.So how can we beat the Dunning Krueger effect and propel ourselves as developers? First, we need to understand how the Dunning Krueger effect works.

How the Dunning Krueger effect works

The Dunning Krueger effect is a form of cognitive bias where people overestimate their ability to do a particular task. It’s when the unskilled gain an illusion of superiority, leading to overconfidence in their ability to execute the task.

As time progresses and the person gains more knowledge, they begin to see that there is more than what they think they know. The Dunning Krueger effect is represented as a downward curve, with the person starting at the top and quickly descending to the bottom of the confidence level as more knowledge and skills are obtained. Then there is the hard slogging climb back up the confidence curve over time as mastery is obtained.

In a way, experiencing the Dunning Krueger effect is like experiencing a node tree structure unfurling in real life. One bug or feature request can easily lead you down a rabbit hole. Your confidence only truly starts to pick up once you’ve dived into enough rabbit holes and realize that they’re all interconnected.

It’s all one big jigsaw puzzle

When it comes to code, nothing is ever clear-cut. Nothing truly exists in isolation. It’s a cacophony of skills and knowledge points melted together to materialize a particular idea.

Because that’s what code is — ideas materialized, organized, and systemized.

Most new developers don’t tend to think about code in this manner. It’s all loops, switch statements, and getting that app up into the cloud. This process can lead to feelings of being overwhelmed, which leads to the downward decline on the Dunning Krueger graph. The more knowledge gaps you have, the quicker the decline.

But it doesn’t have to be this way. From what I’ve learned, many of us descend downhill because we don’t have a game plan. We go in blind, thinking that we can just Google it. There’s nothing wrong with Googling — but no amount of Googling is going to help if you don’t know what you’re searching for.

First, you need to figure out what you don’t know.

How to figure out what you don’t know

While we can argue that you can’t know something that you don’t know, most developers aren’t going in that blind. The trick is to start with the idea and then work backward.

For example, you want to make an app. You know one of the main features is a login/logout/signup form. It’s a standard feature — but you’ve never made one before. However, you know how it works.

There is a form. You type something into the fields and send it off to be verified. If it passes the authentication tests, you’re allowed into the private area of the site. There’s no code involved in this — just you working out what different parts you need to achieve your desired outcome.

This initial plan is your scaffold — the thing that you should go back to as your true north star map once you’ve started digging into the technicalities of the implementation. It’s easy to lose your way once you start digging. You get sidetracked by other thoughts like how are you going to secure parts of your site from non-members? Or different types of authentication systems and security protocols. There’s nothing wrong with them either, but they’re the things that are going to contribute to the feelings of being overwhelmed.

Final thoughts: Start with an idea

Everything is just an idea until it gets coded. The process of creating software is mostly figuring out what the app looks like, its core functionalities and how to structure it. The actual code is only a fraction of it.

To prevent that beat-down feeling of incompetence that we feel when we hit the bottom of the Dunning Krueger curve, we need to follow through with the process of figuring out what we want.

When we’ve got a plan, we at least have a road map that lets us discover more roads the further we travel on our journeys as developers. Rather than worrying about the technology and what you need to know to get it working, figure out what you actually need first. It also decouples your personal gauge of what you think you know from what you actually need.

The issue with going in head-first into the technology is that we don’t have context. You can’t build an application if you don’t know what that app is supposed to be. It’s like someone telling you to start coding and then giving you the details of what they want three months later. You’re just going to waste your time.

So start with the idea, flesh it out, decide on what you want, and then start filling in the gaps to materialize the final picture. Keep doing this process and at some point, you’ll find yourself looking back at all the skills and knowledge you’ve picked up along the way.