There is such a principle of KISS (keep it simple). I once touched on this topic at a speech, but it hasn’t been here yet. In my opinion, this is a fundamental principle that someone underestimates, someone does not understand. I will propose this formulation:

The goal is simplicity. Why? It is easy (cheap and fast) to change, and therefore maintain. If we have a product, and not a one-time development, then support is important.

Simplicity at the first stage is achieved through primitivism (actually, the KISS slogan).

At the same time, starting from some scale, primitivism leads to complexity. Then, in order for the code to remain simple, it needs to be complicated (DRY, design patterns, etc. are already being recalled).

It is extremely important to be able to catch this moment in order not to do both types of technical debt: too much code due to primitivism and too complex code due to anti-primitivism.

In general, it is difficult to write simple code. This is a craft: you need a proven skill to immediately understand where to apply what technique and where to lay down what.

This is very clearly seen by the students: they still somehow manage to make the code work, but very rarely simple.

Many novice programmers reduce the quality of the code due to the fact that they simply do not keep up with other programmers. They still don’t have the skill to do well the first time, and they don’t have time to refactor with reflections.

As a result, the simplicity of the code is primarily clarity. And it’s difficult.

By the way, this also applies to the higher level: the application and changing requirements over time: with increasing quality requirements, the technical leader (architect, if there is a dedicated role) must gradually “tighten the screws” in the same way: introduce more and more practices that improve the quality of the code. If you do not do this, then at some point an active conflict between business and programmers will begin: business requires quality and does not significantly reduce speed, and programmers say that they have 0 test coverage and it is impossible to increase the quality of supplies without noticeable costs.