The Problem of Lost Context

There is a rather famous multipanel cartoon created by Jason Heeris in 2013 which makes the rounds on social media every few months.

It has as many promoters as detractors, which seem to qualify it as great art in my mind. People bring themselves to it, and it inspires them to think. It is provided here in its entirety for your edification:

Most of us can relate to the developer in the cartoon. We have all experienced some period of deep thinking, when we have to bring a lot of context and logic to bear, in order to understand some behavior, code, or situation.

With so much context floating around in our heads, assembled into many dimensions of the same problem, we find ourselves in a fragile mental state. It doesn’t take much to disrupt our current thoughts and see the mental model we’ve been working so hard to understand collapse entirely before our very eyes.

There is a related cartoon called Unfinished Work from MonkeyUser.com, also presented in its entirety here:

I appreciate the work of both artists in expressing the angst of lost context. Kudos all, and well-deserved.

Nature of the Problem

The problem with the mental model is that it’s inside a human head. It’s a volatile place. We’re prone to distraction, forgetting, interruption, and depletion. The more we rely upon the persistence of our thought and memory, the more prone we are to a loss of context and having to start over again.

If memory were more persistent then maybe it wouldn’t happen.

If interruptions never occurred, maybe it wouldn’t matter.

If we never had to leave work partially finished for any reason, there would be no problem.

If wishes were horses then beggars would ride.

The more work we have in progress, the more likely we are to suffer interruptions. While we can try to manage interruptions by keeping WIP to a minimum, you are still likely to be on the hook to consult about work you might do in the future or to answer questions about work completed in the past.

Our misguided expectations leave us in a fragile mental state.

• We don’t really have the right to expect the world to stop and wait when we’re thinking.
• We can’t expect that our colleagues and family members will never need us when we’re deep in thought.
• The bosses hired us so that they would have relatively unfettered access to us during working hours - that’s part of the expectation of working for a boss.

Even if it only takes an hour or two for you to do your deep thinking, who is to say that those hours will not include some emergency, interruption, or notification from others?

How can all the people working from home know that today at 3:25 you are going to need exactly 47 minutes of completely uninterrupted deep thought and not one second less?

Saving Your Game

If we can’t rightly expect to be uninterrupted, then perhaps we had better concentrate on being robust in the face of interruptions.

We need other ways of maintaining context.

I suppose I could fire up a CAD workstation and spend endless hours documenting all of my thoughts in boxes and lines and text, maybe in 3D in a virtual world.

That kind of documentation takes a lot of time and distracts from the focus needed for building a mental model: while I’m fiddling with boxes and arrows and fonts, I could suffer the same loss of context. Sigh.

I need a solution that is in the moment and lightweight.

Luckily the necessary techniques exist and are not hard to incorporate into our workflow.

A Story Map

Story mapping is a technique used in product discovery to help outline a new product or a new feature of an existing product. The result is a lightweight model called a story map which helps you keep your eye on the big picture while also providing meaningful details of the whole application.

Story maps help me remember what I’m doing now, what I’m leaving to later-if-ever, and where I’ve been. I sometimes refer back to the story map to help me recapture my current intention and scope.

Story maps help you visualize the product and make tough trade-off decisions as you negotiate the scope of each defined release slice.

The White Board

When we were all together in physical space, we used to gather at a flipchart or whiteboard and sketch ideas together.

Now it’s the age of COVID, and everyone is remote, but now we have tools like Miro, Mural, Google Drawings, and Excalidraw. If we can put together a very simple diagram of text boxes and lines, we can hold our context in a medium more persistent than our imaginations.

It’s still a good idea, even if you are working alone. Get used to quickly sketching ideas, even on paper with a pencil (remember nonvirtual work?) and you increase your chances of recovering after an interruption.

Tests

A failing test is a good reminder of what I was working on when I stopped. Using TDD or BDD is a great way to hold context in the codebase directly. It may not reveal all of my thinking as of the time I stopped, but it tells me what I am working directly on, and that’s a big deal.

Having an incomplete BDD scenario and failing unit tests can give you a surprisingly strong reminder of your context and reminds me that I have one job to do, get the test to pass! I would not discount the value of this memory aid.

The Test List

Kent Beck provided a technique in his TDD book.

The idea of the test list is that you begin by jotting down a list of tests that you want to write for the code you are about to write. This provides you with some intention and context.

• As you implement a test, you cross it off the list.
• If you realize a test is unneeded, you cross it off the list.
• If you think of another test that might be needed, you add it to the list.

You will reach a point where all the tests are crossed off the list. That suggests you’ve done everything that you intended to do.

This provides you with focus and a recoverable context.

Imagine going to a meeting or attending to some emergency and returning to see exactly what you were planning to do next and exactly what you’ve done. Convenient, eh?

The list doesn’t have to be a piece of paper or a shared document - you can make the list inside your test code either in comments

or in test outlines

Notice that these do not produce a failing test error, so you have to look at the test file to see them, but they are present in the work as you are doing it.

It’s probably not surprising to know that this works even better when you co-create code in a group.

TODOs

TODOs are messages written in the code to tell future maintainers about something important: something that should be added, or should be changed, or should not be forgotten. The goal here is to only have one TODO in your codebase at a given time. The degree to which you can accomplish that is the degree to which TODOs are helpful.

If you only have five TODOs, you’re still able to see the one that matters most to you. However, when there are 50 or 500 TODO’s, they’re all just feckless fantasies. Nobody is going TO DO what they say any time soon. They’re probably better off as backlog items, stories on the story map, or simply deleted.

Partners

Many of us are privileged to work in pairs or other ensembles. There are many advantages to this way of working, but one of the most important is that we build our mental models together, communally co-creating a vision.

Even though we have different perspectives, we have a shared vision of what we’re doing and how it will all fit together.

It is a bit like a RAID array: if we lose one member, we can piece together enough from the people who remain that we’re never really lost. Some catastrophe would have to occur to wipe out all our memories at once in order for us to be lost.

It’s a very powerful bit of resilience on top of all the other benefits.

Commit messages

We do micro-commits (several per hour).

When you commit after every important piece of work, then your commit messages (especially those written using conventional commits) provide a nice trail of breadcrumbs. We can see where we started, and our progress so far, which reminds us where we’re intending to go – it’s a matter of recognizing the vector.

One can use a nice commit viewer such as gitk illustrated here (part of the git gui package) to walk through the past commits step-by-step.

Why not all of them (and more)?

When we think of safety in an automobile, it is easy to understand that no one safety feature or device on a car makes you safe but rather you become more safe in the presence of many safeties.

Similarly, we don’t rely on one person’s attention or one person’s memory in order to maintain important project information. We have externalized our progress and intentions in several different ways so that we can recover from inevitable interruptions.

No one technique is going to give us enough coverage to prevent us from losing our place, but when we take a few of these in combination we find them powerfully capable of bringing us back to our initial thoughts.

These aren’t the only ways to externalize context, nor are these all the ways it can be done. You may have others that work well for you.

I would love to see how you survive interruptions and breaks by externalizing your context. Why not drop us a note in the comments below?

Related Discussion:

We had an open discussion through our Industrial Logic TwitterSpace. Here is the recording of that conversation.