To a programmer working on code in motion, beauty is code that can be modified with a minimum of fuss. You read the code, determine what it does, and change it. Your success depends as much on how well you understood the code to start with as it does on your ability to code. It also depends on how well your code is understood by the next programmers to tackle it; if you're never called in to help them out, you've done well.
Were we to trim the narrative from this chapter, all we'd really have left to say is that the success of code in motion depends on how comprehensible it is to the programmers who read it. But this is not news to anyone.
What is news is that 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.
In this chapter, we've examined the effect of using "The Seven Pillars of Pretty Code" as guidelines to make code more comprehensible in more contexts. We've had success with the Seven Pillars. We've used them to write code that can move with the flow of change, and we think that's beautiful.