How to focus on code

NEDIO already has a longer guide on how to focus while coding. It is about the day: why starting is hard, what interruptions cost, how to survive a slow build, and how to protect flow. This page assumes you are already sitting in front of the editor and asks a smaller question: what do you do with your attention, and with the editor, so that it stays on the code?

If your problem is that you cannot start, or that chat keeps pulling you away, read the main guide first. If you are looking at the code and keep sliding off it, stay here.

People search for this phrase for different reasons. Some want to stop drifting while they read or write code. Some are looking for an editor feature that dims everything except the current scope. Some are asking a philosophical question about whether developers should focus on code at all or on the software it produces. This page answers the first two, because they are the ones you can act on today.

Practically, focusing on code has three layers, and each can fail on its own:

• Scope: how much code you are trying to hold at once. Too much, and you skim.
• Surface: what else is on the screen. Panels, badges, and tabs that are not part of the task are small invitations to look elsewhere.
• Question: what you want the code to tell you. Without one, reading is passive and attention slides easily.

The rest of the page goes through them in that order, then covers feedback, code you did not write, and getting back after a break.

Working memory is limited, and code asks a lot of it: variable meanings, call order, what a function returns on the unhappy path, what you changed ten minutes ago. When the target is “the billing module”, you cannot hold it, so your mind keeps reaching for the next thing. That reads as lost focus, but often it is just an object that is too large.

Pick the smallest unit that can still produce a result: one function, one branch, one failing test, one error message. Name it in a sentence with a verb: “find where parseInvoice() returns null for an empty line.” If you cannot write that sentence, the work has not narrowed enough, and the right next step is to narrow it, not to read harder.

A concrete if-then plan helps here. Gollwitzer’s work on implementation intentions suggests that a specific plan (“if the test fails, I read the stack trace from the top and open the first frame in my own code”) is easier to follow than an intention to “debug this.” You do not need to believe a particular effect size to use the idea: a plan that names the first move removes a decision.

Write the unit and the question in a place you will see them, such as a comment at the top of the scratch file, a line in the sprint goal, or the first line of a notes buffer. The sentence is your anchor when attention slips.

Most editors ship with several features that reduce what competes with the code. None of them creates focus; they remove predictable reasons to look away. Use the ones that match your problem rather than switching everything on.

Check the exact shortcuts and setting names against your own version, since editors rename and move them. The principle is stable: the code, its test, and its output should be the only things asking for your eyes.

A related trap is the second monitor or window full of reference material. If you need it, keep it to the single page that answers your question. Ten open documentation tabs are ten ways to leave the code “just to check something.”

Reading a file from line one to the end is a poor way to stay focused, because nothing tells you when you are done or what to keep. Attention does better with a target. Before you read, write the question: “what calls this?”, “where does this value become null?”, “what does this return when the list is empty?”

Then read in this order, and stop when the question is answered:

1. Start at an entry point you can run: a failing test, a log line, a route handler. Code you can execute gives you something to check your reading against.
2. Follow one path: go down the call that matters for the question and ignore the branches that do not. Note them in one line and leave them.
3. Predict, then confirm: say what the next line should produce, then run or log it. A wrong prediction is the quickest signal that your mental model has a gap.
4. Write the answer down: one line in your notes. Reading that ends in a sentence is easier to keep your attention on than reading that ends when you get tired.

Side questions will come up. Park them in a “later” list instead of chasing them; each chase is a context switch inside your own head. Research on attention residue suggests that an unfinished thread can keep occupying you after you leave it, which is one more reason to write the parked item down and close it.

Attention follows feedback. If you can change a line and see the result in seconds, your focus has a reason to stay on the code. If every check takes a four-minute build, the gap invites a tab switch, and the switch is where the session often ends.

Tactics that shorten the loop without a big tooling project:

• Run the single test, not the suite, while you work on one unit. Run the suite at the end of the block.
• Use a watch mode, a REPL, or a scratch file for the function under study so you can call it directly.
• Log one value at a time. A wall of output makes you read the log instead of the code.
• When a run is unavoidably slow, write the next step first, then start it. See the build-wait section of the main focus guide for what to do with the gap.

Code from a teammate, a library, or an assistant is harder to focus on because you do not already hold its model in your head. The usual failure is skimming: the diff looks plausible, so you accept it without reading the parts that carry the risk.

Read it in passes with one purpose each. First pass: what is the shape of this change and which files does it touch? Second: what happens on the error path? Third: what data does it read or write? Stop each pass when you have the answer, and pick the next pass deliberately. A long diff read as one undifferentiated pass is where attention tends to give out.

The same applies when an assistant produces a large patch. Treat each hunk as a unit with its own question, and run it before you move on. The longer walkthrough is in review AI-generated code without losing the thread, and if you are stuck in repeated failed patches, see how to escape an AI debugging loop.

Even a good setup breaks: a meeting, a question from a colleague, lunch. The cost shows up when you come back. In an observational study of programmers resuming after interruptions, Parnin and Rugaber found that most sessions did not resume programming within a minute, and that people typically navigated to other files and locations before their first edit. Coming back to code is mostly re-orientation, not typing.

You can make that re-orientation cheaper before you leave and when you return:

• Before leaving: leave a failing test, a TODO at the exact line, or a one-line note with the next command. A code state that tells you what to do is the best handoff.
• On return: read the note, then the diff since the last commit. Do not open the tabs you had before. Open only the file the note names.
• First action: run the failing test or the command in the note. A result in under a minute pulls your attention back onto the code.

For the end-of-day version of this, see stop coding and resume tomorrow without rebuilding context, and for the evidence on switching, see context switching cost for developers.

Here is how the pieces fit in one block. The task: an invoice parser returns null for some inputs, and you do not know why.

1. Minute 0–2, scope and question. Write: “Find why parseInvoice() returns null for the empty-line case.” Done when one failing test pins the cause.
2. Minute 2–4, surface. Turn on Zen Mode, close every tab except the parser, its test file, and the terminal. Mute chat.
3. Minute 4–10, read with the question. Open the parser at the function, follow the empty-line path only, predict what each step returns. Park an unrelated naming issue on the “later” list.
4. Minute 10–20, short loop. Write a failing test for the empty-line input and run just that test. Log one value. Adjust the prediction until the test fails for the reason you expect.
5. Minute 20–25, clean ending. Write one line: “Cause: trailing newline trims to an empty string, returns null at line 42. Next: return an empty list and update the caller.” Commit the failing test.

Nothing here depends on feeling focused. It depends on a small object, a visible question, a quiet screen, and a result you can run.

Open this editable 25-minute example

Using Zen Mode as the whole plan. Hiding the sidebar helps, but if the target is “the billing module”, you will still drift. Narrow the scope first; set up the surface second.

Reading without a question. A file read from the top has no natural end, so you quit when you tire rather than when you have the answer.

Chasing every side thread. Each detour is a small context switch. Park it in one line and return.

Running the whole suite for every change. A slow loop gives your attention somewhere else to go.

Treating drift as a character flaw. If you slide off the code repeatedly, check the size of the object, the clutter on the screen, and the length of the loop before you blame discipline. If trouble with attention is persistent and affects your life beyond work, talk to a qualified professional; this guide is a workflow lens, not medical advice.