I have a simple question:
What makes code good? I’ve recently been struggling to answer this. Is it how “clean” it looks in a text editor, what it accomplishes, or something else entirely?
To me, the accepted answer feels like a heavily guarded secret.
Coding has long been a skill only available to a privileged few, but there are more options now, than ever before, to learn to code. Companies even proclaim “anyone can learn to code,” which is great.
However, even when one knows how to code, one’s output must often pass a subjective quality check with a common result: this code is not “good code.” Which makes me wonder: is solving an important problem with messy code worse than not solving it at all?
A software engineer with over 20 years of experience once told me and a group of new-ish coders to keep bad code to oneself and to not push it live for others to use.
I understand the thought, as there are, in fact, serious implications involving security and protecting users data when making applications, but focusing on concepts like DRYness and other efforts that arbitrarily make code “good” is unwanted gatekeeping.
I know many brilliant programmers who don’t write what is seen as the “best” code, but you know what? It works. Their software changes lives and isn’t even all that DRY. They don’t even write tests!
Yes, writing code a performant, maintainable fashion is needed when a project grows larger, but this perfectionist mindset prevents less experienced coders from even attempting to make great things that solve big problems.
The reason I and many others code is to improve the lives others, so isn’t it harmful to prioritize the perceived quality of code over its impact?
Perhaps the difference one’s code can make, not it’s DRYness, should be the guiding metric that makes code good.
