As a self-taught developer and as a manager who has watched the growth of many young developers, I have seen a pattern in the learning cycle of developers.  It usually goes like this:

1.  Make it work

The young developer is ecstatic to just have code that is working properly. They probably have poorly named methods and variables, commented-out code strewn everywhere, and overly long methods.

2. I love this object-oriented stuff!

The developer discovers interfaces and classes and becomes “class happy”.  They think that if you build a class you should build an interface because “at some point we’ll need multiple classes here, right?”.   They create classes out the smallest data constructs into classes and prefer enumerations over basic data types.

3. We could re-use this code if….

Abstracting all code seems like a great idea. Duplicate code is evil.  In fact duplicate logic is evil.  The coder believes abstracting functionality will lead to great efficiency in the future.  May become obsessed with writing code that writes code to write code.  Avg. method length is ridiculously low.

4. Did I write this?

After a while of maintaining the overly complicated code he has written in the past, the developer begins to see the downside of added code complexity and starts the journey back to simplicity.

5. Master of the tradeoff

Realizes that the search for perfection in coding was a fallacy.  Each project or scenario needs to be evaluated based on it’s parameters only. There is often more than one right answer and evaluating the tradeoffs between options becomes second nature.  The coder becomes a maximizer of his time vs. code functionality/benefit.

The idea for this post was sparked by an excellent article about fighting code complexity:

http://codebetter.com/blogs/patricksmacchia/archive/2009/06/28/fighting-fabricated-complexity.aspx