💡

This post was inspired by an article (with the above title as the teaser) that appeared in the NY Times last month. The article itself was entitled: A Multitasker’s Guide to Regaining Focus, by Anna Borges

We're all very familiar with the concept of multitasking, or at least, with the notion of multitasking that pervades our current society, be it in a work setting or at home.

We are fed the notion that we should be constantly capable of and actively doing multiple things at the same time throughout our day. A classic example can be taken from the fast-food/work culture wherein we find ourselves behind the steering wheel, exiting the drive-thru, with the intention to navigate safely back to the office (during rush hour, using our favourite app to find the best route), while scoffing down the "nutrition", and following up on several work calls and emails that we neglected earlier.

The concept of multitasking involves working on two or more tasks simultaneously, switching back and forth from one thing to another, until all tasks are completed. Psychologists would argue that, strictly speaking, the act of "multitasking" is a bit of a misnomer for humans - we are not really built to perform multiple things at once. Of course, this all depends on your very definition of a "task", or "sub-task".

Multitasking at Home

One of the most obvious settings for this topic is the kitchen... My earliest memories would be of my mother (back in Ireland) preparing the Sunday lunch...

How did she manage to produce such a feast in what seemed like such a short amount of time (albeit time being a very fuzzy concept for a youngster of 7 or 8 years of age)?

The soup (made from scratch) and bread rolls
Followed by:
- The roast beast (Irish lamb or Irish beef being our favourite)
- the roast potatoes (beautifully textured) and the mashed potatoes (beautifully creamed) - it is an Irish household after all :)
- the cauliflower or celery (bathing in a piping hot bechamel)
- the token carrots or peas (admittedly not my favourites, back then)
- the Yorkshire pudding (if it was beef)
- and the gravy (sublime, no packet of Bisto crap here)
Followed by:
- The dessert (hard to pick a favourite... perhaps the cornflake based one, which we called the Coolgreany dessert)
All of this in addition to attending Sunday Service and taking the clothes in from the line before the rain got too much.
I should add that my father would insert himself at important moments in the process - preheat the oven, set the dining table, take care of the beverages, and help out with the serving.

💡

My parents celebrate their 58th wedding anniversary today 💚

Judicious multitasking in the kitchen is of course essential. When following a recipe (or multiple recipes), the "steps" (or sub-tasks) almost always have to be interleaved in some fashion - performing/completing each and every step sequentially is clearly suboptimal, resulting in a ravenous cantankerous rabble (be they young or old). With that said, doing too many things at once, or having "too many cooks in the kitchen", can have disastrous consequences (pre-al-dente/mush, char-less/burnt, bland/acrid, watery/gloopy, ...).

Multitasking at Work

💡

Context switching can sap your productivity: Atlassian blog article

The electronic age heralded a change in our daily work habits. Having various information technology devices and communication media at our fingertips promotes a multitasking type of behaviour. The work-from-home culture is exacerbating these tendencies. Meetings, particularly in the virtual form, are becoming less effective as a means of collaboration and making decisions on stuff -- too often, the participants are preoccupying themselves with other "sub-tasks" (messaging, email, Web browsing, etc.) and are simply not engaged enough to truly participate.

This seems like a good place to touch on this general topic from a software developer's perspective.

Multitasking in Computer Science

The concept of executing multiple tasks concurrently requires the introduction of some additional vernacular.

Thread

A thread of execution is the smallest sequence of programmed instructions required to accomplish a particular task.

Process

The instance of a computer program that is being executed by one or more threads. Typically the threads will share common resources "owned" by the process, such as memory (to store stuff that allows the program logic to keep track of what it's doing).

Scheduling

The assigning of resources to perform tasks.

Multithreading

The ability to execute multiple threads simultaneously. On a system that only has one processor (CPU, which you can think of as the brain of the computer) with a single core (you can think of the core as the processing unit of the engine), the illusion of concurrency is implemented by the scheduler (in reality, only one thread can actually execute at any given time on a single core). On a modern PC, for example, there will typically be multiple CPU's, each containing multiple cores. Getting back to the chef above, this is a little bit like the multi-headed monster (think Gordon Ramsey meets the mythological Hydra) that gets to work in a professional kitchen (with multiple prep stations, appliances, ovens, etc.).

Context Switching

The act of switching from one thread to another, and back again, to ultimately process multiple tasks and bring them to completion. The concept is pretty similar to how we behave ourselves, as we shift our attention back and forth between different tasks during our day.

This is a huge area in computing, and the above is just a little rudimentary sampler. Computing has many different variants in this space, all to do with executing and completing tasks in the most efficient manner possible. It's an ever evolving area at both the hardware and software level, but, for the most part, it goes anywhere from basic concurrency (one cook in the kitchen at home) to extreme parallelism (a team of chefs in a Michelin star graded kitchen).

Multitasking in Software Development

In terms of the daily behaviour of the software developer (indeed this applies to many different professions), multitasking has become a rather contentious subject. The advice from the "experts" can be quite polarizing:

The Agile purist might insist that one must block out all distractions that might potentially detract focus away from the top priority coding task at hand... the noise-cancelling headphones are donned, the DND (Do-Not-Disturb) status is activated in the collaboration app, notifications are turned off, email and other windows are closed on the desktop, no home-from-school kids in the next room, and absolutely no meetings.
The "team player" can only become such if they are an "excellent multitasker", open to interruptions throughout the entire day - i.e. status: green (available). They should read (and optionally respond to) email/text messages in a timely manner, openly volunteer to pivot to some other task that is deemed higher priority (who prioritizes these things? Ahem, that's a whole other discussion!...), be the first one to perform a code review when a colleague creates a PR, etc.

As with most things in life, the extremist approach rarely works well for the greater good.

Monotasking

Dr. Mark suggested you start by observing yourself throughout the day, noticing when and how you task-switch without realizing it. From there, the advice is simple yet challenging: You’ll need to practice monotasking, or doing one thing at a time, to gradually retrain your focus and build your tolerance.

[excerpt from the aforementioned NY Times article, which also cites this workplace study]

Intentional Multitasking

The NY Times article concludes with a little advice on how to become more intentional about your "multitasking habits". I'm going to repurpose that advice here with a software developer bias.

Stick to your strengths: for tasks that we know will require a lot of "brain power" (due to relative complexity and/or limited, beginner level knowledge/experience), it's best to take on some of that Agile purist mindset and concentrate fully on the task at hand. For other tasks with which you are extremely comfortable, some task-switching will not be an issue (e.g. during these times, you can allow yourself to be more responsive to external disruptions, to assist a colleague or whatever).
Weigh the risks: sometimes it's necessary to log on to a customer's system and perform some sort of tweak to rectify a behavioural defect. For example, this might require altering some data in the customer's database. While the developer may have done this sort of thing on countless previous occasions, any time you are dealing with "production data", regardless of whether the "data cleansing" is trivial or more involved, you really need to be focused and meticulous, and set yourself up to be distraction free until the task has been completed.
Find break points: a customer support issue is being worked and the developer is knee deep in the bowels of debugging a decidedly elongated stack trace, while also looking at logs in the monitoring tool, while also trying to figure out how to reproduce the behaviour in-house in a repeatable manner. Rather than switching away from this complex task in an ad hoc fashion (and then having to try to remember where you left off upon returning), the developer should proactively set some targets along the way, which can act as natural "breakpoints" (pun intended for techie readers!) to preserve sanity and avoid brain-power drainage. The first breakpoint might be the formulation of an initial root cause analysis (where perhaps the source of the defect is isolated to a particular "component" in the system, and a particular category - bad data, software logic, infrastructural, etc.).
Use multitasking when it actually helps: the article's author suggests habit stacking as a useful technique to encourage more productive patterns of behaviour by associating/linking an existing/instinctive habit with one that is less comfortable, or perhaps less engaging. For example, if you've been stuck with a somewhat mundane, tedious task (perhaps involving data entry, or some manual regression testing, or some rudimentary housekeeping/refactoring work), then it might be a good time to crank up some block rockin' beats (or whatever gets you going) to keep you energized so that you can push through and bring the task to completion!

So, this is all well and good, but what does multitasking have to do with storytelling (the underlying theme of this blog)?

A great story (book, movie, lecture, et cetera) comprises the main plot (or simply the main character/subject, if the plot is insignificant), and may well have various other sub-plots (supporting characters/subjects) in the mix. As the reader, we become engaged by virtue of a strong hook. We need one central theme, or plotline, or character development upon which to concentrate. If we are presented with too many superfluous threads and tangents with no readily apparent coherent hierarchy, then we tend to tune out, become less engaged, and perhaps get to the point where we have little interest in getting to the end of the story (we might instead ask, "What is this story actually about or what is it trying to say?").

It might well be that the audience comes into it with a healthy spirit of intentionality and mindfulness, however, it's up to the author to do their part and to not force the audience to work too hard (regardless of the subjective biases of the audience)!

💡

The audience should always be required to do some work in order for the story to be truly impactful. The mass media and large franchises (like Disney and Hollywood production companies) tend to pander to their target audience. The audience dutifully drinks from the firehose. But, hey, I'm not here to judge - occasionally, we really do need to just wallow in that which makes us entirely comfortable.

💡

If you've managed to read this far then I hope it was something to do with a good hook, backed up by some thought-provoking articulation, rather than out of pure stubborn curiosity to see if there was anything useful being said here!

Multitasking is a Bad Habit; Here's How to Stop (Kind of)