As a younger programmer, the complexity of a solution appeared to be a measure of the skill of the developer. The more complex, sophisticated, or enigmatic the solution, I reasoned, the more clever, skilled, and impressive the architect.
I learned the truth the hard way. Because when the time came to hand-off, enhance, debug, or even just re-understand a complex system a few months later... I found myself struggling against the complexity. It was too hard to load up an understanding of everything into my brain to form a mental model for moving forward.
Eventually I realized that the role of a good developer was not to develop complex solutions, but rather to develop simple solutions. In fact, the more simple the solution, the better.
Simple solutions have a lot of virtues. First, they are cheaper (easier) to explain, change, fix, and grok. Second, they tend to only do what is necessary, and nothing more. This helps reduce unintended consequences like regressions and bugs in the new functionality.
But the best thing about simple solutions is that they leave capacity for the system to do more. I'm not talking so much about technology resources as I am about cognitive capacity. If your system is constructed from a series of simple, minimally coupled subsystems, you can comprehend discrete chunks at a time, understand the operation of the whole thing working together, and dream up new capabilities with more ease and confidence.
A good developer is one who isn't happy until he's satisfied that he's found the simplest possible way to solve the problem he's been given. A good developer reduces complexity.