Bad code, good developers and the Imposter Syndrome trap

Bad code doesn’t just make software worse - it makes developers feel worse. It creates confusion, slows progress and fuels that nagging doubt that maybe, just maybe, we’re not as good as we thought. Imposter Syndrome thrives in messy, unclear and inconsistent codebases. And yet, we often blame ourselves instead of the real culprit: poor coding practices.

So let’s break it down. How does bad code mess with our heads, and what can we do about it?

The “Is It Just Me?” Effect

You open a file. It looks like an ancient relic from a forgotten civilisation. Variables are named data1 and thing, functions are a hundred lines long and logic jumps around like a caffeine-fuelled squirrel. You squint, re-read and wonder: “Will I ever understand this?”

Reality check: It’s not you. It’s the code. Poor naming conventions, lack of structure and overcomplicated logic make even great developers feel lost. But here’s the kicker: because nobody likes admitting they don’t understand something, we internalise the struggle instead of recognising the root cause. But as Boustani says, admitting to someone else that we don’t know something can lead to higher success and more confidence.

The code fix? Make clarity the standard. Well-named variable, consistent formatting and refactoring aren’t just for clean code - they’re for clear thinking.

Debugging: Skill v Survival

A well-written codebase is like a well-organised kitchen. You can find what you need, everything has a place and making a meal (or a feature) is straightforward. But when a project becomes an inconsistent mess, debugging feels less like troubleshooting and more like searching for a missing puzzle piece in a pile of nearly identical puzzle pieces.

Ever spent hours tracing a bug, only to realise it was due to a silent side effect buried in a 1500-line class? It’s not because you’re bad at debugging. It’s because the code made it unnecessarily hard. And the worst part? That feeling of, “I should have caught this sooner”.

Great developers don’t just fix bugs- they prevent future ones by simplifying complexity. Small, focused functions. Explanatory tests. Thoughtful architecture. Meaningful (and limited) comments. They aren’t just coding best practices… they’re sanity savers! Even if it means failing fast.

Code Reviews: Collaboration or Confidence Crusher?

Bad code doesn’t just impact the person writing it- it affects the whole team. Ever reviewed a PR and struggled to give constructive feedback because the code is just that chaotic? Or worse, ever had your own work picked apart because someone else couldn’t untangle what you inherited?

Code reviews should be about learning, not just finding mistakes. A good review culture treats unclear code as a team problem, not an individual failure. When feedback is framed around, “How can we make this easier to read?”, rather than, “Why did you write it this way?”, Imposter Syndrome takes a hit instead of developers' confidence.

The Myth of the 10x Engineer (and Why They Write Bad Code Too)

Somewhere out there, a so-called “10x engineer” is shipping unreadable, undocumented, but technically functional code at breakneck speed. And somewhere else, another engineer is quietly cleaning it up so the rest of the team can actually work with it. Guess which one feels more competent?

Velocity isn’t everything. Great engineers prioritise maintainability over quick hacks. The best developers aren’t the ones who write the most code- they’re the ones who write code that helps everyone move faster.

AI might promise to speed things up, but it still needs careful review, understanding and application. With the pressure to move faster, engineers might be tempted to trade quality for quantity or blindly trust AI-generated solutions. The risk? Losing valuable knowledge and craftsmanship in the assumption that AI always has the right answer. The best engineers will be the ones who use AI as a tool, not a crutch.

Related Insight

Engineering best practices

Build better software by understanding the disciplines, practices and principles that underpin great code.

So What’s the Fix?

1. Call out bad code for what it is - if it’s unreadable, unstructured or inconsistent, it’s not your failing (unless you wrote it!) Recognising bad patterns is a skill, not a weakness.

2. Refactor without fear - if something confuses you today, it’ll confuse someone else tomorrow. Improve it. Future you (and your team) will be grateful.

3. Make code reviews safe - foster a culture where feedback is about improvement together, not criticism in isolation.

4. Measure success differently - instead of celebrating speed, celebrate clarity. The best code is the kind you don’t have to think about.

If you’ve ever felt like you’re struggling because you don’t “get” the code in front of you, take a step back. You might not be the problem. Bad code can create doubt, but good coding practices create confidence. Let’s build teams- and codebases -that do the latter.