The life of a developer goes through several phases, generally over-engineering is one of them, then generally comes clever, many times developers never get pas

The life of a developer goes through several phases, generally over-engineering is one of them, then generally comes clever, many times developers never get past clever and start to confuse it with elegance, but clever code is not by itself elegant, the mark of elegance is simplicity, when code is simple it becomes elegant, when it is simple and clever it is elegant. But if you have to choose between one or the other choose simplicity. Code that even a novice can see the beauty in the simplicity of it (and understand it) is where true elegance lies. It takes a true craftsman to take something complex and make it simple. That it what we do every day, we take complex processes and simplify them via automation and association. When one realizes the same principle applies to the development of their code, they then start down the path of writing truly elegant code. Simple code is decoupled, simple code does not have tight dependencies, simple code is well organized and simple code does not rely on too much abstraction. If you strive to achieve those few things you will be a better developer than a significant portion of your peers. decoupling code allows you the ability to extend the system without having to go back and modify existing code. Avoiding as many tight dependencies as possible allows you to change portions of the code base without having the ramifications of those changes leak out into other areas. Well organized code allows new developers to find what they are looking for, it helps document itself. Part of good organization is adhering to standards and best practices. Relying too much on abstraction means that you can't see a complete picture of the code without understanding multiple layers. Abstraction, when used properly, allows you to reuse code which is a good thing, but it comes at a cost, it sacrifices conceptualization. Too much abstraction and the system or a portion of it cannot be easily conceptualized in the mind. It also creates tight dependency among components that sit on top of abstracted layers. It should not be avoided, but no problem can be abstracted away, if the code in question cannot be reused there is no reason to abstract it, rather componentize it into discreet blocks, so that it can be conceptualized as a black box.