Beautiful Code

O’Reilly just published Beautiful Code. I was invited to contribute, but I just could not go along with the premise. I disagree that beauty is a guiding principle of programming. Here is how I responded.

I am having trouble with this assignment. Telling an inspiring story about a beautiful design feels disingenuous. Yes, we all strive for beautiful code. But that is not what a talented young programmer needs to hear. I wish someone had instead warned me that programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements. Of course I wouldn’t have believed them. It seems that pragmatism and humility can only be learned the hard way. I don’t know how to explain this in a case study. War stories do not instruct, because in retrospect the mistakes seem obvious. It is hard to convey the extent of the minefield of mistakes laying in wait. In essay form, I might say something like this:

I can’t teach you how to design beautiful code, because I don’t know how myself. I may have managed to get a few things almost right, and I have seen others do some nice work, but to be honest these successes always came from trial and error. The first try was often a total mess. Truly beautiful designs typically evolve from dozens of attempts, as for example with languages and libraries. Telling you to build one and throw it away, or to study a dozen prior examples, is just to admit that there are no general principles or techniques of software design. I hope that someday we will discover such principles. But in the meantime software design is still a matter of wisdom, not knowledge, and is therefore largely unteachable.

A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance. I find it immensely helpful to work on the assumption that I am too stupid to get things right. This leads me to conservatively use what has already been shown to work, to cautiously test out new ideas before committing to them, and above all to prize simplicity.

Another lesson I have learned is to distrust beauty. It seems that infatuation with a design inevitably leads to heartbreak, as overlooked ugly realities intrude. Love is blind, but computers aren’t. A long term relationship, maintaining a system for years, teaches one to appreciate more domestic virtues such as straightforwardness and conventionality. Beauty is an idealistic fantasy: what really matters is the quality of the never ending conversation between programmer and code, as each learns from and adapts to the other. Beauty is not a sufficient basis for a happy marriage.

70 Replies to “Beautiful Code”

  1. @“Beauty is truth, truth beauty,—that is all
    Ye know on earth, and all ye need to know.”

    oy veh, you better be saying that in jest, or you had better start telling juries to judge solely on the fashion abilities of those on trial. (which the actually do already, i’m sure, just not to the complete exclusion of things like, you know, evidence?)

    if anything, i think any truth which involves humans is guaranteed to be ugly.

  2. Without adding to all the noise, I’d like to recommend two related books to your attention:
    – Bob Martin’s “Clean Code’
    – Kent Beck’s “Implementation Patterns”

    Jay Conne

  3. Great stuff from a true Sage.

    Anyone who’s been practicing this ‘art’ for a few decades will recognize these opinions as truth.

    Anyone who places value by aesthetical means is truly lost. Correctness, utility and ‘conveyance of intent’ should be the software ascetic’s hallmarks of what is ‘right’.

    Textual programming is an encumberment to both programmer and compiler.

    Visualizing languages is not a solution either. (Clarifying that ‘subtext’ is not a visualized language.)

    Funny. I thought beautiful code meant it looked pretty on the screen (which ironically enough does have value)…

    1. Providing the correct function is always high up on a programmer’s priority list, but let’s not get too hung up on casting “beauty” to the wayside in lieu of doing whatever it takes just to get it done because “we aren’t smart enough”.

      There is a certain amount of pride that a programmer should take when they craft software. Part of that comes from writing code that not only functions as expected, but that is easy to read, maintain, and flows correctly.

      A programmer evolves as she grows and experiences development, both successes and failures. Ignoring what has caused the most grief and continuing to fall into the same traps over and over shouldn’t be used as an excuse to learn and discover new ways of formulating code. Beautiful software comes from growth, not from prettying up your indentation, or implementing every single design pattern the Gang of Four wrote down.

      You can’t expect your first (or hundredth) iteration of software to be truly brilliant and start considering it a work-of-art, but you can make an effort to mold and shape your design so that with each future endeavor, it becomes a little bit cleaner, a little more flexible, slightly more modular, etc.

      Beauty in software development is, ultimately, evolution.

  4. Thanks so much your writing!! As a newbie programmer I find a good deal of both consolation and inspiration in this piece. Thank you!

  5. apologies for this minor tangent…

    truth be told, i sincerely enjoy looking at code in its various physical incarnations and containers: color coding, block nesting, camel casing, project explorers with trees of assemblies implicitly ordered by naming conventions, class diagrams, white board sketches, etc.; all the constructs that we developers use to tame the chaos, press the lever, and squeeze the lump of clay through the star-shaped stencil. i find that the code product explored in the environment of its creation often has a visual, narrative beauty in and of itself.

    thanks to all for sharing your thoughts.

  6. One insight I think you hint at is that the code is not the full story and a beautiful system includes an environment that facilities analysis, new creation and change.

  7. “Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious.” — this is probably wrong ^_^

    “The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today.” — this is certainly wrong. you have probably not met a ‘brilliant programmer’. things are easy for them is because they use elegant mechanisms so that the complexity is minimized regardless of scale. those guys do this (write elegant code) as if it were their flesh. so in other words they never encounter complexity– in their own code…

  8. Do you know about the theory of beauty from Jürgen Schmidhuber?

    It is quite easy to apply it to this case, with good results. In this case the most beautiful code is the most simple to understand, with the lesser amount of entropy, very few bits should be needed to write it and very little processing to understand (compress) it according to our own knowledge, this is, with few ‘gotchas’. Code would be specially beautiful when it gives a better perspective of the problem that it solves, and gives us an insight that lets us compress the information related with that problem in a more efficient way.

    I may be wrong in any of the assertions made here, and I know, I didn’t read nor wrote about this very carefully yet, sorry if wrong, read more if interested. gl, hf.

Comments are closed.