If we’re living now and always have been in the Age of Blurgs, then our strategy might change accordingly. Before I go to some ideas from the modern we got "The Age of Blurgs", and we got "Blurgs: Try Harder Won’t Work".
We need some better ideas, and the modern synthesis has some. Today I want to focus tightly on "just the coding". Coding’s not all the work doing software for money requires, not even most of it at the majority of shops, but it’s obviously important, and I think the restricted focus will help us get at the underlying ideas.
We considered three causes for blurgs that are bound in to our humanness: bandwidth, distraction, and semantic expectation. They are always with us, and have to be accounted for and worked with, not ignored or suppressed. That’s what the modern ideas are all about.
Let’s take a geek who’s actively coding, and consider the ways in which the modern synthesis tackles these very human problems.
Solving a coding problem in this style involves five activities: narrating, failing, passing, expressing, and pushing. These aren’t narrow, linear, or mechanical steps, but just loose collections of behaviors grouped around different areas of concern in the process. (i’m using strange language on purpose. Sometimes it helps to poke at a thing using words that don’t fit our received understanding. No question, tho, you’ll still recognize most of them.) there’s often overlap, recursion, and revision in these activities, but the general order is as written. Instead of going that way, tho, i’ll go contrarian and work backwards.
Pushing: this is the last thing we do in a code change. We take the edits we’ve made and we push them to head of the master branch. They become, effectively, "live" at this point, available for all to see, run, debug, test, change, and ship.
Expressing comes before a push. It is the time we spend taking our code and making it optimally expressive of its meaning. It’s a key element to the modern approach, and as we’ll see, is a direct embrace of blurging and its causes.
Passing is next back in time. It’s the actual getting of the code to "work". To do whatever we set out to accomplish. In passing we use a number of techniques to confirm that we’ve really accomplished it. How we do that is a huge response to what we know about blurgs.
Failing comes before and is the contra- of passing: the efforts we make to confirm that we have not accomplished whatever we set out to accomplish. As with passing, the modern style uses various techniques, most notably the creation of automated confirmations.
And before everything? Narrating. It all starts here, where we tell ourselves a story, a predictive fiction about what is going to happen to us and the code in the near future.
So let’s roll that forward, this time looking for the ways in which this style of working accepts and even embraces the reality that blurgs are an unavoidable part of software for money, of human makers making the made.
When a geek sets out to accomplish some task, she narrates: she tells a story about the future of the making. It’s an odd business, but is fundamental to success. That story is the first bridge between the world of fuzzy human language and obsidian-sharp computer processing.
Narrating involves fits & starts. It usually begins with some large goal and a great deal of uncertainty. As it proceeds, she’ll usually wind up shrinking the goal and increasing her certainty. The task we’re trying to accomplish is the final climactic scene of our story, and we go back & forth over various trial versions of the story, in quest of a coherent set of scenes that will get us there. It’s continuously iterative and refining. (side: it’s the best part.)
It speaks to human factors in blurging in several ways. It makes semantic expectation explicit. It creates sequences, each element of which reduces bandwidth. It assists us with distraction by providing focus based in a sense of momentum or progression. (Narrative needs a whole muse to itself, as does the tremendous value embedded in making expectation explicit. I can feel this thread growing out of my control already, so I am going to keep moving for now.)
Failing is the part where we prove that we don’t have what we wanted yet. In the modern synthesis, we do this overwhelmingly by writing many small tests that let the computer processing do the proving for us. We work hard to make those tests small, fast, accurate, precise, and graspable. The size speaks to bandwidth. Precision & graspability speak to semantic expectation. Fast & accurate? There we have perfect alignment and acceptance w/the fact of blurging. We do this because we know we blurg. We know it, so we need tests that are fast cuz we’ll want to run them often. We know it, so we need tests that are accurate so they don’t mislead.
Passing then comes along. Passing means holding the tests stable while changing the code until it gets through them. Notice that splitting the act in two, first fail, then pass, is a direct effort to reduce bandwidth and minimize self-distraction. As with failing, too, the passing tries on the one hand to make semantic expectation explicit, and on the other hand to place as much of the actual confirmation of that expectation not in the fuzzy human world but in the exact repeatable binary world of the computer.
Expressing is the part where we take our code that is passing and make it map perfectly onto the narrative we started with — more correctly, the updated & revised narrative we’ve built along the way. (again, explicitness and/or what I think of as reification rears its head. Another day, another day.) passing & failing shift the burden of proof in an effort to reduce the risk of semantic expectation creating blurgs, expression is our effort to come full circle.
Backed by automatic verification, we freely change the code to restore and enhance the narrative we started with. The narrative was our first bridge between human & computer. Failing & passing are the rickety boot-strapped reaching of the other bank. Expression is reforming the bridge to make it viable for heavy traffic.
When we first straggle across to the computer bank, we very often will have discovered entities, relationships, and plot points — sequencing, that wasn’t in our original narrative. But now that we’re reliably across, we re-shape the bridge from both banks.
Often, expressing involves lots of chunking and naming and resequencing. These activities mirror the exact activity of the human mind in handling lots of independent concepts. They are the key mechanisms by which in non-geek life we "outwit" the harsh bandwidth limit.
And pushing? Pushing the code is injecting it into a world shared with others, we do two things. 1) we close a box for now, a kind of chunking that lets us reduce bandwidth and accept new distractions. 2) we expose that code to even more rigorous inspection for blurgs.
So, narrating, failing, passing, expressing, and pushing. We’ve just discussed them in the very narrow context of doing the coding itself, but the underlying ideas, about working around bandwidth, distraction, and semantic expectation, are spread throughout the modern synthesis.
(This is just a start, and i’m frustrated that I didn’t get the best expression of what i’m after and had to leave out a bunch for space. So it goes. Upside of following me: u get it fresh. Downside: u get it fresh. Plus following me.)