Three Phases of Programmer Development

I was reading with some amusement Doug Boude's retort to a Java purist that was dismissing ColdFusion for being too... simple? to be considered a "real" language, and I was reminded of a topic I commonly rant on. It's what I call the Three Phases of Programmer Development.

Phase One

A novice programmer is happy to get anything to work. Eventually, the novice programmer becomes a journeyman programmer, and is able to not just get things to work, but to start to create some truly complicated programs.

Phase Two

Here, a journeyman programmer starts to develop their chops. They can take a complicated problem and build applications with a level of complexity equal to (or greater than) the problem at hand.

Phase Three

Programmers usually find Phase Three when they've been asked to go back and maintain some Phase Two code they wrote six months or two years ago... and all they can think was "WTF was I doing /here/?" "What's /this/, now?" "Geez, did /I/ write this? Wow."

The epiphany that leads a programmer to Phase Three is the realization that the hallmark of the professional programmer is not in the complexity of the code they produce, but rather in the simplicity. When you can take a complex problem, and solve it with simple code, you are a professional programmer. A lot of people that are die-hard ColdFusion fans are Phase Three programmers, who use it because it allows them to produce simpler, more maintainable code. And a lot of ColdFusion's detractors are Phase Two programmers, who think that anything /that/ simple must be for novices/children.

Note that frameworks of all types can often be categorized into Phase Two or Phase Three frameworks. The question to ask is, "in the long run, does this framework (or design pattern) make this application simpler, or more complex?" Or, "Will this framework make troubleshooting errors or performance problems nightmarish?" Or, "do I have to use this whole bloated framework for this problem, or can I just use a few of tastier bits to address this issue at hand?" If the use of a framework or design pattern makes the solution simpler, or at least more maintainable, great. If not, it may be good to evaluate whether you're using it for Phase Two or for Phase Three reasons. I suppose it bears mentioning that "resume-building" is never a valid reason for the use of a pattern or framework. That being said, having at least a passing familiarity with many patterns and frameworks is good, so that when you start designing something that does fit an existing solution well, you know to use it.

[n.b. I often recommend that people new to ColdFusion or Java (or any other language) read the description of *every* function or JDK library method. Not for the sake of memorization, but so when you run into a problem that's already solved, the voice in back of your head can say, "Hey, I think I saw something that does that..."]

Code complexity is like an infestation; it tends to spread to all areas that touch it. When you find code for a problem growing overly complex, STOP. Take a moment to understand where the complexity is coming from, and refactor it to something more simple; don't let complexity sprawl and infest the rest of the system. I tend to dislike ORM implementations, because they tend to reduce object cohesion and often require you to write more code in support of the ORM than writing simple loadFromDB(id)/loadFromResultSet() methods would require, and I've found performance (for other than basic CRUD applications) to be anywhere from unpredictable to abysmal. I know this makes me something of a heretic, and there are bound to be people that insist I was doing something wrong or "just don't GET it", but when I recently ripped Hibernate out of a Java application, the code size shrunk by about 30%, and the performance improved by an order of magnitude. (For the record, I was the one who put it in there in the first place, because I bought into the hype. Now I understand better what it's good for, and what it's less good for.)

It bears repeating: the hallmark of the professional programmer is not the complexity of the code they produce, but rather the simplicity. Whenever you see code getting complex, stop and ask yourself if there's a way to do it simpler/better.