Our profession loves to wrap itself in objectivity so this doesn't get talked about much, but a big thing that I think separates bad programmers from mediocre ones, mediocre ones from good ones, and good ones from great ones is basically their "taste" in code (and then their relationship with that taste).
Bad programmers just don't really have a sense of taste, ime, they just settle on whatever approach gets the code working first, usually because they don't have enough experience to have developed any unconscious coding style yet (pretty much anybody can be at least a mediocre programmer with practice).
Mediocre programmers have their own preferences/taste, but it's not good taste because it's sort of just an outgrowth of the bad programmers' "whichever approach got it working first": their preferences are just for whatever particular style choices they were taught, and aren't really their own yet. Usually this means their taste is pretty inflexible and just carries norms from one particular context into every other context, e.g. think "Java written in Python". Also, these programmers usually think that their preferences are actually just objective, correct rules of design because they haven't yet had the experience to see why different contexts have different styles.
Good programmers have good taste in code, and also realize that this is taste. They're the most likely to leave lots of code review comments along the lines of "IMO it's cleaner to do X instead of Y, but it's up to you so feel free to just mark this resolved if you disagree :)", I think, because they'll notice lots of decisions they don't agree with in bad & mediocre programmers' code but see it as mostly aesthetic preference and don't think it's reasonable to demand everyone adhere to their personal taste.
Great programmers have basically the same taste as good ones, but understand it more as a tool because with enough experience your intuitive preferences aren't just things you've accumulated randomly, a lot of them are probably informed preferences. Programming isn't that hard, but programming well is very hard, so being able to lean on intuition is a big plus. The key, I think, is to treat your taste as a way to flag potential problems. You don't immediately reject a piece of code because it seems "ugly", but you also don't immediately dismiss the feeling as aesthetic preference. Instead you stop and ask yourself why it's ugly, and spend some time figuring that out if need be. If after some thought it really does just seem to be an aesthetic judgment you move on, and if it turns out your intuition had picked up on something you write a review comment explaining what should be changed and why (or just change it if it's your own code, obviously). Telling the difference is a skill & it takes a lot of practice using that skill to develop it, which I think is probably why most good programmers never make the jump to great programmers.
