Code Hurts

I use email a lot.  I seem to be sending questions or replies to my co-workers constantly throughout the day, so you’d think I’d be very good at it.  Yet even with all my years of experience communicating through this high-tech medium I still find it difficult to get an idea across without inadvertently sending the wrong message.  You’ve seen it yourself, of course.  Probably more so on online forums or chats where it’s easy to be misunderstood; people flaming each other over imagined slights, reading innuendos and insults into even the most innocuous comments. I used to chalk it up to problems with the medium itself, plain text.  After all, it doesn’t convey the subtleties of how we normally express ourselves, it lacks gestures and inflections and so forth.  Now I’m starting to see that answer as a bit too simplistic.  Because I know it’s not true. 

Words alone can be as expressive as any other form of communication.  How else can you explain the works of great authors?  Surely, you’ve been exposed to passages of prose that evoked deep emotion, or described so richly and accurately something that made you feel as if you’ve been there.  Surely, you’ve read something that for you just rang true, where the author got it just right; it made perfect sense. All that understood through just words. Well chosen words can evoke a range of responses from the reader; sadness, glee even anger. Sure, most of us are not great authors, but our words do leave lasting impressions. This might explain why so much that is read is reacted to with hostility, because we aren’t great authors and don’t do a good job of it.  

So if we are not great writers of words, why do we think we can be great writers of code? Programs are written in languages, as plain text. Why do they not suffer from the same malady as the rest of our daily writing? Elegant code often evokes a sense of rightness; it instills confidence in us that overall programs are correct. Inelegant code does just the opposite; it deflates us with confusion and despair. Yet it’s likely that these emotions are unintended side effects of the writing. The code needed to be elegant because it was the right/best solution; or was inelegant because the problem was mired in complexity or was accumulated over time.

It’s obvious that what we write and what we read have a real effect on us, as we are emotional beasts and are wired to respond. Code with unwieldy structure, unnecessary complexity or simply with poorly chosen names can have negative mental influences on the programmers that must read and interpret all the work that has come before.  Yet this is exactly the kind of source code found in large projects that have either accumulated over time or been designed by committee. This is the real cost of maintainability of source code, the undue consequence of shepherding large bodies of antiquated text.  It explains why morale suffers on legacy projects. Reading old code is just depressing. 

It also explains why the open source movement is so popular with the self-deprecating crowd.  Some people are just drawn to that stuff.

Or is that just insulting?  I can never tell.

Comments (6)

  1. anonymous coward says:

    Most authors i know can’t program.. Since programming means writing code, and writing code is writing words, they must be bad writer?

  2. "So if we are not great writers of words, why do we think we can be great writers of code?"


    While my 5 year old can express herself quite well when discussing simple ideas, more complex ideas are beyond her. By structuring the same words she used differently, I am able to express more complex ideas.

    It’s not just an issue of syntax.

    Most of the code we write is used as an API by other code, yet API design is not known by many developers. More advanced concepts like fluent interfaces are largely unknown. When using fluent interfaces, then the impact of "sentence structure" on code quality just jumps.

    This is at the core of the new-ish movement of teaching developers not only by having them write code, but by reading high quality code as well.

    We might also consider the transitive effect that quality code = developers who feel good at work = more productivity & lower turnover and so on.

    However, I think that the biggest impediment to getting this word out is the "just get it working" philosophy that permeats dev shops. This appears to have its source in college/university (as I wrote about here: However, many development managers have this perspective as well.

    Anyway, great post.

  3. Anthony D. Green, MCPD says:

    Yes, yes. I generation a "programmers" half of whom don’t really love the work but jumped into a field because of the promise of money or job security. Trying to get good "grades" or "just graduate" they have no sense of workmanship, of pride in their craft. They never have that nagging voice of "How will this code reflect on me when I turn it in", "will this make it easy/less-complex for my team mates/calling code to consume".

    Dev managers have this perspective for a different reason, very realistic reasons. A symptom of a larger problem of not managing client expectations, scoping, or artificially deflated estimates and timelines.

    The fact remains that clients care about their bottom line and don’t directly see the benefit to TCO of maintainable code, and users only appreciate the UI (something equally starved of proper attention) and will never say "gee, that database is really normalized and the use of interfaces and factory methods makes this component super flexible".

    As Joel Hummel said (roughly) "Architects study great architecture, writers study great literature – programmers should study great programs" or in your brother’s case – the right way to do things.

  4. Welcome to the 27th Community Convergence. I use this column to keep you informed of events in the C#

  5. Corey Phillips says:

    When you started to see that answer as simplistic, then you thought you knew. Maybe. But, consider that you just thought you knew because you just started to see and just couldn’t resist the urge to jump into your point which had just been rendered worthless. Everything which follows this asinine statement is unreadable. I see your point.

  6. says: