Context switching costs more than we give it credit for

&gt; Trying to code and listening to music falls under cognitive functions. Naming a variable while listening to your favorite songs&#x27; lyrics may result in cognitive overload. You are more likely to name a variable after the singers&#x2F;songs name than what the variable is supposed to reflect (true story).<p>This point in the article lost me pretty quickly. My flow state is drastically improved by music, and I have never ever named a variable after the song name or song artist I&#x27;m listening to in my life.<p>Edit: Nor have I ever seen a variable named after a song name or artist.<p>Edit2: NotoriousViewController. TheWeekndTimer. RedHotChiliPointers. Now I <i>want</i> to name my variables like this.

I&#x27;ve recently been assigned a course to teach where I need to mark lots of assignments. These assignments have 12 short answer questions and each student must do them.<p>Slowest part about marking these is having to context switch for each question. So I&#x27;d mark Q1 , then Q2 etc for one assignment, then go over to the next one and start back at Q1.<p>I figured this was super inefficient since I needed to have the answer and context of the question in my mind and keep switching.<p>So I wrote a program to parse all of the questions from all of the reports and present them to me in question batches. So now I see all of Q1 one after the other for each student&#x27;s and mark those. Then once all of the Q1&#x27;s are done, I mark all the Q2&#x27;s. After all the marking is done, I run that through another program that then formats that data to each student so it&#x27;s back onto their individual report plus any comments or deductions.<p>I find that apart from saving the time to have to open tonnes of docx files, now it takes maybe 5 mins to mark everything.

Rarely have I read an article with such a perfect balance between a premise I agree with an examples I do not. But I think this illustrates something important: what constitutes a context switch is not universal. It depends on what parts of a task you need to think about.<p>In the kitchen, from long practice, I do not have to think about prep, technique, or washing up. There are no decisions I need to make for those tasks. They take very little attention. This frees me to spend my focus on the more abstract goals of what I want to cook, and for me it is not a context switch to wash a bowl while an onion is sauteeing. I can certainly cook while keeping the kitchen clean more efficiently than I could cook and then clean it. But when I was first cooking, it was a context switch to go from chopping an onion to chopping a carrot. Both tasks required my attention and focus.

The author states switching from cooking to washing dishes is a huge context switch and a waste of time...I disagree. Everyone who cooks efficiently is constantly switching between tasks, since you&#x27;re often waiting a few minutes before your next cooking step can occur. Maybe in a professional restaurant where your role is defined, then no, don&#x27;t switch roles.<p>But in your own kitchen? While my toast is toasting, you know I&#x27;m going to get a head start on the dishes, or chop those garnishes, or check in on a second dish, etc. If I cooked by focusing solely on each task until it&#x27;s done, I&#x27;d probably use 50-100% more time to do the same job maybe 10% better.

What makes it worse is the number of times I see people get their work interrupted by a WhatsApp, SMS or Facebook Messenger notification on their phone.<p>That damn pop ding Messenger notification sound is like a dog whistle for many people; instantly dropping what they&#x27;re doing and picking up their phones to follow this sound.<p>I wonder how this generation will be able to remain focused with all of the distractions that keep popping up around them.

People talk a lot about the costs of context switching, but not about how to reduce those costs. Instead they talk about reducing context switches, which is often unrealistic.<p>The cost of context switching can be reduced, and reducing it is one of the most important job skills and productivity gains you can get. It will also reduce your frustration.<p>Break up your mental model of what you are doing into smaller tasks. Compartmentalize. Encapsulate. If you are in the middle of something so intricate that you would forget what you were doing if you stepped away from it for a few minutes, persist that state somewhere outside your brain -- write it down!<p>Very few of us are in a position where we can lock ourselves away from others for hours of deep work at a time. So, focus on reducing the impact of the interruptions!

The kitchen analogy is apt. Woodwork (shop work, joinery) too. I can think of people in my life for whom cooking without also continuously tidying is anathema.<p>It keeps the deck clear but at a huge efficiency cost. Some people just can’t stand untidiness, yet learning to live with mid-process untidiness — and the associated anxiety — is a big step towards being more productive.<p>It is certainly not easy. When coding, I feel a great anxiety if I am mid solution and have a large amount of the current batch left to complete. It is as if I had taken a gulp of air and dived under the water into a cave. Batching involves being able to commit to living without safety checkpoints, and to be able to get a batch complete in the time allotted. If you don’t, you risk having a large pile of four-fifths completed batches.

Context switching has high costs, but it&#x27;s a mistake to assume those costs are unchangeable.<p>With practice, it&#x27;s possible to train yourself to get back into focus faster after being interrupted or context switching. It doesn&#x27;t completely cancel out the costs, but having a strategy to get back into focus helps immensely.<p>The worst mistake I see people make is assuming that focus is something that only strikes serendipitously, and is ruined on the first signs of interruption. Once you accept that focus can, in fact, be cultivated and interruptions can be overcome with deliberate effort to re-focus, it becomes much easier to start training yourself to get back into the flow.<p>The other mistake I see people make is letting minor interruptions spiral into an impromptu 30-minute break of checking HN, browsing Twitter, or other distractions until they feel like getting back to work. Don&#x27;t like your own habits amplify existing distractions.

<i>The best analogy is sorting forks, knives, and spoons when we are putting them in drawers. We can throw all silverware together. But then finding a spoon in that pile will take time whenever we need a spoon. The task changes from getting a spoon (execution) to finding a spoon (identification). And that&#x27;s a cost we want to avoid.</i><p>I agree with his overall point about the costs of context switching (and was disappointed that he didn&#x27;t talk about the low level issues of coordination on multithreaded systems) but this seems like an odd candidate for &quot;best analogy&quot;.<p>When I moved to a new house a few years ago, we initially lacked an organizer tray as is typically used to keep silverware sorted in the drawer. Our solution, which we thought was temporary until we bought one, was to unceremoniously and clatteringly dump all the silverware into the same drawer, and to pick out what we wanted at mealtime.<p>Three years later, we&#x27;re still doing it and have concluded that it&#x27;s much better system. Sorting silverware was always one of my least favorite parts of putting away washed dishes, and now it is trivial: dump the entire basket from the dishwasher into the drawer, often while grinning with joy. And I don&#x27;t think I&#x27;ve once become angry at the extra time of searching for a spoon or a fork.<p>Consider, if we&#x27;re being technical, that the primary advantage of presorting happens when you can sort once and take advantage of the ordering many times. But with silver, it&#x27;s once-in and once-out. Sorting all at once isn&#x27;t actually faster, it&#x27;s just preloading the pain. Also note that you can fit a lot more silverware into a drawer unsorted. Having twice as many spoons and forks might reduce utilization, but silverware is cheap and having more makes finding what you want a lot easier.<p>Anyway, you know the standard advice to measure before you optimize? Given my positive experience with the unsorted method, I wonder if he&#x27;s even tried the approach he&#x27;s using as a central negative example. Personally, I&#x27;d suggest that more people should try it!

I have done some things to eliminate small context switches, as I found even those were a trigger to unfocus. I no longer use two monitors, I use i3 to manage windows so I don&#x27;t have to move to my mouse, same reason I use vimium. I have all my tools inside the IDE and then a terminal sitting below it for all else.<p>When I have to do frontend implementations, switching between tabs and screens, I can work for much less time and I constsntly lose focus before essentially burning out for the day.

&gt; <i>My answer is to</i> always batch<i>. Depending on the task&#x27;s size, batching may take the same amount of time as it will to complete the task. And on a few occasions, batching may take even more time than the actual work. But batching is also a skill that needs to be developed.</i><p>Absolutely no data is given to back up this assertion, and even if data were given in some research, it would be some kind of average value, selected from a sample size of, say, 20-25 year old, disproportionally male Californiamen, who all studied at the same university, and were all willing to donate their time for some undergraduate research and obtain 50 U.S.D. in return, and the data would already reveal immense spread and variability with clearly around 40% at least heavily increasing productivity by switching, but the article would stress that the average would not, and thus advocate that no man so “context switch”.<p>Yes, practicing batching will make one more efficient at it, but practicing context switching will also make one more efficient at it,and the true reason is that many tasks require one to wait for something else and do nothing.<p>The reason why I&#x27;m already washing many of the dishes I cooked with as I cooked is of course simple: there is nothing to do except stirring once in a while at a certain stage in cooking so I might as well use that time to do something else.<p>I also took various sips of my coffee writing this, not because I had nothing else to do, but because it tasted nice.

It might be common sense that batch processing is faster and more efficient than constantly context switching, but it&#x27;s important to recognize this isn&#x27;t always the case. It&#x27;s not software but you can see an illustration of this with stuffing and addressing envelopes: <a href="https:&#x2F;&#x2F;blog.gembaacademy.com&#x2F;2014&#x2F;07&#x2F;29&#x2F;whats-faster-one-piece-flow-or-mass-production-watch-this-envelope-stuffing-simulation-to-find-out&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.gembaacademy.com&#x2F;2014&#x2F;07&#x2F;29&#x2F;whats-faster-one-pi...</a>

Does it though? I&#x27;ve heard about it so many times that I&#x27;m starting to think it cannot possibly be as extremely bad as the never-ending torrent of articles would have me believe.

This can jeopardize domestic tranquility, though. I like to focus entirely on cooking, then clean up in bulk after the meal. My wife likes to clean as she goes. We&#x27;re both sure the other is wrong.

&gt; You are more likely to name a variable after the singers&#x2F;songs name than what the variable is supposed to reflect (true story)<p>This would happen maybe in one out of a hundred cases if at all, making the statement blatantly false.<p>How can I trust that anything the author says will be minimally rigorous about a topic as complex as cognition when they’re making such outlandish claims, even if they’re being facetious?

I gave up that illusion of multitasking a long time ago. I tend to devide my task in steps and execute them sequentially.<p>When I bake pizza rolls for instance: I need to make the dough, fill it with ham and cheese and then bake them. Of course that are idle time in between those steps (letting the dough proof and baking, for instance) so I insert a small task in between. Like making coffee or mayonnaise. Looks like I&#x27;m doing a whole bunch of things at the same time, but I&#x27;m not. I&#x27;m making just one task of &quot;preparing a meal&quot;.<p>I&#x27;ve noticed context switching is costy at my current job. When I&#x27;m working on a feature usually I have to wait for my boss to do a code review. During that time I usually start a new feature. When I have to work in two features simultaneously that&#x27;s when I make a lot of mistakes (usually small mistakes due to lack of attention).<p>I much rather work at one thing at the time.

It would be great if there is a follow-through research article that quantifies the cost of context switching for developers in an open office plan. There may be some real-estate cost savings too...<p>these 2 numbers need to be compared...

I think context switching is difficult to quantify, and difficult to talk about in a general sense.<p>* I&#x27;m sure some people are better at it than others<p>* Some work is easier to switch to and from<p>* Some work demands it—e.g., people in supporting roles that will put up with constant interruptions in order to help others<p>Throw into the mix that some people are better than others at deluding themselves about their abilities to context switch (or handle distractions in general), or who simply struggle focusing on a single task for hours at a time.<p>Personally, I don&#x27;t find meetings and random conversations too bad. But if I have to completely unload a complicated task from memory and replace it with something else, coming back to the original task can often feel like starting from scratch.<p>Other things to think about:<p>* Figure 2 here—<p><a href="http:&#x2F;&#x2F;www.scielo.org.za&#x2F;scielo.php?script=sci_arttext&amp;pid=S2224-78902015000300009" rel="nofollow">http:&#x2F;&#x2F;www.scielo.org.za&#x2F;scielo.php?script=sci_arttext&amp;pid=S...</a><p>—from a study showing how &quot;time spent on value-added tasks&quot; drops if working on 3 or more parallel projects<p>* For other reasons (e.g., for faster feedback cycles, reducing overhead), batching isn&#x27;t always a good idea. Here&#x27;s a fun video showing that contrary to intuition, batching isn&#x27;t always faster:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dmQORuNFE4c" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dmQORuNFE4c</a>

For anyone still unconvinced about batching&#x2F;chunking, here&#x27;s a set of tasks:<p>- Cleaning the bathroom<p>- Wiping the poop off the toilet bowl<p>- Polishing the silverware<p>- Vacuuming the car<p>- Shopping<p>- Fixing a syntax error in some code<p>- Washing the car<p>- Eating a hamburger<p>If you don&#x27;t think batching &#x2F; chunking is useful, try swapping ramdomly between these tasks and leaving them partially done and resuming. The context switch costs should be abundantly clear. Especially if you add in some travel time.<p>Multitasking relies on tricks and effort to actually work. Not even computers get to multitask (until you add more cores). Context switching is still required. Even going from user to kernel space involves some cost.<p>Listening to music, chewing gum and walking is only multitasking because these are using complementary or different &quot;cores&quot;. Real multitasking requires independent pathways. Try reading three books at the same time. Or drinking coca-cola and some fine wine. This is my usual challenge for multitaskers. The books and the drinks wont fully be appreciated if you attempt them via simultaneous multitasking. The context switch isn’t trivial and if not properly done always has negative outcomes.<p>Especially the coke and wine combination. Nasty.

I though this would be about trashing cpu state.

The advice to always batch is at odds with the primary advice of systems like the Toyota Production System (TPS) and Lean, which is to strive for one-piece flow in most places in the system under study.<p>A continuous integration system doesn’t batch jobs; it starts working on a job the moment it arrives. Would it be better if CI jobs were arranged into batches that were processed, say, twice a day?<p>I would not want the front desk of a hotel to batch the processing of my request for a room with all the others received in the last hour so that the front desk person can maximize their sense of efficiency.<p>In seeking to maximize the efficiency of each business operation at the local level, do we wind up harming performance of the company as a whole?<p>What is the goal?

This is why work queues and asynchronous state machines are awesome. All the high performance systems I have worked on avoided having a multitude of threads and have tended towards a thread per CPU model. Use your CPU cycles for things that matter.

Batching things into &#x27;contexts&#x27; is the premise of Getting Things Done by David Allen. It was popular in the early 2000s. My guess is that the older engineer that told the author to batch things was referencing it [1]. It&#x27;s a business book based on aggressively making and prioritizing todo lists and then working on them in contexts like &#x27;email&#x27;, &#x27;phone calls&#x27;, etc.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Getting_Things_Done" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Getting_Things_Done</a>

Did anyone else get totally confused by this article, thinking it was about operating system context switching? Took me a while to realize he was only talking about cognitive context switches.

Context switch and kernel scheduler implemention details also dominate the networking busy loop tests with one client. The kind of naive benchmark you see often in blog posts where every database tested seems to deliver like 10k ops per sec. You are actually just measuring the latency in the networking ping pong the kernel is able to sustain between two processes, so usually the fastest client implementation wins (because the rest is the same for all the systems, being outside the systems).

See the thing is that I think we give a lot of credit in the cost of context switching, no one talks about the reverse cost, sometimes you have 5 tasks to do in a day and you don&#x27;t context switch and focus only on the one task at the detriment to other tasks. You ruin your sleep because you&#x27;re so focused on getting something done and it&#x27;s only 3am, and so ruin your next day of productivity

&gt;You are more likely to name a variable after the singers&#x2F;songs name than what the variable is supposed to reflect (true story).<p>I thought this was a bit absurd. Good article nonetheless though, I can see how getting into a routine about when you will perform specific tasks throughout the day would be more productive.

Why do blogs that make such bold claims without any sources, with everyone in the comments disagreeing with these random statements, end up so high on the front page?<p>A few days ago there was also the blog about the UK Covid variant that was just nonsense.

I&#x27;m not sure I understand what he means by batching by function.<p>Is it dividing by work type (eg coding, responding emails, writing documents, etc) and doing all the tasks in one type before going to the next?

Music is the only thing that frees my creativity and focus as when I&#x27;m lost in it I find I&#x27;ve solved the problem in no time at all because I don&#x27;t realize the passage of time.

I have the similar feelings as the author when randomly dealing with tasks one by one. These feelings were gone when I grouped the tasks by some criteria firstly before dealing with them.

i think this applies only to a specific category of tasks. non-tech people seem so reluctant to understand the cost of context switching for somebody who&#x27;s doing software

Here&#x27;s how I reduced cooking costs to an infimum: switched to carnivore diet, setup a sous vide system and eating as much as raw possible.

<i>&gt; Trying to code and listening to music falls under cognitive functions. Naming a variable while listening to your favorite songs&#x27; lyrics may result in cognitive overload.</i><p>I don&#x27;t know. Good music helps me concentrate.<p>Something like:<p>* <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KUn9SYdPF4A" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KUn9SYdPF4A</a><p>* <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9Qnhn1mCL18" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9Qnhn1mCL18</a>

i mean if he had been talking about tabs and stuff he is 100% correct, but making dinner and slapping in a couple of washes in between is easy peasy. i think because its so tactile. flipping tabs it your brain doing all the work. changing topics. but muscle memory in the kitchen makes it go smooth.

Yes, true, but how to explain that to you manager?

can anyone suggest any resources on how to batch a typical office day?week?

time wasted complaining about context switching &gt; time wasted context switching

I&#x27;m surprised this isn&#x27;t common knowledge.

<i>&quot;Water is wet. News at 11.&quot;</i><p>I don&#x27;t think that context switching costs more than I give it credit for, because I already consider it to be outrageously expensive.<p>I am not a fan of IM platforms, like Slack. I don&#x27;t listen to music while I&#x27;m coding, and I schedule my life around coding sessions; not the other way around.<p>I seem to get a lot done.<p>I was a manager for many years, and I had a few basic philosophies (that I sometimes had to shelve, because, corporation):<p>1) It was my job to act as an &quot;interruption shield&quot; for my team.<p>If one of my managers, or outside developers wanted information or access that required one of my team stop what they were doing, and attend, then it was my job to be &quot;bad cop,&quot; and say &quot;no,&quot; or &quot;wait.&quot;<p>I often wouldn&#x27;t even let my team member know that they would have an interruption, until they came up for air.<p>2) It was my job to know what my team was doing; not their job to tell me what they were doing.<p>This meant no standups (except that I didn&#x27;t have a choice, as it was policy, so we had useless standups; even though I didn&#x27;t want them). If I needed regularly scheduled meetings, I would schedule them in a fashion that would reduce the likelihood of interrupting developer &quot;flow.&quot;<p>It also meant using things like infrastructure tools, integration testing, and frequent checkins to monitor progress. It was my job to interpret them, and ask questions; not my team&#x27;s job to send me reports (except that I was required to send a weekly report, so I had to gather reports every Thursday. I worked around that, by letting my team members send a quick, one-paragraph email, then annotating that with details from my observations).<p>3) I made sure that my team was always able to take care of family and life priorities.<p>I cannot stress enough the importance of this. I had a team of experienced developers with families and medical issues. These would always take priority over their work, and I&#x27;d be a coldhearted S.O.B. to refuse to acknowledge that.<p>I wasn&#x27;t real big on letting them have &quot;me&quot; time, but, if they needed to run out to get their kid out of school in a hurry, I would let them do that. Otherwise, I&#x27;d get to hear them spending three hours on the phone, trying to get relatives to step in and help.<p>If they were doing something like selling&#x2F;buying a house, or having contractors in, I&#x27;d support them doing what was needed, but I would insist on making sure they got whatever tasks needed doing out of the way.<p>I also encouraged them to confide in me, issues like divorces, and severe medical issues. I did that by being empathetic, and also closed-mouth. Sometimes, I violated company policy by not informing people of issues with employees, as it would have been completely inappropriate. If the issue ended up causing a disaster (it never did, in over 25 years), then I would take the fall.<p>I learned that lesson, real quick.<p>4) Classic Management 101: Things go well, I highlight the team. Things go bad, I take the heat.<p>This meant that they felt supported in taking risks, and going down rabbitholes, and not having to spend time in a panic, if the avenue they were exploring wasn&#x27;t giving good results.<p>5) The smallest unit of schedule time was 1 day. In extreme circumstances, I would schedule for half days.<p>This allowed context switching to happen in normal cycles.<p>In my experience, this ended up with a very productive team, that worked well together, was extremely motivated, cohesive, honorable and honest, and highly productive. I kept engineers on board for decades.<p>But that was just me. YMMV.

dang, could you change the title to add &quot;human&quot; at the beginning? I clicked on this thinking it would be about timesharing OS context switching.

That&#x27;s why I love down-to-earth data oriented programming, and I cannot stand design patterns, OOP, abstraction etc.<p>I would rather iterate over several intermediate datasets, than going into some tedious other way.<p>A computer is a machine. Why go into abstraction if your project is not complex?<p>It seems developers believe that going into higher abstraction is like using analogies, they think it&#x27;s like using a new form of language so that other developers might understand what they&#x27;re doing.<p>Of course there is a minimum of code readability, reusability and maintainability, but in the end, a computer is best as looping linear data.