I'm starting to look at it from a different perspective. I don't necessarily think bad is actually bad, or a better way to put it, there's no such thing as "good" code. What I usually find people calling bad code is just not easily understandable. We as programmers started programming with really comfortable abstractions for easy problems and we expected things to continue like that.
When we go into the world of unsolved problems that someone solved and we have to maintain them, and we can't understand them immediately, we call them bad. It's my gut reaction almost every time I'm confronted with something that doesn't immediately enlighten me, even thought I know it's the wrong reaction.
We are always comparing everything to the simplest and most solved problems that were easy for us to understand. When it isn't so easy we call them "bad".
Well, there's that, and there's also "bad code" as in "bad engineering", in the real-world sense of engineering. If someone build a bridge quick and dirty and it works for the task at hand, which is crossing some ravine/river, we could all just say "well, it got the job done, so it was good." But when it collapsing due to entirely foreseeable circumstances, and not necessarily because a lot more resources needed to be spent, but possibly just because someone didn't know or didn't care to take the time to figure out the common failure cases, then that's bad engineering.
That happens in code all the time. People do things in ways that are prone to problems because either they don't have the experience to know better, or they didn't take the time to think about the domain. I would call that "bad code", no matter how pretty it looks or understandable it is.
Part of the problem is that "good" and "bad" are far too vague, so everyone will bring their own meaning. You might see people using "bad" to mean unclear, but I would count that as a sign of progress. A imagine a "bad" mechanical in this day and age engineer is someone that does stuff that costs more money, either now or later when it breaks early, but still produces mostly safe constructs because that portion of the job is highly constrained, and when they fail there, they often aren't just "bad", but may be criminally negligent if they failed to adhere to both the law and industry best practices.
If were getting to the stage that "bad" programmers are just ones that write unclear code, that's a huge step up. Unfortunately, I don't think we are there.
> When we go into the world of unsolved problems that someone solved and we have to maintain them
I don't believe in this world of unsolved problems. Most codebases reinvent the wheel like they've never seen one. Most "problems" are just a problem of picking one from known solutions and gluing it all together. People don't always pick the right solution, or they start gluing at the wrong place and won't stop once they realize it, so the end result is a mess. And then you can ask, why did they do it like this? This is not good!
If you're a programmer, you've hopefully tried to rewrite some bit of code of yours a few times until you've arrived at something that eliminates redundant logic, is more readable and less buggy than the previous versions.. don't tell me they're all just equally bad?
I have written all sorts of implementations for things that I'm positive there's a library or existing example out there that is just plain better and more thorough.
The problem is, I don't know what it is. I don't know where it is. And finding it will take time, take effort to evaluate the non-good implementations, and take effort to integrate with other systems.
Whereas I can write code now which is "good enough" (or worse, just not good at all but exists and does something right now) and then move on and hope I'll find the "better" I'm looking for later.
One definition of bad code is code that isn't even consistent with itself. I.e. you just tack stuff on when you know you really should go back and refactor some interface, but it's too much work so you just do the minimum you need to get some feature working, but the new stuff follows subtly different semantics, and you have to keep it all straight in your head. And then someone adds another layer on top of that, that's almost but not quite compatible with the other parts, and so on...
When we go into the world of unsolved problems that someone solved and we have to maintain them, and we can't understand them immediately, we call them bad. It's my gut reaction almost every time I'm confronted with something that doesn't immediately enlighten me, even thought I know it's the wrong reaction.
We are always comparing everything to the simplest and most solved problems that were easy for us to understand. When it isn't so easy we call them "bad".