I have a copy of the new book Beautiful Code: Leading Programmers Explain How They Think (you can also check out the O'Reilly Beautiful Code Home. My concern is that Beauty, depending on how you define it in this context, does not seem to me to be the way to measue or judge code. Now, some people seem to define beauty in terms of the readability of code and that is important for those that follow in your footsteps. Some define it in terms of the simplicity and compactness of an algorithm and implementation and again that seems valuable in that a smaller implementation tends to be more understandable (fills fewer pages in the brain). But those who become enamoured with the elegance, symmetry or "beauty" of code we should remember the words of Donald Norman "".
My personal preferrence is to see well-laid out code, reasability, simplicity and openess as great tools in the service of safe code. I would be much happier to judge the value of my code on what the test team think of it rather than the adulation of other programmers (even though that is nice). Code that doesn't come back to haunt you, that's beautiful. So what else can we include in the list of tools for developing safe code? Well Bryan Cantrill discusses the book here but more interestingly here where he argues that programming language choice plays a part in beautiful (and by my extension, safe) code. This an area which tends to bring about some heated, even passionate, discussion but I believe that language choice really does make a difference in both the ease with which concise and clear code can be written as well as the ability to develop safe code.
To this end one area where I think many programmers struggle is the development of parallel code; and with the widespread availability of multi-core machines (it's hard to by a PC these days which isn't a Duo) it's a skill more of us will need to know when our jobs include the performance of applications. This is certainly part of the discussion in a new book on the language Erlang - a language which includes simple, compact and elegant parallel primitives. I spent some time working in Ada which has a good set of parallel abstractions and while Ada has many problems it is interesting that few of the popular languages today provide much in the way of parallel primitives beyond Thread classes and synchronized keywords. I'm not sure that Erlang is going to be any more successful than Ada outside of it's current niche but it is now a fully open sourced project and does seem to be generating quite a bit of buzz. The nice thing about Erlang is that it combines a god functional language, single-assignment and a high-level set of parallel primitives in an elegant (dare I say beautiful?) manner. Whether Erlang does take off or not I do think that we'll have to work out a way to keep our code beautiful when it is split into numerous components running parallel across different cores, processors, blades or machines.
Just for kicks, here's a nice piece from Jonathan Edwards in his post Beautiful Code.
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.