The labyrinth challenge

I’m writing a novella intermittently and the most recent drafting session raised a challenge. I need to create a labyrinth with two constraints.

  1. The labyrinth contains three destinations: A, B and C. Continuous lefts at four-point intersections lead to A; continuous straight-aheads lead to B; continuous rights lead to C.
  2. Choosing different directions at four-point intersections avoids A, B and C and keeps one within the confines of the labyrinth.

In the novella, this labyrinth is set within the bend of a river. A visual representation (obviously wrong and not to scale):

I’m only half-concerned that such a structure is conceptually possible (author = God, after all) but I thought it would be interesting to see if anyone:

a) knows of similar structures that exist and/or
b) knows how to begin creating one.

If it turns out that it’s possible to create a labyrinth like this, I may look into producing a map of some sorts as an AMP (adjacent mini-project) to accompany the novella when it is eventually done.


This is not a post about the intricacies of programming–I can barely sense, yet alone articulate, any intricacies. It’s a short post about an updated belief…

I’m in the midst of learning about interactive programming in Python. This morning, I was toying around with a key functionality: lists. Like most programming languages, Python includes a variety of methods to manipulate basic data types like lists. One of these methods is append. The append method is used to add one item to the end of a list.

For a while, I’ve maintained a semi-private list. This list is called certainties. It contains one item. The entirety of the list can be formulated as:

The only certainty in life is that the fragile will break.

Now, I would like to append an item to certainties. Now, it contains two items. Now, it can be formulated as:

The only certainties in life are that the fragile will break and the broken can heal.

The first iteration of the list was not exactly synonymous with rainbows, unicorns and lolipops. The second iteration is, at best, equivalent to bleak, plus a twist of lemon. But that’s okay. The joy of life is in the possible, not the certain. The second item in the list serves to remind me of that.

Everything plus one

Four models concerning the theory of individual habit formation:

The commonalities between these four models is easy to detect, even if you rely only upon my simplistic descriptions. A commonality that is slightly harder to detect, however, concerns the number of habits that are changeable at any one time.

A foundational assumption of the habit formation domain is that habit (re)formation is most likely to succeed when only one habit at a time is changed or learned. It is possible to change multiple habits at once but the likelihood of “success” drops dramatically for every extra attempted change. This seems sensible and correct, assuming habit alteration takes place on a ceteris parabus canvas. What if it doesn’t?

My speculation: if everything is changing, every extra attempted change increases the likelihood of successful new habit formation.

Starting a new job (especially if it requires changes in established norms of space and time), moving house (especially if it means moving to a whole new town, region or country), and exiting a significant romantic relationship all classify as scenarios where (i)everything is changing. There are likely more.

Let’s take an extreme example. Imagine someone who is moving to a new house in a new part of the country and starting a new job because they’re fleeing from the tendrils of a messy break-up. So much has already changed in their life that adding one more thing isn’t going to cause much more disruption. This sad soul has never woken up in the morning and done a yoga flow? They can now. They’ve never abstained from drinking during the week? This is their chance. They’ve never engaged in adult education or tried learning a new craft in the evening. Smell that opportunity!

On a ceteris parabus canvas, adopting a morning yoga habit, changing an alcohol consumption habit and adding in a new and explicit learning behaviour is likely to fail. On a canvas where everything is changing, novel habits and behaviours are nothing more than features of a new environment which already requires major adaptation and orientation.

Of course, there’s a hidden aspect to such aggressive change; it will likely involve significant discomfort. Discomfort that could even be experienced as pain. Human minds (especially mature adults) are wired to seek solace in the continuation of the status quo. Which means a modification is in order…

My speculation, vers. 2: if everything is changing, every extra attempted change increases the likelihood of successful new habit formation (provided one can tolerate the associated psychological disorientation).


Like a child with a high time preference who desperately wants a marshmallow, I couldn’t wait. I finished Winslow’s Cartel Trilogy last night (read it!) and gave in. I was going to wait until I’d finished Slate Star Codex Abridged. I didn’t. Couldn’t. I caved and got myself five new Kindle reads. Hence; NBD.

New. Book. Day.

I’m still making my way through the Little Black Classics–most recently, number thirteen, John Keats–but I prefer to read these slowly, on empty mornings. Unfortunately, due to a mixture of internally and externally imposed constraints, these are not particularly regular. So, to supplement the LBCs and SSCA, I have:

At times, it feels like the practice of reading is hard-coded into my DNA. Books–or, more accurately, the people that write them–have given me so much. Changed me in countless, incomprehensible ways. I have faith that the above will continue to catalyse my ongoing, never-ending metamorphosis…

The strange loop of super active omittance

I’m making a deliberate effort to use my notebook as an unconstrained, free-thinking journal. In a recent entry, I riffed on “swell and cut” as a process and started listing synonyms for the process. One was “commit and omit”. This evolved into the following table:

Commit has a positive valence but in two senses. A passive commit means doing something. It’s relatively easy, in basically any scenario, to do something. An active commit means doing the right thing. As we all know, that is much harder.

Omit has a negative valence but in three senses. A passive omit means doing nothing. Again, standard and easy fare. An active omit is slightly more complex; it means avoiding the right thing. I couldn’t decide whether this was easier or harder than doing the right thing, so I allocated them the same difficulty. And yes, I’m aware of the semantic complexities of defining action versus inaction–I’m just opting for selectively applied ignorance. A super active omit means negating the right thing. It’s this last that I find most interesting.

Negating the right thing can mean a few things. Rolling back a hastily deployed software update; a societal wide attempt at degrowth; exiting a less-than-suitable relationship. But what do these examples have to do with strange loops? Straight from the annals of Wikipedia (emphasis mine):

“And yet when I say ‘strange loop’, I have something else in mind — a less concrete, more elusive notion. What I mean by ‘strange loop’ is — here goes a first stab, anyway — not a physical circuit but an abstract loop in which, in the series of stages that constitute the cycling-around, there is a shift from one level of abstraction (or structure) to another, which feels like an upwards movement in an hierarchy, and yet somehow the successive ‘upward’ shifts turn out to give rise to a closed cycle. That is, despite one’s sense of departing ever further from one’s origin, one winds up, to one’s shock, exactly where one had started out. In short, a strange loop is a paradoxical level-crossing feedback loop. (pp. 101-102)”

In the context of the above examples, software is regressed to a previous version, a person exiting a relationship returns to single-status and a society that degrowths executes a weird time hop. In each case, however, the state returned to is different due to the presence of insight and the gathering of now-invisible experience.

(Confession: the above is likely inconsequential. However, it refused to give up its tenancy in my mind so I thought I’d persuade it to take up residency in yours. Let me know if I am successful…)

Fat tails and boring edges

In light of feedback received during my ongoing search for my first product management role, I re-read Taylor Pearson’s article, How to Get Lucky: Focus on the Fat Tails. The following section stuck:

Almost everyone systematically under-allocates resources to the fat tails. We tend to spend most of our time and energy thinking about the middle, because we see the world through a bell curve lens, and most of the area in a bell curve is in the middle. But in reality, we live in an 80/20 world, where the top 1% of fat tails account for 50% of the results. The people who understand this seem to know how to attract luck, but really they’ve just adopted the 80/20 curve model.”

In terms of job/work hunting, that means de-emphasising traditional methods (cover letters and CV submits) in favour of fat-tailed methods (asking people questions, attending meet-ups regularly, joining virtual conferences, working in public). Visually:

I’ve considered the “focus on fat tails” approach in another domain, too: stack entry.


For a long while technology has been an interest. But it’s never been more than that. It’s been like an invitation to dinner that I’ve never taken the host up on. Until now. Recently, I decided I wanted to build a simulation model that would allow me to play with the mechanics of trust de- and re-generation. One problem: I don’t know how to code. The agents in’s agent-based models are programmed in either Python or Javascript; I decided to start by learning Python. The above wasn’t as whimsical a decision as it sounds.

The internet is an integrated software-hardware stack. For example, the Internet protocol suite is modelled with four layers: link layer, internet layer, transport layer and application layer. Visually:

I’ve spoke with people about learning to code before and my preference has always been to enter the stack at one of two points: the bleeding edge or the boring edge.


I recently listened to Dawn Song’s appearance on the Lex Fridman podcast. Dawn Song does all sorts of interesting things and one of those things involves neural program synthesisbuilding a program that can solve a problem by writing its own program. That is bleeding edge.

In the same episode Lex Fridman also mentioned that he was looking for an expert in Fortran. Fortran is a third-generation programming language but one that is older and increasingly hard to find “experts” in. Below third-gen languages there are second-gen languages (assembly languages) and first-gen languages (machine-level languages). That is boring edge.

In contrast to the bleeding and boring edges of the stack is what Taylor Pearson called the body of a bell curve: the lumpy middle. Entering the stack at the lumpy middle is, on most accounts, fine. It’s okay. Reasonable. The most sensible. After all, the lumpy middle is lumpy for a reason; the skills and knowledge contained there are both readily available and relatively valuable. But I think entering at the bleeding or boring edge is a better proposition, both in the short-term and the long-term.

Short-term: I suspect learning about the bleeding or boring edge is just more exciting. Long-term, I suspect it turns out to be much more valuable. Until expertise in the boring edge is needed and until the functionality of the bleeding edge is realised, both are undervalued, but when those times inevitably come a premium can be had. In other words, the fat tail of the technological stack is the bleeding edge and the boring edge.

Another reason not to begin in the lumpy middle: generally, I suspect it is easier to move from one of the B-edges to the lumpy middle (or even straight to the other side) than it is to do the reverse. I don’t have data (even anecdotal) to back this up; it’s just a hunch (feel free to inform me otherwise).

As to choosing between the two edges in the context of stack entry: I think it depends on one’s preference for abstraction. Bleeding edge competencies tend to revolve around system-level problems and solutions–the realm of high abstraction. Think Elon Musk’s dallying with rockets and brain chips or attempts to solve super wicked problems like climate change or wealth inequality. Boring edge competencies tend to revolve around component-level problems and solutions–the realm of minimal abstraction. Think circuit board design.

Personally–as I think my objective to toy with simulation models and the joy I find in writing stories demonstrates–I lean towards abstraction.

Cull and craft

Hurrah! My Elements & Components of Product Management project is past the initial stage. I’ve collated five-hundred-odd ideas from the disciplines of business analysis, UI/UX design, software development, project management and interfacing/integration. Now I have to cull eighty percent of them and create a shortlist, leaving me with roughly twenty per discipline.

The end goal is to have a selection of powerful ideas that can be used as long levers by a product manager. Before I get there, however, I have to figure out the method and criteria for selection.

As well as this, I’ve just begun exploring the tool-stack (my profile is here: I want to modify one of the existing information/opinion spread models to reflect something like this:

Why? Although I have an interest in tech, I’ve never actually built something before. Fooling around with agent-based modelling not only aligns with my tendency to start hard and ratchet down in difficulty (instead of the more reasonable reverse approach), it is also something I’m actually interested in. The going, of course, will be slow–I’m no coder. But didn’t someone once say, “slow is fast, fast is smooth”?

The root of disagreement

The C4 Model is a paradigm for more effectively diagramming software architecture. The four Cs are context, containers, components and code. This video is a great introduction for the interested. It also provoked a question.

During the presentation, Simon Brown–C4 Model creator–used an analogy. He said that when it comes to understanding software architecture the problem is often notation, not abstraction. He cites two different maps of the same place–they will describe the same things, fundamentally, but do it in a different way. They will disagree.

Consider the abstractions-versus-notation issue in another context. We all agree that inequality is a thing–it’s like the thousand-year-old church on the map of contemporary civilisation. It’s most definitely there. But we all disagree about how to analyse it, where its boundaries end and where they begin, whether to classify it as benign or inevitable or malevolent, and so on. Notation, not abstraction, is the problem.

Now, visualise disagreement as a tree. The trunk diverges into branches and twigs and leaves, all unique but all still birthed by the same arbor. The question is, What is the root of disagreement?

An obvious answer would be “difference.” You and I, we have had different experiences. I grew up in a different place, at a different time, around different people, focused on some things and fearing others. By nature and by nurture, we are not the same. It’s logical for these many differences to eventually manifest as disagreement. Another answer could be “language.” The inadequacy of language is a well-documented phenomenon, after all. If I cannot explain my thoughts–my differences–with sufficient clarity then disagreement is sure to reign. The best answer, in my opinion, encapsulates both the above. I think the root of disagreement is “communication.”

Using language to convey difference is a case of speaking, remember; it makes no mention of listening. An example: imagine two diametrically opposed people are locked in a room. They are compelled by some supernatural entity to listen (and speak only in order to more accurately hear) until they comprehend one another. At the end of the exercise, would they disagree more or less than when they had entered the room? I think “less.”

Unfortunately, even when our notation of reality aligns, even when our abstractions are shared, we have neither the means nor the motive to comprehensively communicate. Good faith and empathy can take us far indeed but never beyond the long reach of disagreement.

The shape of a story

When I finished Barker, I tried to not write. It didn’t work–see Ss. Now, in the midst of a career pivot, I’m still writing. I’m outlining a novella and as I have a little time spare I thought I’d provide some insight into my process. This is where I’m at right now . . .

First Steps

A writing project hasn’t begun in my eyes until I create a place for it within my “Active Projects” folder. After doing that I create a Scrivener document. That document has two primary sections: Elements and Draft. The Draft section stays empty for a while. The Elements sections gets filled with a document for each of the following:

  • Meta: Key questions and other things I need to consider.
  • Authorial Intent: Musings on what I’m trying to accomplish with this project.
  • Characters: The cast of the story.
  • World: Where it takes place.
  • Events: What happens.
  • Narration: How is it shown and told.

For this project I’m corresponding with a subject matter expert. This means there’s an additional doc with all our dialogue.

Here’s how each of the above docs is filled out.


In this document I record critical information related to the project. Current snapshot:

  • Title: xxxx
  • Length: 20,000 words approx
  • Genre (time): Medium-form; novella
  • Genre (reality): Realism; imagined but possible
  • Genre (style): Drama; solemnity, facing reality as it is.
  • Genre (structure): Mini-plot; inner war of internal antagonism, d(a)emon-facing
  • Genre (content): Status / Worldview / Morality hybrid; see below
  • Controlling idea: Awakening
  • Idea scale: Suffering – Disillusioned – Being – Contented – Awakened
  • Inner conflict: T needs to face reality but he doesn’t want to.
  • Personal conflict: T tells GC his story and is scared of apologising to A
  • Greater conflict: T doesn’t want to be perceived as a bad partner and father.
  • P or C Driven: Character-driven
  • ‘A’ Story: T facing up to his self.
  • ‘B’ Story: T facing up to others.
  • Conventions: ???
  • Obligatory Scenes: ???
  • POV: 1st Person
  • Tense: Present; simple present
  • Soundtrack: Voices, Max Richter
  • Epigram/ph: ???

For a lot of this section, I’ve leaned heavily on the work of Shawn Coyne, Steven Pressfield and Robert McKee.

Authorial Intent

I always have an implicit idea of what I’m trying to accomplish. Often it’s actually a strong sense or deep feeling. However, I tend not to articulate it until I’ve explored the other sections/elements in depth, and even then I prefer to say less than necessary. I’ve found that holding the raison d’être of a project within gives me more energy and power when I attempt to realise it.


In contrast to Barker, where I went a little OTT with the character profiles, I’m doing very little discovery here. There are four notable characters and all I’m recording are their roles and their status (in the Keith Johnstone sense). The latter is either high, low or variable. In this case, I have two high status characters and two variable status characters.


In Ss, I essentially shirked outlining (aside from notebook scribbles). Here, I am returning to stricter form. As you can see below, the story takes place over five days. For each segment, I’ve allocated an average that the events should equate to.

Beyond a daily overview, each day is broken down into eight separate components, each of which will be its own beat and have its own charge. The cumulative total of the beats (49) divided by the approximate length (20,000 words) gives me a word target for the writing of each beat: 408 words. The aim is to create a detailed outline of the events before beginning to draft.


In this section, I lay out how I want the final prose to feel. With that objective in mind, I then choose the most appropriate POV (1st, 2nd or 3rd) and the most appropriate tense. In this case, I’ve elected a 1st person POV and the simple present tense.

With this project, I’ve also taken an additional step. In line with the ideas of moodboards, I’m creating sample styles. The prose will remain the same through it, but it will be supplemented with a different tone depending on the story’s events. For example, a beat with a “+ +” notation will have a different feel than a beat with a “- -” notation.

I think of this in terms of apparel. One person can wear many outfits; prose can remain the same in overall construction but have a different tone.


This seems like a lot of work, and it is. But doing it at the front end of a project means I don’t have to do it at the tail-end. The total amount of work remains the same, and there’s no right or wrong approach. Like most things, the answer to “How do I do X?” begins with “It depends…”

From elements to components

Last week, I compared the elements of stories to the elements of product management. Character, world, events, narration and authorial intent vs business analysis, UI / UX, software engineering / development, project management and interfacing & integrating.

Now, my intention is to further examine the elements and their makeup and document my exploration using a living, breathing artefact. Check it out here.

In other news, I’ve completed the Professional Scrum Master I cert (yay!) and I’ve begun to outline a shiny new novella. The latter will drop at a hopefully-near-but-still-indeterminate point in the future.