Most code is likely to remain just that: code. Impenetrable to secondary readers, because it was barely comprehensible to its original author. Hard to reason about because reason was a distant goal behind “making it work well enough to ship”. Convoluted because the natural entropy of systems is towards a ball of mud. –DHH, Writing Software is Hard
Coding seems to be mostly a collection of trade offs. There certainly is bad code, but it is hard to judge what is good code simply because you end up arguing over trade offs. Trade offs of clarity or speed or precision or etc. Does speed matter more than clarity? If a project has multiple developers across multiple continents, to what degree does clarity matter over speed?
As long as it is not bad code, is it good? I think there are degrees of good, but as judgement can be personal, it seems pointless to argue over.
Good software is uncommon because writing it is hard. In the abstract, we all know that it is hard. We talk incessantly about how it’s hard. And yet, we also collectively seem shocked — just shocked! — when the expectable happens and the software we’re exposed to or is working on turns out poor. – DHH, Writing Software is Hard
Is it poor? Or, when judging our own work, is it that we’ve changed our minds about things, place emphasis on things we had not before. This is the road to mastery, but i cannot think that sometimes it’s just trade offs we’re making. Like with all hard work, we shy away to work on things that are obvious to us. As long as we come back to solving the hard or difficult problems, then we should be OK with what we momentarily poor.
What’s dangerous is if you cannot see the bad in your code. This, to me, means you are not progressing. Or worse, you’re ignoring it, afraid to criticize yourself.
You are avoiding the painful work. The work that scares you. The work that will take you to the next level.
If you cannot criticize yourself, if you can’t be your harshest critic, you will never proceed.