Skip to main content

TECH VEDA

Embedded Linux on Edge-AI 23rd Sept 2026 enrollingLinux kernel & Device drivers starts on 24th Oct 2026 enrollingCorporate on-site training - Submit proposal Pick your modulessignup for free monthly live Masterclass Register
Career

Continuous Partial Attention: Why You Are Never Fully in the Room

Linda Stone named "continuous partial attention" in 1998: always scanning, half-available, never fully landing on anything. For engineers in the AI age, leaving that state for a few hours at a time is now a real advantage.

Continuous Partial Attention: Why You Are Never Fully in the Room

Most of us work in a state Linda Stone named “continuous partial attention” in 1998: always scanning, always half-available, never fully landing on anything. It feels like being connected, but it is the state in which you read code without seeing it and sit through a session without being in it. In a period when AI supplies answers instantly, the ability to be fully present with one difficult thing is what separates an engineer who uses the tools from one the tools replace.

In 1998, the writer and former Microsoft and Apple executive Linda Stone coined a term for a way of paying attention that most of us now treat as normal. She called it “continuous partial attention.” It describes the habit of keeping a low level of awareness spread across many channels at once — the chat window, the build log, the phone, the meeting, the tab you opened five minutes ago and have not read.

Continuous partial attention: always scanning, always half-available, never fully landing on anything.

Stone was careful to separate this from simple multitasking. When you multitask, you are trying to get more things done, and each thing is usually routine. Continuous partial attention is different in motive. You keep a slice of your mind on every channel because you do not want to miss anything — an opportunity, a message, a signal that something needs you. It is driven by a wish to be connected, and it keeps you in a permanent state of low-level alertness.

That state has a cost, and engineers pay it more often than most.

What it does to technical work

Technical work is not made of many small independent steps. It is made of a few long chains of reasoning. To find out why a driver’s probe function is failing, you have to hold several facts in your head at the same time: what the device tree says, what the bus reports, what the log printed three seconds earlier, and what you assumed but never checked. That chain takes time to build and only a moment to drop.

It feels like staying connected. It is actually the enemy of depth — the state where you read without seeing and sit in a session without being in it.

When part of your attention is permanently reserved for whatever might arrive next, the chain never gets long enough to reach the answer. You reread the same function four times. You look at the log and do not see the line that explains everything. Then, later, someone else looks at the same log for thirty seconds and finds it. The difference was not intelligence. It was presence.

This matters more now, not less. When a model can produce a plausible explanation for any error message in two seconds, the engineer who is half-present will accept the plausible explanation and move on. The engineer who is fully present will notice that the explanation does not match what the hardware is actually doing. That noticing is the job.

How to work in the opposite state

The remedy is not complicated, but it does require a decision made before you start work, not during it. Deep work needs the opposite of continuous partial attention: one thing, fully, for a while.

Presence is not a mood that arrives on its own. It is a state you enter on purpose, at the start of a session.

Some habits that make this practical:

  • Set a fixed block, and make it short enough to keep. Ninety minutes with the phone in another room is worth more than a whole day of half-attention. Start with sixty if ninety feels unrealistic.
  • Close the channels, do not just ignore them. A muted notification still costs you, because part of your mind knows it is there. Quit the chat client. Close the tabs that are not part of this task.
  • Read the important thing twice, slowly. The error message, the requirement, the datasheet section, the function you are about to modify. Most expensive bugs begin as a line someone’s eyes slid over.
  • Finish or park cleanly before you switch. If you must move to something else, write down where you were and what you were about to test. Otherwise you carry half of the old problem into the new one.
  • Notice the reflex to check. The urge to glance at something else usually arrives exactly when the problem gets hard. That moment is the work. Stay in it a little longer than is comfortable.

Using AI without losing the skill

AI assistants are not the cause of continuous partial attention — the habit is older than they are — but they make it easier to stay in it. Every question can be asked immediately, so the discomfort of not knowing never lasts long enough to force you to think.

Reach for the model after you have formed your own answer, not instead of forming one.

A practical order of work: sit with the problem, write down what you believe is happening and why, then use the assistant to test that belief, fill in what you do not know, and speed up the parts that are mechanical. You keep the reasoning; you outsource the typing. Used this way, AI raises the ceiling of what you can build. Used the other way, it quietly removes the only thing that made you useful.

At TECH VEDA we train this the same way we train any technical skill — long, undistracted sessions, where the answer is not available until you have understood the system.

Twenty-eight years after Stone named it, continuous partial attention is no longer a warning about the future. It is the default condition of most working days. Choosing to leave it, for a few hours at a time, is now a competitive advantage.

— Raghu Bharadwaj

Was this worth your time?
RB
Raghu Bharadwaj

Founder, TECH VEDA — 20+ years teaching the Linux kernel, device drivers and embedded systems.

Follow on LinkedIn

Get new posts by email

Kernel, embedded Linux and AI-era engineering — a few sharp reads a month. No spam.

We email occasionally and never share your address.