The Four Phases of the 20% Programmer

There's been a bit of meme about the 80%/20% rule around programmers.  I actually firmly believe that this phenomenon exists, and I'm lucky enough to work in an organization which consists of 20%'ers. 

With the opportunity to work with people closely for a long period of time, you begin to notice patterns, and if you take the time to think about them, they help you realize some things about yourself.  One thing I've noticed is that there's a pattern that is common among the  20%'ers as they grow and develop as programmers.

Now, none of this is a bad thing.  What we should all realize, despite the fact that at some of these phases the outcomes appear negative, is that I'm talking about extremely good programmers to begin with.  The negative outcomes I describe are relative, and each are extremely great learning experiences that each great programmer goes through on their path to software development Zen.

Phase 1 - "Are You Sure I Should Check This In?"

This is your first day on the job, where you first see this mountain of code, and folks are throwing around acronyms and technologies that you've never heard of.  Source control?  Unit Testing?  Continuous Integration?  Coding Standards?  These things are unheard of in undergrad or even grad school in most cases, so you're likely dealing with this all for the first time.  However, you can probably whip up a quick sort in no time.

So, you get your first production ready task, probably fixing some low-touch bug, and you pour over the changes for hours.  Something that normally takes a couple minutes may take you a couple hours because you pseudocoded the two line change, and then mentally executed the fix, over and over, and over.

Then it comes time to commit the change, in which you update your source, recompile, check your change again, then finally commit and stare at the continuous build until it completes.  Crossing your fingers that you're not going to be the target of non-stop "You broke the build newbee" ridicule.

Ultimately this is a good phase to be in, sans the fact that it took you three hours to correct a spelling error on a web page.

Phase 2 - Danger is My Middle Name

Otherwise known as cowboy programming, this is where a great programmer does the most damage.  By now you've figured everything out.  You're familiar with the code base, the technology and the processes.  On top of that, you've gotten pretty efficient at finding your the bugs and fixing them.  You've probably got some ownership of a piece of functionality, something you've developed from the ground up, so you know it inside and out.

This is where you get dangerous, and start feeling invincible.  You get the attitude that your code is bug free, impenetrable to any security threats, and deployment will be a breeze.  Additionally, you're willing to get started right away on some functionality that hasn't been thought through or communicated completely, but that's ok, you're just so excited at how efficient of a programmer you've become, you can't wait to hear the business analyst say "You're done already?"

This is also the phase at which you see the most pattern abuse.  At this stage you're just learning patterns, and everything starts to look like a visitor, an observer or a decorator.

Likely what happens at this phase is that your code causes many bugs, your client's security audit identifies a dozen XSS vulnerabilities, and you end up being responsible for an additional QA build because you forgot to include all your resource files in source control.

This is always where most folks start to learn to estimate, but often do their worst estimating.  The cowboy attitude applies to estimating here too, and and you're so quick to deliver a number, that your estimates can be off by 300%.

We've all gone through a cowboy programming phase, where our world is about clearing our plate as quickly as possible, and not about making sure what we've done is done well.  And once you do make these mistakes, you never, ever want to make them again, and that leads to the next phase, which is at the other end of the spectrum.

Phase 3- Hell Hath No Fury Like a Programmer Scorned

Once you've been burned one too many times by cowboy programming, you come almost full circle back to phase 1, where you triple check your work, hesitate to take on anything too risky, and heavily pad your estimates to account for any issues.

Usually when you're at this phase you go overboard.  You start saying no to requests, without real good reason, other than the fact that you want to insulate yourself from any risk.  If the request comes through anyway, you try to over-estimate your way out of the request, figuring that if it costs too much, then the person requesting it will nix it and save you the risk.

You might also find yourself being a rigid stickler to waterfall processes, requiring final documentation before estimating or writing a drop of code, ensuring that you've got every last nook and cranny identified prior to providing an estimate that you'll be accountable for.

Ultimately I feel that this behavior is the result of the fact that you still don't know exactly everything that is involved in delivering software yet, and that uncertainty causes you to insulate everything from risk blindly.

Phase 4 - "Neal Naysayer, meet Peter Pragmatist"

This is the phase that the 20%'er comes into their prime.  The balance between the cowboy programmer and the super-conservative engineer is struck and you start to settle into your stride.  You can deliver quality solutions in an efficient manner.  You've mastered how to use source control, become proficient at refactoring, and you begin to pay attention to the continous build again.

At this phase you've honed in on exactly what steps are needed to deliver high quality work on time.  You know what's involved with the tasks that you need to complete.  You've thought of everything, broken it down logically, thought about the impact, planned for interruptions, and refactoring.

Instead of immediately saying "No" to the business analyst, you start providing pragmatic options that balance functionality and the limited resources of the project.  You understand the information you need to collect to glean then things that have an impact on a projects or tasks success.

Ultimately this is where you want to be as a programmer.  It's certainly where I want to be.  It's hard not to revisit the other phases from time to time though, especially phase 2 and 3.  You feel pressures from different directions, and it's hard to keep your head about it.

The master programmers aren't phased by these pressures, and have faith in the fact that their pragmatic approach to things will serve them best in all situations.  That is where I want to be.

Have you noticed any patterns of your own?  Are there phases that I'm missing here?  Am I generalizing too much?  Does this apply to everyone, and not just the 20%'ers?

I'd love your feeback.