Beautiful Code. Leading Programmers Explain How They Think

Citation

Kekäle, T. (2009), "Beautiful Code. Leading Programmers Explain How They Think", Journal of Workplace Learning, Vol. 21 No. 7, pp. 576-578. https://doi.org/10.1108/13665620910985568

The second book on expertise is about programmers, and written mostly for programmers. The book is full of pieces of code that the authors think are the best examples they have been able to code; they discuss the details where their “expertise” and many years of learning their profession shows. The examples, of course, are mostly beyond my abilities (firstly, the authors are “today's leading programmers”, so it would be naive to assume myself to be one of them, and secondly, I have forgotten most of what I have ever learned on how to code). But for the purposes of workplace learning, it is interesting to study computer programming from an intellectual capital point of view. The best coders' minds are human capital to an organisation, taken to a wider use through interaction with others (social capital); the best pieces of the code itself are saved for further use through organisational‐capital systems.

The question that always has fascinated me is how software designers can write better code than expected, given their initial knowledge in coding (a bit like a bumblebee not being able to fly). The answer seems to be in the combination of their own knowledge, their colleagues' knowledge, and trial and error. Really deep software learning seems to be comparable to Vygotskian social learning. As the initiator of this book project, Greg Wilson, states in his foreword: “Architects are taught to look at buildings, and composers study one another's scores, but programmers – they look at each other's work only when there's a bug to fix; even then, they try to look as little as possible. We tell students to use sensible variable names, introduce them to some basic design patterns, and then wonder why so much of what they write is so ugly” (p. xv).

The chapters of the book show time after time that even master programmers initially seem to write just a piece of code that works, and only later, more often than not through insights of others, are able to simplify and streamline the code to its bare minimum:

In frustration, I drove with another developer, Ben Collins‐Sussman, from Chicago down to Bloomington, Indiana, to seek the advice of Jim Blandy, who had invented Subversion's repository model in the first place, and who has, shall we say, strong opinions about design. Jim listened quietly as we described the various avenues we'd explored for transmitting tree differences, his expression growing grimmer and grimmer as we talked. When we reached the end of the list, he sat for a moment and then politely asked us to scram for a while so he could think. I put on my jogging shoes and went running; Ben stayed behind and read a book in another room or something. So much for collaborative development. After I returned from my run and showered, Ben and I went back into Jim's den, and he showed us what he had come up with. It is essentially what is Subversion today; there have been various changes over the years, but none to its fundamental structure (Karl Fogel, p. 16).

I loved the algorithm, but I always tiptoed around its innermost loop. I once spent two days debugging a complex program that was based on that loop, and for years I carefully copied the code whenever I needed to perform a similar task. It solved my problems, but I did not really understand it. I eventually learned an elegant partitioning scheme from Nico Lomuto, and was finally able to write a Quicksort that I could understand and even prove correct. William Strunk Jr.'s observation that “vigorous writing is concise” applies to code as well as to English, so I followed his admonition to “omit needless words (The Elements of Style). I finally reduced approximately 40 lines of code to an even dozen” (Jon Bentley, p. 30).

The book includes numerous attempts to promote the tacit knowledge of senior programmers to novices through similar memoirs and many examples of code in different script languages as well as basic Unix. This is certainly important for programmers to learn better programming, but the book is also interesting for people who want to gain an insight into how programmers learn better programming after college as part of their real programming work. In the last chapter, Brian Hayes comments on this briefly (p. 550):

One lesson that might be drawn from my experience is to seek help without delay: somebody out there knows more than you do. You may as well take advantage of the cumulative wisdom of your peers and predecessors. In other words, Google can probably find the algorithm you want, or even the source code, so why waste time reinventing it? I have mixed feelings about this advice. When an engineer is designing a bridge, I expect her to have a thorough knowledge of how others in the profession have solved similar problems in the past. Yet expertise is not merely skill in finding and applying other people's bright ideas; I want my bridge designer to have solved a few problems on her own as well.

So, human capital, social capital, and organisational capital all interact.

This book is a thought‐provoking tome for programmers who want to find their best and write “beautiful code”, with several good “how I saw the light” insights, rules of thumb and stories in between the excerpts of beautiful code. The book is also relevant for researchers and others who wonder how programmers really do learn their profession. And the royalties of the 39 authors all go to Amnesty International.