Why Are Many Coders Mediocre?

Last week, following the publication of this article on Builder.com, I was approached by an editor at Wiley & Sons (Makers of the “...For Dummies” books) in the UK about reviewing a draft of a book they are working on. I agreed, and the past two weeks have been fabulously interesting. I can't discuss the book yet (BELIEVE ME, when I can, I will) but I can say that it now comes in #2 on Robert's List of Books Every Programmer Should Read™, right behind Writing Secure Code, Second Edition.

So I'm working on my review, and it got me thinking about the difference between a mediocre programmer and a great one. What single factor makes a developer a master of their craft? Well, think back to the last piece of code you saw. How good do you think it was? If it was really good, what made it so? I consider great code to have the following characteristics:

  • Well formatted
  • Accurately commented
  • Descriptive
  • Concise
  • Easy to understand

Wouldn't you agree? We'll get back to that in just a minute.

In this day in age, I think the term “programmer” is a misnomer. I prefer to think of it as “code writer”. If you think about it, while code is meant to be interpreted and compiled into instructions that operate a machine, code is meant to be read by humans. In performing code reviews, when questioning the coder about their style, I've often been told “I'm a programmer, not an English major.” But often times, great code shares the same qualities as a great book. Code that is well written is engaging and fun to read. It makes you want to dive in and learn every nuance, watching for little details that make it stand out. Great code spawns creativity and new ideas. Invention begets invention.

(In the following paragraph, I will make a broad generalization that may or may not apply to you. If it does not, do not take offense. I realize that this generalization does not apply to most of the other people that blog here, but bloggers here are not the only ones that read this stuff.)
Now, consider most programmers. The stereotypical programmer spends lots of time in front of computers. Often when they were younger, they had trouble interacting with others. Human behavior is frustrating and unpredictable, which is confusing to many people of intelligence. At one point or another, these people discover computers, and fall in love with their predictability. You tell it to do something, and more often than not, it does what you ask. They find comfort in this, and eventually become developers.

So why are many programmers mediocre? Because they are poor communicators. They write hodge-podge, unmanageable, unmaintainable code because they cannot organize their thoughts in a concise and understandable fashion. Their code does not simultaneously contain instruction and convey intent. This is readily apparent at all levels, from code to comments to documentation to UI. A lack of instruction and practice in communication and social interaction makes mediocre communicators mediocre (or bad) coders. I believe that this is the reason so many people are frustrated with computers today. Poor communication of intent at the lowest levels are intensified exponentially at the highest levels. if you see a program with a UI that is nonintuitive and horribly unnavigable, it's a safe bet that the code is in the same shape or worse. Is it any wonder that so many people are calling “social computing” the next big thing?

So what is the lesson here? If you want to be a Software Master Craftsman, you must consistently practice and refine your skills as a communicator. Coders SHOULD be more like English majors. Code should go through an edit process identical to the edit process for a literary work. All code should be printed and checked for clarity, consistency, and accuracy. It should convey intent quickly and with precision, and should be as engaging as any spy thriller or romance novel.

But hey, I'm preaching to the choir, right? Isn't that what we're doing here every day... refining our communications skills?

9 Comments

  • Good thoughts, Rob. I also think "programming" and "writing code" aren't always necessarily the same discipline.

  • In many large organizations, there is a divorce between "design" and coding. Team leaders do the "design" and the programmers just fill in the code. A programmer required to "just fill in the code" of a given design can be so seriously cobbled that any chances of quality code are gone.



    I guess that that's my main point. You can't just code. Code and design must be done together, entirely by one person ( at least - you may have 2 or more people working together, but any person that's coding must be involved in the design process ). More importantly, the process must be fluid. The design must be redone in light of new understanding that surfaces during coding.



    Like you said before - preaching to the choir.

  • I think that one of the reasons that coders aren't very good is that they don't know where the bar is. How does a coder know if they're good or not?

  • errr, my example would look better if the formatting wasn't stripped out. ;)

  • My lack of looking at it from a functional standpoint was entirely intentional. We could hack all the other stuff to death about what makes it "good" code, and everyone else has different opinions. When you strip all that stuff away and get right down to it, if you can't read it and understand it immediately, it's crap.



    Further, Scott, your example does not fit my definition of good code, because the comments are totally redundant. Descriptive code does not need to be commented because it describes what you're doing. Your example would have been "good" code in my book if it instead contained a complete set of C# comment tags.



    I don't think that functional considerations make a Software Master Craftsman. Before you shoot me, hear me out. That stuff can be learned fairly quickly. Communications skills cannot. If you're a poor communicator, typechecking won't make your code any better.



    Take this unformatted example: (I'm not a C# guy)



    private int a(int b, int c)

    {

    if (b > 0, c > 0){

    return b/c

    }else{

    throw new exception["You Suck."]

    }

    }



    That code does typechecking, and always assumes failure. The code is horrible, because you have no idea what B and C are, nor do you know what A is, its purpose, and how it fits into the rest of the code. Nor does the code throw any meaningful exception in case of failure.



    And besides, if you're not validating your inputs, defaulting to failure and specifically asking for success, it's not a matter of whether or not you are a coder. You should not be allowed near a computer.

  • BTW, this was just my observation based on the book I am reviewing. It talks about the other aspects of Software Craftsmanship. I just had an idea triggered by a single sentance of the book. I chose not to talk about that stuff because a) I can't, and b) the book does a darn good job of covering it already.

  • Those are some very good points you're making.

    I have to say that this has been something I have learned over the past several years, as I began to work for a company, instead of making my own one-man projects amateurishly.

    I think another point that should be made (if I haven't by any chance missed it being made already) is that code mustn't always be self-descriptive, but it should always be understandable. This means that if I write a really complicated algorithm to make something work faster and reading it would make absolutely no sense unless you sat with a pen and paper for half an hour, I would put a page long comment before that code segment to describe it to whoever has to read it next. There have even been times when I have been forced to read such comments, even ones made by yours truly after not working on something for very very long, and found them not only useful, but quite necessary.

  • Scott,



    You're gonna love this book then. I think it's about time someone came up with an organization of programmers that was based on meeting standards and not just "who-knows-who".

  • Robert,

    May be you should read "Code Complete" by Steve McConnell (second edition). It's my favorite book on this topic.

Comments have been disabled for this content.