Chapter 1

It’s Wednesday evening. Incandescence lazes out from the rectangle in the southeast corner of my home work station. Zen Master Bon Seong, a fiery bushel on screen, a big circle face in the biggest square. He is using the figurative Zen Stick to short-circuit our cognition. He is fond of saying things like “You are stardust” or “What is I?”.

Jeff breathes hot air through the broom on his face. Those bits go through audio processing and seem to emanate from nowhere around the work station. “The infinite expansion of the same thing” is uttered. We’re discussing how people can interpret the same phenomena differently. As we say: “The whole world is made by mind alone.” And: “The whole world is a single flower.” As the Heart Sutra says: “form is emptiness, emptiness is form”. You cough. I’m startled. I freeze. I think you have COVID. I think I’m going to get it. Then get long COVID. Someone else sees you cough, they think it’s a sneeze and continue on. Perhaps it is.

The dharma talk continues. There’s nothing wrong with our kaleidoscope of perspectives. They are regular. This is the human mind being itself, resting in its station, but painting a tale on snake, coloring it’s ridiculous karma all over “the small box” that is our little piece of understanding of the universe.

Gosh, we’re talking about boxes from within boxes. Our thinking creates this separate, enclosed being. (Consciousness bound by a skin sack? Not today, the microbiome field transforms you. (Sigh. No help lugging our sacks and their biomic nerve fields closer together. We have decades of men making the Bay car-friendly, but I can’t get across conveniently. I can’t get to Berkeley from Potrero without spending as much time commuting as the duration sitting meditation with the other sacks for Wednesday night dharma talks.)) The problem is getting attached to difference. Not understanding our “universal substance” – what we say as a convenience. That’s why Zen is about returning to before thinking, accessing the truth before difference. So maybe instead: you cough, then I hand you a tissue.

I don’t want this post to be about the negatives of the human mind’s proclivity to be a multiversal agent. It’s not really a negative, is it? It’s a matter of fact about our minds as atoms floating in space. Space dust. So, instead: let’s relish in the generative creativities that difference making unleashes when multiple human minds are applied to a problem of interpretation.

Zen students say: “All things return to the one.” Once again, I have returned to software. One of my favorite ones for organizing and observing life’s exposures, like Scrabble tiles. Despite the one, I’m thinking about difference. The way the one refracts and playfully escapes. Our turn here will be akin to Jewish monotheism – a personal return to spiritual foundations – a spiritual tradition where the only official doctrine claims one god but there’s no consensus about what that means.

An often-cited medieval midrash asserts that each of the Israelites at Mount Sinai heart God’s revelation differently according to their own capacity to understand it. They each had their own individual experience of the Divine. – Sarah Hurwitz, Here All Along

A long time passed but the Buddha did not open his mouth to say a single word. He then reached down, picked up a flower and, without a word, held the flower aloft. Nobody in the assembly understood what the Buddha meant by this action. Only Mahakasyapa, sitting at the far back, smiled. – Gye Mun Sunim JDPS, The Birth of Zen

But not everyone smiled!

This “problem” of software:

The epistemological endeavor to solve challenges in the world, happening out there, with(in) reason. Then squeezing all that into binary logics and electrical pulses. Holding a shared thought among humans – sometimes only the wispy thrust of a thought – and making it instructions for the computer.

Zen Master Seung Sahn used to say you have to “digest your mind meal." He meant your understanding. Making software is a kind of digestion of understanding. Pushing thought stuff through a cheese cloth named Divine. A streetcar named Desire.

The software process is messy, from beginning to middle to end.

As a Zen student, I must declare: Where does the one return? Software’s interpretive act is a mix up, a Deleuzian differencing that flies a-face a unifying core concept. Software is never completed, and is not easily located anywhere in particular. Is it those words on the screen, dormant? You could print them. Is it the code as it runs, sonic or electrical (im)pulses amidst fibers, plastics, and metals. Is it what the mouse clicked? When was it conceived? Was it the idea?

Not the cleanest of lines, but lines in flight.

I want to argue here that the distinction between the software system and its development–that is, between the process and product–is another “point of opacity” of software engineering since, albeit necessary, it cannot be kept up at all times. – Federica Frabetti, Software Theory

Software is subversive to hard-dick narratives. It’s feminist, it’s counter-cultural in its essence. That’s why the gate-keepers are relentless trying to wrest it away from the hacker collective with a trademark.

The wisp of generative artificial intelligence hallucinatory resonance is hardly surprising. It’s a re-run run amok. Where does the one return inside your stolen nebula of documents? No citations, indeed. Where is your mind, Algorithm?

Messy. Material. Just as digestion is wont to be, from mouth mashing through shitting. The physical body process is mostly obscured by our containment sacks. But it leaks. It’s hacked.

The metaphor is apt. The world is messy as it is, and software is in it, made from it, made for it. This is why the end product of the software process inspires programmers of acrimonious humor, sometimes of low emotional intelligence, or of self-deprecatedness, or simply exasperated, exhausted… these programmers must declare that which comes from the butt. “This code is crap.” “Who wrote this shit code?”

It’s generally a pessimistic view to call code crap. I’d offer compost to lift us out of the sour sap to a corresponding brownish, molten tree sappy substance. A brighter horizon. Effluent cream - a regenerative solar punk version. Or something like “the best with what we had.” We need less snark in the industry, more heart, don’t you think?

Thankfully (we can breath a sigh) there are loving defenders of our end products out there. (Com)posters on the Net. Rachel Kroll is one, synonymously online as rachelbythebay. She emancipates some lines (of code) and litigates her own “crap code” through a simulated trial judged by such an exasperated panel, and then performs my favorite type of “if I knew now what I knew then” refactor blogging with a procedural splunk. It’s a beautiful example of husbanding thought stuff a second time through.

Chapter 2

Regarding playful escapings of difference.

Like verbalized language, programming languages provide multiplicities for getting thoughts out. In English spoken about town, adults will be overheard in conversation to utter variations on simple themes such as bipedal reversal, for example, with such enriched phrases as “they retraced their steps”, or “they went back”, or “they returned to”. Similarly, the general purpose Ruby programming language invented by Yukihiro “Matz” Matsumoto toward the end of the last century was composed with a syntax of including many lexical pathways to express its computer instructions. Of course, while these variations may not be imbued with the rich cultural context of spoken English idioms, they demonstrate what I’ve always found to be a never gets old trait of modern programming languages used in heterogeneous postmodern programming environments: there is creative choice!

Like English speakers, Ruby programmers will follow contextual precedence and are bounded by syntax constraints. And when going about telling a computer to execute a simple command, they can still do so in ways that delight and surprise us.

Let’s say a Rubyist wants to reverse a word. In programming parlance we refer to that word as a “string” which represents any sequence of characters including letters, numbers, or symbols. Such a rubyist might reach for an implementation using “primitive,” “imperative” syntax constructs like a while loop, indexed lookups, and string concatenation. These expressions are common across different programming languages. Additionally, they yield more control and flexibility back to the programmer. To wit:

    counter_index = original_word.length
    # create empty string to contain new reversed word
    reversed_word = "" 
    # start processing reversal
    while counter_index > 0
      # decrement the counter
      counter_index = counter_index - 1
      current_letter = original_word[counter_index]
      # add letter to the result
      reversed_word << current_letter
    end

So that’s one option. But looping over a string is such an everyday procedure that Ruby provides conveniences to do this with less code. In place of a while loop, index references, esoteric symbols like <<, the Ruby language includes higher order methods: a bit of logic slurped behind a human-readable name. Like each_char, which means “loop over each character”. And prepend, add something to the beginning of a string. Under the hood, Ruby implements these methods with its own primitives, likely similar to what we’ve written above. Let’s try reversal using the each_char method and see how it fits:

reversed_word = ""
original_word.each_char do |letter|
    # optional debuggers
    # puts letter
    # puts reversed
  reversed_word.prepend(letter)
end

This code is considered easier to read by many programmers because the method names makes the code’s intent obvious. Less code to mash in the mouth also means less information to pack into the brain’s working memory.

Above we see Ruby’s do block syntax in action. It creates a syntactical wrapper that logically bounds each letter in a semantically associative workspace. Somewhat different than the unhinged free jazz of a while loop block with throw-away variables.

Generally, declarative methods for strings can play nice together. They can be “chained” together and called sequentially. This makes it easy for a Rubyist to write concisely and fit a complete reversal procedure into one line. No need for instantiating a variable. Just push the word through multiple operations down an assembly line. Programmers verbalize this into one lining:

original_word
    .chars
    .each_with_object("") { |index, reversed_word| reversed_word.prepend(index) }
    .join

It’s subtle, but there’s actually some extra processing in the above statement by transforming the original word string back and forth from an array to feed the each_with_object. It’s conceptually funky, but since the complicatedness is hidden behind the alluring veil of each_with_object, the statement is still pleasantly terse.

Of course, who even has all this time on their hands to f*** around. Let’s just make Ruby do all the work for us:

original_word.reverse

Well, in reality, that quotidien commercial workplace, we often have more time. Because we need to build software to last. Which mean it’s uncommon to see these concise computational lines of code registered into a higher order architecture of collaborators. Our reversal code becomes a member of a reversing machine – a Ruby object – that can receive messages for requests with commands like reverse_my_word:

class WordReverseMachine
    def initialize(word)
        @word = word
    end

    def reverse_my_word
        @word.reverse
    end
end

# Somewhere else in my system...
WordReverseMachine.new(word).reverse_my_word

Although, maybe my WordReverserMachine shouldn’t be so opinionated in how it reverses things. Perhaps I want to borrow a reverse engine from other distant cyberscapes. Let’s allow our machine to swap engines as needed:

class WordReverseMachine
    def initialize(word, reverse_engine)
        @word = word
        @reverse_engine = reverse_engine
    end

    def reverse_my_word
        if reverse_engine? 
            @reverse_engine.new(@word)
        else 
            word.reverse_my_word
        end
    end

    def reverse_engine?
        @reverser.nil?
    end
end

# Somewhere else in my sytem...
WordReverseMachine.new(word).reverse_my_word

Reversing a word is a simplistic task, which is why languages like Ruby come with a reverse method on all String objects out of the box. And yet, programmers can dream wildly different expressions as demonstrated above.

Let’s take a look at the diversity of expression that unfolds from interpreting a task in a more culturally rich and relevant problem space. This is one is from an actual mess in the wild – unruly realism – where the task at hand is to look at all the products currently on sale in a restaurant website product inventory database that are not assigned to any particular menu.

Ok: so imagine this shop management software lets managers add products, but wait till later to figure out what menus those products go in. After all, does a croissant go in Breakfast or Pastries? It may not be obvious at first. Splitting up the administration of products this way creates efficiency for product inventory management and menu design. Which allows for more general flexibility and adaptability of a restaurant’s ordering experience. It lets a shop not use menus at all, or have some products in menus and some just floating on their own as standalone products.

These requirements imply that software developers working with this database will need to care about querying for products in a few different ways. Let’s play with a use case where a restaurant manager wants to display a website menu with products that are both in menus as well as a section for all other products. For example, there might be menus for Breakfast, Lunch, Dinner, and then a general list of other products under an…“Other” heading.

The software that supports this shop management software implements this data model for relating products to menus: Marketplace Products have many Marketplace Tags, and these two data types are associated with each other through a bridge table of Marketplace Product Tags. This is a fairly typical way of modeling a tagging system in a Ruby on Rails project with a relational database. Here’s what the model definitions might look like in Rails code leveraging ActiveRecord as an ORM:

# Product Model
class Marketplace::Product
	has_many :tags, through: :product_tags, inverse_of: :products
end

# Tag Model
class Marketplace::Tag
	has_many :product_tags, inverse_of: :tag, dependent: :destroy
  has_many :products, through: :product_tags, inverse_of: :tags
	scope :menu_tag, -> { where(is_menu: true) }
	scope :not_menu, -> { where(is_menu: false) }
end

Ok: so menus, or groups of products, are formed by products sharing a Marketplace Tag where a special boolean field called is_menu is set to true on that tag.

For our case, where this restaurant’s ordering page lists both products in menus and the rest beneath an “Other” heading, querying the right content for our others is the tricky part. This system allows shop managers to tag products freely. There is no restricted set of tags, or other constraints for product and tag associations. Therefore we’ll need to join across three different tables, marketplace_products, marketplace_products_tags, and marketplace_tags, and then collect any Marketplace Products where none of their associated marketplace_tags have an is_menu flag set to TRUE.

Lets start the beautiful differencing!

With the help of my fellow coders at Zinc Coop with whom I workshopped this problem, I’ve cooked three ways to query our postgres database for products without a menu tag with both postgres-flavored SQL and ActiveRecord ORM. (More ways left to be discovered.)

Even if you’ve got a mature ORM like ActiveRecord at hand, it can be pragmatic to express your query in SQL so the selection logic you enshrine in code is blatantly evident. What if, for our initial cook, we code with oneness. Get the data with a single select statement. Not necessarily bravado, or premature consideration for performance characteristics just yet. Let’s see what we can do with that generative single origin select start point.

Mario Kart starting line count down anticipation…

 select
            mp.*
        from
            marketplace_products mp
            full join marketplace_product_tags mpt on mpt.product_id = mp.id
            full join marketplace_tags mt on mt.id = mpt.tag_id
        where
            mp.marketplace_id = '#{id}'
        group by
            mp.id
        having not
            't' = any(array_agg(mt.is_menu));

The cleverness on the last line creates a collection of boolean markers for each Marketplace Product – t or f – representing whether the corresponding Marketplace Tag is a menu tag. The resulting row would look like {f, f, t, f}. Moving out left from the aggregate function, a filter computation is applied against the collection for any existence of a TRUE/t flag. The lispy parentheticals are sleek!

Thought: while the above option foregoes a subquery, I find the combination of group by and having clauses with the aggregating semantics notionally similar to a subquery insofar as we are selecting over a secondary “view” into the data.

It’s dawning on us: getting all the products without menu tags is not complex, although it may have seemed tricky at the jump. We’re only narrowing the product result set based on a single condition, it’s just that the condition happens to live a distance away. Let’s try again without the single select cleverness and consider nested queries:

select
    mp.*
from
    marketplace_products mp
where
		 mp.marketplace_id = '#{id}' AND
    mp.id not in(
        select
            mp.id from marketplace_products mp
            inner join marketplace_product_tags mpt on mpt.product_id = mp.id
            inner join marketplace_tags mt on mt.id = mpt.tag_id
        where
            mt.is_menu = true);

Because we now know that this query is shallow, both wide across only a few tables, and deep with only a single subquery, let’s see if Active Record’s query interface can provide similar conveniences like we achieved above with Ruby in our toy string reversal fractals. As it turns out, we can one-line all that SQL!:

Marketplace::Product.where.not(id: joins(:tags).merge(Tag.where(is_menu: true)))

This is slick, but might not be easy to come by without our previous work or deep knowledge of ActiveRecord. Our subquery version is informative for getting a mental handle on this terseness. We can reverse engineer. Notice how the entire subquery is captured in the outer parens pair. Now: the need for merge and passing in the Tag model as the argument is a bit elusive because we might expect to be able to simply joins(:tags).where(is_menu: true). But this would error because Active Record would think we were applying the where clause to Product instead of Tag, despite chaining on the join. merge is a logical separator that let’s us filter across these two relations with more discreet semantics.

Refine. Refine.

We can utilize the is_menu scope on our Tag class, hiding our where(is_menu: true) filter behind a shorthand that minimizes keystrokes:

Marketplace::Product.where.not(id: joins(:tags).merge(Tag.is_menu))

Ruby on Rails scopes are a brevity blessing. You can imagine where this might be going. Adding a scope for without_menu_tag on Product will make querying and displaying results on our restaurant odering page a triviality. Dropping into the view layer we can grab the data and splat it into components with human-readable phrasing:

<h1>Other</h1>
<div class="grid lg:grid-cols-3 gap-3">
  <%- marketplace.products.without_menu_tag.each do |product| %>
    <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>
  <%- end %>
</div>

The without_menu_tag scope can play well with other chainable scopes for quick prototyping and iteration for restaurant managers.

<h1>Other</h1>
<div class="grid lg:grid-cols-3 gap-3">
  <%- marketplace.products.unarchived.without_menu_tag.sort_alpha.each do |product| %>
    <%= render Marketplace::Menu::ProductComponent.new(product:, cart:) %>
  <%- end %>
</div>

How shitty is that?

Mind meal tests your mind: do you go for the bait? If you check the Ten Gates, the ten kong-ans, does hungry mind, desire mind, not-enough-mind appear? If so, you must eat your mind meal. You must completely digest your understanding. Then finishing your mind meal is possible. Then you get enough-mind, no-hindrance mind, no I-myme mind. Enough-mind does not go for the bait, so everything is clear and you can perceive any situation in your life and kong-an clearly, and save all beings. – A DOG’S “WOOOF WOOF” IS BETTER THAN ZEN MASTER JOJU, Only Don’t Know by Zen Master Seung Sahn

In 2015 I bought this book.    
7, or 8 years ago.    
Year one into my software career.   
This book is canon.   
I've had little use for its studies of algorithms. # thus far, see below     
I don't think Bentley would be offended.    
First sentence: "Computer programming has many faces."    

I’m sure I glanced at its pages before entering the corporate interview gauntlet to get in the vigilante mood. To shake out the shoulders, find some relaxment, whilst staring down a twenty two minute treadmill run or pile of laundry Sunday evening. You must to armor up for the algos in the kingdom of men.

While Bentley’s pearls are the type of polished wisdom earned through real life experience we get on the job, this book never became the vade mecum for my quotidian affairs. Is it for others? What comes after Part I was too metallic for an early-career front-end Rails dev.

Yet, the book can be pragmatic for all ages – see 3.2 Form-Letter Programming!. The fantastic headings are pedagogically caring. It is sensually satiated with geeked thoroughness. The cases are actually well-situated within the real-world: Bentley spoils you with further readings and sidebars, journalistic first-hand-accounts that remind you of how the metal has been worked over by a person’s hands.

It reminds you that software is not lonely, which is important.

But beware: there’s a modest amount of myth-making for his contemporaries and mentors. Yet, they are the most honest plagiarisms. Yes/and: he’s humbler than many. (Perhaps it is worth another pass now that I have more years in the rear view).

I am a visual learner and thinker: logical word-problems were always a pain. In recent years I tend to reach for Bhargava’s Grokking Algorithms for a refresher on binary search or walking trees. It has cute pictures. It’s stacked next to other faves like Land of Lisp and Why’s (Poignant) Guide to Ruby.

Hmmm (thinking emoji, I will not look you in the eye as I cock my head buried in thoughts). After all, the solstice konmari of my bookshelf – which I thought would elicit a reflection on some forgotten paper taking up space – has become the discovery of lost treasure. And yet, I’m still tickled by the scant amount of notes taken. I can’t read without a pen. Perhaps we’re time-traveling, then.

It's year one. 
Young Rails dev. 
He makes only two liner notes in a book considered staple grocery. 
I don't remember if I even read the whole thing. 
I bet I got through Part 1's wider lens, then started to gloss over.

One note is an exaggerated check mark next to this principle listed on p29 (Second Edition, published 2000):

Rework repeated code into arrays. A long stretch of similar code is often best expressed by the simplest of data structures, the array.

With “the array” also underlined from the outer left edge of the “t” to the outer right edge of the last “a.”

This one has stuck. Arrays, especially maps, can be more durable when staring down change. Before long any thoughtful software developer will realize that the components of a software system will become ordered and/or multiple.

There is no lonely software.

Data, whether as scalar, “bags” of properties, even subroutines and processes, even the manual lever pulling human tasks must be sequenced, serial, bound, reversed, indexed, sorted. The maintenance cost of housing data in ordered collections is generally low.

[<anything>, <anything>] 

Whole ass languages, like Clojure, were designed to favor ordered, associative arrays. As I learned after finding Hickey’s seminal talk Simple Made Easy. Richly simple and luxurious as Hockney’s bathers.

A second mark: a vertical line next to the opener for section 12.2 One Solution. This was (yet another moment in my lifetime) I learned that we never have to go it alone when staring down the void of what we’re building next:

As soon as we settled on the problem to be solved, I ran to my nearest copy of Knuth’s Seminumerical Algorithms (having copies of Knuth’s three volumes both at home and at work has been well worth the investment).

This has also stuck, reified after seasons.