Beware of the second worst programmer

I attended a Domain Driven Design course on Monday at Skills Matter offices. Eric Evans led the course and put forward a very interesting theory that the quality of a software system is proportional to the skills of the second worst programmer.

The explanation for the idea is that everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.

Although the story was intended as a joke, it is not completely without merit. Of course, just watching that person as well is not going to solve the problem. The moral of the story is, I think, that code and design reviews need to be done periodically. Most teams I’ve worked with in the past don’t take code reviews seriously, but that is one of the key practices to prevent problems and should not be skipped. Pair programming helps a lot since at least two people are working on the same task, but it still does not protect against problematic code (especially if the worst and the second worst guy pair up).

Drawing a parallel between writing and coding, proof-readers and copy-editors play a crucial role in any magazine or publishing company. They look at the stuff that you have written, identify and sort out (or suggest sorting out) language and grammar issues and look out for stuff that is expressed overly complicated and should be made more clear. An impartial view on the stuff that an author has written often helps a lot to make his text easier to understand and read.

Code reviews matter. Do them often, read code that other people wrote and get them to read your code. Step back for a moment and switch to reading mode rather than writing and check if the stuff can be written simpler or better. Even with the best intentions, people sometimes get blind to unnecessary complexity that they wrote themselves and an objective opinion of another developer can help a lot to sort things like that out. And of course, they might spot things that you have missed while writing the code, intercept bugs and suggest additional unit tests to check potential problems.

Image credits: Jenny Rollo

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. My latest book is Fifty Quick Ideas to Improve Your User Stories. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Specification by Example Workshops

Product Owner Survival Camp

Conference talks and workshops

7 thoughts on “Beware of the second worst programmer

  1. Or use pair programming and constant rotation to eliminate the need to do code reviews since you will have continuous peer reviewing.

    This is also how you can mentor your worst and your second worst developers. Turn your best developers into teachers and bring everyone up.

    Code reviews are weaker at the strong end (even great developers can turn out crap or gold-plated code and need sanity checks) while in general they result in weaker code because once code “works” the inertia to change working code is higher. Code reviews might catch serious flaws but lots of the subtle things that don’t warrant changing after the fact slide by.

  2. Your post caused me to realize something interesting. To quote yourself, “Drawing a parallel between writing and coding, proof-readers and copy-editors play a crucial role in any magazine or publishing company.” No one with any understanding of how modern publishing works would disagree with that assessment.

    However, you conclude from this that even systematic code reviews are important. This is clearly wrong. It’s as if you proposed that the NYT impose a new policy where editors and proof-readers will only check every fourth article that they publish.

    Clearly, from the example in publishing, to get acceptably low-error code the solution is to employ dedicated copy-editor/proof-read programmers who spend all day reading code and fixing code or design problems.

    Just my 2cp.

    Sean

  3. > Clearly, from the example in publishing, to get acceptably low-error code the solution is to employ dedicated copy-editor/proof-read programmers who spend all day reading code and fixing code or design problems.

    Which is how NASA writes perfect code for the shuttle:

    http://www.fastcompany.com/node/28121/print

    Now, what’s the difference. Well, I’ve never heard of any terribly innovative code concepts coming out of the shuttle program. Material science and electrical engineering, yes. Basic physics innovations? No. Comp Sci innovations. No. Hacking innovations? No.

    It’s a great way to write safe, stable code in a fiercely controlled environment. It’s also unbelievably expensive and slow to evolve.

  4. Nice post. I’m so jealous that you got to meet Eric Evans. His DDD book is probably the single most-impactful book on how I design my software.

  5. In my current job we use an internal review tool to do systematic code reviews on every single changelist submitted to the codebase. While immediately intriguing this took a few weeks to get used to in the beginning. Now I can’t imagine how someone can live without it, code reviews are our strongest tool to keep the team cohesive and up to speed.

  6. Pingback: Arjan`s World » LINKBLOG for October 8, 2008

  7. I had interesting experience….totally opposite but also interesting:
    “Software architect” as a best in team takes UML design tool, makes some diagrams as a foundation for code and db generation for big ERP software and then “second best” programmer takes this, remodel everything and generate code and database and system works perfectly for few years now.
    Of course “architect” sad that he is proud author of new model but who cares about this :).

    Pozdrav iz Srbije!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>