Blog > The pros on working on bad code

It is good to ask whether or not solving the problem brings significant benefits to the application

II'm writing this article after yet another deep dive into a codebase so poorly written that, even with three people on it, we still haven’t found a solution—after an entire day.

The problem itself could be considered simple. But the way it has been implemented is unexpectedly tangled and convoluted. We jump from file to file, trying to understand how the logic is interwoven, only to find ourselves stuck. It feels like a dead end—a maze of messy instructions and obscure algorithms. It’s easy to lose patience. And even easier to get frustrated.

Why does bad code exist in the first place?

Often, it’s due to tight deadlines that don’t allow for proper structure or planning. Other times, it’s because a junior developer was never properly mentored. And sometimes—let’s be honest—it’s because someone simply doesn’t care about their craft (in which case, they should probably change careers).

Still, when dealing with bad code, there are a few key principles I try to keep in mind.

Not all evil comes to harm

Isn’t it exactly because I love solving logical problems that I chose this job in the first place? Isn’t programming, at its core, a continuous exercise in problem solving?

From this perspective, working with messy, disorganized code is almost the purest expression of that challenge. It pushes creativity to the limit. Finding a solution to what initially seems unsolvable—even if it’s not elegant or clean—is still deeply satisfying.

If you enjoy solving logic puzzles while lying on the couch, why wouldn’t you also enjoy cracking the puzzle of poorly written code? The thrill is the same—only the stakes are higher.

No repetitive patterns

All in all, we can say that most day-to-day development relies on more or less standard patterns—ones we can recall and apply almost instinctively.

Poorly written code, on the other hand, often ignores any kind of standard or convention. And that’s precisely where our ability to forge new paths comes into play.

It’s a great mental workout—one that, in a way, we need every now and then.

Can be funny

Seriously, our skype call was luckily a lot of laughs, since the code literally did "weird things"

In practice, how do I handle it?

The first thing to do is, of course, to inform your colleagues and superiors about the current state of the program. Next, it’s important to assess whether solving the problem will bring significant benefits to the application—after all, addressing issues like this often consumes a considerable amount of time that could be spent elsewhere. If the benefits justify the effort, try to identify possible alternatives.

Then, it’s crucial to analyze the code as thoroughly as possible, being as clever and strategic as you can when running tests in the areas most likely to yield useful information about the issue.

Above all, you must absolutely avoid making the code even more confusing or unpredictable. If you’ll be the one maintaining the software in the future, you might find yourself facing even tougher challenges down the line. And if it’s your colleague who will take over, well—respect them ethically.