In 1927, a Soviet-Lithuanian psychologist named Bluma Zeigarnik was sitting in a Vienna café watching the waiters. She noticed something odd. They could rattle off the precise contents of a long, unpaid table order without writing it down. The moment the bill was settled, the same waiter could barely remember what the table had ordered. The information just… evaporated, the second it was no longer needed.

Zeigarnik went back to the lab, ran the experiment properly, and confirmed it. Across multiple studies, people remembered interrupted or unfinished tasks roughly twice as well as completed ones. The effect now bears her name. It’s one of the older, more reliable findings in psychology - and it shows up almost everywhere in modern life, including, I’d argue, in how we write software.

The everyday version

Once you know what to look for, the Zeigarnik effect is everywhere.

  • TV cliffhangers. The reason you can’t stop thinking about a season finale is that the writers have deliberately left the loop open. Inception’s spinning top is the canonical example, Christopher Nolan handed an entire generation a recurring intrusive thought.
  • Open browser tabs. The 47 tabs you’ve been “meaning to read” aren’t open because you’re disorganised. They’re open because each one is an unfinished task and your brain is keeping the receipt for each.
  • The call you haven’t returned. You missed a call from a friend or relative three days ago. You haven’t called back. You’re not ignoring them - you’ve just been meaning to find a good moment. That low-level guilt that surfaces every time you pick up your phone isn’t anxiety. It’s your brain keeping the receipt on an unfinished task.
  • Abandoned shopping carts. This is so well-known that retailers built entire email funnels around it. Amazon doesn’t email you about things you bought and forgot. They email you about the thing you almost bought and didn’t, because that’s the open loop they can re-engage.
  • Songs stuck in your head. Neuroscientists have shown that earworms are usually fragments - partial choruses, the bit just before the hook. Your brain is trying to complete them. Hum the rest of the song and the loop closes.

The unifying observation: the brain keeps unfinished things on the active list, and pays a small ongoing cost in attention until they’re closed.

The original story, slightly clearer

Zeigarnik’s setup was simple. Subjects were given short tasks - puzzles, beadwork, arithmetic. About half were allowed to complete, the rest were interrupted partway. Later, when asked to recall what they’d been working on, subjects remembered the interrupted tasks about 90% of the time, against roughly 50% for the completed ones.

What’s elegant about the result is that the interrupted tasks weren’t more interesting, longer, or more personal. The only difference was the lack of closure. The unfinished thread itself was the memory hook.

A century of replications later, the effect is well-trodden. The neuroscience is less settled, there’s still a debate over whether unfinished tasks live in some explicit “things to do” cache or whether they’re just more accessible because you’re still rehearsing them but the behaviour is solid.

The engineering version

This is where it gets personal for me. The Zeigarnik effect explains a lot of what good and bad software development feels like from the inside.

1. The TODO that won’t shut up

Every codebase has a TODO that’s been sitting there for two years. Nobody fixes it. But every time someone opens that file, they read it, register it, and silently re-add it to their personal “things hanging over the project” list. The TODO is doing exactly what Zeigarnik would predict - a small, open task taking up working-memory space, every single time.

The fix isn’t to fix the TODO. It’s to either do it now or delete the comment and the implicit obligation. Logging the work in a tracker (Linear, Jira, GitHub Issues) closes the in-code loop while preserving the work. The brain stops carrying the receipt; the project still tracks the task.

2. WIP branches and half-finished PRs

The interrupted refactor I started six weeks ago is still loaded in my head. I can recall, at startling resolution, the exact spot in the call graph I was working on, the file I last touched, the half-decision I made about whether to introduce a new abstraction. None of it is written down. All of it is taking up space.

When I finally come back to that branch, two things happen. First, the recall is impressive, I pick up almost where I left off. Second, I realise that for those six weeks, some fraction of my background attention has been quietly devoted to keeping that context warm. That’s a real cost. It’s why senior engineers I respect ruthlessly close tabs, branches, and Slack threads; they know the open loops compound.

The pragmatic fix: write a short note when you stop. Three sentences in a Markdown file at the root of the branch.

“I was about to extract processWithRetries. The tricky bit is the exponential backoff math; I haven’t decided if the jitter should live inside or outside. Resume by reading src/job-runner.ts:142.”

That handful of sentences buys back the attention you’d otherwise spend keeping the context alive.

3. Hemingway’s trick

Ernest Hemingway famously said that he’d always stop writing for the day in the middle of a sentence, never at the end of a chapter or even a paragraph. The next morning, he’d sit down and finish the sentence, and the writing would flow from there.

It’s a deliberate exploitation of Zeigarnik. By leaving an obvious unfinished task at the end of yesterday’s session, you give your brain a clear, short, on-ramp for tomorrow’s session. The cold-start problem of resuming work disappears, because there’s a half-formed loop calling out to be closed.

The same trick works on code. When I’m wrapping up at the end of a day with unfinished task, I deliberately try to leave the build broken in a small, mechanical way - a missing import, a renamed function call I haven’t propagated. Tomorrow’s me sits down, sees the error, fixes it, and is already in the file, already focused, already reading code. The Zeigarnik nudge has dragged me past the worst part of resuming, which is figuring out where to look first.

4. The CI red badge

There’s a reason a red CI status icon is so effective. The build is broken. The loop is open. Until it’s green, the icon is a low-grade Zeigarnik tax on every developer who looks at the repo. Most engineering cultures rely on this - make the failing state painfully visible, and the team naturally pulls toward closing it. The moment the icon turns green, the unease drops to zero.

If the badge has been red for three days, the brain stops treating it as an open loop and starts treating it as background noise. The Zeigarnik nudge degrades. Now you have a problem nobody’s actively thinking about, which is much worse than one that’s loud and uncomfortable.

5. Notifications and dialogs that demand action

This is the dark side of the same effect. Modal dialogs, badges, and notifications are designed to plant an open loop in your head. “1 unread message.” “You have 3 alerts.” Each one is a tiny Zeigarnik dart aimed at your attention.

Used well: to flag a genuine open task that you should close, they’re useful.
Used badly: to keep you opening the app, they’re parasitic.

The hardest thing about modern software design is the line between the two, because the mechanism is identical.

I now treat notification settings as a hygiene practice, the same way I treat closing browser tabs. If a badge isn’t pointing at a task I genuinely want to close, it’s not informing me, it’s renting space.

6. The graveyard of side projects

Every developer I know has a ~/code/ folder full of half-finished side projects. A habit tracker with a sleek UI. A RSS reader. A budgeting app. A URL shortener that never got past the schema. They sit there, three commits in, the README half-written.

Zeigarnik explains why this hurts more than it should. Each abandoned project is an open loop. You started it, you didn’t finish it, and your brain keeps it on the list. Years later, every time you cd into the folder, you feel the small twinge of a thing you owe yourself.

It also explains the trap - the thing where you keep starting new side projects instead of finishing the old ones. The fresh idea is shinier because it’s a brand new open loop. The old one is shinier because it’s a still-open loop. Both are pulling on attention, and the brain, which has no good way of comparing the two; defaults to whichever is most novel right now. So you start a new repo, get to three commits, and the cycle begins again.

The hack I’ve slowly learned is that shipping is the closure mechanism. Even if “shipped” just means “deployed to a free-tier Netlify URL nobody else will visit”, the act of putting something into the world flips the loop from open to closed. The project moves from “thing I’m working on” to “thing I built”, and the brain’s relationship to it changes overnight.

This is why “build in public” works for a lot of people. It’s not about marketing; it’s about creating an external commitment that forces closure. The same project, kept private, will sit unfinished for years. Announced on a Friday with a “shipping next weekend” tweet, it’ll get shipped. Different project, same code, only the closure mechanism changed.

If shipping isn’t possible, deletion is. A surprisingly liberating exercise: walk through your ~/code/ folder, look at each old folder, and ask “do I genuinely intend to come back to this?”. For 90% of them the honest answer is no. Delete the folder. The closure isn’t just “I finished it!”, it’s also “I let it go”. Both close the loop. Both free the attention. The graveyard, finally, is empty.

The business version

Once you’ve seen Zeigarnik in your codebase, you start seeing it in every product you use. A frightening number of modern apps are built on top of carefully engineered open loops.

Streaks

Duolingo’s streak counter is the cleanest example I can think of. The moment you’ve practised for one day, the loop is open - the streak exists, it can be broken. The thought of breaking it is, neurologically, the thought of failing to close a loop you’re already invested in. Same with Wordle, GitHub’s contribution graph, fitness app streaks, Snapchat snapstreaks. None of these would feel compelling on day one. They become compelling on day three, because by then there’s a continuous, fragile open loop the user is committed to keeping alive.

The engineering for this is trivial - a counter and a timezone-aware reset job. The psychology is everything.

Continue watching / Resume reading

Netflix’s continue-watching row, Spotify’s recently-played, Kindle’s “you’re 38% through this book”, all of them are explicit Zeigarnik nudges. The product is reminding you of an unfinished task you started. The reminder works precisely because the task is unfinished, your brain was holding the receipt anyway, and the UI surfaced it.

This is also why books abandoned 30 pages from the end haunt readers far more than books abandoned at chapter 2. Closer to closure, stronger pull.

Progress completion meters

LinkedIn’s “your profile is 85% complete” is a small masterpiece of psychological design. Without that meter, an incomplete profile feels fine, there’s no reference point. With the meter, the profile becomes a partially-filled task, and the brain treats it as such. The 15% gap is now an open loop you didn’t know you had until LinkedIn told you.

The same trick is used by onboarding wizards in SaaS products. “You’ve set up 3 of 5 things.” Each unchecked box is a small open loop. Some of them genuinely matter for activation. Some of them are theatre. The behavioural effect is the same either way.

Cancellation friction

The dark mirror of all of this is the cancel flow. When companies make subscription cancellation hard: “are you sure?” → “we’ll miss you” → “here’s a discount” → “click these three places to confirm”, they’re exploiting Zeigarnik in reverse. They’re betting that you’ll get fatigued, leave the cancel flow half-finished, and the open loop will silently fail to close. A month later you’re still subscribed because you never got past the third confirmation page.

This is regulated in some jurisdictions for a reason. The asymmetry, it’s easy to start, hard to stop; is a deliberate exploitation of how working memory handles unclosed tasks.

Drip campaigns and abandoned-cart emails

I mentioned abandoned-cart emails earlier, they’re the textbook case. Same playbook: drip-marketing campaigns that “remind you” of webinars, courses, or trials you started but didn’t finish. Done well, this is genuinely useful (the Duolingo “your owl is sad” emails close a loop the user wants closed). Done badly, it’s harassment.

Side-project closure as a business idea

The flip side of all of this, and this is the one I find most interesting, is that there’s a genuine product category around helping people close their open loops. Todoist, Things, Notion, Linear, Trello, Bear, Obsidian, the “second brain” / GTD tooling space exists almost entirely because Zeigarnik is real. Users will pay for software whose only job is to convince their brain that an open loop has been written down somewhere safe.

The most successful products in this space don’t make you more productive. They make you feel like the open loops have been captured. That’s the actual transaction. Productivity is a side effect.

Closing the loops

The most useful takeaway from Zeigarnik research is, weirdly, just an awareness rule:

An open loop costs attention until it closes. Either close it, or write it down somewhere your brain trusts will close it later.

That’s the whole productivity system. Inboxes, tickets, project boards, sticky notes, they all work because they trick the brain into letting go of an open loop, on the agreement that the loop is logged elsewhere. The actual closure can wait. The brain just needs to believe it’s been recorded.

Without that trust, every open loop sits in active recall, paying interest forever. With it, you can hold a hundred unfinished tasks across a project and not feel them, because each one has been shifted from the brain’s working memory to a system you can re-check.

Software, in some sense, is the act of opening hundreds of small loops and closing them in the right order. The Zeigarnik effect is the reason the unclosed ones haunt you, and also the reason, when used carefully; they’re useful.