Friday, June 2, 2006

The Curse of the Code-Writer

After having seen a lot of software engineers, inspected their code, fixed their bugs and otherwise worked closely with them... I've determined that there a several types of software engineers.  Now I'm sure a lot of you are going to bristle somewhat at the fact that I'm categorizing people.  Face, we're all categorized all the time.  If you've ever filled out a census form... you've been categorized.  So agree or disagree, that's fine.  However I also think most of you will probably relate to this very well and have observed very similar phenomena.  None of these categories are absolute.  Most software engineers posess some blend or mixture of all of them.

The Code-Writer

The first type of engineer is what I call the "Code-Writer."  This engineer is probably the most dangerous type to have on your team.  At first, you're excited by having this engineer.  I mean, this person cranks out mountains of code very quickly and it actually works.  So what's the catch?  Version one of your product ships, gets great reviews, there's a few rough edges, but, hey, it's version one.  So you now start working on version two.  This is where the "Code-Writers" begin to show their true colors.  You now ask them to add a new feature to their code.  Whoops!  The first thing they do is come back and say "I gotta rewrite the whole subsystem!"  Not just refactor it, or tweak the design a little bit, bit wholesale drop the bits on the floor sweep them into the trash and start fresh.

The problem is this.  This person is just a Code-Writer.  They can't look at a chunk of code and fully understand it in such a way that they can effectively maintain and enhance it.  Even for code they wrote themselves!  This type of engineer is especially prone to do this for code they didn't write themselves.  More times than not, it is far worse to rewrite code rather than refactor and redesign.  This means that more time is spent, unit-test have to be redone, and QA is not confident and has to do a full regression cycle on the entire product.

The Code-Reader

This next type of engineer I call the "Code-Reader."  This engineer is probably the most useless type of engineer for a software production team.  As the name implies, this engineer is really good at reading and understanding existing code, whether they've written it or not.  Mostly not, because as the name also implies they don't ever really write code.  Oh sure, they may actually type some code into the editor, compile it and even have it working... only on their machine!  So either way (never really write code or simply never check it in), this type of engineer is an albatross around any software team's neck.  For the ones that actually write code but never actually check it in, this is typically a confidence issue.  They are afraid to check in because they may break the build, or someone will not like their code, or there is some other fear that keeps them from actually submitting code.  The former, the one never even writes code, is probably a lost cause... the latter is probably salvagable if you have a psychologist on staff and can figure out why their parents hated them...  Bottom line, you eventually stop assigning critial tasks to this person which tends to feed more into their insecurrities.  It can quickly spiral.

The Code-Designer

This final type of engineer, the "Code-Designer," is a wiley bugger.  This person interviews very well, and is usually hired on in a more senior capacity.  He impresses the managers and even the other engineers on the team.  The thing is, this person is a great thinker... and that's it.  Ask them to actually write the code behind their killer application design and architecture... well you may as well ask them to compose a Concerto in Dminor... Oh, they actually write code.. check it in... and it even passes the unit-tests.  But when you look at the code, it is hideous!  Poor and inconsistent formatting of the code is the rule.  It looks like 20 different engineer's wrote the code with no eye for a consistent or team agreed-upon coding style.  CS101 algorithms are about all you get in terms of implemenation details.  And finally, the actual code only peripherally matches the design.  So, on paper, the design is great and gives great Powerpoint... but when the rubber meets the road.. it's flat.

The Blender

So there's the categories.  The Code-Writer, Code-Reader and Code-Designer.  The good news is that most engineers are a blend of all three.  I'd say that the most valuable and generally useful engineers are the "Code-Reader-Writers".  They are good solid mid- to high-level engineers.  They produce the bulk of the product's code.  Most Code-Reader-Writers also will have a good amount of Designer in them as well which means that they can solve problems in very clever and robust ways.  They also have some level of leadership skills and are good mentors.  You need your team to have more of these engineers than the next valuable blend. 

The Code-Reader-Writer-Designer is the next most useful blend.  As the name implies, this is a senior-level engineer that also provides a high-degree of technical leadership while maintaining a good down-to-earth understanding of the day-to-day bits and bytes.  They can usually jump in anywhere in the product and be helpful and productive.  It is good to have a few of these on the team with the number proportional to the team's size and age.

Some teams may actually have a Code-Designer, but most folks call them the analysts or the architect.  Many times they never actually work on the code but instead prefer to live their life in Powerpoint, UML, Visio, and email.  This actually works for a lot of very large software teams that have huge numbers of Code-Reader-Writers and/or Code-Writers.

So there you have it... my personal, totally biased, non-scientific, probably irrational categorization of software engineers.


  1. Sounds like someone has been maintaining some legacy code recently. :)

  2. In general, can relate. My opinion is that most people evolve through "categories" as they build their blend of skills. There are always the stubborn ones, though ;-).

  3. This is the most funny blog of the year!

  4. What about the pessimistic coder? This guy writes code, it's decent, he checks it in, but he never likes it. He is unsatisfied with his code, or anyone else's. And the blaming coder - the guy who always says "oh, so and so wrote that, the bug is in there code." Not that I know anyone like this. :)

  5. So Allen, which one are you?

  6. Yip I agree, but what about the Useless coder. The one that keeps on arguing that he can do it better in VB ?

  7. You forgot the fidget coder, the one who writes a perfectly good routine but then decides to prove his/her worth by turning everything into the most unreadable block of code ever to achieve functionality, and much like the code writer because its so fuddled it can never be fitted into a shape it has to be dropped and redone.

  8. I would divide developers up into Top-down, Bottom-up and All-rounders. Bottom-uppers produce the most robust code. Top-downers struggle to finish anything. All-rounders (like, well, I don't like to say - I'm too modest) are the best. They start at both ends and end up with two channel tunnels instead of one.

  9. Charles McAllisterJune 3, 2006 at 10:56 AM

    i like "joel on software"'s breakdown:

    there are two kinds of programmers:

    1. really really smart

    2. gets things done

    you want to find someone who is both 1 and 2.

  10. Allen,

    since you are in the management boat now. It will be much more interesting to hear some thoughts about managers. At leats you've started to categorize people ;-)

  11. Well sometimes the Code Designer finds delegates to implement their designs, and of course they take several times longer to impelemnent than planned, the harrassed engineers end up having to force fit everything into the Code Designer's favorite "Design Pattern" from his good ole days in Java, the architecture re-invents every possible wheel, and ultimately, if lucky produces .net/C# code in 2 yearas that a Delphi developer could have produced in a couple of months...oh wait, what were we talking about again??? :)

  12. I started out with Rambo, moved into patching Rambo, shot Rambo cause he wasn't RAD enough. Now I am learning to Objectively Oppress my Programming through OOP!

  13. A "good" code designer that isn't a code-writer and a code-reader is a creature I've never encountered.

    Invariably, all code-designers I've ever encountered that were doing just that all produced useless designs, that failed in a myriad of ways, from raw design flaws galore to overlooking "implementation details" that turned out to not be details, but whole projects on their own.

  14. Categorizing people???? Guess someone's is preparing for some job interviews. :-) I don't care if someone is categorizing people, just as they remember there are lot of relevant scales to categorize on. You could say I categorize people in (a) single-scale-categorizers and (b) multi-scale-categorizers.

  15. Take it from someone who's met someone who was a code-designer who tried to be a code-writer - it's an ugly scene.


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.