My starting point for this adventure was Kenney’s Pirate Pack. If you want to make games and haven’t heard of Kenney, he’s worth checking out. He produces a titanic amount of high-quality art assets and releases them under a CC0 license.

His pirate pack has the essential art I’d need for the core gameplay in a 2D top-down sailing game. This was perfect. I could kitbash the rest of the game with Kenney’s other asset packs without too much drama.

An idea takes shape

Visual inspiration in hand, I spent some time considering the kinds of games I wanted to play. I mostly play games on my iPad. It’s just easier to pick up for a casual or short session. I’ve long wanted a diet strategy game similar to the space trading games I played when I was younger. EV Nova, Endless Sky, and even the OG, Space Trader, on Palm OS.

These games all had a common thread - they provided a sandbox of layered and interwoven systems that let the player write their own story. For EV Nova and Endless Sky, there are a handful of randomly selected storylines you can work through, but they aren’t mandatory. You can just as easily skip them and become a space privateer, or a merchant.

Rather than just build a clone of these classics, I pushed myself to explore further for a keystone mechanic to set my theoretical (at the moment) game apart.

The core game concept emerges

Unlike the classics of the 2D space trading genre, my nautical setting has a distinct difference - time. It takes time to sail between ports. It takes time for a captain’s orders to be carried out, and to see an effect (taking in sail doesn’t immediately stop a ship for instance). The delay presents players with a challenge as they make strategic decisions. It also makes travel between ports more meaningful than just “jumping” instantly between planetary systems.

The more I thought about it, the more interesting it became. An in-game economy is likewise affected by time - it takes time for news to travel between islands for instance. This presents an element of risk for players who rely on news to make trading decisions.

It was an intriguing idea, but I was unsure if this would translate into actual fun. There was only one way to find out - a cheap and dirty prototype. I opened my code editor, created a simple web page, and fired up Claude Code. This prototype is entirely disposable, so code quality is meaningless here. A good prototype for this would be simple - a rectangle to stand in for the ship, two order types (speed and direction), and some buttons to issue orders.

A quick and dirty prototype

With about two hours LLM code sh!tting (technical term of art), I had the answer. The orders-based mechanic has a kernel of fun in it. There was something satisfying about getting the timing right for the ship speed and turning so that it hit the moving target. It was also pretty funny when I got it wrong and overshot - it resulted in a flurry of adjustment orders. Imagining a captain losing their sh!t on deck was a pretty humorous image.

It’s a good prototype

Even with this kernel of fun, the mechanic would need careful tuning and playtesting to get the balance right. Luckily, there’s plenty of parameters that can be tweaked - order timing, order effect magnitude (the turn order is currently fixed at 30 degrees for instance), and the influence of the sailing physics can all be twiddled. The potential is there for a great game mechanic for a casual game though.
If you want, you can try the prototype here. Fair warning - it only works on a larger screen such as a tablet or desktop. It’s also rather janky and a bit gross. I did create it entirely with an LLM in 2 hours after all.

My glorious prototype

Where do we go from here?

The Space Trader genre of 2D game provides a rich field of ideas for game mechanics. With the core concept of “time as a first-class antagonist”, these ideas take on a more unique appearance.

The orders mechanic can be refined further - different orders taking different times to execute (bringing in sail taking longer than turning the ship’s wheel for instance). With sailing now being more involved and meaningful, combat could be explored - how might the mechanic work to make aiming and firing cannons fun, while still having to direct the ship in battle?

We haven’t even begun to dig into ideas such as diegetic maps/navigation, trading, an in-game time cycle, ports, missions, reputation, skills, crew and resource management, and emergent systems such as weather or sea monsters. There’s clearly plenty to explore in this space, if I get the time.

Concluding thoughts

I would be remiss if I didn’t mention that my inspiration/confirmation for time as a mechanic was in no small part due to Sam Sorenson’s novel wargame Cataphract. In it, players issue orders via a discord channel, and the wargame plays out in near real time. The limited information and time constraint produces a game that described as complete chaos and brilliant by its players. It was from this that I drew my own time constraint inspiration.

I’ve got at least one more disposable prototype to create. In my current prototype, the turn orders are relative to the ship’s bearing. A change to make the orders absolute, based on an 8-point compass rose might make things feel more “nautical” - the captain plots a path on the map, and issues a bearing to turn to.

For a long time my mental model for success/failure has been one that resembles losing to Pressfield’s Resistance. However, failure doesn’t typically resemble a singular event much less a war to be fought daily. We don’t fail because we didn’t defeat the wolves of resistance on some specific and pinpointable day. Such thinking results in the root causes going unexamined, and thus the resistance persists.

In all energy exchanges, if no energy enters or leaves an isolated system, the entropy of that system increases.
Energy continuously flows from being concentrated to becoming dispersed, spread out, wasted and useless.
– Muse, 2nd Law: Unsustainable

A more useful conceptualization is to think of our goals as a system, or a machine. Like any system, these goal systems are subject to the 2nd law of thermodynamics. Without the constant addition of energy, entropy will increase until the system is at a standstill. (In case you skipped physics, entropy is your coffee going cold as the drink reaches an equilibrium with its environment, or your room getting progressively messier).
Entropy in our goals and projects comes from a variety of sources (much like it does in the real world). It shows up as underestimation in planning, beliefs that hold us back, becoming sidetracked by trivialities, or just life shoveling too many things onto our plate.

This change in concept removes failure as a binary personal flaw (win or lose against “resistance”). Instead, it frames progressing towards our goals as something that is allowed to wax and wane with life’s challenges. The sources of entropy in our system concept stem from things that we all struggle with at times. Framing it in this way enables us to examine these struggles with compassion while making progress (however slow) on our goals and dreams.
The only real failure is letting the system come to a halt and then abandoning it when we still wish for the success we started out to achieve. As long as we are pushing energy into the system, as long as we still dream of achieving what we set out to, and are still trying to get there, we have not failed.

Sources of goal related entropy

There are three common sources of entropy sapping energy from our personal endeavours. False obstacles overcomplicate our plans, while our inherent optimism bias often results in over-estimating how much we can achieve in a given time. Finally, we all fall prey to the trap of trivial distractions, aka bike-shedding.

False obstacles

Our core beliefs are a powerful thing - they are the machinery that our decision-making runs on. They subtly influence our thinking, and can end a desired goal or dream before we even get started. One of the more common effects of these can be false obstacles. They take the form of a laundry list of seemingly intractable prerequisite tasks that we think we must do to achieve the goal.

If we examine these prerequisites closely, we often find that they are ultimately not realistic, or that there is another way around them. In short, they are excuses in sheep’s clothing. The phrase “I can’t do ____ until/unless/because ____” is a good sign that we need to look closer. These false obstacles sap energy and drain our momentum by making the goal seem further and further away.

While they often appear to be the only way to achieve the goal, in reality there’s always another path that can be taken. Consider overseas travel. Most people would get stuck on what to pack, or a need to plan the trip out in minute detail. These are all false obstacles. The only hard requirement for overseas travel is a valid passport, everything else is up for debate.
My brother once travelled France and the UK with a hydration pack (minus the bladder) as his only piece of luggage. The travel writer Rolf Potts travelled for 6 weeks without any baggage as part of his “No Baggage Challenge”.
He also wrote “Vagabonding”, a solid guide to travelling in the absence of trust fund levels of wealth. Communities like Couch Surfing make it even easier now. Personally, during my last trip, I stopped planning in any great detail beyond making sure I had a bed when I landed.

The planning fallacy

The psychologists Daniel Kahneman and Amos Tversky first described the planning fallacy in 1979. It’s one of the most pervasive effects in human history - generalising equally well across cultures, and task sizes whether it’s doing our chores or planning a multi-million dollar infrastructure project. For our personal projects and goals, it explains why we cannot seem to hit a target deadline to save our lives.
The fallacy is the result of an optimism bias - we are realistic about the time it’s taken for us to complete a task in the past, but we are optimistic about the time required to complete a similar task in the future.
In not learning from our own past experiences, we don’t account for the inevitable delays, interdependent tasks, unforeseen obstacles, and accidental stupidity that occur when trying to do anything.

Parkinson’s law of triviality

It’d be great if, once you avoided the false obstacles and chronic underestimation, you were on the easy path to goal nirvana. However, this is when the third horseman raises its ugly head - the law of triviality.

The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved.
– C. Northcote Parkinson

It’s the tendency we all have to take the path of least resistance when presented with multiple options. This happens even if the easy path isn’t overly consequential to the big hard thing we’re trying to achieve.
For software engineers, it’s known as yak shaving - a stupid, fiddly little task that bears no obvious relationship to your goal, but that is connected by a pointlessly long chain of causal steps.

For a software engineer, it looks like this:

1. They want to write more and decide to create a blog
2. So they research the best options for static site generators
3. Then they build a custom theme
4. Then they shave the rest of the yak by wasting more time deciding on hosting
5. Finally, they launch a blog with a single post (“how I built this site”), and never write again.

This is evidently an insane course of action - our notional software developer should instead have opened a text editor and started typing. But this kind of behaviour is common to us all. How many of us have sat down to Do The Thing, and ended up reading our emails, browsing reddit (“research”), or some other easy and inconsequential activity.

Two very simple rules:
A. You don’t have to write.
B. You can’t do anything else
The rest comes of itself.
– Raymond Chandler

The titan of detective fiction, Raymond Chandler, was onto something with his two rules for writing. By removing the option to shave yaks, we can either do the hard thing, or do nothing. Either outcome is preferable to wasting time on inconsequential activities that make us feel like we’re working on our goals (but are in reality standing still).

Powering the system

To help overcome these three horsemen of goal entropy, we have a few tools. It’d be easy to simply say “do the work”, but that is both obvious and unhelpful. Instead, we need some tools to help define the space and scope of work we need to do.

We’ve often heard the phrase “start small”. This, for me, does not fully answer what I’m supposed to do with all the cool ideas that spring forth when I start out on a project. Instead, I prefer to start with a minimum essential core of a goal. I start a new project with a blank note, and I dump every cool idea and thought I can into it. Once the brain-dump is complete, I can sift through the result to find the minimum lovable core of the idea. We must be ruthless in this stage - each additional element means more time required, and increases the likelihood of entropy overtaking us.

This essential core is what we start with. The remaining good ideas you’ve had? They can still be done, but only after you finish the first and most essential version of the project.

A good example of this is in learning. I learn best by working on a project of some kind. If I were to learn iOS development, I might start by dreaming up a really cool app. Perhaps I decide to build a tool to help myself plan events with friends. I might have a sign up, log in, the ability to publish an event to the web to share, and more in my brainstorming file.

The essential core of the app is more barebones - local first (using SwiftData), composed of 3 basic screens (create event, list events, view event), and built with whatever the default styling is. There’s no authentication, no complex data storage, no networking, no animations. These can be added later. I don’t even launch it in the App Store - it lives in the simulator or in TestFlight at most.

The second thing we can do is spend some time thinking of ways we can make working on our goal simpler, easier, and more fun to do. The more fun the better. We want to want working on it.

A good way to start making your goal simpler and easier is to systematise it - you are looking for small actionable steps that can be done continuously. For my example of learning iOS development, this might look like “After clocking out, spend 30 minutes working on my event planner project”. I work from home in the afternoons, and my day job is software development, so this fits neatly into my existing processes. I’m already sitting in front of my computer, and I’m already in the mindset for programming. It’s simple, easy, time boxed, and something I can do 5 days a week without much change.

Making things fun doesn’t need to be complicated. Grab some graph paper (or make some with a ruler), and create a rewards chart for your goal. Like earning that free 10th coffee from your local cafe, you can check off your progress. When you hit 10 successfully completed items, take yourself out for breakfast, buy a book you’ve been thinking about, or just have a bar of chocolate. Whatever the reward is, it should be something to look forward.

To account for the waxing and waning of life’s unpredictable nature, we can also make a list of the tasks/chores/other goals that we’re going to skip and sacrifice and do halfassed in pursuit of our goal. Making the decision on this load-shedding before life hits us with a bat is vital - you don’t want to be making this choice while in a time crunch and stressed

I experienced a great example of this just last week - my kitchen had gotten out of hand. I could have bludgeoned myself over my inability to keep things clean. Instead, I followed the plan. By emptying the dishwasher and stacking the clean stuff neatly on the island counter, and reloading the dishwasher I was able to tidy up the kitchen sufficiently to feel better. It wasn’t perfect - my cups and bowls were not put away. But having a neat stack of clean dishes in the open is head and shoulders better than having a landslide of dirty dishes and a dishwasher screaming to be unloaded.

Momentum isn’t just physical, though. It’s mental, and for me it’s also emotional. I gain so much energy from staring at a bunch of colored-in checkboxes on the left side of a list, that I’ve been known to add things I’ve already done to a list, just to have more checkboxes that are dark than are empty. That sense of forward progress keeps me enthusiastically plugging away at rudimentary, monotonous tasks as well as huge projects that seem like they might never end
– Adam Savage, on his use of lists and checkboxes

Finally, we can build up our motivation by tracking momentum. Adam Savage, in an article for Wired on his use of lists and checkboxes, relates how using a visual checkbox system helps him build mental momentum to keep going on a project. Seeing the completed work stack up on the page is a powerful antidote to the three horsemen of entropy. Using a pen and paper enables this by default, and most to-do apps have an option to keep completed tasks visible.

Concluding thoughts

In changing our view of our goals from a binary win/lose to being a system, we gain a fresh perspective. Failure is no longer a binary personal flaw, but a far distant possibility that only happens if we abandon the goal. As long as we keep adding energy to our goal systems, they stay alive and progress.

One of the most useful elements of this change in perspective is that failure is not final. The system can always be restarted, and there’s still time for you to succeed and achieve the thing you set out towards. The opportunity needs only your effort (in whatever capacity you can give). It’s still waiting for you, no matter what you are pursuing.

There’s never a better time to re-energise whatever your goals are than right now. Figure out what the essential core is, make a load-shedding list, make it fun, track your momentum, and get after them.

Will Turner: “How can we sail to an island that nobody can find with a compass that doesn’t work?”
Mr. Gibbs: “Aye, the compass doesn’t point North. But we’re not trying to find North, are we?”

It got me thinking about the history of sailing and navigation. You see, up until 1730, when John Harrison completed his chronometer, sailors had no way to accurately measure longitude (one’s position on the east/west axis of the globe).
This was no small achievement by Harrison - it took him 4 attempts and most of his life to produce a chronometer that could accurately keep time onboard a ship. The cost of setting sail without one was not to be underestimated - in 1707 the British Navy lost 4 warships (and between 1,400 and 2,000 lives) off the Isles of Scilly because the fleet was unable to accurately calculate their position in stormy seas.

As I was reading about this naval disaster, another question occurred to me - in the face of such an extreme unknown, how did these intrepid sailors set off and manage to arrive at their destination at all?
And is there something in their methods for navigating the unknown that we could learn from, to live up to our values and work towards our goals? Or as Mr Gibbs put it, can we find a compass that doesn’t point north for our own lives in the annals of sailing history?

Medieval navigation before charts

The answer, as it turns out, is a fascinating piece of nautical history. The sailors of classical antiquity navigating in the Mediterranean Sea and beyond would use handwritten notebooks known as “portolani” - port books - that contained sailing directions built around landmarks such as ports, coastal features, and the distance between each one to the next.

In one you could expect to find:

• detailed physical descriptions of shorelines, harbors, islands, and channels,
• notes about tides, landmarks, reefs, shoals and difficult port entries,
• instructions on how to use navigational instruments to determine position and plot routes,
• calendars, astronomical tables, mathematical tables and calculation rules (notably the rule of marteloio),
• lists of customs regulations at different ports,
• medical recipes, and actual recipes,
• instructions on ship repair,
• illustrations of ports and coastlines as seen from seaward,
• and more. Whatever the navigator thought might be needed to bring the ship to port safely went into their port book.

To compensate for the lack of a longitude measurement, sailors would use the crude system of dead reckoning - using a piece of driftwood and a rope, they’d estimate their speed. Coupled with an hourglass, they could calculate roughly how far they’d travelled on a given heading, thus placing themselves on a map.
The large amount of extra details found in the surviving examples of portolani is telling. Dead reckoning alone wasn’t enough - navigators need more observations to confirm their position, essentially acting as an error correction mechanism.

It’s worth noting that these books were almost always written for personal use. The majority were passed down through families. The few commercially available port books were tightly controlled by guilds and merchant organisations - they were worth their weight in gold.
In spite of the rough level of accuracy afforded by these books, they were enough to build empires - or destroy them. One prominent example of the latter was the breaking of a century-long Portuguese monopoly on the East Indies by the publication of Reysgheschrift by Dutch sailor Jan Huygen van Linschoten in 1575. This single port book enabled the Dutch and English to compete in the spice trade, previously a closely guarded secret of the Portuguese.

Personal port books

Medieval sailors would use their port books to increase the accuracy of their dead reckoning calculations. Better estimates of position meant they were more likely to arrive at their destination intact.
We can use the idea of these port books to help us avoid succumbing to the museum of the almost. By keeping one, we too can adjust the dead reckoning of our own fallible memory to better keep us on track to reach our goals.

Avoiding the museum of the almost

The museum of the almost is the collection of started but never finished projects, goals, and ideas that we all accumulate in life. It’s the half built ruins of our dreams, littering the out of sight places of our homes. Reminders that we almost finished a project, almost achieved a goal, almost lived up to our values.

We shape our buildings and afterwards our buildings shape us.
– Winston Churchill

This is far from ideal. We should be building metaphorical cathedrals, not collections of rubble. Churchill’s quote may sound familiar - a paraphrase is often attributed to Marshall McLuhan – “we shape our tools, and afterwards our tools shape us”. the tools and environments we shape for ourselves have a pervasive and constant effect on the course of our lives.
Whether you are deliberate about them or not, every decision shapes the course of your life. If we are to build our cathedrals, we will need to be intentional about building ourselves a set of tools and a practice for using them. Like Jack Sparrow’s compass, they help us set a dependable direction to achieve what we set out to do (with a little luck).

Why keeping a personal port book helps

The truly worthwhile goals in life are rarely easily achievable (for our individual circumstances). Maybe you’ve set out to keep to a personally defined “rule of life”. Maybe you’re starting a business so you can be more in control of the creative work you live for. No matter what you dream of doing, there’s not a “for dummies” guide that is perfectly tailored to your situation, skills, and circumstance. Even if there were, the seas of life are out of our control, and never do they calm to the point where we have no problems facing us.

Luckily, we don’t need to know the entire course from A to Z in order to navigate towards it. Actions taken need not be perfect, but they do need to be guided by our prior efforts. Our memory is limited, fallible, and prone to errors and omissions that make relying solely upon it less than ideal.

It is really true what philosophy tells us, that life must be understood backwards. But with this, one forgets the second proposition, that it must be lived forwards.
– Søren Kierkegaard

The solution is to leverage tools - in this case, your own personal port book - to pick up where your memory falls short. Recording a log of your observations as you progress through life extends your working memory over a distance of days, weeks, and months, instead of just minutes. These observations, thoughts, and ideas can be reviewed, and reshaped to help guide your present actions. It becomes a tool that allows you to, as Kierkegaard put it, understand your life backwards while living it forwards.
In doing so, we become like those medieval sailors - adjusting their dead reckoning with observations so as to set a more accurate course. Our own observations, kept in a port book for ourselves, become a similar error correcting device for our lives.

How to create your own

If I’ve convinced you of the value of keeping such a book, you might now be wondering “what do I actually put in one?”.
The question of what goes in your port book is deeply personal. After all, it’s there to serve you. No one else will read it, it doesn’t have to become some kind of performance art. It can be messy, with false starts, dead ends, and genuinely enlightening entries.
A simple journalling practice is a great place to start. There’s no need to limit yourself to just that when the port book can be much more to you. Here’s a list of ideas for your inspiration -

• For reflection - a weekly review, your own personal framework, values you hold dear, life lessons, shower thoughts, and ideas that have stuck in your head
• For planning - to-do lists (using bullet journalling, dash/plus, or something entirely different), project planning, project task boards, and bucket lists
• For memory - poems, quotes, theatre tickets (and your thoughts on the experience), polaroids of loved ones & mortal enemies
• For expression - sketch-notes, sketches, badly drawn maps of real places, perfectly drawn maps of fictional places, deliberately misheard lyrics
• For your future self - Anything else you want to keep for your future self to remember - the highlights, lowlights, and sidelights of your life can all find a place in your port book.

Start with the easiest option

So far, I’ve refrained from talking about the specific mechanics of keeping a port book for yourself. It’s the question of our age - do I use an app for this, pen and paper, or something in between. The answer is fairly simple but not universally definitive.

Use what’s the easiest and most accessible for you and your goals..

If either option is going to be a chore to use for you, it’s the wrong one. You should look forward to using your port book, if the form it takes is a hassle, it defeats the point.
If you’re still stuck for choice, here are some of the pros and cons for each solution:

• Pen and paper
  • Pros - tactile, doesn’t need charging, private, offline, can’t be hacked, easy to add inserts such as photos or tickets, easy to stumble across old entries
  • Cons - Can be hard to carry with you when you want it near, cannot be easily backed up/duplicated, less accessible, can feel messy without structure
• Note taking app
  • Pros - easy to have on you at all times (via your phone), you probably already have one, easy to add pure digital content such as video or audio, can be easily backed up
  • Cons - can be stolen by a wider array of villains, easy to lose entries without structure, low discoverability of old entries, hard to add physical inserts such as polaroids or concert tickets.

Personally, I use a hybrid solution - I have a specially created note for temporarily holding thoughts for transfer to my port book. I try to keep things mostly analog, but this is a personal preference. I enjoy writing with pen and paper - it feels like an extension of my mind in a way that a digital app has yet to replicate. I also find great value in stumbling across old entries as I flip through to find something.

At the end of the day, there’s nothing wrong with either option. You can also try both, or transition from one to the other at a later stage - nothing is ever locked in. I actually started with an app and transitioned to an A5 notebook later.

Concluding thoughts

This post has been more theory than practice. That’s by design - there’s never any one framework that works for everyone. Some people find bullet journalling to work for them. Others might use something a little more idiosyncratic. I use a mix of bullet journalling, weekly review (with a personal framework), and semi-structured entries.

The value is not found in the specific framework, it’s in the continued use of it as a tool to help you along your path in life. Humans are storytelling creatures - we’re not just “bullet journaling”, we’re navigating the unknown seas of life. It sounds more exciting, dramatic, and romantic. We’re more likely to keep at it, and see a benefit if there’s a story involved.

It’s not the large decisions that shape the course of our lives. It’s the small choices we make on a daily basis. Crafting a tool such as a port book helps us guide those choices by extending our working memory, and keeping us accountable to our values, goals, and ideals. With the world drowning in ambiguity right now, there’s never been a better time to start one. Like the sailors of old, we can chart our own course through history by building a practice for observing and adjusting our course.

In my free time, I play around with writing fiction. It’s a lot like gardening - I collect interesting ideas, come up with unique worlds, and plots. Thus far, it’s mostly been a vehicle for fuelling my imagination rather than anything that produces a finished draft. It’s been on my list to actually sit down and write out a short story with some of my world building.
To that end, and in prescient fashion, YouTube recently recommended me a clip of an interview with Dan Harmon (creator of Community). In it, his argument is simple - instead of trying to be a good writer, prove you are a bad writer.

When we learn any new skill we are prone to suffering from the gap between our beginner’s skill level and the level we wish to perform at. If we aren’t intentional about managing it, this friction can stop our learning entirely. The only way to make progress is to make bad art…so that we learn how to make good art. Given time, practice, and feedback, we will eventually close this gap.

“The only thing that’s going to make you get better is practicing and the only thing you’re going to be able to write right now is something worse than what you think you should be writing.”.
– Dan Harmon

In the meantime, we can use all the help we can get when practicing. In the case of writing fiction, we must confront the tyranny of a blank page and write (something I struggle with when thinking about writing fiction). This gap can feel like a chasm sometimes - how do we go from our disconnected ideas for setting, character, and plot to something that reads coherently?

What we could use is some training wheels - something to help us get started so we can develop our sense of story to the point where we can take the training wheels off. To borrow from the academic analyses of story, we need a plot structure to hang our ideas off while we learn how to create the elements of a good story. One writer who mastered the use of plot structure was Lester Dent, a master of the golden age of pulp fiction.

Enter Lester Dent

Lester Dent made his living as a full time writer in the 1930’s and 40’s. That alone takes skill, but Dent was exceptionally good at it. He wrote 159 novels and many more short stories in just 16 years. He also wrote the content for 138 issues of Top Notch Magazine by himself (at a rate of 2 issues a month). At one point he had sold an impressive 7 million words in just 5 years (for an average price per word of 1.5 cents). His prodigious output allowed him to indulge in his hobbies - sailing, exploring, flying, amateur radio, and more.

If there was ever a writer to seek advice from on how to practice writing, Dent is a pretty good start. After all, anyone can produce a large quantity of words (especially now with LLMs). It takes some real talent to produce work that sold consistently for over a decade at a high rate of pay.
Today among writers he is most remembered for his “master fiction plot” in which he outlines the plot structure he used to produce his short stories. The author Michael Moorcock used this formula to write much of his Elric sword and sorcery series. It’s this plot structure that we can adapt for our training wheels today.

Refreshing the master fiction plot

The master fiction plot is the structure that Dent used in his writing to achieve his impressive output. However, unlike the more popular structures discussed in literature (such as Freytag’s pyramid, or the 3 act structure), the master fiction plot is a lot more concrete. It’s a formula for a 6000 word short story that, to quote Dent, “tells exactly where to put everything. It shows definitely just what must happen in each successive thousand words.”.

The original formula itself can be found around the internet - the University of Iowa hosts a copy, as do several others. I recommend giving it a read - it’s a fascinating look at a successful working writer’s process.

The concrete nature of Dent’s formula makes it an ideal tool for new writers. Unlike the 3 act structure (for instance), it provides specific placement instructions for dramatic conflict, and plot twists. This kind of instruction will help us maintain story tension, and ensure that the rising action doesn’t…deflate in the middle of our story.

That said, it is a product of the kind of stories that Dent wrote. If we want to use it for a wider range of story types, we’ll need to make a few tweaks to terminology (so as not to corral our thinking), the setup, and the conflict structure for each of the 1500 word parts. These changes will make our new set of writer’s training wheel more versatile and adaptable to new story ideas.

Terminology

The first thing we should keep in mind is a change of terminology - replacing “hero” and “villain” with protagonist, and antagonist respectively. While it might not seem that important, this serves to free our thinking about these roles.
This isn’t just about gender implications - it frees our thinking to new ideas for these roles. An antagonist doesn’t need to be human for instance - an inhospitable environment such as the icy desert of Antarctica can serve as an excellent source of trouble for a protagonist.

Setup

Dent’s formula has four elements for the setup. At least one is required, but the more the better. These elements are:

1. A DIFFERENT MURDER METHOD FOR VILLAIN TO USE - Think poison, garrotting, death by spiders, or getting smashed like a bowl of eggs by a falling piano.
2. A DIFFERENT THING FOR VILLAIN TO BE SEEKING - The gem encrusted falcon statue, the suitcase full of golden light.
3. A DIFFERENT LOCALE - Details to mention that help the locale stand out - a phrase in Egyptian for a story set there for instance
4. A MENACE WHICH IS TO HANG LIKE A CLOUD OVER HERO - the consequences for the hero if they don’t solve the challenge posed by the villain

We’re going to tweak each of these four setup elements in turn. They’re fine in their own right, but if we reach for the core concept behind each one, we can adapt this setup for a wider variety of stories.

A different story essence

The original plot calls for “a different murder method”, which is fine if people get murdered in our stories. However, the core concept of this setup element is also applicable to non-murder stories. It is prompting us to define the story essence - the unique or unusual mystery or challenge that the protagonist faces from the very start. This can be a murder mystery to solve, but it can just as easily be a new take on a heist story. Take “Die Hard” for instance - Hans Gruber and his team pose as terrorists to steal a fortune in bonds (knowing that the police will cut power to the building, thus opening the safe).

It helps to remember that this doesn’t necessarily need to be the work of the antagonist - they can be taking advantage of a situation (such as a natural disaster) to further their goals. The only requirement is that it is directly related to the antagonist pursuing their goals.

A different goal for the antagonist to be pursuing

Dent’s second element is a different thing for the villain to be seeking. Our antagonist can be seeking a Macguffin (gold bars, a ray gun, a bottle of rare gin, etc). But they can just as easily have an intangible goal - saving their old neighbourhood from demolition, exacting revenge, or trying to make it to retirement. Having a believable goal that isn’t “because evil” makes our antagonists and thus our stories more engaging to readers.

A locale that participates in the story

Here, we’re just intensifying Dent’s third element - a different locale. In his song, “Wreck of the Edmund Fitzgerald”, Gordon Lightfoot writes that Lake Superior “never gives up her dead”. This is perfect; it propels the lake from a body of water to being a natural foe, and a danger in itself.
The locale should participate in the story, aiding or hindering the characters in a meaningful way. To do that, we must add plot relevant details about the locale to bring it in on the action. Think about what makes the story locale unique, interesting, or challenging for the characters in it.

Trouble to propel the protagonist forward

The final element from the original formula is a menace which is to hang over the hero like a cloud. The protagonist needs something serious to motivate them into action, driving them into conflict with the antagonist. If this trouble can be caused by the antagonist (deliberately or accidentally), even better. Think “about to be evicted”, “loan shark will break legs in a day if I don’t pay”, or “my boss is going to fire me if I don’t close this deal”.

Story structure

Dent breaks his 6000 word short story into four parts of 1500 words each. The structure he recommends for each one is simple:

1. Shovel grief on the hero
2. Who works to overcome it, making progress that
3. Lands them in an actual physical conflict near the end of each 1500 words
4. Leading to a surprise plot twist near the end of each 1500 part

There’s some extra details for the start and ending parts. In the first 1500 words, you’ll want to introduce the cast as soon as possible, and start in the action as close to the first line as possible. For the last 1500 words, the hero must be neck deep in trouble, and they must resolve the story problem with their own skill and cleverness.

Before digging into our updated structure, a word on story conflict - Dent’s original plot structure calls for a physical conflict near the end of each 1500 word part. The conflict in our stories needn’t be so obvious, unless we’re specifically writing that kind of story. The “conflict” can be emotional, mental, ethical, or moral.
If we’re writing a story about a protagonist with a horrible boss, the conflict can be an argument with said boss (or a lackey). A moral/ethical dilemma makes for great drama. In the film “Horrible Bosses”, a character is forced to choose between illegally firing a disabled employee, or be fired themselves by their heinous boss.

For the purpose of explanation, we’ll keep the same word count target as Dent’s original formula. Bear in mind that it’s the proportions that matter here, so don’t feel forced to make the specific counts - as long as each part is roughly equal in length you should be fine.
However, we can update the foundational structure for each part to reflect our new setup and terminology.

First 1500 words

1. First line, or as close to as possible, introduce the protagonist and the story essence. preferably with the protagonist’s first encounter with it. Hint at the larger mystery or challenge of the story essence.
2. The protagonist pitches in to overcome the challenge facing them
3. Introduce ALL other characters as soon as possible. They should be either causing mischief, or helping to solve it.
4. The protagonist’s efforts land them in a dramatic conflict near the end of these first 1500 words.
5. Near the end of the first quarter, there is a complete surprise twist that changes the protagonist’s perspective/understanding/approach to their troubles.

We want to open in the action and grab the reader’s attention. One effective way to do that is to latch onto their curiosity from the first sentence. Starting as close to the protagonist encountering trouble as possible accomplishes this. Dent also recommends introducing the whole cast as soon as possible, and to bring them into the action. Characters in a short story should either be contributing to the problem, or helping to solve it somehow - there isn’t the word budget to waste.

Second & third 1500 words

1. Shovel more grief on the protagonist
2. The protagonist struggles to overcome the problems
3. Leading to another dramatic conflict
4. And a surprising plot twist to end each 1500 word part

The middle two quarters follow the core structure, making sure that the protagonist is slowly mired deeper in trouble. This is the rising action, building tension and suspense for the reader. It is important to note that it is important to give the reader small moments of decompression from this building tension.

This can come in the form of our protagonist succeeding in making progress in some fashion. If the protagonist’s action land them in a physical conflict, the decompression comes when they win (or escape without being completely kerb stomped, metaphorically speaking).

Doing this not only helps keep the reader engaged (and not so stressed they put the book down), but it also sets up opportunities for our surprise twists. If our protagonist escapes certain death at the hands of a hulking henchman, maybe they overhear the henchman updating their boss…and that they deliberately let the protagonist go.

Final 1500 words

1. Shovel even more grief onto the protagonist. Almost bury them, so that hope of success looks slim - they’re tied to a table with a band saw approaching, the antagonist has launched the missiles, etc
2. The protagonist extracts themselves from this neck deep grief using their own skill, training, or intelligence.
3. Clear up all the remaining mysteries/story questions in a final dramatic conflict in which the protagonist overcomes the story essence.
4. A final twist to end the 1500 words, such that we adjust the reader’s perception a little (or a lot).
5. A punchline to end it, leaving the reader with a warm fuzzy feeling.

The final quarter must figuratively bury the protagonist, making victory seem impossible. In the final dramatic conflict, the protagonist will use their skill and ability to overcome the troubles they’ve struggled with for the entire story. They succeed on their own merits - no god or machine to rush in and rescue them. A final surprise twist to end the story, and we’ve successfully written a coherent story with our new set of writerly training wheels.

A yardstick for progress

When directing our own learning for any new skill, it’s important to seek out or to set criteria to use as a yardstick when measuring the quality of our efforts. In this instance, Dent has helpfully provided a set of criteria to judge how well we’ve written each part of the story.
His criteria ask four simple questions for each part -

1. Does it have suspense and dramatic tension?
2. Does the protagonist’s troubles grow like a black cloud around them?
3. Is the protagonist getting it in the neck with each successive part?
4. Are all the events proceeding logically, linked by cause and effect?

These criteria ask us to examine our story from different angles to make sure we’re ratcheting up the tension as the story progresses. This is known as rising action, and it’s part of what keeps a reader engaged and interested in continuing to read our work.The first three criteria relate to this story tension.
The last question - are all events proceeding logically - is possibly the most important. Events in our stories must proceed not at random, but as a consequence of the preceding event.
The reader can only see what your prose shows them. If an event happens without a preceding cause, it severs the reader’s suspension of disbelief, and we will lose their interest. If, say, we want the antagonist to blindside the protagonist, it would be wise to lay the groundwork for that leading up to the event. That way the reader can make the connection, and we get room for the big reveal.

Concluding thoughts

This is not the only plot structure out there - they are plentiful in literary analysis, from Blake Snyder’s “Save the cat”, to Freytag’s Pyramid. It is, however, a plot structure that is more explicit about what to put where and when in the plot. This makes it an ideal candidate for beginner writers to use as they practice and grow. It has a track record for this - many writers found success with it, both during Dent’s lifetime, and after (we’ve already mentioned Michael Moorcock’s prolific run of Elric novels built with it).

“The best hygiene for beginning writers or intermediate writers is to write a hell of a lot of short stories. If you can write one short story a week—it doesn’t matter what the quality is to start, but at least you’re practicing, and at the end of the year you have 52 short stories, and I defy you to write 52 bad ones. Can’t be done. At the end of 30 weeks or 40 weeks or at the end of the year, all of a sudden a story will come that’s just wonderful.”
– Ray Bradbury

It helps that this structure is specifically for short stories. Rapid iteration and experimentation will help us learn faster, and for a writer of fiction there’s nothing better for that than a short story. As Ray Bradbury says, you can’t write 52 bad short stories. Eventually we’re gonna hit a winner.

Is the master fiction plot, or our additions to it going to produce the world’s greatest story? Probably not. But you don’t race in the Tour de France on a department store bike with training wheels. You do, however, learn to ride on a department store bike with training wheels. That’s what we’re doing here - learning to write.

Practice enough with this plot, and we’re eventually going to outgrow it, feel it chafe at the edges of our ideas. At that point it will have served its purpose, and we will be well on our way to writing great stories. All we need to do now is sit down and write.

The square/cube law was vividly, if a bit grotesquely, summed up by the Scottish scientist J.B.S. Haldane – “You can drop a mouse down a thousand–yard mine shaft; and, on arriving at the bottom, it gets a slight shock and walks away, provided that the ground is fairly soft. A rat is killed, a man is broken, a horse splashes.”

The slightly more scientific definition from Wikipedia is as follows:

“When an object undergoes a proportional increase in size, its new surface area is proportional to the square of the multiplier and its new volume is proportional to the cube of the multiplier.”

The speed at which volume increases with surface area explains why we cannot simply scale something up (beyond a certain point). The increase in volume when doubling a creature’s size brings issues with circulation, weight, and oxygen supply – doubling the size of a human would give them 8 times the weight and only 4 times the muscle and skeleton to support it. They would also be getting half as much oxygen per kilogram to survive.

The effects of this can also be seen in architecture – the largest habitable building in the world for several centuries was the Lincoln Cathedral at 147 meters. Construction was constrained at this limit owing to the need for lower sections of the building to support the entirety of the building above it. It wasn’t until the switch from load-bearing walls to steel frame and curtain wall construction that we could build stable structures higher than that. The more complex processes required to produce materials such as steel, and to model the forces at play are what allowed this advancement. Without this radical shift in project complexity management, we would not be able to manipulate the immense forces of gravitational weight and wind to achieve this.

The Square/Cube law of software complexity

The mammals of Haldane’s vivid mineshaft example, and limits of construction are not the only place we can see this scaling law in action. Software projects are equally subject to its silent and inexorable effects. If anything, it’s worse in a software project simply because the effects are less visible. Any developer who’s ever been asked something along the lines of “why is this taking so long?” has experienced its effects.
Returning to our Wikipedia definition of the square/cube law, we can restate it for software as follows:

“When a software project undergoes a proportional increase in scope, the new feature set surface area is proportional to the square of the multiplier and the new implementation complexity is proportional to the cube of the multiplier.”

Feature set surface area is relatively straight forward – it’s the desired outcome from adding new functionality. Take a PDF export feature for a time tracking app – the end user sees one or two new buttons to export and download a well designed PDF file of their weekly tracked time.
The implementation complexity behind that is a lot more expansive than one might guess. Who hasn’t had a non–technical ideas person say something uninformed like “It’s just a simple feature, how hard could it be?”. Behind our simple PDF export feature is a multitude of implementation details:

1. Designs for the UI changes to be made.
2. Architectural designs for adding the backend support for PDF generation.
3. Setting up an S3 bucket to store generated PDFs for fast retrieval. Ideally with something like Terraform so the infrastructure can be rebuilt in a hurry if needed.
4. At least one new API route must be written, secured, and tested. It’s got to connect to both the database, and the new S3 bucket for PDF storage.
5. The frontend client must be updated to add the new UI elements
6. Somewhere along the line, developer docs should be written to retain the knowledge of this new system for new developers who may need to work on it.
7. QA must test and pass the new feature, and anything they find must be fixed.
8. User facing docs to educate the users on this new feature must be written and disseminated.

What appears to be something small (“export a pdf”) results in the cubic growth of implementation complexity – the scaling law in action.
Software complexity is never about just the code we write. For any non–trivial functionality, there is a vast depth of concerns and problems that must be solved in order to launch a working feature. This is the implementation complexity part of the above software scaling law.

It would be easy to go with the reflexive, yet incorrect takeaway that simpler software is always better. After all, simple pieces of software individually require less – less documentation, less support, less design, etc. However, the point Haldane was making in his essay On being the right size was that there are unique advantages and disadvantages at every size of creature from insects to elephants. The same is true for software. Unlike evolution’s random walk, we have the opportunity to explicitly design where and how complexity is leveraged in the software we build.

“All warm–blooded animals at rest lose the same amount of heat from a unit area of skin, for which purpose they need a food–supply proportional to their surface and not to their weight.…In fact a mouse eats about one quarter its own weight of food every day, which is mainly used in keeping it warm”
– J.B.S. Haldane, On being the right size

Being deliberate about these choices is one of the keys to better software. Needlessly complicating the code wastes developer time and cognitive capacity. Contrived simplicity wastes infrastructure resources and increases time required to setup a deployment correctly. There is no magic solution that works at every size for software, just as there is no magic physiology that works at every size of warm blooded creature.

User authentication at a micro, and macro scale

A useful example of the differences at a macro and micro scale is a basic element of most software – user authentication. For such as conceptually simple feature (“As a user I want to authenticate against my profile so I can access my protected resources”), it can quickly turn into a deep pit of technicalities and complexity, even for small personal projects.

Micro–scale

At the micro–scale is the personal project. On a recent exploration of AdonisJS, I wanted to keep this as simple as possible. Adonis provides built-in utilities for a simple email/password user authentication that builds on session cookies. It’s pretty close to plug and play.
The entire user authentication system was constructed by:

1. Selecting session auth when running the project generator CLI.
2. Creating login/logout/register views so the frontend has something to render.
3. Adding the authentication middleware to the routes I wanted to protect.

Total setup from zero to protected routes for the entire project, including frontend took me half a day, and that was in part due to needing to learn about the framework as I went. I’ve had projects where it’s taken me more time to get Auth0 working in just the frontend for a React app. And then one inevitably winds up having to fiddle around getting serverside auth setup for the Auth0 token verifications.

The total complexity for the drop in email/password authentication is low. The documentation required is low. Email & password authentication is well understood by users, and the AdonisJS auth is a built-in option from the framework’s team.
Any dev who’s used Adonis will be immediately familiar (and their docs are good enough that even devs who aren’t familiar will have few difficulties picking it up). All I need to do to document it is add a few links to the readme – to the relevant Adonis docs, and to the views I created to explain how it currently works.

Macro–scale

Compare that to my initial plan for the nanoblog project – passkey auth with email recovery. Along with my learning goals for the project (explore AdonisJS), I had a limited amount of time. After some brief research into setting up passkey auth, it became apparent that implementing it would become a time sink.

There are no drop in libraries for passkey auth in Adonis. I would have to write my own authentication middleware and session guard. The DB schema is now entirely custom, and significantly more complex per user – instead of just 2 fields (email, password hash) – I now have to contend with 9 fields.
Passkey as a single factor for authentication (to replace passwords) is also relatively new. The documentation requirement for new developers just tripled. Education for users just expanded, and while passkeys are flawless on Apple’s devices, the same cannot be said for Android devices as a whole.

Apart from the value in learning about passkeys, the only benefit here is that the markup for the frontend’s views got slightly simpler. Since the goal of the project was not specific to passkeys, I opted to use the simpler email/password option.

Concluding thoughts

Software at every scale brings different advantages. Understanding how to identify when we are reaching the limits of our current approach is vital to building and maintaining complex software.
Martin Fowler has a solid observation on teams that succeeded with micro–service architecture – they were the ones that started with a monolith, and only moved to micro–services when the need became apparent.
This gives us a good rule of thumb for complexity management – the team that succeeds is the one that starts with simple architecture, and only evolves it as the need to manage increasing complexity of requirements becomes apparent.

Warning signs

There are two good warning signs to watch out for when working on a project. Both are symptoms of poor management of the effects of the scaling law.
The first is a steadily decreasing rate at which new features can be added or bugs fixed in the project. The root cause for this is typically due to the project’s code complexity beginning to saturate an individual developer’s cognitive capacity. This can be due to poor code quality (duplicated and poorly organised code), or having outgrown the original architectural pattern. Either way, it’s a sign that the process for managing complexity must shift.
The second sign is an increase in the time required to onboard a new developer to the project. Like the first sign, this can be due to poor code quality, poor documentation, or other poor decision making. It can also be due to the system having grown large enough that it cannot be reasoned about as a whole anymore. Regardless, at this point it’s time to consider new approaches to meet the effects of the scaling law at play in the project.

Learn from others

“By reading, you learn through others’ experiences, generally, a better way to do business”
– Jim Mattis

If we are to understand and manage the relationship between feature functionality, and the volume of work required to implement it, we cannot simply sit back and hope for the best. As Jim Mattis put it we must learn from others experiences, both their successes, but more importantly their failures. In the absence of studying other people’s projects, our only option is to unknowingly commit the same mistakes ourselves.
It is incumbent upon us to know our craft and our industry – study and experiment with new ideas and old. Having both knowledge of software engineering, and of the business domain we work in allows us to create solutions that both properly manage the effects of the scaling law and achieve the results for which we are paid.

Further reading

• Ousterhout, J. K. (2021). A philosophy of software design (2nd ed.). Yaknyam Press.
• Benner, T. (2023). Naming Things. Leanpub.com; Leanpub. https://leanpub.com/naming-things
  • Better naming of things in software development is an easy win to help manage cognitive load for a project.
• Anything written by Martin Fowler on software architectures, in particular:
  • Conway’s law
  • Monolith first

“Do you think it’s better to specialise or keep getting better at being a generalist? I know AI will put the pressure on generalists first but it seems survival in this industry requires being a generalist these days.”

I was recently asked an interesting question regarding AI and software development - is it better to specialise, or become a better generalist?
The short answer is neither – the frame around the question is too specific to be useful as a guide. Pause for a second and ask what skills are needed to “specialise”? What skills are needed to become a “better generalist”?

Once we peel away the details of specific techniques and tools, the core skills required for either approach are the same. We need critical thinking, creativity, curiosity, and an openness to learn and experiment with new ideas. No field is static, and even “specialists” such as doctors and accountants have minimum continuing education requirements to stay current. Those uncurious souls who stop learning are dead from the neck up, and nothing will help them.

Lessons from history

The specifics of what we do are not as important as our ability to learn and create unique solutions to problems. Humanity has gone through many technological revolutions before, and has been fine after an adjustment period. The adjustment period for integrating new technology into the social fabric has been steadily decreasing from the century long first Industrial Revolution, to a few decades for microprocessors, to a few years for blockchain and AI.

This is not just optimism - it’s borne out in the history of the oldest surviving companies. Stora, a Swedish paper and chemical company, first began as a copper mine in 1280. They survived for the last 737 years not because they were generalists, or specialists. As a company, they’ve done many different things to survive and thrive over the centuries. It has survived multiple wars, political instability, and several technological revolutions (including the Industrial Revolution).

Stora is not alone in this - there are many other multi-centenarian companies such as Nokia (started by making sewing machines), Sumitomo (copper and silver mining), and Mitsui (started as a miso store and pawn shop). Each of these companies have seen upheaval, war, and tectonic changes in their worlds, and survived not because they were generalists or specialists, but because they could adapt and grow into areas previously outside their core skillsets.

Thriving in interesting times

These companies and the others like them owe their survival to more than just luck. Their history describes something that is more than just specialist vs generalist. Each of these companies was a major player in their field. Stora supplied two thirds of Sweden’s copper at one point. Nokia dominated the mobile phone market for a time. It is clear that they built and maintained specialist knowledge as a prerequisite for survival.
However, that does not fully explain their longevity. They also share a common set of characteristics that we as individuals can take inspiration from.

Most importantly, these companies cultivated an ability to adapt themselves to the changes in the world around them. To do this, they are tolerant of new ideas, orienting themselves towards learning and experimenting with fields outside their current core competencies.
Their ability to change, to move away from the core product that gave them their initial success is one of the most powerful examples we can follow.

They are able to move into new industries, and new areas because each of these companies from the entry level worker to the leadership team understand something powerful. They understand that the company’s identity is not defined by what they sell. It’s defined by the people who make up the company.

It’s this people-first approach that made Southwest Airlines great in their early years. It’s what enabled the American manufacturer, Barry-Wehmiller, to survive the multi-year long economic effects of covid without laying off any staff at all.

Kodak - a failure of identity

Defining themselves by their product line is what killed Kodak - they invented the digital camera, but could not see beyond their core product, photographic film. Their true identity as a company was not “we sell film for cameras”. It was in the “Kodak moment” - they were the company that put the power to preserve our fondest memories in our hands. They captured our birthdays, our graduation, they were there when we travelled for the first time and when we got married. At their peak, Kodak had a grip on 70% of the US domestic market for photography film.
By forgetting what and who they were, they fell far and fast. Few know the name “Kodak” today and they’re a hollow shell of the titan they were in the 80s and 90s.

Evergreen skills

The historical examples are just one example of how the skills for thriving transcend a specialist/generalist dichotomy - the patterns for thriving can be seen again in the natural world. In Sweden’s Fulufjället National Park there’s a 9,565 year old spruce named Old Tjikko, growing on the mountain side. It has survived by nature of the extreme adaptability of the spruce tree - they can grow new roots from branches, and share the common trait of all plants - that of evolving to conditions in real time. During warmer periods Old Tjikko has stood upright as a tree, while in colder periods it has survived as a bush, using snow as insulation.

Much like Old Tjikko, we can grow the skills necessary to thrive in adversarial climates. The list of core competencies required is short: critical thinking, creativity, curiosity, and an openness to learn and experiment with new ideas.

These skills are not something that we must be born with. We can learn and develop them on our own, if we possess the intrinsic desire and discipline to do so. Make no mistake, it’s not always easy - nothing worth doing ever is. But it is not a chore - the process might be difficult, but if we look for it, we can find happiness in the pursuit. Mastery, autonomy, and the satisfaction of creating things that are uniquely our own are the rewards for seeking out these skills.

Cultivating your skillset

The way we develop these skills is really simple. We must actively engage with our interests and ideas instead of passively consuming the thinking of others. And no, we cannot use an LLM as a shortcut - if we aren’t putting in the effort mentally, we are merely consuming other people’s thinking by an automaton proxy.

A good example of how to engage instead of consume can be found in the realm of video games. In the early 2000s, the second Thief game was published. What followed was a flood of fan created missions using the game, art, fiction, collections of in-game lore and history. The people doing all of this were not just consuming the story of the game. They were forming a new one for themselves.
Anyone who has written a non-trivial piece will know that corralling one’s thoughts takes effort. Researching the in-game lore sparks questions that can only be answered by reading history, or science. It is this process of actively sparking new ideas, new questions to answer, new connections to other areas of interest that represents the best path for actively engaging in something.

Regardless of our interests, there is always an opportunity to create, and think, and tinker with them. We can write (don’t have to publish it), create art (don’t need to share it), record videos (don’t need to play it for others), discuss it on a forum with other enthusiasts, and more. The creation of each of these requires the key element of learning - active thinking and engagement with the ideas being presented. It is the only way to learn (and coincidentally also part of the reason why most people retain more if they write by hand instead of typing). We have to actively participate in our own curiosity and learning if we are to retain anything at all.

Concluding thoughts

The dichotomy between specialist and generalist is the wrong question to be asking in the face of a powerful paradigm shift such as LLMs. What is far more important is asking ourselves how we can turn the changes we face to our advantage. How might we adapt, learn, and grow from them. Unfettered curiosity and experimentation builds a rich and diverse collection of ideas, techniques, and patterns that we can draw on. It is this raw material, unique in nature to each one of us, that enables us to adapt to the world as it changes.

We must dive deep into our interests outside our fields of work. Create, instead of consume - write, draw, learn to throw clay on a potter’s wheel. Whatever it is, do not just passively sit back and absorb the results of other people’s thinking (whether that’s movies, video games, or books). Engage with the things we learn - the act of communicating our ideas to others (even just to a rubber duck) builds that store of memory and knowledge. They become available to us when we least expect it. Write, draw, record a video diary explanation, something, anything.

The creativity, autonomy, and mastery that comes from building a kaleidoscopic body of knowledge are part of what makes life enjoyable. In the face of another technological shift in society, there has never been a better time to become a person with a love of learning and thinking. Our capacity to learn and grow is what matters most.

The right perspective

NASA Director: This could be the worst disaster NASA’s ever experienced.
Gene Kranz: With all due respect, sir, I believe this is gonna be our finest hour.
– Apollo 13 (1995)

This quote from 1995’s Apollo 13 highlights two sides of the same coin. Both of these characters had seen the same situation. One of them started with a lack of confidence in their ability to overcome it. The other started with the position that, in the absence of a confirmed catastrophe, the situation was not only recoverable, but would be the greatest comeback of the agency.

“If we can recognize that change and uncertainty are basic principles, we can greet the future and the transformation we are undergoing with the understanding that we do not know enough to be pessimistic.”
– Hazel Henderson

Even if Apollo 13 had ended in the worst disaster NASA had ever seen, trying to work the problem with that belief would have made things harder, and more stressful. In my experience, starting with such a belief leads to a kind of tunnel vision. The worst-case outcome obscures the actual goal I’m working towards, and in doing so, makes the problem seem harder than it actually is.
Breaking this tunnel vision starts with remembering that the worst has not yet come to pass, and may never come to pass. As the futurist and environmentalist Hazel Henderson put it, “we can greet the future…with the understanding that we do not know enough to be pessimistic.” It is a powerful antidote for our mind’s tendency to assume the worst.

Work the problem

“Let’s work the problem people. Let’s not make things worse by guessing.”
– Gene Kranz, Apollo 13 (1995)

The right perspective is the foundation for your decision making process. Having a dependable process to work a problem to a solution has helped me to overcome the mind’s built in negativity bias. Such a process is what allows us to find the solution we need, and make our mindset a reality.
The ideal process would be useful in both static situations such as software development, and dynamic situations such as handling an uncooperative bureaucrat at the department of main roads.

“You solve one problem… and you solve the next one… and then the next. And If you solve enough problems, you get to come home.”
– Mark Watney, The Martian (2015)

While there are any number of mental models for problem solving, the one I find myself using the most is John Boyd’s OODA loops. It’s been useful in approaching a wide variety of challenges. It functions well on its own, or as a framework to plug more domain specific models into.
The OODA loop is composed of four steps —

1. Observe - Gather data with your 5 senses.
2. Orient - Contextualise the data with your intuition, and knowledge. If it’s not a realtime competition, you can do some research to define your unknowns.
3. Decide - Formulate a course of action by using your observations, knowledge, and intuition.
4. Act - Enact the decision without delay, and start the loop again from the start.

The loop is repeated in a continuous cycle until you either win, lose, or quit. As a process, it allows you to make iterative decisions, atomising the problem until you reach a solution.

Take trying to cook a new recipe for instance. It seemed simple enough, so you skipped doing any mise-en-place (setup before cooking begins). Now you’re juggling several dishes on the stove, and you still need to prep some ingredients. It feels out of control.
Pause, and observe the work in progress. Orient yourself by remembering the recipe, and your past culinary experiences. Make a decision that buys you time (maybe you take something off the heat temporarily). Act, and repeat the loop until you arrive at a passable dish. And next time you know not to skip the mise-en-place.

The original use of this decision-making model was in competitive, dynamic environments such as aerial combat. I’ve found it useful in handling most situations where better decision making is needed. It works equally well in the kitchen, or when diagnosing a failing build pipeline, or when driving in adverse weather.
Sometimes all it takes to get back on track is a reminder that it’s not over yet and work through this loop a few times.

Conclusion

“Success is never final. Failure is never fatal. It’s courage that counts.”
— John Wooden

It takes both mindset and process to drive the best circumstance to overcome the problems in front of us. The right mindset is one of optimism - we rarely see the entire picture, and thus do not have enough information to be pessimistic. Our decision making process should build on that foundation, and work in iterative loops.
Next time you’re facing a chaotic situation, or you feel yourself rushing (and that the solution is slipping from your grasp as a result), take a breath. Remind yourself that it’s not over yet, and keep working the problem with deliberate intent.
In the end, all we have to do is stay in the game. A solution will eventuate.

“It is not incumbent upon you to complete the work, but neither are you at liberty to desist from it.”

It is a good reminder that perfectionism is a character flaw. Something done imperfectly is better than never starting at all. We must not refrain from action due to the fear of failure. Failure is not getting started in the first place, not doing something imperfectly. It bears repeating – the only true failure is not starting at all. The antidote to this failure starts with play - doing things without consideration of how they will be received by others.

“Music as an art form is essentially playful; you say you “play the piano”, you don’t work the piano.”
– Alan Watts

Not everything we do must be work in service of some greater purpose. In her recent book Tiny Experiments, Anne-Laure Le Cunff described it as “the tyranny of purpose”, or the need for our activities to be advancing some grand goal so that we “win at life” by arriving at some destination. Doing something simply for fun, or to learn, without worrying about how the thing will be received by others is the starting point to overcoming true failure.

Overcoming true failure begins with doing things imperfectly, and without preconditions. In their Cult of Done Manifesto, Bre Pettis and Kio Stark lay out a good starting point for overcoming this resistance to action. The manifesto is short, just 13 points. Here are a few of my favourites:

Banish procrastination. If you wait more than a week to get an idea done, abandon it.

I have a queue of half-written blog posts that feels like it has grown, not shrunk. After reading this, I let go and returned them to the ideas pool. I might revisit them, but only under the umbrella of actively working on them. No more aspirational post ideas that never get worked on.

Failure counts as done. So do mistakes.

Failing counts as done, and therefore not a failure at all because at least we tried something. Remember, the only real failure is not starting at all. Afraid? Don’t know where to begin? Start by defining the things you are uncertain about. I have found that the tasks on my to-do list that I avoid and procrastinate on the most are the ones where “done” is ambiguous. When I define the outcome (and occasionally break it down into multiple tasks), I can easily accomplish the thing. The same holds true for more creative projects.

For these blog posts, I define done as 100 words. Concerns such as coherence of thought or quality don’t enter into it. They begin as letters to myself on an idea that’s captured my attention. Not all of these make the leap to published posts, and that’s ok. My only purpose for them was to explore an idea I’m curious about.

If you have an idea and publish it on the internet, that counts as a ghost of done.

Not everything you do needs to be shared with others. Nor does it need to be published in public - just sharing with friends is perfectly acceptable. But telling people about what you’re doing leads to learning, growth, and new perspectives.

Done is the engine of more.

All that is required of us is that we do things imperfectly, and tell people. Completing the thing for some grand purpose is not necessary. What done looks like is up to us to define, and all we need to do is keep doing. We are not at liberty to desist from having fun, from playing, or from exploring. The more we do, the more we have the opportunity to continue doing.

Why it matters

“People judge an experience largely based on how they felt at its peak and at its end, rather than the total sum or average of every moment of the experience.”.
– Laws of UX: Peak-end rule

Customer acquisition is a non-zero cost for most businesses. By not properly considering the user departure experience, the business is both wasting some of this cost, and risking incurring more costs. Worse, it throws away an opportunity for goodwill and referrals. It risks leaving the business with a former user who has nothing good to say, and every reason to bring that up whenever the business is mentioned.

Chargebacks

Returning to my zombie subscription example, a simple renewal notice would have removed the need for me to contact their support (lower customer support bills sounds like a good idea). It would also have almost entirely removed the risk of my submitting a chargeback. If that had happened, they’d have lost the $25 AUD non-refundable dispute fee, and if I’d won, the amount they’d charged me as well. Regardless of whether they win, the dispute would increase their chargeback ratio, thus risking the loss of their ability to process payments at all.

The cost to send a single email with AWS SES is $0.00009. Stripe and other payment processors offer this service as a feature (if you turn it on). The cost benefit analysis is so heavily weighted in favour of being considerate of your users that it’s crazy not to do this. Not spending a fraction of a cent so you can risk paying almost $75 AUD when you lose a chargeback is shortsighted in the extreme.

Goodwill is invaluable

“Goodwill is the only asset that competition cannot undersell or destroy.”
– Marshall Field

Unlike the financial benefits of avoiding a chargeback, the second good reason to have a user friendly off-boarding experience is intangible. Acquiring a customer via the goodwill and referrals of your current and former users is worth exponentially more than acquiring a customer via a cold channel such as an online advert.

If your off-boarding is well designed, former customers are more likely to remember you exist. They are more likely to recommend your service when it would be a good fit for their friends and colleagues. They are also less likely to disseminate negative press about your service. In a few instances, the former customer may return (if their departure was due to their own financial circumstances changing for instance).

What should have happened

The design of UX for anything should start from the basic understanding that humans are imperfect. Something as simple as a renewal notice prior to charging the customer’s card costs almost nothing to send. The return on investment for such a notification is invaluable to a business both in avoiding chargebacks, and in the intangible goodwill it preserves.
The notification needn’t be complex. A simple email with the amount and the expected charge date would have been sufficient. The risks for the business vastly outweigh the amount of money they might have been able to claw out of my bank account.
If the burning of any goodwill you had, and the risk of a chargeback are really worth less than the subscription price you might have been able to hold on to, perhaps your app isn’t valuable enough to justify the cost in the first place.

I had attempted to learn Ruby and Rails late last year. The effort ended in defeat. My interest in Rails has not diminished. However, by working counter to the subconscious learning process I’ve developed over years of technically demanding jobs, I had run out of motivation.

PostcardRSS

After the collapse of my first learning attempt, I paused to reflect. What was different between the high-speed learning I do at work and my attempt to learn via the Odin Project’s coursework? I identified several key attributes that were missing from the false start - Autonomy, creative control, and a meaningful yet achievable challenge. The coursework didn’t connect to what I wanted to do with Rails in a concrete way. Without the ability to explore, the lessons didn’t stick and I lost interest.

Instead of restarting the coursework, I instead spent a few days designing a real project (codenamed PostcardRSS). It’s an RSS to email service that mails a newsletter summary of your feeds each week. This time, my learning efforts have been a success because the project gives me control, and is something that I want to use for myself. I’m almost through with the UI for the app, and in the coming weeks I’ll be implementing the rest of the backend. I know more now about Ruby and Rails than I gained in the Odin Project course, and I’m on track to hit my goal for the year.

If I am to achieve my goals for the year, I must work with my current learning process, not against it. The only logical question to answer is: what exactly is my current process for learning? Having both a failure, and a success in the same goal has afforded me a golden opportunity to figure that out. It became apparent to me that my learning is not a single path to be walked once.
Instead, it is more akin to the growth of an evergreen tree. Vital knowledge and skills are added, outdated knowledge is judiciously pruned, and the tree is always adapting to find new ways to overcome challenges in its environment. In applying this growth oriented metaphor to learning, we can see that it occurs in three interconnected stages.

Spiralling upwards towards competence

The ultimate goal for a student is to build a strong intuition so your work simply flows. My process for achieving this is imitation, integration, and intuition.
These are not necessarily discrete steps to be ticked off on a list. I’ve found that I inevitably spend time moving forwards and backwards through these stages. The difference is that the trend of competence in any given skill moves upwards towards intuition. With each cycle, the subject area I’m studying gets smaller, and the time spent in the first two stages gets shorter. In short, I learn by spiralling upwards as my ability to maintain an unbroken flow increases.

Imitation

Knowing what you do not know is the foundation of all self directed learning

The first step in growing new skills and knowledge always starts with imitation. By repeating the thinking of others we can build up a set of fundamental building blocks for the new skill. This is achieved by following tutorials and coursework. By working through these, we eventually build up a small set of principles, and a knowledge of what we do not yet know (to be used to self direct our learning as we go). This map of everything we don’t yet understand can feel overwhelming, but it is a valuable part of our learning process. Without it, we are unable to properly self direct our learning.

Of all the stages, this map is one of the most valuable things you will create for yourself while learning. Don’t make the classic blunder of dismissing the imitation stage as just for beginners. Your abilities as an abstract cartographer are the foundation of all other learning.

In my second attempt at learning Rails, I began this stage by working through the Rails “Getting Started” guide. This guide provided me the map I needed to be able to explore the problem space effectively by using the API docs and the other guides on the Rails site.

Integration

Interrogate what you learn to internalise the principles behind the specifics

In order to integrate the knowledge we’ve blindly accepted by following tutorials, we must examine and question it. Ask yourself why – why did the author build it this way and not another. What were the problems this method solves? Knowing why a thing is the way it is leads to a deeper understanding of the thing itself. By being curious about what you’ve learned, you gain the ability to self correct, to critique your own work dispassionately and to improve as a result. Tutorials fall away, replaced by reference material and experimentation (with a reasonable degree of success). Part of this process of questioning will often result in you being able to drop older techniques that no longer serve you. Use the map of known unknowns to explore the skill space in depth, always asking why so that you understand the abstract problems each element solves.

As I began to build my own project in Rails, I inevitably wound up with a lot of questions. How do I do X? Why is it done like this? These questions, and the process of research and experimentation to answer them formed the integration stage of my Rails learning. As I progressed, I cycled between integration and imitation until understanding began to emerge.

Intuition

Experts act from experience and accumulated knowledge. Amateurs try to follow a recipe. The mark of learning success is your ability to read the environment and adapt your actions accordingly to meet your goal.

The final stage is intuition. You can now set the grand strategy for your output, and you work without thinking – a flow state of action to get things done. This is not to say you know how to accomplish everything before you start. Rather you know what done looks like, and what the key concerns you need to solve are. The specific techniques are not as important as your ability to define what good looks like for yourself. You can adapt the abstract principles of your learning to overcome any novel problem you may face.

I can’t say I have a fully developed intuition for Ruby and Rails in the same way I do for Javascript. I am seeing flashes of brilliance, instances where I make choices that are supported by testing. It’s always rewarding to see my understanding solidify like that.

Wrapping up

From this experience, I’ve come to realise that both process and environment are important for faster, more concrete learning. A good learning environment is one in which the student has the autonomy to explore, the creative control to express themselves with the fruits of their learning, and challenging enough to be interesting.
On a process level, I’ve found that the cyclic interwoven stages of imitation, integration, and intuition weaves a strong foundation of understanding. The cycle repeats for every part of the problem space you do not yet understand. Knowing that ahead of time not only makes you feel better about being a beginner, but turns the list stuff you don’t know from a discouragement into a guide, and a place to explore.

Overall, I have found a new sense of enjoyment in my learning as a result of explicitly considering how I learn. Like leveraging the habit loop to improve my daily life, knowing the learning process allows me to better target my efforts. Give it a try – everyone deserves to have their curiosity rewarded with the satisfaction of understanding.

This was actually easier than I thought it would be. The process I landed on combines the gamification, the loss aversion cognitive bias, and an awareness practice to help me be chill while driving.

Loss aversion

Loss aversion is a powerful motivator. Humans come with a strong cognitive bias to perceive a situation as worse if it’s framed as a loss instead of a gain. We treat the threat of loss with more urgency than the opportunity for a potential gain, as this presents an evolutionary advantage.

It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.
– Charlie Munger

For my driving improvement, the threat of loss is twofold - first, I lose the game of “keeping calm”, and second, I actually lose the peace I started out with. The idea to frame the motivation for the exercise as loss aversion came from Simon Parrish’s article on avoiding stupidity. In it, he relates a study on amateur vs professional tennis - that a game of amateurs is won not by the points scored by the winner, but by the points lost to the mistakes of the loser. Or put simply, the game is yours to lose.

Gamification

Gamification is the process of adding games or game-like elements to a task, to make it more engaging. It was the latest tech fad circa 2010. One of the success stories of that trend has been the language learning app, Duolingo.
However, it’s not just for tech bros to make their Skinner boxes more entertaining. It’s also a useful way to help you motivate change. All you have to do is find a way to make your task into a game. It doesn’t need to be super complicated - reframing your chores as “quests”, and giving yourself a reward if you get them all done is a classic for a reason.

For my driving practice, I coupled this with loss aversion. Every time I get behind the wheel, I reminded myself that the game was mine to lose. This became a habit pretty quickly, with the car as a trigger to remind me. To keep the win, all I had to do was to not “knife hands and judge” the other drivers when they did something myopically dumb.

This is a good example of a default win state for a game - useful for a task that relies on not doing something in order to be successful. If you’re gamifying your chores, a default lose state (in which you must act in order to win) is usually more useful.

It’s also worth remembering that this is a motivational tool - there’s no need to keep a record of wins and losses unless doing so would help you win more often. For my driving game, I simply use the memory of my worst trip to compare to my current trips to see how far I’ve progressed. The scoring system I use is binary - did I throw knife hands and say something aloud about other drivers? If so, I lose the game. I do score based on legs of the trip - so a round trip to the grocery store has two legs, getting there and getting back.

Awareness practice

The final piece in the puzzle is something I’m terming “awareness practice”. It’s not enough to be able to operate a vehicle without GTA 5’ing other cars, pedestrians, and buildings. You must drive defensively, and that requires awareness of what you’re defending against.

The way I accomplished this was by applying a technique my father mentioned in passing when I was learning to drive. It’s simple - while driving, narrate aloud everything you’re seeing, and everything you’re doing. I do this several times a week. The results can be seen almost immediately - your awareness of other drivers goes up, as does your awareness of how unaware you were. I’ve found it to be like exercising a mental muscle - the benefits accumulate with regular practice. Some examples of these narrations:

• “Car in front is braking, I’m braking to maintain distance”
• “Lights are green, lights are green, intersection cleared”
• “Approaching turn, indicating left, entering turn, exiting turn”
• “Motorcycle on my right” (Useful, since they are easier to lose in a blind spot)

Results

The results after several weeks are pretty good. I average less than one Mushu incident per trip now. My driving is a little less aggressive, and I arrive calmer. The effectiveness of this experiment is due in no small part to my use of multiple tactics. Gamifying my loss aversion, even in a simple win/lose game such as this one has paid off. By giving the problem no place to hide it’s gone away rapidly.

The awareness practice has also helped increase my situational awareness behind the wheel as well. One can only assume this makes my driving safer in general. I certainly feel like I’ve become a safer, more considerate, and less aggressive driver as a result. Overall, the experiment has paid off, with a mental health benefit for me and a lower risk for other road users.

Entire businesses have started out as email only - Craigslist began life as an email list run by a guy named Craig. Today, writers can quickly and easily use Substack or Ghost to publish articles and get paid for them. Services routinely use email to provide asynchronous and non-urgent notifications to their users.

“Email as the interface is a great fit for prototyping and building out a laser-focused product that can easily integrate into people’s everyday usage.”
– Matt Swanson

As an interface for user interaction however, email is often overlooked. With a little design, it is perfect for prototyping services that would otherwise need to launch with yet another app. Consider for a minute - you can reasonably assume that your target users already have an email account. Emails already fit neatly into an existing space in your users’ lives (so your service won’t have the friction of carving out a new space). Best of all, it’s asynchronous, allowing them to deal with it when they please.
Even the extreme simplicity of email is a blessing in disguise - it forces you to focus on the core service. The constraints it imposes encourage creativity, and result in a better product.

The building blocks of email first

There are two elements to consider when building an email based service - the interactions and the triggers. The interactions are the operations the user can perform on the emails they receive. The triggers are how your service initiates an email flow. The problem your service solves will need to understand both in order to compose an effective solution.

Interactions

Unless your service is a newsletter, you likely need something more than just standard content delivery. Emails support 4 basic types of user interactions that you can use to solve user problems, and elicit user action. These interactions are the consumption of content, delivery of attachments, user response via links, and user response via reply.

Consumption of content is the most obvious - user reads the email. This works exceedingly well for newsletters. But it can be useful for other services. For example, the todo list app TeuxDeux will email you a summary of your daily tasks each morning.

Jon Fuller’s Apple Health Report service is a good example of how to build an attachment based interaction. Users email their data export as an attachment. A few minutes later, the service responds with an analysis in an attachment for them to use.

For more complex operations, a service usually needs more sophisticated interactions. There’s two options for this. The first is to build emails with links in order to gather these responses. These can be simple - Jira or Github’s “accept invite” emails, or more complex - review services that let users click on a star rating in the email (with each star being a different link).
The second option is to leverage email replies. CRMs build on this - reply to the email, and it gets added to a support ticket to be addressed shortly. It can be more complex - travel planning apps such as TripIt allow you to forward email confirmations for flights and hotels to see them added to your itinerary automagically.

Triggers

Unless your email service is a newsletter, you’ll likely implement some combination of both scheduled and reactive triggers to connect with users.

Scheduled services are common - an email course, or sales funnel use emails delivered at regular intervals. It can be as simple as a service running on a cron job each day. More complex scheduling can be designed by integrating users’ response (via clicking on a link, or replying) to adjust schedules

Reactive services are those that respond to an external action of some kind. The source of the event can be almost anything, from the basic (an sms, or email), to the exotic (a home automation sensor, or GPS location event)

Reactive triggers operate on the same principle as a standard webhook. However, they can be more transport agnostic. RPC, WebSockets, or even an RS232 serial connection can be used to trigger an email (useful for a home automation with an IoT sensor).

Using low-code tools such as Zapier, you can compose complex flows for prototyping and personal use. Imagine an email service that emails a summary of changes from a shared google doc. Or a daily summary of your calendar. The potential here is limited only by your imagination.

Recap

Email as a user interface is a powerful and often overlooked base for software services. Despite its limitations, it provides a set of flexible tools to support a core service. The interactions extend beyond just reading content - users can reply to your service’s emails, send and receive attachments, and click links to execute actions. Email first services can be reactive, in response to an event, or scheduled (like a weekly newsletter, or daily task summary).

With careful design, and leveraging of low-code tools such as Zapier, we can effectively use email as a platform for prototyping services. Entire businesses have started this way - Craigslist being just one example. With an email user interface, your next service can be built faster, and be more useful to its users than building another app.

This is borne out in the usage data of mobile apps. According to a report by BuildFire ¹, the average mobile device user interacts with just 10 apps each day, and only 30 apps each month. A quarter of downloaded mobile apps are used once and uninstalled. The competition for yet another app is fierce. To make matters worse, the top 10 mobile apps by usage are platforms such as Facebook, Instagram, or TikTok².

The software solutions we create must meet users in the spaces, habits, and apps that they are already familiar with. The more we can build into our users existing spaces, the more likely our solution is to be successful.
The critical question that successful solutions must answer is simple - how can we reduce the inertia of this adoption barrier for our solutions?

Reduce inertia with the MAYA principle

“The adult public’s taste is not necessarily ready to accept the logical solutions to their requirements if the solution implies too vast a departure from what they have been conditioned into accepting as the norm.”
– Raymond Loewy

Raymond Loewy is often referred to as the father of industrial design. His body of work included logos for Exxon, Shell Oil, and BP, as well as the livery for Air Force One, updates to the design of the Coca Cola bottle, and assisting with the interior design of NASA’s Skylab.

He called his approach to design the MAYA principle - Most Advanced Yet Familiar. He set out to design solutions to problems that were both novel, and familiar. The ideal design sits in a sweet spot where it is advanced enough to help and yet familiar enough to be accepted.

There’s a psychological phenomenon underpinning this - the mere exposure effect. This effect explains our tendency to like or dislike something simply because we are familiar with it.

If our solutions to the problems of our users are to be successful, they must grow out of the spaces our users are already familiar with, not apart from them. A successful solution is one that needs fewer adjustments for its users to integrate into their lives. Your onboarding shouldn’t stop at just showing the user how to use the app. Show them how to make using it effortless by integrating with an existing routine.

Start with existing platforms

The most impactful way to apply the MAYA principle to our software solutions is to recognise that not everything needs to be its own app (mobile, desktop, or otherwise). Not every service deserves the space on our devices, or the ongoing cost paid with our attention. The best new app is the one that integrates into the user’s existing digital spaces, instead of trying to build a new space at the cost of their attention and time.

Our digital spaces are the platforms and websites that we regularly visit. A lot of these interactions are habitual - checking your email each morning while riding the train to work, or doom scrolling facebook while waiting for a bus. The reasoning for meeting people in these spaces over trying to carve out a new one is simple. If given the choice between two solutions, we are more likely to choose and stick with the one that fits into our routines better.

By way of example, I’ve been using Safari’s reading list feature for a while. It’s a well designed feature, it delivers on the promised functionality, and it’s easy to use. However, in spite of these well rounded attributes, I struggle with actually returning to read the articles I save to it. The button to access it is hidden inside a drawer. The lack of a permanent visual cue means that more often than not I just forget it exists. My habits, not the app are the problem - I’ve also tried Omnivore with similar results.
A better solution would be one that is both well designed, and that does not need such a large change in usage patterns in order to be successful.

Case study: Australia Post

A good example of how to build an app free service can be found hiding within Australia’s national mail carrier, AusPost.

AusPost’s process for delivery updates, and notifications doesn’t actually need a mobile app. In fact it functions commendably well without one. This is achieved by relying on two technologies that both have decades of reliability built in - SMS, and email. When I get a package sent to a parcel locker, I get an SMS with a code to open the locker when it’s ready. Their delivery updates are sent via email. These are just frequent enough to keep me updated, and they are not interruptions in the same way a push notification is.

To complement this flow, but by no means required for it, is an amazing web app. It loads fast, looks good, and it works almost flawlessly. The web app provides the same level of access across mobile and desktop browsers. It has been well designed from head to toe (which is fantastic, considering AusPost is a government owned corporation).

Moving users from this to a mobile app, with push notifications would be step backwards. SMS delivery has decades of reliability in adverse conditions built into it. It is available to every mobile device with a valid phone number assigned to it. On the other hand, the data connection that a push notification relies on is the first thing to die when cell reception gets bad in Australia. It’s a testament to our mobile carriers that the cell site coverage is as good as it is, given the sheer size of the coverage zones.

Case study: A better reading list app

Let’s return to my failures with the Safari reading list for a second. I already have a process for reading long form content. I use it almost everyday. It’s my email account. Like most people, I’m subscribed to several email newsletters.

An ideal reading list app could function as a browser extension, with an “add to reading list” button (same as Safari’s reading list). It gets configured once, and then it unobtrusively becomes part of the fabric of the browser. As I add items to my reading list, it emails them to me. With tools such as gmail’s “+” aliasing, I can even create an automated workflow for the articles.

Best of all, reading the articles doesn’t require a new habit. I already check my emails regularly. The reading list now exists in a space I already inhabit, with a process and a habit I already have. The inertia for starting, and the friction to regularly use it is reduced almost to zero. After it’s set it up, I would be using it the same as I already do for Safari’s reading list feature. The difference is that I’d actually read the stuff I add to the list. It’s fused to an existing habit, an existing attention spend, and an existing platform (Apple Mail).

There’s another side benefit here too - it archives a copy of the articles. Dead links are no longer a concern. The content is saved to my mailbox and I can print it, export it, or forward it to friends.

Creating a new space

It’s not always possible to integrate into an existing platform or space to solve the problem you’re tackling. Some requirements necessitate a dedicated app - for instance:

1. Complex workflows - The Adobe suite benefits from native apps in order to orchestrate complex work such as rendering video or editing images. While some of these can be accomplished inside platforms such as a browser, it is often a better fit for a native app.
2. First class offline support - Stable persistent storage is not always available to a web app, or platform plugin. If your solution needs offline support, a native app is likely a better option.
3. Hardware integration - The Briar Project messaging app depends on integration with a device’s bluetooth and wifi radios. If your app requires tight integration with hardware APIs, a native app is often the only solution.
4. Security - Banking apps benefit from being able to completely control the environment in which they run to secure user funds.

When a dedicated app is required, there still every reason to connect it to a user’s existing spaces when possible. This helps lower the adoption barrier, and keeps your work in line with the MAYA principle.
A simple example would be offering social logins such as Facebook, or Google. Changing the way in which your app sends notifications is another. Any notification that isn’t time critical should be an email. Not only does this connect to the user’s email spaces, but it also respects and conserves their attention. Save their attention for when it really matters, and let them handle your updates in their own time.

Existing platforms to integrate into

So far, this discussion has touched on two bedrock technologies of the digital world - email and SMS. These are far from the only technologies to consider when looking to integrate into the existing digital spaces of your users.

A large number of platforms, such as Slack, Discord, Facebook, or Google’s Workspaces provide support for plugins. The AI image generator MidJourney ³ is built as a Discord bot. They leverage the years of engineering paid for by the Discord team in order to focus on their core offering.

Another ubiquitous platform is the web browsers we use to access the internet. Browser extensions are now a web standard, making it even easier to support multiple browsers. Instead of building a separate app, we can instead integrate into the fabric of a platform that’s used daily by users.

Recap

The cost paid by users for a software solution is not just financial. Users pay multiple times, first financially, and then with their attention and willpower. Solutions that minimise these second order costs are more likely to be successfully adopted by users.
By applying Raymond Loewy’s Most Advanced Yet Acceptable (MAYA) principle, we define a framework for design decisions. If our solutions are to feel familiar, they must build into and on top of the user’s existing digital habitats. A solution that doesn’t need an app to solve the user’s problem is likely to be more popular than one that requires a shift in habits. AusPost did this with an SMS based delivery notification UX. We can do it by building into the platforms our users already inhabit.
We have a wealth of options for this. Major platforms such as Facebook, Slack, and Discord offer support for plugins or integrated apps. Almost everyone on the internet has access to an email account. The original meta-platform, the humble web browser now offers extensions that allow apps to extend it.
Even when our software requires a dedicated app to solve its target problem, we can still leverage the MAYA principle. Integration with the user’s digital spaces such as email for update notifications are a simple starting point available to almost every app.

Footnotes

“Technology always develops from the primitive, via the complicated, to the simple.”
— Antoine de Saint-Exupéry

This post has come about from several weeks of reflection on tech debt. Specifically, the mistakes we made that resulted in a codebase that was hard to navigate, difficult to update, and ran slowly. There was no single person to blame, and in some part it was due to a remote team with poor communication.

There’s plenty of technical failures that led to this moment. Instead of talking about the specific aspects for the project, I went a level deeper. I was interested in the substrate beneath the surface level technicalities of the project. What could I learn from this so that it does not happen again?

After some research, a common theme emerged. Code quality, typically considered to be a measure of how well a project has managed complexity, is also a reflection of the decision making skills of the developers writing the code. Our habits, and the discipline we exercise determines the results we get in our code. This decision making is vital. We can make better design choices when starting a project to encourage the kinds of results we want to see.

Built with habitual excellence

“It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.”
– Charlie Munger

The first step for better code is to not make the codebase worse. This is true for new projects, and for existing projects. Anything that gets merged into production is never getting “fixed”, regardless of the good intentions of the author. Truly disposable and short lived code is relatively rare, and should be separated from evergreen code with a hard barrier - in a separate repository for instance.

Any change to a system should appear as if it were part of the original design. This means making hard decisions, and choosing the path that will occasionally take longer to complete. To sum it up, “death before hacks”. Successfully achieving this is not an end goal. Rather it is a process built on discipline, and a set of principles for code quality and software architecture that must be consistently adhered to.

Do not heed the siren’s song of a quick hack. It will drown you, and the project if you listen to it. Your standards and principles as a developer are the nautical maps that show you the way. That idea for a quick hack “to fix later”? That’s the beam from a lighthouse cutting through a storm to warn you of a submerged hazard. Sail around it, or your vessel will run aground. The very best captains follow their charts, and trust the disciplined running of their ships to guide them - they know that dangerous shortcuts will only cut them short.

The currency of discipline is willpower

“In the absence of willpower the most complete collection of virtues and talents is wholly worthless.”
– Aleister Crowley

The price for consistently applying principles and discipline to your project is paid with willpower. Willpower is both a skill that can be learned, and a muscle to be exercised. Like a muscle, your willpower can fatigue, and break down without a rest. Without practice, the best intentions to write a maintainable project are worthless.

If you intend to write better code, maximising the amount of willpower for decisions that matter is a good place to start. The good news is that there’s a way to gain an easy amount of leverage to achieve this - by making use of the power of habit.

Habits are the original timesaving life hack - literally. Put simply, they are unthinking, skilled routines - the blueprints for the things we do repeatedly. They are present in some form in all mammals, and for good reason - they allow us to pay attention to the things that matter for staying alive.

They are also rather simple. Habits run on a loop of reinforcement - a cue that triggers a routine that results in a reward of some kind.
The more we repeat a routine like this, the stronger the habit becomes. It’s hard to put a stop to a habit, but by changing any one part of the loop, we can easily morph the habit into something else, if desired.

When it comes to helping us with disciplined coding and willpower maximisation, our habits are essentially a free throw. Because they run almost entirely autonomously, they only impact our willpower reserves when we’re establishing them, or fighting to change them. Once embedded, we run through the habit routine without ever spending conscious thought.

It is simple to learn what well structured code and projects looks like. It is a lot harder to maintain the discipline to consistently write them. When you start any new routine, it always takes some conscious effort to complete. The more you do it, the easier and more automatic it becomes - excellence in any field is a habit.

Consider the initial setup phase of a greenfield project. If you are leveraging habit and willpower maximisation, you will already have a process. Instead of wasting time thinking about how to structure a ReactJS app, you’ll grab the template you keep updated for these situations. Instead of wondering which architectural flavour of the month to use for the app, you already have one planned and roughed out in the template.

On the flip side, if you have no standard approach, no template, and only a hazy idea as to architectural pattern, you’re going to burn willpower and time repeatedly making decisions that should only be made once.

If our projects are always bespoke one offs where we are constantly solving the same problems in different ways, we will never get better. Our projects must be engineered to minimise conscious expenditure of willpower and to reward disciplined behaviour.
Remove the need to make the same low value decisions over and over again (such as “how am I going to structure this react app”, or “what package will I use for a job queue”). Turning these decisions into blueprints that can run without much effort is a force multiplier that costs little beyond the initial learning curve.

Easy wins for willpower conservation

“One change always leaves the way open for the establishment of others.”
– Niccolo Machiavelli

Developers have a wealth of easy wins for conserving their decision making muscles. The easiest win available is properly setting up automated tooling. This cuts down a swathe of repetitive tasks that dull the mind and sap willpower. With each interminably boring task automated, the door is open for a developer to spend more effort on what actually matters - shipping features.

Using a well integrated linter and code formatter, building a CI pipeline that makes basic checks for pull requests, or automating manual tasks with scripts are all prime examples of this. It’s understood by great developers that this kind of leverage is what allows them to work at an advantage to other projects. They prioritise setting these tools up, and making them effortless. If they can be made to run “like magic”, then they should. A great tooling setup is like ambient background magic - it just works.

This doesn’t have to stop at tooling though. Examine your business processes with a people and purpose over process frame. Are there easy wins to be had, such as scheduling all meetings in the afternoons to give people uninterrupted working time? Can meetings be eradicated by using email, or asynchronous videos?

It is only by prioritising willpower conservation that great software projects are able to ship better features faster. Decision making is not wasted making many small decisions, but is instead spent in the broader pursuit of shipping features for users.

The system designs of William of Ockham

“That’s been one of my mantras - focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
– Steve Jobs

Better software therefore can be seen as the product of better decision making. Habits and willpower are only part of the equation for better decisions. It is possible to engineer our projects to encourage good habits, conservation of willpower, and disciplined coding. The only question is how. To answer this, we will examine two guideposts - Ockam’s Razor, and the Lindy effect, as they apply to system design choices.

Shaving away complexity

“The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.” (Wirth, 1995) ¹

“Entities must not be multiplied beyond necessity” is the typical paraphrasing of William of Ockham’s famous razor. The simplest design that fulfils all the criteria is usually the best option. The razor can be used to shave away numerous ills commonly encountered in software development.

Instead of building a massive Gordian knot of a project, the razor is an exhortation to design with a bias towards small and loosely joined pieces of technology. The result will be easier to understand and easy to modify. Equally important, it will encapsulate tech stack choices. This is long term thinking in design. When the stack it was built with inevitably becomes considered legacy code, they will be easier to refactor out without a major rebuild effort.

A second order effect of the razor is summed up in Tim Berners-Lee’s rule of least power. For any given project, choose the least powerful language that is still suitable for the task. His example was that of the machine readability of html vs a Java applet. The rule refers not to the theoretical power of the language, but more so to the ease to which it can be used by its developers. Programming a web app in Rust that’s compiled to WASM is neat…but you should use Javascript, HTML, and CSS unless you truly need the features of Rust for your product’s features.

Longevity as a measure of robustness

“Shopify is now one of the world’s largest and oldest Rails apps. It’s never been rewritten and still uses the original codebase, though it has matured considerably over the past decade. All of Tobi’s original commits are still in the version control history.” (Shatrov, 2018)²

The second guidepost for better software designs is commonly known as the Lindy effect - the longer a thing exists and is in use, the longer it can be expected to exist. The longevity of any given tool, framework, design pattern, or idea can be seen as a measure of the thing’s suitability and robustness.

Better software is not built by using the latest hot new toy. It’s built with modern, mature, reliable and well understood frameworks that have proven themselves over the course of many years, and many varied projects.

Javascript frameworks often feel like they’re a dime a dozen, with the lifespan of a mayfly. Other frameworks such as Ruby on Rails, ASP.NET, and Spring have not only survived for decades, but proven themselves in large enterprise deployments as mature, modern solutions.

There are a few reasons why these frameworks persist and thrive over decades of use in the changing web application space. The core is that they enable their developers to ship features instead of solving the same class of problem over and over again. They bring a wealth of out of the box solutions to the common needs of a modern web app. Rails, for example, provides a set of built in solutions such as database ORM, job queue, and management of reactive webpages. These are all solutions to commonly encountered problems for web apps.

These frameworks have something else in common that allows their developers to ship features faster - they provide an idiomatic way to write and think about code. Less time is wasted thinking about things that should be a solved problem - such as project file structures. Less time is wasted choosing a package for handling simple tasks such as sending a transactional email - there’s a recommended and rock solid package for it in the framework already. These frameworks enable developers to get to work designing and shipping high quality features.

There’s another benefit to having an idiomatic approach to projects like this. It makes it easier to join a project, and make meaningful contributions faster. Instead of hoping the next project wrote documentation, developers can rely on the knowledge they already possess. They can get up to speed and start shipping features faster. And that, after all, is the result we’re paid for.

Recap

Simplicity is the ultimate sophistication.
(Apple Computers Inc, 1977)³

The project outcomes that are under our control are almost entirely determined by how we make decisions. Better software starts with developers who have the discipline, principles, and self control to enact the hard decisions. As luck would have it, these attributes are not something you’re born with. They can be learned. Habits can be leveraged to conserve and amplify our limited willpower, so that it isn’t wasted on meaningless minutiae.

Our projects can be designed better to encourage this. It’s really easy to write good code if the project is designed to encourage good habits, such as using a framework that has idiomatic ways to accomplish tasks. Time isn’t wasted on thinking about minutiae - developers can simply get to work.

References

“Let’s put stupid out of it because saying someone is stupid is not explanatory. Saying they are stupid means you write off understanding their reasoning.”
– Sarah CM Paine

I recently returned from visiting family in country NSW. Aside from destroying a brand new tyre on a pothole that you could hide in, I also discovered that the only time I can listen to a podcast or audiobook is while driving. It’s because my hands have something to do that doesn’t require conscious thought - the mechanics of driving become habit loops with practice.
As I drove, I was listening to an interview on the Dwarkesh Patel podcast with Sarah C. M. Paine of the Naval War College. I recommend listening to the entire episode.
However, there was one idea in particular that changed the way I viewed and consumed political media - the idea that authority figures always tell you what they’re going to do¹. Paine was talking about dictators and other authoritarian leaders. But the concept holds for government leaders regardless of their stripe. Regardless of position on the spectrum, leaders must communicate their plans to their supporters in the general populace to get support for it.
Ordinarily, it’s so they get re-elected. For a dictator, it’s to stave off being hanged by a mob after being pulled from a storm drain when the people revolt.

The mainstream media isn’t lying. They’re just telling you the truth from the viewpoint that best suits those in power. The distinction is important - objective, absolute, and durable truth is extremely rare, especially in the political arena. Complex issues such as housing affordability, cost of living, and inflation have multiple drivers, and multiple possible solutions. The solutions are never clear cut in black and white - viewpoints on the issues are presenting the same thing from different perspectives.

Instead of dismissing the messaging of those in power as lies, there is more value to be had in listening to what the mainstream media says, from both ends of the political spectrum. Not with blind acceptance, but so that you can examine the invisible frame that’s been put around it. Only by moving back, and seeing beyond and around the message, can you begin to understand the greater implications.

For large scale efforts, those that affect a broad base of the population, the government is going to tell everyone what they’re doing, as loudly as possible. Examining a list of conspiracy theories that turned out to be true, and there emerges a common thread.
It’s almost always the American government committing authoritarian evils. Remember, the purpose of the system is what it does, not what it says it is - for a country that espouses freedom and democracy, the US has a long history of using extrajudicial violence to decrease the amount of both in the world.
Each of the proven conspiracies were always being done to a small group, or just an individual. From the long list of American classics, such as the overthrow of democratically elected leaders (Iran in 1953, and Chile in 1973 among others), to the FBI surveilling John Lennon, it’s a handful of people doing something to an individual or a handful of people.

Three may keep a secret, if two are dead
– Benjamin Franklin

It is not possible to maintain a lie about large scale things (such as the purported chemtrails or covid vaccine conspiracies). It becomes too easy to prove falsity. Those in power need support from a broad base of the population in order to effect whatever widespread change they intend. The only way to get that support is if the people trust what they’re saying, and the only way to get that is to not constantly lie.

By way of examples, Putin made it clear he was going to invade Ukraine ². Xi Jinping has been quite vocal about invading Taiwan ³ (which is concerning, since he hasn’t made good on it yet).
The effects of a government broadcasting its plans is not always something that takes years to bear fruit. Between April 7 and July 19, 1994, more than half a million Rwandans were systematically killed while the world stood by and watched. RTLM, a key media outlet for the then Hutu government, was responsible for driving 10% of the participation in the killings (Maximino, 2014)⁴. The effect of their messaging resulted in both direct action and spillover violence.

The truth is almost never absolute, especially in politics. It requires a perspective from which to stand when viewing it. The messaging of those in power tells us more than just the content. The frame around each message is itself a powerful piece of information. The consequences of ignoring the message behind the message are not always light. But all it requires is that we step back and ask why this frame?, and how does this serve its advocates?.

References