Beautiful Code - Leading Programmers Explain How They Think edited by Greg Wilson and Andy Oram - ISBN 9780596510046 - O'Reilly Media 2007



Describe in a sentences or two what motivated me to read this book.

Pre-reading model

Draw a schema (using PmGraphViz or another solution) of the situation of the area in the studied domain before having read the book.


...earlier chapter to add

14. How Elegant Code Evolves with Hardware The Case of Gaussian Elimination

  • "Amdahl's Law: the observation that the time taken by the sequential portion of a computation provides the minimum bound for the entire execution time, and therefore limits the gains achievable from parallel processing."
    • "In other words, unless most computations can be done independently, the point of diminishing returns is reached, and adding more processors to the hardware mix will not result in faster processing."
  • see also

15. The Long-Term Benefits of Beautiful Design

  • "primary concern is not what the code looks like, but what I can do with it."

16. The Linux Kernel Driver Model: The Benefits of Working Together

  • overall evolution of Linux kernel programming?

17. Another Level of Indirection

  • ?

18. Python's Dictionary Implementation: Being All Things to All People

  • ?

19. Multidimensional Iterators in NumPy

  • ?

20. A Highly Reliable Enterprise System for NASA's Mars Rover Mission

  • "This chapter describes the design and development of Collaborative Information Portal, or CIP, which is a large enterprise information system developed at NASA and used by mission managers, engineers, and scientists worldwide."
  • "beauty is embodied in a complex software structure built by master builders who knew just where to pound in the nails. Large applications can be beautiful in ways that small programs often are not."
  • "the more successful the middleware is, the less visible it becomes. Beautiful middleware should be invisible!"
  • "In any large application, the key to success is integration, not coding. The beauty behind adhering to industry standards and best practices is that we did less coding by using COTS components, and because of common interfaces, these components were able to work well with each other."
  • "For CIP, beauty is in its implementation of a service-oriented architecture and in the numerous simple but well-chosen components—the nails that master software builders know just where to pound in"

21. ERP5: Designing for Maximum Adaptability

  • ERP5 Community Wiki Industrial Grade Open Source / Libre Software ERP/CRM Solution
  • "The core idea of a document-centric paradigm is that every business process relies on a series of documents to make it happen. The document's fields correspond to the structure of the process—that is, the fields reflect the data and the relationships among this data. Thus, if you watch how the business experts who use the ERP5 system navigate through the documents, you will discover the process workflow."
  • "This chapter will show how this document-centric paradigm and a unified set of core concepts make ERP5 a highly flexible ERP. We will illustrate these ideas by explaining how we used rapid development techniques to create ERP5's project management module, Project."
  • "ERP is software that aims to integrate all the data and processes of an organization into a unique system."
  • Unified Business Model (aka UBM) according to ERP5 Community Wiki

22. A Spoonful of Sewage

  • ". As software engineers, we are responsible for our own stress tests. Those that don't believe this—those have some patrician notion that writing such tests is too coarse for the delicate hands of a Gentleman Engineer—will deliver chronically broken software."
  • "the first code written on any project should be the code in which bugs may invalidate larger design ideas."
  • "implementing the hardest problems at the earliest phase in any given project, and to putting in place the infrastructure to validate that that infrastructure works (and remains working)."

23. ?

  • no notes, read a while ago

24. Beautiful Concurrency

  • "a beautiful program is one that is so simple and elegant that it obviously has no mistakes, rather than merely having no obvious mistakes"

25. Syntactic Abstraction: The syntax-case Expander

  • "The KFFD algorithm is simple and elegant, and an expander based on it could certainly be a beautiful piece of code. The syntax-case expander, on the other hand, is of necessity considerably more complex. It is not, however, any less beautiful, for there can still be beauty in complex software as long as it is well structured and does what it is designed to do."

26. Labor-Saving Architecture: An Object-Oriented Framework for Networked Software

27. Integrating Business Partners the RESTful Way

  • "This chapter will address some of the reasons for using a Web Services architecture, as well as explore some of the options to consider when integrating systems with the outside world."
  • "I typically write a series of comments in the code as placeholders where I'll insert the real code later. I then systematically attack each pseudocode comment until I have a working implementation. This helps keep me focused on how each piece relates to the entire solution"

28. Beautiful Debugging

29. Treating Code As an Essay

  • "Computers can, of course, deal with complexity without complaint, but this is not the case for human beings. Unreadable code will reduce most people's productivity significantly. On the other hand, easily understandable code will increase it. And we see beauty in such code."
  • "In the past, some organizations measured productivity by the number of lines of code a programmer produced, so redundancy was actually tacitly encouraged."
  • "Balance is the final element of beautiful code. So far I have talked about brevity, conservatism, simplicity, and flexibility. No element by itself will ensure a beautiful program."
  • Yukihiro Matsumoto chief designer of the Ruby programming language

30. When a Button Is All That Connects You to the World

  • the computer at, previously checked for OurP.IM hardware section
  • Seedea:Oimp/Ubiquitousvocabulary
  • "Our first question, and that of every engineer we explained this problem to, was: could we not find a way to increase the number of inputs Professor Hawking could provide? But his assistant was steadfast: Equalizer worked with a single button, and they saw no reason to change. We too saw the wisdom in writing software for the most extreme case of physical disability, for there were many kinds of binary switch that even a severely disabled person could press, operated by a shoulder, eyebrow, or tongue, or even directly by the brain. Having devised a solution that the largest possible number of people could use, we might then see how to speed up input for those with greater dexterity."
  • "The software offers choices one by one to the user, who accepts a choice by clicking when the desired one is presented."
  • "To speed up typing, eLocutor looks ahead, offering ways to complete the word being typed, and choices for the next word and the rest of the phrase."
  • "The intelligence we built in is of three kinds:
    • A relational database
    • A cache
    • Special groupings"
  • "besides simply just clicking the button, he could hold down the button and release it at a strategic moment. The button, in effect, is not merely a binary input device, but actually an analog one, for it can provide a signal of varying duration."
  • "Clicking a node performs its default action. But if you keep the button pressed, a separate menu opens up whose options roll by one by one, from which you pick one by releasing the button when the desired choice shows up."

31. Emacspeak: The Complete Audio Desktop

  • lot of comments about (Emacs) Lisp advice and its object-oriented equivalent Aspect Oriented Programming

32. Code in Motion

  • mostly inspired by The Seven Pillars of Pretty Code by C. Seiwald, Perforce Software 2005
  • "this chapter is about how the code looks: specifically, how certain human-visible traits of coding make serial collaboration possible. It's about the beauty of "code in motion.""
  • very interesting code analysis
    • release branches
    • Number of if statements at successive indentation depths per release
    • Number of patches applied per release
  • "To a programmer working on code in motion, beauty is code that can be modified with a minimum of fuss."
  • "programmers read code in diffs, patches, merges, compiler errors, and debuggers—not just in syntax-colored text editors—and that they frequently, if unconsciously, infer logic from the visual appearance of code as well as from the code itself. In other words, there's more to comprehending code than meets the eye."

33. Writing Programs for "The Book"

  • "The mathematician paul erdös often spoke of the book, a legendary volume (not to be found on the shelves of any earthly library) in which are inscribed the best possible proofs of all mathematical theorems. Perhaps there is also a Book for programs and algorithms, listing the best solution to every computational problem."
    • About Paul Erdos
      • "Erdös liked to imagine that God had a book in which he wrote down all the most elegant and beautiful mathematical proofs. "That's one for The Book," was his greatest praise."
      • see also PCM even if it doesn't have a section about Paul Erdos
      • N Is a Number: A Portrait of Paul Erdös, 1993
  • "In cartoons, the moment of discovery is depicted as a light bulb turning on in a thought balloon. In my experience, that sudden flash of understanding feels more like being thumped in the back of the head with a two-by-four. When you wake up afterwards, you've learned something, but by then your new insight is so blindingly obvious that you can't quite believe you didn't know it all along. After a few days more, you begin to suspect that maybe you did know it; you must have known it; you just needed reminding. And when you pass the discovery along to the next person, you'll begin, <<As everyone knows….>>"
  • "Google can probably find the algorithm you want, or even the source code, so why waste time reinventing it? [yet] doing so is not necessarily prudent: you are trading known problems for unknown ones."

See also

Overall remarks and questions

  • this? that?


So in the end, it was about X and was based on Y.


Point A, B and C are debatable because of e, f and j.


(:new_vocabulary_start:) new_word (:new_vocabulary_end:)

Post-reading model

Draw a schema (using PmGraphViz or another solution) of the situation of the area in the studied domain after having read the book. Link it to the pre-reading model and align the two to help easy comparison.


Back to the Menu

Other read books linking to the BeautifulCode page :


Back to the Menu