Remembering to Follow Up: Why Developers Forget Tasks (and What to Do About It)

You finish reviewing a pull request. Something looks off in the error handling, but it’s not a blocker — you leave a comment and tell yourself you’ll check back tomorrow to see if the author pushed a fix.

Tomorrow comes. You don’t check back. The PR sits for four days until someone else pings you about it.

This isn’t carelessness. It’s a well-studied failure mode in cognitive psychology, and it has a name: prospective memory failure.

The two kinds of remembering

Most of what we call “memory” in everyday conversation is retrospective memory — recalling things that already happened. What did the function return? What was the error message? What did we decide in that meeting last Tuesday?

Prospective memory is different. It’s remembering to do something in the future. Follow up on that PR. Ask about the edge case in standup. Check if the deploy went through after lunch. Revisit that flaky test once the infra changes land.

Developers rely on prospective memory constantly. And the research says it fails in predictable, systematic ways — especially under the kind of cognitive load that software development demands.

It’s not a personal failing

Dismukes (2012) studied prospective memory failures across professional settings and found that they’re not individual character flaws. They’re systemic. The failures happen most often when the cue to act is subtle or absent — when there’s no alarm, no popup, no external trigger to remind you that it’s time.

Think about the “check if the deploy went through” example. Nothing in your environment changes when the deploy finishes. There’s no tap on the shoulder. You have to spontaneously remember, mid-task, that you intended to check. And if you’re deep in a different problem by then, the odds aren’t in your favor.

Dismukes found this pattern across aviation, healthcare, and office work: the more absorbed someone is in their primary task, the more likely they are to miss a delayed intention, even when they fully planned to do it.

Full paper — see reference [1] below.

The cognitive load problem

The reason prospective memory is so fragile for developers is context switching. Your working memory can hold roughly four items at a time. When those four slots are occupied by a debugging session — call stack, variable state, control flow, the hypothesis you’re testing — there’s no room left for “remember to check that deployment.”

This is the gap between intention and execution. You formed the intention when you had spare capacity (right after kicking off the deploy). But the moment you need to act on it, your capacity is allocated elsewhere. The intention is still in long-term memory somewhere, but there’s no retrieval cue to pull it forward.

The result: you “forget” things you genuinely intended to do, and it feels random. But it’s not random at all. It’s a resource allocation problem.

What makes a reminder actually work

Here’s where the research gets practical. Kuhlmann and Rummel (2022) studied how offloading prospective memory to external tools affects performance. Their finding was nuanced: external reminders help, but only when the reminder encodes both the target event and the intended action.

In plain terms: a sticky note that says “Bug #4523” is almost useless. You’ll see it later and think, “…what about Bug #4523?” But a note that says “Bug #4523 — ask Sarah about the edge case in standup” actually works. The reminder reconstructs enough context to act on, without requiring you to re-derive why you wrote it down.

This has real implications for how developers take notes. Bookmarking a work item URL doesn’t cut it. Starring it in a tool doesn’t cut it. The reminder needs the why — what you intended to do, and when or where you intended to do it.

Full paper — see reference [2] below.

Knowing you’ll forget is a superpower

Kelly and Risko (2019) found something encouraging: people who have accurate metacognitive awareness of their own memory limits are more likely to offload effectively. In other words, knowing that you’ll forget makes you better at compensating for it.

Developers who say “I’ll just remember” are the ones most at risk. Developers who reflexively write things down — who assume their future self will have zero recollection of the current moment — consistently perform better on delayed intentions.

This isn’t about discipline or personality. It’s a learnable habit. Once you internalize that prospective memory is unreliable under load, you stop trusting it and start building systems.

Full paper — see reference [3] below.

Building a system that doesn’t depend on your brain

So what does a good follow-up system look like, based on the research?

The reminder lives next to the thing it’s about. Not in a separate app, not in a text file somewhere. It’s attached to the work item, the PR, the ticket — wherever you’ll encounter it again.
The reminder includes the action, not just the reference. “Follow up” means nothing a week later. “Ask Sarah about the null check edge case before merging” means everything.
The system surfaces reminders without requiring you to remember they exist. If you have to remember to check your reminders, you’ve just moved the prospective memory problem one level up.

This is the thinking behind custom lists in TicketHop. When you’re working in Azure DevOps and you hit something that needs a follow-up — a PR to revisit, a work item to check on, a question to raise in standup — you add it to a list with a note that captures the full intention.

The note isn’t just the work item ID. It’s the what and the why, written in the moment when you have full context. “Bug #4523 — Sarah said the edge case only reproduces with EU locale settings, confirm her fix handles the date format.” That’s the kind of reminder that Kuhlmann and Rummel’s research says actually leads to action.

Because the notes are private and attached directly to the work item, they surface when you naturally encounter the item again — no separate app to check, no sticky notes to lose track of. The next time you open that work item or scan your list, the context is just there.

The low-effort version

You don’t need a complex system. The research suggests a minimal approach:

When you form an intention, write it down immediately. Don’t tell yourself you’ll remember. You won’t — not because you’re forgetful, but because your working memory will be full of something else when the time comes.
Include the action, not just the reference. Spend the extra ten seconds to write what you’re going to do and why. Your future self will thank you.
Put the reminder where you’ll see it. Co-locate it with the work, not in a separate productivity app you’ll check for two weeks and then abandon.

That’s it. No elaborate GTD framework, no daily review ritual. Just a habit of externalizing intentions the moment they form, with enough context to act on later.

If you work in Azure DevOps and want a low-friction way to do this, TicketHop takes about 30 seconds to set up. But whatever tool you use, the underlying principle is the same: stop asking your prospective memory to do a job it was never designed to handle under load.

References

[1] Dismukes, R. K. (2012). “Prospective Memory in Workplace and Everyday Situations.” Current Directions in Psychological Science, 21(4), 215–220. https://journals.sagepub.com/doi/10.1177/0963721412447621

[2] Kuhlmann, B. G. & Rummel, J. (2022). “Benefits from Prospective Memory Offloading Depend on Memory Load and Reminder Type.” Journal of Experimental Psychology: Learning, Memory, and Cognition, 49(7), 1120–1131. https://pubmed.ncbi.nlm.nih.gov/36201804/

[3] Kelly, M. O. & Risko, E. F. (2019). “A Role for Metamemory in Cognitive Offloading.” Cognition, 193, 104012. https://www.sciencedirect.com/science/article/pii/S0010027719301854