Five Phases of Developer Maturity

I generally don't post stuff like this but…what the hell…

Are you a good developer? A great developer? A World Class developer? Perhaps you only think you are a good developer. Maybe you are a terrible developer and don't even know it. The only way to know for sure is to get feedback from other developers and the users of your software.

I believe developers go through several learning phases on their way to becoming World Class developers. There are no short cuts…the dues must be paid. Here are five phases I have observed…as they relate to the code produced:

Phase I: It Works. The first time you get a program to work is immensely rewarding: You have mastered the computer. It was tough…but patience and persistence paid off. Not everyone can do what you just did. Not everyone can make a program work. You are special. You have experienced the magic of bending a machine to your will.

However, sometimes your program crashes. Sometimes it gives unexpected results. How were you to know those pesky users would type in letters when digits were expected? Sadly, some developers never get beyond this phase. Some begin to see themselves as 'creative visionaries': their code is 'proof of concept' and wasn't designed for actual use (so they say). Implementation details are left to others. Often these people are arrogant and fool managers into believing they are gifted. It is a sad programming shop where this occurs.

Phase II: It Works Good. At this phase, the developer has learned to really test the code. They test every input and account for every output. They check the return value of every function. They installed exception handlers and deal with the exceptions raised in testing. The program is now bullet-proof, tsunami-proof and even pointy-haired manager proof. It took extra work but now it is rock solid. No more embarrassing crashes.

But there is a slight problem; the code is a pile of convoluted spaghetti with deeply nested if-else clauses and case statements. It's disgusting to look at and it's embarrassing to admit you can't maintain your own code. When someone asks for a new feature, you take a sick day and update your resume.

Phase III: It is Good. The code works well and it's solid. But, you rewrite it anyway—sometimes several times. You re-organize it so it is clear to read and easy to understand. The code is logically separated into functions, classes and modules. There are concise helpful comments in the code. An intern may view the code and sneer, "What's the big deal, that's simple, I could have written that". No, he couldn't. He has no idea what it took to get the code to that state. Simplifying complexity is an art that cannot be taught.

Phase IV: It has Added Value. While working on the code, you created several functions and classes that can be reused in other projects. It takes more work to make a module reusable...three times as much work is the general consensus. The reusable modules help other projects get a head start. Other developers trust you and, more importantly, they trust your code. You recognize when to consider 'outside' code and understand the risk/reward of doing so. Leveraging the work of skilled developers is not a short cut, it's smart.

Phase V: It is Delivered Early. After mastering code, design and system architecture, there is only one frontier left to keep the job interesting…beat the schedule. Statistically, 30 to 50 percent of software projects fail. Even more are late. When you can deliver on-time solid code that is easy to maintain, you are gold. Caveat: Schedules are calculated guesses. You can plan all you want but as Mike Tyson succinctly put it: "Everyone has a plan, until they get hit."

So, there it is—my two ¢ents.

Steve Wellens

Note to Professional Editors: I'm aware the text vacillates between second and third person form…but it seemed to work that way so I broke the rules.


  • Delivering systems early is not a sign of a good developer but a sign of bad estimates.

  • "Delivering systems early is not a sign of a good developer but a sign of bad estimates."

    I've never understood how you can estimate a completion date without knowing the developer(s) who will be working on the project.

  • I always try to review old projects and see how long it took and base new project time lines off that... but as you said, it's hard to guess.

    So I just work out a rough estimate.. and multiply by 2. :)

    Seems to work okay.... for now.

  • Watch our for Wellens. He can stick his approach shots to 6 feet(less some days) on a regular basis.

  • Regular basis? I must point out that one out of 500 shots is a "regular basis".

    FYI: Confused? This is off-topic golf talk.

  • Wonderful article..!

  • From a business point of view I'd add another Phase called "It is well protected". Organizations pay a lot of money for good code, and often the software is THE critical element that differentiates the final product from competitive choices. Making it extremely difficult for someone to analyze or copy can provide a barrier to entry. Especially if the product is a niche product most likely to be copied by a small organization with limited resources.

  • Really interesting article, It reminded me those days when I have to spend hours in writing simple code. Life is never easier :D now people expect me to deliver in less time and more quality

Comments have been disabled for this content.