This is very much a re-interpretation of a post by Thorsten Ball, written back in 2015. Like him, I too came to the same realization, years after I first stared programming:
Anyone could write it and anyone reading it should be able to understand it. It shouldn’t make the reader think about the code itself, but about the problem at hand. It shouldn’t be long, it shouldn’t be complex and, most importantly, it shouldn’t try to be clever. It should get the job done and nothing more.
Programmers, like most other creative individuals, suffer from the weight of their egos. One sees code as a form of self-expression, a way to explain the Universe through their own thoughts. The more expressive a programming language, the deeper the rabbit hole of individual ego-pleasing.
Developing software is about solving a problem. Whether it is as simple as calculating the sum of two numbers, or as complex as running the operations of an entire factory, it doesn’t matter. In an ideal world, code should concern itself with solving the problem at hand and nothing else.
In reality, lots of the code out there exists to support the design choices of the person who wrote it. It solves the underlying problem, but through a series of mental hoops known only to the person who wrote it. For small, short-lived projects written by one person this is perfectly fine. For most other projects, chances are that either more people will get involved in solving then same thing, or that the single developers’s design choices might change over time. Either case will sooner or later cause a clash.
Thus the advice from Thorsten. Write code that solves the problem and does little else. Don’t jump straight for the shortest solution. Take the one that your future self, having done no code for five or ten years, will be able to look back at and understand.