Robert McLaws: FunWithCoding.NET

Public Shared Function BrainDump(ByVal dotNet As String) As [Value]

News

<script type="text/javascript"><!-- google_ad_client = "pub-4330602465258980"; google_hints = "ASP.NET, VB.NET, C#, C#.NET, WindowsForms, .NET Framework, VS2005, Visual Studio, XAML, WinFX, Windows Workflow, WPF, WCF, Atlas, NetFX3, Visual Studio Orcas"; google_ad_width = 120; google_ad_height = 240; google_ad_format = "120x240_as"; google_ad_type = "text_image"; google_ad_channel ="4997399242"; google_color_border = "B6C9E7"; google_color_bg = "EFEFEF"; google_color_link = "0000FF"; google_color_text = "000000"; google_color_url = "002C99"; //--></script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>
<!--
-->

You should feel free to challenge me, disagree with me, or tell me I'm completely nuts in the comments section of each blog entry, but I reserve the right to delete any comment for any reason whatsoever. That said, I will most likely only delete abusive, profane, rude, or annonymous comments, so keep it polite, please.

Blogroll

Cool .NET Articles

My .NET Tools

My Builder.com Articles

My MSKB Articles

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?

Posted: Jan 30 2004, 11:55 PM by interscape | with 14 comment(s)

Comments

Jason Salas said:

Good thoughts, Rob. I also think "programming" and "writing code" aren't always necessarily the same discipline.
# January 31, 2004 2:00 AM

Udi Dahan - The Software Simplist said:

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.
# January 31, 2004 3:04 AM

Alan McBee said:

I hope I'm not making a CLM (Career-Limiting Move) here, but I have sort of the opposite problem.

I love to code, but I'm not terribly good at the "look how much stuff I wrote in 6 straight hours" flavor of programming. Your stereotypical mediocre coder has non-existent comments, random formatting, and any semblance to "elegant code" is invisible. In my experience, the coders that fit this stereotype nevertheless produce a lot of working code. Bug-free and intuitive it may not be, but it can still be shipped.

I, on the other hand, tend to carefully craft my code as I craft my words. Unfortunately, it's time consuming. As I believe Blaise Pascal once wrote, "I have made this [letter] longer, because I have not had the time to make it shorter." I find very few business managers that care for well-written code as much as they care for meeting a deadline, no matter how capricious the date may have been.

So, I try to emphasize my analysis and design services, and de-emphasize my coding services. It's frustrating; I am still often expected to wear the "ship that damn code already" hat. This still puts me in the camp of "mediocre coder" although for a different reason than you suggested.

My guess is that most people like me give up trying to work with code, and train, suport, document, evangelize, or manage instead. That leaves the your code-shipping mediocre programmers at the helm.
# January 31, 2004 5:50 AM

Chris Sells said:

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?
# January 31, 2004 9:27 AM

Avonelle Lovhaug said:

Alan - Interesting. I agree that for some people, the deadline is the most important thing, and everything else takes a back seat. But not everyone is like this, and I hope you continue to look for people who will emphasize the kind of coding that you want to do.

Also, most of the time emphasizing the deadline and everything else really wrong, but sometimes it is okay. It depends on the people and the project. For example, when I worked for a consulting firm, we had a guy who always seemed to have analysis paralysis. Every project I was on with this guy, he wanted to slow down, and reconsider decisions already made, because they had some limitation ("harder to maintain", "won't perform as well", "more difficult to install", etc.)

The problem is that most decisions that are made involve tradeoffs. Ultimately, you have to make decisions and start coding. This guy was constantly removed from projects, because even after he was told - "look, we made the decision, just live with it", he would agree, and then come back tomorrow and argue about it again. Geez!

On one project, the customer just wanted to meet the deadline. It was political. They wanted to prove that something could be done in a few months - someone else had used up a whole year, and gotten NOTHING done on this project. It was an application that screen scraped data from a mainframe app, so we didn't even have a design ("make it look like this, but in Windows"). We had to remove the guy who couldn't get over the fact that it was just not being done right. We got it done on time - and the customer was happy. Sure, it would suck to maintain it, but they weren't intending to keep it around very long.

So, I guess my point is - there has to be a balance. Deadlines are important, but so is well written code, and good design, etc. Very few projects I've worked on have an unlimited budget and schedule. Sometimes you have to strike a balance between code that is well written and executes correctly and is well documented, etc. against getting it into an end user's hands whose life or job will be better because of using the software.
# January 31, 2004 11:16 AM

Scott said:

Chris, good point. Who sets the bar? I've seen a lot of crappy code come out of "senior" coders and good code come out of "ink-is-still-wet-on-their-cs-degrees" type of guys.

I think that Roberts definition is lacking. He seems to be looking at it from a maintinence and asthetic point of view, without considering performance and functionality considerations.

By the standards mentioned above this function could be an example of "good code"

private int divideTwoNumbers(int iNumOne, int iNumTwo)
{
//divides iNumOne by iNumTwo and returns the value
return iNumOne/iNumTwo;
}

It meets all the requirements for "Good code" that Robert listed but it has a fatal flaw that prevents it from being "Good code" in my eyes. No input checking. What happens if iNumTwo is 0? You're going to puke up an exception.

More here
http://www.lazycoder.com/article.php?story=20040131151944229
# January 31, 2004 3:47 PM

Scott said:

errr, my example would look better if the formatting wasn't stripped out. ;)
# January 31, 2004 3:47 PM

Robert McLaws said:

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.
# January 31, 2004 4:18 PM

Robert McLaws said:

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.
# January 31, 2004 4:22 PM

Scott said:

Good points Robert. I didn't realize you were only looking at it from a formatting POV. The only problem with including the XML comments in the formatting group is that VB.NET doesn't have them but for C# code they are essential.

My POV is a result of seeing lots of "why is there so much bad code being written. Why are there so many bad coders" articles (the most recent one before yours I think is here http://weblogs.asp.net/wallen/archive/2003/12/11/42935.aspx) without anyone defining what makes a good coder and good code. How can anyone strive to become a "good coder" if they don't know what differentiates a good coder from a bad coder. I'd like more people to chime in with their ideas of what makes code good and a good coder.
# January 31, 2004 4:37 PM

Omer van Kloeten said:

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.
# February 1, 2004 2:26 AM

Robert McLaws said:

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".
# February 1, 2004 1:49 PM

TrackBack said:

# June 14, 2004 6:31 PM

Stephan Branczyk said:

Robert,
May be you should read "Code Complete" by Steve McConnell (second edition). It's my favorite book on this topic.
# June 25, 2004 3:58 AM