Over the last two weeks, I’ve had the extreme pleasure of watching a lot of old Quantified Self Show&Tells. Whenever somebody has replied to our pre-order announcement that The Quantified Self: Learning to Observe was going to be published on October 6th and mentioned that they’d been following and participating in the QS community, I searched for any talks they might have given. I found many that I remembered and many I didn’t.
Some would have been impossible to remember because they took place at meetings I didn’t attend. Others were at conferences that I organized or helped organize, but those conferences often had over 50 talks and presentations over the course of two days, so I only got a chance to see a fraction of them. Of course, in writing the book, I watched many videos and read many transcripts, but our database has over a thousand records.
Besides, I like this approach better - I see somebody’s name, and I think “they must have given a talk.” Then I watch and am amazed. Topics that are just now emerging into the mainstream, such as continuous glucose monitoring for non-diabetics and tracking hormone levels and cognitive factors, were already being explored in ingenious detail.
Several important reasoning patterns that are taught in The Quantified Self appeared very early in the records of these talks, and before the end of this post I’m going to talk about one that is seen again and again but rarely easily customizable in self-tracking dashboards. I’m also going to link to a demonstration I’ve made with my colleagues that allows you to explore this pattern using your own self-collected data. If you don’t care much about the background you can go there now and ask your robots for help. What follows is the human bit.
The idea of reasoning patterns is adapted from the work of Christopher Alexander who introduced it in his classic work about proven solutions to challenges in the built world.1 Back when I was just starting out at Wired, this idea was beginning to spread into software development. In the spring of 2000, I got an assignment to go talk with Alexander at his rented house on Shasta Street in Berkeley, about a half hour walk from campus. The exterior was pink and dusty, the interior a desperate mess, and I felt an immediate sympathy for this stout and rumpled genius, who stood and spoke with me in an oversize blue shirt hanging loose and bare feet. There wasn’t a way for the two of us to sit down because the middle of the room where he brought me was taken up by a large model on a high platform, with a hole in the bottom into which he asked me to put my head so my eyes were just above the level of the floor.
Perhaps “talked with me,” is too gentle. He felt I needed firm correction. He’d read something I’d written about Rem Koolhaas and called it immoral. I didn’t like that. I said I’d neither excused nor glamorized. He made a sound of pain. He compared Koolhaas to Adolf Eichmann and asked: “Can one write objectively about such a person?” He had serious doubts about me, and before we agreed to talk more he wanted to understand where I was really coming from. That made sense. But in the next hours, he elicited very little information because he spoke without interruption. The book he was then working on, The Nature of Order, carried his hope — against admitted improbability — that a new way of thinking would transform architecture, along with the civilization that made such brutal and thoughtless design inevitable. At the end of the afternoon, when he tired a bit, I told him how much I liked A Pattern Language and The Timeless Way of Building, and gave him fair warning that the unavoidable question for a man who has built so little and spent so long on an unpublished work meant to overturn civilization will be: is he just a dreamer?
“I’m very vulnerable,” he replied. “To be announced as a dreamer would kill me.” We had a second meeting planned, but both of us understood the risk and let it drop.
The first volume of The Nature of Order came out in 2002, and I treasure my copy. Alexander was part of an emerging resistance to planners and architects who were overconfident about their reasoning power. Coherence, legibility, elegance: these virtues have something going for them. They are scale invariant: a box in a rectangle that is made out of aggregations of other boxes and rectangles, and filled with objects shaped like boxes and rectangles, packs neatly everywhere, including in our heads. We understand the principles in general, and then we apply them to specific cases. But along with this big thing going for them, the methods they spawn have many small things against them. Everywhere they are applied they encounter facts about the world that were not born of high-level abstractions but of extremely low-level processes. The world is full of knotty entanglements you can’t cut through with a knife; though you can cause a lot of harm by trying. For Alexander, modernism was worse than error, it was apocalypse.
The Trainer of LLMs
If you don’t know already about what happened — and it’s hard to predict who knows what these days — the events by which these ideas influenced everybody’s life will seem fantastical. In the 1980s Kent Beck & Ward Cunningham had developed a framework for object-oriented programming based on Alexander’s patterns,2 and in 1994 Cunningham created a website called the Portland Pattern Repository to catalog examples. The plan of the website itself was a design challenge to which Cunningham applied Alexandrian ideas. In March of 1995 he created a supplement with pages that could be edited by anybody, permitting a stable structure to emerge out of a continual process of repair. He called it the WikiWikiWeb. And, yes: that’s the origin of Wikipedia, trainer of LLMs. This is a tragic fate for the turn-of-the-century’s greatest cultural achievement, since LLMs destroy the social process that created them. (Chatbots, as we’ve been taught by hard experience, don’t allow anonymous but secure attribution, deterministic reversion to earlier states, or reward participation; how quickly we unlearn!)
Alexander saw where this was going when he addressed a conference on object-oriented programming in 1996.3 He asked the programmers to stop thinking about his ideas as a mere grab bag of solutions. Yes, there are patterns in the design of buildings and cities. And yes, there are patterns in the design of software. Cataloging these patterns so they are at hand when needed is useful, but not useful enough. What we need are generative patterns, that is, patterns that can be used as part of a living social process to solve problems for ourselves rather than to execute orders. Here’s a quote:
Please forgive me, I’m going to be very direct and blunt for a horrible second. It could be thought that the technical way in which you currently look at programming is almost as if you were willing to be “guns for hire.” In other words, you are the technicians. You know how to make the programs work. “Tell us what to do daddy, and we’ll do it.” That is the worm in the apple.
What I am proposing here is something a little bit different than that. It is a view of programming as the natural genetic infrastructure of a living world which you/we are capable of creating, managing, making available, and which could then have the result that a living structure in our towns, houses, work places, cities, becomes an attainable thing. (my emphasis)
Can you tune your ears right to catch the signal?
Self-experiment and pairwise comparison
In his later work, Alexander emphasized empirical self-assessment of our emotional responses, and insisted that their so-called subjectivity made them more rather than less reliable. In the passage below from The Nature of Order, you can see, somewhat entangled in his typical jargon, a very practical suggestion for how to solve a tricky problem of quantitative measurement of subtle emotional reaction to objects.
Our responses to things, Alexander writes, do not live in the patterns, but in the world of our shifting relations, and therefore there is no way to build a map in advance that securely connects some detail of a design to its expected result. He liked to model at full scale, and, when that was impossible, to use tricks of perception (like when he had me put my head through a hole in his toy floor), to disturb the misleading abstraction that comes from a God’s eye view. Though he was arrogant in argument, his methods were the opposite: simulate, test, reflect, use, and repair.
I’m glad I never wrote anything about Alexander while he was alive. He was too easily hurt to have a spotlight on him; he was renowned within his own circles and ignored where he wasn’t wanted, so there was really nothing for him to gain. But when I had to really cook up something useful; that is, to figure out how to distill and teach methods for self-research from the real life practices of the Quantified Self community, I found him to be just the right help.
Cycles: Reasoning Pattern 9
Here’s a worked example of a reasoning pattern, taken from our upcoming book, followed by a link to an interactive way to test it out.
Cycles
Our expectations are shaped by cycles: circadian, ovulatory, seasonal, and the social rhythms of work, school, and family. When cycles are strongly rhythmic and mostly the same length, they’re easy to spot; you can frame your timeline chart around one or more cycles and your graph will look like a wave. But cycles can be important even when they’re less obvious.
Visual presentations that explore cycles often take the form of a grid with shaded colors. If rows are weeks and columns are days, weekly cycles show up as vertical stripes around certain days. If rows are years and columns are months, seasonal cycles appear as vertical stripes around certain times of year. Cycles that are longer than expected show up as diagonal stripes running down and to the right; shorter cycles run the opposite way.
When to use: When you suspect that your measurements follow a recurring pattern—daily, weekly, monthly, seasonal—and want to visualize and compare cycles.
The method: Create a grid in which rows represent one time unit (weeks, months, years) and columns represent subdivisions (days, weeks, months). Shade each cell based on the measurement value. Vertical stripes reveal cycles matching your column unit. Diagonal stripes reveal cycles that are longer or shorter than expected.
I’ll resist writing more, since you can just try it.
Christopher Alexander, Sara Ishikawa, and Murray Silverstein, A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press, 1977; The Nature of Order, Book One: The Phenomenon of Life. Center for Environmental Structure, 2002; Christopher Alexander, The Timeless Way of Building. New York: Oxford University Press, 1979.
Kent Beck and Ward Cunningham, “Using Pattern Languages for Object-Oriented Programs.” Workshop paper, OOPSLA ’87, 1987. See also Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1994.
Christopher Alexander, “The Origins of Pattern Theory, the Future of the Theory, and the Generation of a Living World.” Keynote address, OOPSLA ’96, San Jose, October 1996; reprinted in IEEE Software 16, no. 5 (1999). Full text: https://www.patternlanguage.com/archive/ieee.html
Gary, this is (of course) an outrageously great piece of writing. I felt myself right in that Shasta St room with you and Christopher Alexander, especially when he wanted you to "wear" his model. Wow,what a memory.
I also love that you reminded us of the power of those deceptively simple grids, to show patterns in data.
Boy, I can't wait to read your book.