The Complexity Curve: we all go through it

Through the years, I’ve noticed a correlation between experience and the complexity of the software we produce.
There are three phases. In the beginning you don’t know much, so you create simple things: you simply don’t know how to do complex things. The second phase is when you learn techniques that allow you to tackle complex problems (patterns, patterns everywhere!). In the second phase you use every trick you know, because you can. The final phase is that you know when not to use advanced and complex techniques because the cure would be worse than the problem.

The result is a curve like the one shown on the right: the complexity of software goes up with experience, and then down again. Another illustration of this idea is here: Hello World Joke.
Although this is not exactly rocket science, it is a nice little model that explains what it means to be pragmatic. The difference between the second and third phase is the ability to apply knowledge within a context. For example: in the second phase you have learned about the Abstract Factory pattern, and apply it all the time because Hiding Knowledge Of Creational Logic Is Good. In the third phase you recognize the cases where a full-blown Abstract Factory is overkill, and a simple factory method with an if..else if… statement is perfectly acceptable, or where you can simply create an instance directly with a concrete contructor.
I’ve noticed that in some company cultures complexity is revered. I once worked with a company that specialized in UML modeling for banking where the peer ranking among designers was the complexity of the models they could produce. The effect was that they made overly complex models that they could hardly understand themselves. Their company culture kept everyone in the second phase, tight on the top of the complexity curve.
There is a very interesting model called the Dreyfus Model that has parallels to this idea. It deals with the differences between five stages of learning, from beginner to expert. The Pragmatic Programmers did a talk (and a blog posting) about it on No Fluff Just Stuff, Dave was interviewed in an Agile Toolkit Podcast about it. There is a summary pdf on the model.
Being an expert does not mean just know how, it also means knowing when not to.