DEV Community: Spartan Rich

Stuck on a Bug? Your Brain Solves It Better on the Edge of Sleep

Spartan Rich — Sat, 14 Nov 2026 07:41:29 +0000

Some bugs get fixed at the keyboard. A surprising number get fixed in the shower.

You know the pattern. You stare at a failing test for two hours. Nothing. You give up, go make dinner, and halfway through chopping an onion the answer drops into your head, fully formed: the cache key doesn't include the locale. Of course it doesn't.

It feels like luck. It's closer to a mechanism. Psychologists call it incubation, and over the last few years researchers have started pinning down when it works, when it doesn't, and one strange moment where it seems to work best of all.

Edison's falling spheres

There's an old story about Thomas Edison. When he was stuck on a problem, he would sit in a chair holding small metal spheres and let himself drift off. The moment he fell asleep, his hand would relax, the spheres would clatter to the floor, and he'd wake up and write down whatever was in his head.

For about a century, that was an anecdote. Then in 2021 a team at the Paris Brain Institute, led by Célia Lacaux and Delphine Oudiette, actually tested it.

They gave 103 people a number puzzle. Each trial was a string of eight digits, and you had to grind through them with two simple rules to reach a final answer. What nobody told them: there was a hidden shortcut. The second answer you computed was always the final answer. Spot that and every trial takes a few seconds instead of a dozen.

After some practice, people got a 20-minute break. They reclined with their eyes closed, holding a light plastic bottle in one hand, while EEG tracked their brain state. If the bottle dropped, they said out loud what they'd been thinking.

Then everyone went back to the puzzle.

The 15-second sweet spot

Here's what the team reported in Science Advances:

People who stayed fully awake during the break: 31% later found the shortcut.
People who slipped into N1, the light, drifting first stage of sleep, for at least one 30-second scoring window: 83% found it.
People who went deeper, into N2 sleep: 14%.

That's 2.7 times more insight from barely dozing. And the benefit vanished if they went too deep. The paper's title says it plainly: "Sleep onset is a creative sweet spot."

The EEG data backed this up. The best outcomes lined up with a middle level of alpha waves (relaxed, eyes-closed wakefulness) and low delta (the slow waves of deeper sleep). Not alert. Not asleep. Somewhere in between.

And Edison's bottle? It was a decent sleep-onset detector, and it seemed to help keep people in that twilight state instead of sliding into N2. The authors are careful here: they say a control without the bottle would be needed before calling the trick itself effective.

One more detail I love. The "eureka" didn't arrive the instant people woke up. On average it came about 94 puzzle trials later, roughly half an hour after the break. The nap didn't hand them the answer. It seems to have set something up that clicked once they were back at it.

So is walking away a real strategy?

Mostly yes, with conditions that matter a lot for how developers take breaks.

In 2009, Ut Na Sio and Thomas Ormerod pooled 117 incubation studies (3,606 participants) in Psychological Bulletin. Setting a problem aside before trying again did help on average. The effect was modest (an effect size around 0.3), not magic. But two moderators stand out:

Longer preparation gave a bigger incubation effect. You have to actually wrestle with the problem first. The break works on material you've loaded into your head, not on a ticket you skimmed.
Filling the break with demanding work shrank the effect. Swapping one hard problem for another is not incubation. It's just switching.

A 2012 study from Jonathan Schooler's lab at UC Santa Barbara sharpened that second point. Benjamin Baird and colleagues had 145 people list unusual uses for everyday objects, then gave them a 12-minute break doing one of three things: a demanding memory task, an easy task that let the mind wander, or simply resting. A fourth group got no break.

When people returned to the same objects, the undemanding task group improved the most. It beat demanding work, and it even beat sitting quietly. Interestingly, those people didn't report thinking about the problem more on purpose. Their minds were just free to wander.

So the shower, the dishes, the walk to get coffee. Low-effort tasks that leave room for drifting thoughts look like close to the ideal break. Opening Slack and triaging five other tickets looks like close to the worst one.

What this means if you write code

Some honest caveats first. Lacaux's groups weren't randomly assigned: people fell asleep or didn't on their own, and the N1 group was 24 people. Number puzzles and alternate-uses lists aren't race conditions. These are interesting, well-run studies, not proof that a nap will fix your build.

Still, the pattern across them is consistent enough to try:

Earn the break. Work the bug properly first. Write down what you know, what you've ruled out, and the exact symptom. That's the "preparation" the meta-analysis says pays off.
Make the break boring. Walk, wash a mug, stretch, stare out a window. Skip the hard context switch and skip the feed.
Try a "bottle nap" when it's really stuck. Sit back, close your eyes, hold something that will fall when you drift, and let it drop. Write down whatever was in your head. Then go back to the code and give it a real half hour, since the click may come later.
Don't nap too long. In the study, going deeper erased the benefit. This is a doze, not a siesta.

The part nobody mentions

Incubation can only recombine what's already in your head. If the thing you needed (that blog post on cache keys, the talk on locale bugs) went in one ear and out the other, there's nothing for your drifting brain to connect.

That's one reason I built Recl. I save the talks and articles I learn from, it pulls out the key takeaways, and it brings them back later as quick recall questions on a spreading schedule. It's not a bug-fixer. It just helps more of what I read stay around long enough to show up in the shower.

Next time you're stuck, don't push for another hour. Load the problem in fully, then go do something dull. Your brain may not be done with it yet.

Asutosh writes about memory and how brains learn, and builds Recl, an app for remembering what you watch and read.

References

Lacaux, C., Andrillon, T., Bastoul, C., Idir, Y., Fonteix-Galet, A., Arnulf, I., & Oudiette, D. (2021). Sleep onset is a creative sweet spot. Science Advances, 7(50), eabj5866. https://www.science.org/doi/10.1126/sciadv.abj5866
Sio, U. N., & Ormerod, T. C. (2009). Does incubation enhance problem solving? A meta-analytic review. Psychological Bulletin, 135(1), 94–120. https://pubmed.ncbi.nlm.nih.gov/19210055/
Baird, B., Smallwood, J., Mrazek, M. D., Kam, J. W. Y., Franklin, M. S., & Schooler, J. W. (2012). Inspired by distraction: Mind wandering facilitates creative incubation. Psychological Science, 23(10), 1117–1122. https://pubmed.ncbi.nlm.nih.gov/22941876/

Why You Blank on Easy Commands During an Outage (Your Brain Has a Stress Switch)

Spartan Rich — Fri, 13 Nov 2026 19:31:09 +0000

Stress doesn't erase what you know. It locks the door to it.

You've probably felt this. Production is down, Slack is on fire, three people are watching your screen share, and you can't remember the flag for git reset. You've typed it a hundred times. An hour later, coffee in hand, it comes back instantly.

That isn't you being bad at your job. It's a well-studied feature of the human brain, and it has a slightly annoying lesson for how we learn things in the first place.

The words were still there. They just wouldn't come out.

In 2005, Sabrina Kuhlmann, Marcel Piel and Oliver Wolf at the University of Düsseldorf ran a simple experiment on 19 young men. On day one, each learned a list of 30 words. On day two, some had to go through the Trier Social Stress Test first: a mock job interview and mental arithmetic in front of an unsmiling panel. It's the lab equivalent of a live incident review.

Ten minutes later, right around the time cortisol peaks, they tried to recall the list.

After the control task, they remembered about 64% of the words. After the stress test, about 57%. The words had been learned under calm conditions the day before. Nothing about the learning changed. Only the moment of retrieval did.

Two details are worth noticing. The drop hit emotionally charged words hardest, and cued recall, working memory and attention didn't change in that study. Stress didn't wipe the memory. It made pulling it out on demand harder.

Your prefrontal cortex goes offline first

Why would a brain do that? Yale neuroscientist Amy Arnsten spent years on that question. Her 2009 review in Nature Reviews Neuroscience lays it out: the prefrontal cortex, the part that holds things in mind, plans and reasons, is the brain region most sensitive to stress. Even mild stress you can't control floods it with noradrenaline, dopamine and cortisol, and at high levels those chemicals weaken the connections between prefrontal neurons.

Meanwhile the same chemicals strengthen the amygdala and older, more automatic circuits. In Arnsten's words, stress switches control from the thoughtful prefrontal cortex to more primitive conditioned responses.

From an evolutionary angle, that's sensible. If something is chasing you, you don't want to weigh options. You want to run.

During an outage, it's the worst possible trade. Debugging is almost pure prefrontal work: holding a hypothesis, the logs and the last deploy in your head at once.

Stressed brains fall back on habits

Lars Schwabe and Oliver Wolf, then at Ruhr University Bochum, showed the other half of this in 2009. They had people learn two actions that each earned a different food reward. Some were stressed first (one hand in ice water while being filmed and judged). Then one of the foods was "devalued": participants ate it until they were sick of it.

Unstressed people adjusted. They stopped working for the food they no longer wanted. Stressed people kept doing the old action anyway, as if on autopilot. They also understood the setup worse: 58% of controls could name which action led to which food, against 28% of the stressed group.

Schwabe and Wolf called it the first evidence in humans that stress pushes behaviour from goal-directed to habit.

Anyone who has been on call knows the developer version. You restart the pod because restarting the pod is what you always do. You rerun the failing deploy. Your hands go for the familiar move while the part of you that would ask "wait, what actually changed?" is the part stress just dimmed.

The fix starts before the incident

So far this sounds hopeless. It isn't, and the most interesting study here is about learning, not stress.

In 2016, Amy Smith, Victoria Floerke and Ayanna Thomas at Tufts published a paper in Science with 120 people. Everyone studied 30 words and 30 pictures. Half then learned by restudying, reading the items again. The other half used retrieval practice: closing the material and recalling as much as they could, several times, with no feedback.

The next day, half of each group went through the same kind of stress test, with speeches and math in front of judges.

People who had restudied showed the usual stress dip. On a test about 25 minutes into the stress response, they recalled around 7 items, compared with a little under 9 for the unstressed restudiers. The retrieval-practice group recalled around 11 whether they were stressed or not. Stressed retrieval learners even beat calm restudiers.

The authors' reading: stress hurts weak, shallow memories most. Memories you've already pulled out of your head several times are sturdier.

Now the honest caveat, because this one gets oversold. Replications have been mixed. A registered meta-analysis by Swiss researchers led by Mariela Mihaylova, published in Swiss Psychology Open in 2025, pooled 10 studies with 908 people. Retrieval practice clearly beat restudying under stress (Hedges' g = 0.45). But across those studies, stress didn't reliably hurt either group, so whether retrieval practice specifically "protects" against stress is still open.

What holds up either way: memories you've practised retrieving are stronger, and that advantage survives stressful conditions. When you need it most, it's still there.

Something to try this week

You can't make outages calm. You can change what's in your head before the next one.

Write your runbook from memory first. Pick one incident type you dread (a full disk, a bad migration, an expired cert). Before opening the real runbook, write the steps from memory. Then compare. The gaps are exactly what would vanish at 3 a.m.
Quiz yourself on the commands you keep looking up. The kubectl flags, the git recovery moves, the SQL to find a blocking query. Cover the answer and type it. Getting it wrong first is fine; that attempt is the practice.
Run small fire drills. Teams that do game days are rehearsing retrieval under mild pressure. Even ten minutes of "the database is read-only, go" with a teammate counts.
When it happens, buy back your prefrontal cortex. Arnsten's work points to uncontrollable stress as the trigger. Saying the plan out loud, writing the timeline in the channel, or handing off comms are ways to make the situation feel more controllable. Slow is smooth.

Where I keep mine

Most of what I'd need in an incident I first learned from a conference talk, a post-mortem, or a thread, and then never saw again until the bad day arrived. That's part of why I built Recl. You save the talk or article, it pulls out the key takeaways, and later it asks you about them on a spreading schedule ("Still remember this one?"), so the useful stuff gets retrieved a few times before you need it under pressure.

Next time you blank on an easy command mid-outage, don't read it as "I don't know this." Read it as "I only learned this the comfortable way." Pull it out of your head a few times this week, while nothing is on fire.

Asutosh writes about memory and how brains learn, and builds Recl, an app for remembering what you watch and read.

References

Kuhlmann, S., Piel, M., & Wolf, O. T. (2005). Impaired memory retrieval after psychosocial stress in healthy young men. Journal of Neuroscience, 25(11), 2977–2982. https://www.jneurosci.org/content/25/11/2977
Arnsten, A. F. T. (2009). Stress signalling pathways that impair prefrontal cortex structure and function. Nature Reviews Neuroscience, 10, 410–422. https://pmc.ncbi.nlm.nih.gov/articles/PMC2907136/
Schwabe, L., & Wolf, O. T. (2009). Stress prompts habit behavior in humans. Journal of Neuroscience, 29(22), 7191–7198. https://pmc.ncbi.nlm.nih.gov/articles/PMC6666491/
Smith, A. M., Floerke, V. A., & Thomas, A. K. (2016). Retrieval practice protects memory against acute stress. Science, 354(6315), 1046–1048. https://www.science.org/doi/10.1126/science.aah5067 (summary: https://www.sciencedaily.com/releases/2016/11/161124160426.htm)
Mihaylova, M., Zocca, M., Kliegel, M., & Rothen, N. (2025). Does retrieval practice protect memory against stress? A meta-analysis. Swiss Psychology Open, 5. https://swisspsychologyopen.com/articles/10.5334/spo.101

Senior Devs Don't Have Better Memory. They Have Bigger Chunks.

Spartan Rich — Fri, 13 Nov 2026 07:44:39 +0000

A chess master can glance at a board for five seconds and rebuild most of it from memory. Scatter the same pieces at random and he does no better than a beginner.

That one result, from a 1973 paper by William Chase and Herbert Simon, quietly explains something every developer has felt. You know the senior engineer who skims a 300-line diff and says "this breaks the retry logic" before you've found the function. It looks like a better memory.

It isn't. It's a bigger alphabet.

Five seconds with a chessboard

Chase and Simon worked with three players: a master, a Class A player and a beginner. Each one looked at a position for five seconds, then rebuilt it on an empty board.

On middle-game positions taken from real games, with 24 to 26 pieces on the board, the master placed about 16 pieces correctly on the first try. The Class A player managed about 8. The beginner, about 4.

Then the researchers took real positions and put the pieces on random squares. The master's advantage vanished. In their words, there was "no relation at all between memory of the position and playing strength." All three did worse on random boards than the beginner had done on real ones.

The interesting part came from watching how they recalled. Players put down a few pieces in a quick burst, paused, then put down another burst. Chase and Simon read each burst as one chunk: a cluster of pieces the player already knew as a single thing, think of a castled king tucked behind its pawns. The master recalled more chunks, and bigger ones.

His storage wasn't bigger. His units were.

Later work by Fernand Gobet and Simon (1996) put a rough size on the library behind those units. Their simulation fit the usual estimate that a master stores some 50,000 chunks. They also found that mirroring a position hurt recall, which means a chunk is a specific pattern in a specific place. It isn't a vague sense of "good chess."

Then someone tried it with code

In 1981, Katherine McKeithen, Judith Reitman, Henry Rueter and Stephen Hirtle ran the same test on programmers. Beginners had just started a programming course. Intermediates had just finished one. Experts had more than 2,000 hours of programming behind them.

Everyone got a 31-line ALGOL W program. Two minutes to study it, three minutes to write down everything they could remember. Five rounds.

Derek Jones later digitised the paper's figure, and the numbers are blunt. By the fifth round, experts had recalled roughly 20 of the 31 lines. Beginners were under 8.

Then the lines were scrambled. Same code, random order. The experts' edge largely went away: about 9 lines for experts against about 7 for beginners on the last round. Later reviews of the study sum it up simply: scramble the code and the expert advantage disappears.

The second half of the study is the part I keep thinking about. The team looked at how each group clustered ALGOL keywords in memory. Beginners grouped them by everyday English associations. Experts grouped them by what the commands do in a program, and their groupings looked remarkably alike from one expert to the next.

So the expert doesn't see 31 lines. They see "a loop that walks the array," "the guard clause," "the swap." A handful of things.

Why the number of slots matters

You've probably heard that working memory holds "seven, plus or minus two" items. That's George Miller's 1956 paper, and it's one of the most quoted lines in psychology.

Nelson Cowan argued in 2001 that seven was always more of a rough estimate and a rhetorical device than a hard limit. When you stop people from rehearsing or grouping items, the real capacity comes out at about four chunks.

Four. Not much room for debugging a race condition.

The good news sits inside the word "chunk." A chunk can be anything your long-term memory already knows as one thing. A single letter. A word. The whole idea of "debounce this handler." Four slots of beginner chunks hold four tokens. Four slots of expert chunks can hold the shape of a whole module.

The runner who remembered 79 digits

If you want proof that chunks are learned, look at a student known as S.F. In 1980, K. Anders Ericsson, William Chase and Steve Faloon had him practise a digit-span task about an hour a day, three to five days a week. He started at a normal span of 7 digits.

After more than 230 hours over about 20 months, he could hold 79.

S.F. was a distance runner, so he recoded digits as race times. 3492 became "3 minutes and 49 point 2 seconds, near world-record mile time." When times didn't fit, he used ages and dates. He then stacked those groups into larger structures, and he never put more than four groups into one supergroup.

Here's the giveaway. When the researchers switched him from digits to letters, his span dropped back to about six consonants. His memory hadn't grown. His library of running times had.

What this means at your desk

Seniority, in this light, is mostly a pattern library. Elliot Soloway and Kate Ehrlich called these patterns "programming plans" in 1984: generic fragments for stereotyped jobs (think "keep a running total inside a loop"), plus "rules of programming discourse" about how plans usually fit together. If that's right, code that breaks the conventions should feel harder even to an expert, because it stops chunking.

It also explains a feeling you've had. Clever, unidiomatic code is tiring to read even when it's short. It's the scrambled board. Your chunks don't fit, so you're back to holding single pieces in four slots.

And it means you can build chunks on purpose. Three things to try this week:

Read code to name the plan. Open a well-maintained repo in your stack. For each function, write one line describing its plan ("cache-aside lookup," "retry with backoff") before you read the body in detail. You're training recognition, which is what the chess master had.
Explain it back from memory. Close the file and say out loud what the function does and in what order. Then check. The gaps tell you which parts are still single pieces.
Run the McKeithen test on yourself. Pick 30 lines of real code in a language you know. Two minutes to study, three to write it from memory. Do it again in a month with different code from the same codebase. If the count climbs, your chunks are growing.

Keeping the chunks you meet

Most of the patterns I've picked up came from talks, blog posts and videos, and most of them faded within a week because I never saw them again. That's the gap I built Recl for. You save the talk or article, it pulls out the key takeaways, and later it comes back with a recall question like "Still remember this one?" so the pattern gets retrieved again on a spaced schedule. Retrieval is how a new pattern stays available long enough to become a chunk.

Next time a senior dev spots the bug in seconds, remember the chess board. Same four slots as you. Bigger pieces in them, and every one of those pieces was learned.

Asutosh writes about memory and learning, and builds Recl, an app for remembering what you watch and read.

References

Chase, W. G., & Simon, H. A. (1973). Perception in chess. Cognitive Psychology, 4(1), 55–81. https://doi.org/10.1016/0010-0285(73)90004-2
McKeithen, K. B., Reitman, J. S., Rueter, H. H., & Hirtle, S. C. (1981). Knowledge organization and skill differences in computer programmers. Cognitive Psychology, 13(3), 307–325. https://doi.org/10.1016/0010-0285(81)90012-8 (digitised recall data: Derek Jones, https://shape-of-code.com/2016/11/17/ability-to-remember-code-improves-with-experience/)
Miller, G. A. (1956). The magical number seven, plus or minus two. Psychological Review, 63(2), 81–97. https://doi.org/10.1037/h0043158
Cowan, N. (2001). The magical number 4 in short-term memory: A reconsideration of mental storage capacity. Behavioral and Brain Sciences, 24(1), 87–114. https://doi.org/10.1017/S0140525X01003922
Ericsson, K. A., Chase, W. G., & Faloon, S. (1980). Acquisition of a memory skill. Science, 208(4448), 1181–1182. https://doi.org/10.1126/science.7375930
Gobet, F., & Simon, H. A. (1996). Recall of random and distorted chess positions: Implications for the theory of expertise. Memory & Cognition, 24(4), 493–503. https://doi.org/10.3758/BF03200937
Soloway, E., & Ehrlich, K. (1984). Empirical studies of programming knowledge. IEEE Transactions on Software Engineering, SE-10(5), 595–609. https://doi.org/10.1109/TSE.1984.5010283

A 3-Second Interruption Can Double Your Mistakes. Your Brain Explains Why.

Spartan Rich — Thu, 12 Nov 2026 07:37:17 +0000

A three-second interruption is enough to double your mistakes.

Not a meeting. Not a long Slack thread. Three seconds. Roughly the time it takes to glance at a notification and decide it can wait.

If you've ever come back from "just checking something" and stared at your own half-written function like it belonged to a stranger, this is for you.

The study that measured a blink

In 2014, Erik Altmann and David Hambrick at Michigan State University, with Greg Trafton at the U.S. Naval Research Laboratory, published a paper with a title that reads like a developer's diary: Momentary interruptions can derail the train of thought (Journal of Experimental Psychology: General).

About 300 people worked through a procedure on a computer. Each step had its own small rule, and the steps had to be done in order. Think of it as a checklist your head has to hold: step four, then five, then six.

Every so often, the program stopped them and asked them to type two letters. That's it. The interruptions averaged 2.8 seconds, about as long as one step of the task itself.

Afterwards, people were twice as likely to lose their place in the sequence. In a version with slightly longer breaks, around 4.4 seconds, sequence errors tripled.

Here's the part I find most interesting. The errors didn't show up everywhere. People still did each individual step correctly. What broke was knowing which step came next. Altmann said he was surprised such short breaks had such a large effect (EurekAlert summary).

The authors' explanation is about how working memory moves forward. While a step is in focus, activation spreads to the next one, quietly priming it. Pull your focus away, even briefly, and that flow gets cut off. The next step starts to fade. You come back, and the thread you were following is just gone.

Sound familiar? That's debugging. You're holding a call chain in your head: this handler calls that service, which reads this config, which is null because... and then a toast pops up in the corner.

Your brain doesn't fully leave the last task

So the interrupted task suffers. But what about the thing you switched to?

Sophie Leroy, then at the University of Minnesota, studied exactly that. In a 2009 paper in Organizational Behavior and Human Decision Processes, she gave it a name: attention residue.

Across two experiments, people who left a task unfinished kept thinking about it, and they did worse on the next task. Part of their attention stayed behind.

The twist is that simply finishing the first task wasn't enough to clear it. What helped was finishing it under some time pressure, which seemed to give people a clean break.

Developers live in this. You get pulled from a gnarly refactor into a code review. You approve the PR, but half your brain was still renaming variables in the other branch. The review is worse, and the refactor didn't move either.

What programmers actually do when they come back

Chris Parnin and Spencer Rugaber at Georgia Tech went looking for real numbers. They analyzed about 10,000 recorded programming sessions from 86 developers, plus a survey of 414 programmers, and published it as Resumption strategies for interrupted programming tasks (Software Quality Journal, 2011).

Only about 10% of sessions had someone editing code within a minute of coming back. And in only 7% did they start editing without first navigating around to other files or methods.

In other words, almost nobody sits down and picks up where they left off. They wander the codebase first, rebuilding the mental model they had a moment ago. Parnin's survey found developers lean on cues to do this: leaving the last file open, a highlighted line, notes, even a deliberate compile error as a bookmark.

A small catch: it doesn't always feel slower

One honest complication. In a 2008 study at UC Irvine, Gloria Mark, Daniela Gudith and Ulrich Klocke interrupted people while they answered emails (The Cost of Interrupted Work, CHI 2008).

The interrupted people actually finished faster, with no drop in quality on that task. But they wrote shorter emails and reported more stress, frustration, time pressure and effort.

So the cost isn't always visible on the clock. Sometimes you just pay it in tension. And email isn't a 40-step call chain. The Altmann result suggests sequence-heavy work, which is most of programming, is where the damage concentrates.

(You'll also see a "23 minutes to refocus" number floating around online. I couldn't trace it to the CHI paper above, so I'm leaving it out.)

The fix is almost embarrassingly small

In 2018, Leroy and Theresa Glomb tested a simple intervention in Organization Science. They called it a "ready-to-resume" plan.

When you get interrupted, take a minute and jot down where you were, what's left, and what you'll do next. That's the whole thing.

Across four studies, people who did this showed less attention residue and performed better on the interrupting task. In the lab versions, they reviewed résumés as if hiring, and the plan-makers made better decisions and recalled more of what they'd read (UW News). Leroy described it as giving the brain "temporary closure" so it can actually switch.

To be fair to the research: those studies measured performance on the new task, not on returning to the old one. Leroy said the plan likely helps there too, but that hadn't been tested yet.

What to try today

Next time someone taps you on the shoulder mid-bug, don't just swivel. Give it thirty seconds.

Write a one-line note in the file, or in a scratch buffer, like:

// was checking why userId is null in AuthService.refresh(). Next: log token payload before decode.

That's a ready-to-resume plan. It also happens to be the exact kind of cue Parnin's developers used to rebuild context.

A few other things that line up with the research:

Batch the tiny stuff. If three-second breaks matter, notifications during deep work are not harmless.
Finish a chunk before switching, and give yourself a small deadline to do it. That's Leroy's 2009 finding in practice.
When you come back, read your note first. Then the code.

Where I use this outside code

I build a small app called Recl, and it came from a similar problem: I'd save talks and articles mid-task, then lose the thread on them completely. Recl turns what you save into a short summary with key takeaways and later brings it back as a question, so picking the idea back up doesn't start from zero. You can browse some example saves in the public library.

But the cheapest version is a single comment line before you look away.

Your train of thought is fragile. Leave yourself a ticket back.

I'm Asutosh. I write about how memory and learning work, and I build Recl, a tool for remembering what you watch and read.

Your Brain Keeps the Code It Writes. Not the Code It Pastes.

Spartan Rich — Wed, 11 Nov 2026 15:41:21 +0000

Your brain remembers what it makes. It barely notices what it reads.

That's not a productivity quote. It's one of the most reliable findings in memory research, and it has a name: the generation effect. If you write code for a living, and lately you've been letting an assistant write a lot of it, it's worth knowing about.

Two psychologists, a list of words

In 1978, Norman Slamecka and Peter Graf at the University of Toronto ran a set of experiments that sound almost too simple to matter. Half the time, people read a word pair in full. The other half, they got the first word and a fragment of the second, and had to fill in the rest. Think "hot" and "c___", where you supply "cold".

Same words. Same time on the page. The only difference was who produced the answer.

People remembered the words they produced better. Every time. Across five experiments, on recognition tests, free recall, cued recall and even confidence ratings, the "generate" condition beat the "read" condition. The authors noted the effect showed up at high levels of reliability "even in experiments employing only 12 subjects." You can read the original paper here.

They also admitted they didn't fully know why. "It is concluded that the generation effect is real and that it poses an interesting interpretative problem."

Then the field checked their work

A single lab finding can be a fluke. This one wasn't.

In 2007, Sharon Bertsch, Michael McDaniel and colleagues pooled the research into a meta-analysis in Memory & Cognition: 86 studies, 445 effect sizes, more than 17,000 participants. The average benefit of generating over reading was about 0.40 standard deviations, or in their words, "almost half a standard deviation." That's a solid, ordinary-sized effect. Not magic. Not nothing.

A larger review in 2020, led by Matthew McCurdy at the University of Illinois Chicago, went through 310 experiments and found the effect held on every type of memory test they looked at. It also found something useful. The less constrained the generation, the bigger the payoff for recall. Filling in one obvious letter helps a little. Building the answer with more of your own thinking helps more.

There's one catch in the 2007 data that I find the most telling. When the material was nonsense, like made-up nonwords, the generation effect nearly vanished (an effect size of 0.05). Generating only helps when there's something already in your head to connect the new thing to. Your brain isn't rewarding effort for its own sake. It's rewarding you for wiring the new fact into what you already know.

Now swap "words" for "code"

Here's where it gets uncomfortable for developers.

Early this year, Anthropic published a randomized trial (full paper on arXiv) with 52 mostly junior engineers. All of them used Python weekly. None of them knew Trio, an async library. They built two small features with it, then took a quiz on the concepts they'd just used.

One group had an AI assistant in the sidebar that could produce correct code on request. The other group coded by hand.

The AI group averaged 50% on the quiz. The hand-coding group averaged 67%. The time saved by the AI group wasn't statistically significant. The biggest gap was on debugging questions, which is the exact skill you need when the generated code is wrong.

A field experiment in a Turkish high school, published in PNAS in 2025 by Hamsa Bastani and colleagues, found the same shape with nearly a thousand math students. A plain ChatGPT-style tutor boosted practice scores by 48%. When the AI was taken away for the exam, those students scored 17% lower than students who never had it. The researchers saw students using it as a "crutch," asking for answers and copying them.

Neither study is a generation-effect experiment in the strict sense. Different tasks, different tests. But they rhyme with it. When something else produces the answer, you end up in the "read" condition, even if your name is on the commit.

It's not "never use AI"

The Anthropic paper has the hopeful part. Using AI didn't automatically mean a low score. The people who did well asked follow-up questions, requested explanations, or asked conceptual questions while writing the code themselves. The ones who handed over the whole task got some speed and lost the learning.

Same in the PNAS study. A version of the tutor with guardrails, which nudged students toward working things out, mostly removed the harm.

So the tool isn't the problem. Who does the generating is.

Things you can try this week

You don't need a new system. You need small moments where your brain produces the answer before it sees one.

Guess the code first. Before you ask an assistant for a function, write the signature and a rough version, even a wrong one. Then compare. You've turned a read into a generate.

Retype, don't paste, the first time. When you're learning a new API, type the example from the docs by hand once. It's slower. That's the point.

Explain the diff in your own words. After accepting a suggestion, write one line in the commit message about why it works. Not what it does. Why.

Ask the AI to quiz you. Instead of "write this," try "give me a hint, not the answer." It's the guardrail version of the tutor, applied by you.

Close the tab and rebuild it. After reading a good explainer on, say, structured concurrency, close it and write three sentences from memory. Then check what you missed.

Every one of these is just the 1978 experiment again. A word with a gap, and you fill it in.

Where I've landed

I build a small app called Recl, mostly because I kept saving good explainers and never thinking about them again. It turns what you save, like a talk, an article or a thread, into a short summary and then brings it back later as a question you have to answer yourself. That "answer it yourself" part is the generation effect doing the work, not the summary. You can see some example saves in the public library.

But you can get most of the benefit with a notebook and a little discomfort. Next time an answer appears instantly, try making it first.

Your brain keeps what it builds.

I'm Asutosh. I write about how memory and learning work, and I build Recl, a tool for remembering what you watch and read.

Your Brain Forgets on Purpose (It's Basically Garbage Collection)

Spartan Rich — Mon, 09 Nov 2026 19:37:33 +0000

Your brain is built to forget. On purpose.

That sounds like an excuse for not remembering how git rebase --onto works. It's actually the argument of a 2017 review in Neuron by two University of Toronto researchers, Blake Richards and Paul Frankland. Their claim, in one line from the paper's abstract: "the goal of memory is not the transmission of information through time, per se. Rather, the goal of memory is to optimize decision-making."

Read that again as a developer. Memory isn't a database. It's closer to a cache with an opinionated eviction policy.

The old view: forgetting is a bug

For most of the last century, neuroscience mostly studied remembering. How a synapse strengthens, how a memory gets stored, how it gets pulled back up. Forgetting was treated as the failure case. The storage leaked, or the retrieval broke.

Richards and Frankland pulled together a newer body of work that looks at forgetting as its own process, with its own machinery. In CIFAR's write-up of the paper, Frankland put it plainly: "We find plenty of evidence from recent research that there are mechanisms that promote memory loss, and that these are distinct from those involved in storing information."

So the brain doesn't just fail to keep things. It spends energy getting rid of them.

Two ways the brain deletes

The first mechanism is the one you'd guess. Connections between neurons that hold a memory get weakened or removed. Use it less, and the wiring thins out.

The second is stranger. Your hippocampus, the region that handles new memories, keeps growing new neurons through life. Frankland's lab tested what that does to old memories in a 2014 study in Science led by Katherine Akers (abstract here). They trained mice to fear a particular box, then boosted the growth of new neurons afterwards. The adult mice forgot the fear.

The new cells wire themselves into existing circuits, and in doing so they overwrite some of what was stored there.

They also looked at babies. Infant mice, which grow new hippocampal neurons at a much higher rate, forgot the box within days. When the researchers slowed that neuron growth, the infant mice held on longer. Guinea pigs and degus, which make most of those neurons before birth, didn't show the infant forgetting at all, until the team boosted neurogenesis and the forgetting showed up.

That's one proposed explanation for why you can't remember being two. Your brain was rebuilding too fast to keep the files.

New neurons (green) wiring into older hippocampal circuits can make old memories harder to reach.

Why would a brain do this?

This part will feel familiar to anyone who's trained a model. Richards works on applying machine learning ideas to the brain, and the paper leans on two of them.

The first is flexibility. Outdated information is actively harmful. If your brain kept every old address, every old password and every old version of an API with equal strength, it would keep serving you conflicting answers. As Richards said in the CIFAR piece, "If you're trying to navigate the world and your brain is constantly bringing up multiple conflicting memories, that makes it harder for you to make an informed decision."

Anyone who has typed a deprecated method name from muscle memory knows exactly what he means.

The second is generalization. In machine learning, a model that memorizes every detail of its training data overfits. It does great on what it has seen and badly on anything new. Regularization fixes that by pushing the model toward simpler patterns. Richards and Frankland argue that forgetting details does the same job for the brain. You keep the gist of how authentication flows work and lose the exact config from that one project in 2021. The gist is what transfers to the next project.

The paper doesn't say forgetting is always good. It says the two forces, keeping and dropping, have to work together, and the balance depends on how stable your world is.

Your environment sets the eviction policy

This is the part I find most useful. The CIFAR piece gives an example: a cashier who meets many new people a day will remember their names briefly, while someone who sees the same clients every week holds on to them. "One of the things that distinguishes an environment where you're going to want to remember stuff versus an environment where you want to forget stuff is this question of how consistent the environment is and how likely things are to come back into your life," Richards said.

Your brain is constantly estimating whether something will come back. If it doesn't come back, the brain bets that it won't matter.

Which explains a lot about developer life. You read the Kubernetes docs once, during an incident, at 2am. Nothing about that reading told your brain "this will come up again." So it didn't keep it.

Forgotten usually means hard to reach

There's a related idea from the psychologists Robert and Elizabeth Bjork at UCLA, called the new theory of disuse (1992). They split memory into two strengths. Storage strength is how well something is learned. Retrieval strength is how easy it is to pull up right now.

Their example is a phone number you used for five years, twenty years ago. It's still stored. You just can't get to it. Your hotel room number on day three of a trip is the opposite: easy to recall, barely stored, gone a week later.

The useful bit: in their theory, retrieving something when it has become harder to reach builds more storage strength than retrieving it when it's fresh. A bit of forgetting before you review makes the review count for more.

Most of what you've learned is still on the shelf. Retrieval strength decides what's within reach.

What to do with this

If forgetting is your brain's bet that something won't come back, the fix is simple. Make it come back.

Try this with one thing you learned this week. A new library, a tricky bug, a concept from a talk. Close the tab. Tomorrow, without looking, write down three things you remember about it. Then check. Do it again in a few days, and again in a week or two, leaving longer gaps each time.

Each return is a signal to your brain: this keeps showing up, keep it. And the gaps matter. A little struggle to recall is the point, according to the Bjorks.

And for everything else, the stuff that never comes back? Let it go without guilt. That's the brain doing its job.

I built Recl to handle the "make it come back" part for the things I save. You drop in a video, article or post, it writes a short summary, and it brings the save back later as a quick question, with the gaps getting longer when you remember it. Some example summaries live in the public library.

In Recl, a save comes back as a quick question, with longer gaps each time you get it right.

Your brain is going to forget most of what you read today. It probably should. The trick is choosing what you give it a reason to keep.

I'm Asutosh. I write about how memory and learning work, and I build Recl, a tool for remembering what you watch and read.

How to Learn JWT (Without Mixing Up Signing, Encoding, and Encryption)

Spartan Rich — Mon, 09 Nov 2026 03:38:21 +0000

The first time I shipped JWT auth, I copied a middleware snippet, watched the login work, and moved on. Six months later a teammate asked why we could read a user's email by pasting the token into jwt.io. I didn't have a good answer. I'd used JSON Web Tokens for half a year without understanding the one thing that mattered: a JWT is signed, and that's all. It isn't secret.

That gap is common. JWT shows up in almost every web stack, but most of us learn it in pieces, on deadline, from Stack Overflow answers that disagree with each other. Then we forget it until the next auth bug. Here's how I'd learn it again if I were starting over, and how to make it stick this time.

Start with the shape, because it explains everything

A JWT is three base64url strings joined by dots: header, payload, signature. The header says which algorithm signed it, like {"alg":"HS256","typ":"JWT"}. The payload holds claims, which are just JSON fields. The signature is computed over the first two parts with a key.

Decode the first two parts yourself once. Use atob in a browser console after swapping the URL-safe characters, or paste a test token into a decoder. When you see your own payload come back as plain JSON, the main lesson lands on its own: base64url is encoding, and anyone holding the token can read it.

So don't put anything in a payload you wouldn't print in a log. No passwords, no internal IDs you'd rather keep private, no personal data you don't need.

Signing is not encryption

This is the part people blur. A signed token (the spec calls it JWS) proves that whoever holds the key created it and that nobody changed it. An encrypted token (JWE) hides the contents. Almost every JWT you'll meet in a login flow is the signed kind.

The two algorithm families are worth one sentence each. HS256 uses a single shared secret, so the server that signs is also the server that verifies. RS256 and ES256 use a key pair: the auth server signs with a private key, and any service can verify with the public key. If you have more than one service checking tokens, the key-pair version saves you from copying a secret everywhere.

The claims you should actually check

The spec, RFC 7519, lists a handful of registered claims. You don't need to memorize all of them. You need to verify these on every request:

exp, the expiry time. Reject expired tokens.
iss, who issued it. Make sure it's your auth server.
aud, who it's meant for. A token minted for one API shouldn't work on another.

sub usually holds the user ID, and iat says when the token was issued. Libraries check exp by default, but many leave aud and iss to you, and that's where real bugs live.

One more: never trust the alg in the header to choose how you verify. Pin the algorithm on the server. The old alg: none trick, and the one where an attacker switches RS256 to HS256 and signs with your public key, both work only when the server lets the token decide.

The trade-off nobody mentions in tutorials

JWTs are stateless. The server doesn't look anything up, which is fast and simple. It also means you can't easily take a token back. If a user logs out or gets banned, a token with a 24-hour expiry keeps working for 24 hours.

The usual fix is a short-lived access token (a few minutes) plus a refresh token stored server-side that you can revoke. Once you see that pattern, half of the "JWT vs sessions" arguments online make more sense. People aren't disagreeing about JWT. They're disagreeing about how much state they're willing to keep.

Where to store tokens in a browser is the other long argument. An httpOnly cookie keeps JavaScript from reading the token, which helps against XSS, but then you need to think about CSRF. localStorage is simpler and fully exposed to any script on the page. Pick one on purpose and write down why.

Why it doesn't stick, and what helped me

I've "learned" JWT at least three times. Each time I read a good blog post, nodded, and forgot the details by the next project. The issue wasn't the material. I never saw it again until I needed it, and by then it was a stranger.

What finally worked was treating auth notes the way I'd treat anything I study: save the explainer once, keep a short summary in my own words, and get asked about it a few days later.

I do this in Recl, which I'm building. I save the article or conference talk, and it gives me a summary with key takeaways. Then it files the save under a topic, so my auth material sits together.

The part that matters for retention is the recall nudge. A few days after saving, I get a question like "Still remember this one?" and have to answer from memory. "Which claim stops a token for one API from working on another?" is much harder to fake than rereading a highlight. When I miss, the gap shows up before a code review finds it.

You can do a low-tech version too. Write five questions on a card and check yourself on day 1, day 3 and day 7. Spaced repetition doesn't need software. Software just stops you from skipping it.

A short study plan

Spend one evening decoding real tokens and reading the payloads. Spend another wiring up verification in your stack with exp, iss and aud checks and a pinned algorithm. Then break it on purpose: send an expired token, a token for the wrong audience, a token with a changed payload. Watch each one fail.

After that, write three sentences you want to remember a month from now. Mine are: the payload is readable by anyone; the server picks the algorithm, not the token; short access tokens plus revocable refresh tokens.

If you want to see what a saved, summarized technical explainer looks like, a few are on the public Recl library. Either way, get the basics out of the snippet and into your head before the next teammate asks you about jwt.io.

Asutosh builds Recl, an app for saving what matters and recalling it later. It turns the articles and videos you'd otherwise forget into summaries, library topics and spaced recall.

How to Learn Linux File Permissions (Without Googling chmod 755 Every Time)

Spartan Rich — Sun, 08 Nov 2026 19:36:32 +0000

A deploy script fails with Permission denied. You SSH in, type ls -l, and stare at -rw-r--r-- like it's a license plate from another country. Then you open a new tab and search "chmod 755 meaning" for what is probably the ninth time this year.

I did this for an embarrassingly long time. I could fix the problem, but only by copying a number from Stack Overflow and hoping. The fix that finally worked was boring: learn the three or four ideas underneath the numbers, then make myself recall them a few times until they stopped leaking out.

Here's that version.

Read the string before you touch the number

Run ls -l on any file and the first column looks like this:

-rwxr-xr-- 1 deploy www-data 2048 Nov  9 10:12 release.sh

Ignore the first character for now (it's - for a file, d for a directory). The next nine characters are three groups of three:

rwx for the owner (deploy)
r-x for the group (www-data)
r-- for everyone else

Each group answers the same three questions in the same order. Can you read it? Can you write it? Can you execute it? A dash means no.

That's the whole format. Once I stopped seeing it as nine random letters and started seeing it as "owner, group, others, each with read-write-execute," ls -l got a lot less scary.

The numbers are just addition

This is the part everyone memorizes instead of understanding. Read is 4. Write is 2. Execute is 1. Add up what you want for each group.

So rwx is 4 + 2 + 1 = 7. r-x is 4 + 1 = 5. r-- is 4.

That means chmod 754 release.sh gives you exactly the string above. And the famous 755 is "owner can do everything, group and others can read and run it." 644 is "owner can read and write, everyone else can only read," which is what most plain files should look like.

I stopped needing a chart when I realized there are only eight possible digits, and I only ever use four of them: 7, 6, 5, 4. Zero shows up when you want to lock something down completely, like chmod 600 ~/.ssh/id_ed25519. SSH will actually refuse a private key that's readable by others, which is a nice real-world reason to remember that one.

Execute means something different on a directory

This is the one that bit me most. On a file, x means you can run it. On a directory, x means you can enter it and reach the things inside.

So a directory with r-- lets you list the names of files but not open them. A directory with --x lets you open a file if you already know its exact name, but not list what's there. That's why web servers usually want directories at 755 and files at 644. If you chmod -R 644 a whole folder, you just removed x from every directory in it, and nothing can get inside anymore. I've done this on a live server. The site went down for about four minutes while I figured out why.

The safer pattern for fixing a tree:

find /var/www/site -type d -exec chmod 755 {} \;
find /var/www/site -type f -exec chmod 644 {} \;

Symbolic mode is easier to read later

You don't have to use numbers at all. chmod u+x deploy.sh adds execute for the owner (u = user/owner, g = group, o = others, a = all). chmod go-w config.yml removes write from group and others. chmod +x with no letter adds execute for everyone, subject to your umask.

I use numbers when I'm setting a file to a known state and symbolic mode when I'm nudging one bit. Six months later, chmod u+x in a script is much easier to understand than chmod 744.

Ownership is the other half

Half the time Permission denied isn't about the mode at all. The file belongs to root, and you're deploy. Permissions only matter relative to who owns the file and which group it's in.

chown deploy:www-data release.sh sets both. id tells you which groups you're actually in. After you add yourself to a group, you usually need to log out and back in before it takes effect, which has wasted more of my afternoons than I want to admit.

Make it stick instead of re-Googling

Reading all this once won't hold. I've read good explanations of permissions maybe a dozen times, and each one felt clear and then evaporated within a month. What changed it for me was treating it like anything else I want to keep: save the explanation once, write my own one-line version, and get asked about it later.

I save the video or article I learned from into Recl, which pulls out the key points. Then I add my own note on top, in my words. For this topic my note says: "r=4 w=2 x=1, add per group. x on a dir = can enter. Never chmod -R 644 a folder."

A few days later the app sends a nudge, "Still remember this one?", with a small question. What does x mean on a directory? What's 640 in letters? If I get it, it comes back in about a week. If I blank, I reread my note and see it sooner.

You can do the same thing with index cards or a text file you review on Fridays. What matters is being asked again before you need it at 11pm on a broken server.

A ten-minute practice loop

Make a scratch folder with mkdir perms-test && cd perms-test, then touch a.txt and mkdir sub.
Before running each command, predict the ls -l output: chmod 640 a.txt, chmod u+x a.txt, chmod 700 sub.
Now run chmod 600 sub and try cd sub. It fails even for you, because the directory lost x. Put it back with chmod u+x sub.
Write 754 and rw-r----- on a sticky note. Tomorrow, convert each one into the other without looking anything up.

You don't need to memorize every flag chmod has. You need the owner-group-others picture and the 4-2-1 addition to still be there next time a script says Permission denied.

If you want to see what saved takeaways look like on real material, the public Recl library has a few hundred of them.

I'm Asutosh, and I build Recl, an app for saving videos, articles and notes, getting the key ideas, and recalling them on a schedule so they actually stick.

How to Learn the JavaScript Event Loop (Without Mixing Up the Call Stack, Microtasks, and Macrotasks)

Spartan Rich — Sun, 08 Nov 2026 11:32:36 +0000

You watch a conference talk about the JavaScript event loop. Someone draws boxes on a whiteboard, or a newer explainer animates two colored queues. setTimeout versus Promise.then suddenly makes sense. Two weeks later a teammate pastes a four-line snippet in review and asks what logs first, and the order falls apart in your head.

I've been through that cycle more times than I want to admit. The event loop isn't hard because the pieces are fancy. It's hard because they only make sense together, and most write-ups walk you through them one at a time, then never ask you again.

This is the version that finally stuck for me, and how I keep it from leaking out between interviews and late-night bugs.

The call stack runs one thing at a time

JavaScript in the browser (and the mental model most of us use in Node) has a single call stack. A function starts, it may call another function, and when a function returns it pops off. While the stack still has frames on it, nothing else in your script runs. That's why a tight while (true) {} freezes the tab. The loop never leaves the stack, so the browser never gets a turn to paint or handle a click.

Async does not mean another thread is running your callback. It means you'll schedule the work and come back to it after the stack is clear.

Macrotasks are the bigger tickets

A macrotask (the HTML spec just calls them tasks) is a unit of work the event loop picks up: the original script, a setTimeout callback, a setInterval tick, a click handler, an I/O callback in Node. The loop takes one macrotask, runs it until the stack is empty, then decides what comes next.

setTimeout(fn, 0) does not mean "run fn immediately." It means put fn on the macrotask queue and run it after the current task finishes, after any tasks already waiting, and after the delay has elapsed. If the stack is busy, zero can be a lot longer than zero.

Microtasks cut in before the next macrotask

This is the part I used to mix up with timeouts.

When the stack empties, the runtime drains the entire microtask queue before it takes the next macrotask. Promise callbacks (.then, .catch, .finally), queueMicrotask, and MutationObserver all land here. In Node, process.nextTick runs even earlier than the other microtasks, which is its own small trap.

So this logs A, then C, then B:

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));

A runs now, on the current stack. The timeout is a macrotask. The promise callback is a microtask. After A finishes, every waiting microtask runs (C), and only then does the timeout get a turn (B).

If a microtask queues another microtask, that one runs too, before any macrotask. A long chain of Promise.resolve().then(...) can keep the UI waiting the same way a tight while loop can. I've seen that surprise people who assumed anything async would keep the page responsive.

The picture I keep in my head

One stack. Two queues. After the stack clears: empty every microtask, then take one macrotask, then empty the microtask queue again.

Clicks, timeouts, and I/O wait in the macrotask line. Promise reactions cut in between them.

If I can walk a four-line snippet against that picture without opening a tab, I actually know it.

Why the talk fades by the next interview

You learned this the usual way: a talk, a blog with colored boxes, maybe a sandbox you closed the same afternoon. The model was clear for a day. Then you went back to writing async/await (which is promises underneath, so microtasks), and nothing asked you about the queues until a whiteboard did.

Re-watching the same video feels like studying and isn't. You recognize the animation. Recognition is not the same as predicting the log order of a snippet you haven't seen before.

What helps is writing the two-queue picture in your own words, then being asked about it a few days later, before you need it in an interview or a race you can't reproduce.

I started saving the talks and articles that actually explained a piece into Recl. It takes a video or an article, gives you a short summary and key takeaways, and files the save under a topic. I add my own note on top: "after the stack clears, drain every microtask, then one macrotask. setTimeout is a macrotask. .then is a microtask. nextTick in Node runs before other microtasks."

That note is what I want the next time someone asks why setTimeout(fn, 0) ran after a chain of promises.

Let a question come back later

A few days later Recl nudges you: "Still remember this one?" The question is usually something small, like which queue Promise.then uses. If I answer it, it comes back in about a week. If I blank, I read my note and see it sooner.

Index cards work too. I just got tired of maintaining a separate deck for every JavaScript topic I keep relearning. It's easier when the prompt comes from the talk I already saved.

A loop you can run this week

Predict the log order of this snippet, then run it: console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4);
Change the promise callback so it queues another .then that logs 5, and predict again.
Write, in one sentence, what happens after the call stack empties.
In a few days, before you open a diagram, try to explain why setTimeout(fn, 0) can still lose to a promise. Check yourself.

You don't need to memorize the HTML spec's processing model. You need the relationship between the stack, microtasks, and macrotasks to still be there the next time a snippet looks out of order, and a way to pull that picture back up on purpose.

If you want to see what summarized takeaways look like on real material, the public Recl library has a few hundred of them.

I'm Asutosh, and I build Recl, an app for saving videos, articles and notes, getting the key ideas, and recalling them on a schedule so they actually stick.

How to Learn Kafka (Without Mixing Up Topics, Partitions, and Consumer Groups)

Spartan Rich — Sun, 08 Nov 2026 03:33:43 +0000

You watch a twenty-minute Kafka explainer over lunch. Topics, partitions, consumer groups, offsets. It all clicks. Two weeks later a teammate asks why your consumer isn't picking up messages, and you can feel the words sliding around. You know you understood this. You just can't get it back in order.

I've done that more than once. Kafka isn't hard because the words are fancy. It's hard because the pieces only make sense together, and most tutorials walk you through them one at a time, then never ask you again.

This is the version that finally stuck for me, and how I keep it from leaking out between projects.

A topic is a named stream, not a queue

A topic is just a name for a stream of records. Producers write to it. Consumers read from it. If you come from a job-queue background (SQS, or a RabbitMQ work queue), the surprise is that reading a message does not remove it. Other consumers can read the same record. The data hangs around based on retention, not based on who already saw it.

That one fact explains a lot of "why did two services both get this event?" conversations. In Kafka, that's often the point.

Partitions are how Kafka scales a topic

A topic is split into partitions. Each partition is an ordered log. Records in a partition have offsets: 0, 1, 2, and so on. Across partitions there is no single global order.

If you produce with a key, say user_id=42, Kafka hashes the key and always sends that user's records to the same partition. That's why order is guaranteed per key, not for the whole topic.

If you produce with no key, records spread across partitions and you should not expect them back in the order you sent them.

Three partitions is not three topics. It's one stream cut into three ordered lanes so more brokers and more consumers can share the work.

Consumer groups decide who does the work

This is the part I used to mix up with partitions.

A consumer group is a team of consumers that share a group id. Kafka assigns each partition to only one member of that group. If you have six partitions and three consumers in the same group, each consumer typically gets two partitions. If you add a fourth consumer, partitions get reassigned.

Two different group ids reading the same topic each get their own copy of the stream. That's how you have a billing service and an analytics service both following the same orders topic without stealing work from each other.

Inside one group, members split partitions. Across groups, everyone gets the full stream.

The group also tracks the last offset it committed. After a restart, members pick up from that offset instead of from the beginning (unless you configured them to). When a consumer "falls behind," it means its committed offset is lagging the end of the partition.

The picture I keep in my head

One topic named orders. Three partitions. Two services: billing (group billing) and analytics (group analytics).

Billing runs two instances, so those two instances split the three partitions. Analytics runs one instance, so that one instance reads all three. A new order shows up in partition 2. Both groups see it. Only one billing instance sees it.

If I can redraw that on a napkin without looking it up, I actually know it.

Why the explainer fades by next sprint

You learned Kafka the usual way: a blog post, a Confluent talk, maybe a local Docker Compose file you tore down the same afternoon. The model was clear for a day. Then you went back to application code, and nothing asked you about consumer groups until production did.

Re-watching the same video feels like studying and isn't. You recognize the diagrams. Recognition is not the same as being able to explain why two consumers in one group won't both process the same partition.

What helps is writing the napkin picture in your own words, then being asked about it a few days later, before you need it in an incident.

I started saving the talks and docs that actually explained a piece into Recl. It takes a video or an article, gives you a short summary and key takeaways, and files the save under a topic. I add my own note on top: "same group = split partitions. different groups = each gets the whole topic. order is per partition, and per key if you set one."

That note is what I want next time someone says "we're seeing duplicate processing." Often two instances accidentally used different group ids, or someone republished after a reset.

Let a question come back later

A few days later Recl nudges you: "Still remember this one?" The question is usually something small, like what a consumer group actually shares. If I answer it, it comes back in about a week. If I blank, I read my note and see it sooner.

Index cards work too. I just got tired of maintaining a separate deck for every backend topic I keep relearning. It's easier when the prompt comes from the talk I already saved.

A loop you can run this week

Draw one topic, three partitions, and two consumer groups. Put two consumers in the first group and one in the second. Label who reads which partition.
Add a keyed record (user_id=42) and say which partition it can land on next time (the same one).
Write, in one sentence, what a committed offset is for.
In a few days, before you open a diagram, try to redraw the picture. Check yourself.

You don't need to memorize the entire Kafka protocol. You need the relationship between topics, partitions, and groups to still be there the next time a consumer "isn't getting messages," and a way to pull that picture back up on purpose.

If you want to see what summarized takeaways look like on real material, the public Recl library has a few hundred of them.

I'm Asutosh, and I build Recl, an app for saving videos, articles and notes, getting the key ideas, and recalling them on a schedule so they actually stick.

How to Learn DNS (Without Forgetting How Records Actually Work)

Spartan Rich — Sat, 07 Nov 2026 19:35:01 +0000

You ship a site. SSL fails. Someone says "check the A record." You nod, open a tab, and type the same search you've typed a dozen times: A vs CNAME vs MX.

You fix it. Two months later a TXT record for email auth shows up and your brain is empty again. TTL? Glue? Why does dig show two answers and nslookup shows one? Same dance.

DNS is not hard once it's loaded. The problem is it unloads the second you stop touching it.

Pick a mental model, not a bookmark pile

Most people start with a table of record types. Tables are fine for lookup. They are terrible for memory. You need one picture you can redraw on a whiteboard without notes.

Mine is boring and it works: a name asks a question, a record is the answer, and a resolver is the messenger that fetches that answer (and may cache it).

An A record answers "what IPv4 address?" for example.com.
An AAAA answers the same for IPv6.
A CNAME answers "this name is an alias of that other name," then you resolve the target.
An MX answers "which hosts handle mail, and in what priority order?"
A TXT answers with plain text, which is why SPF, DKIM, and verification strings live there.

TTL is how long a resolver may trust a cached answer before asking again. Short TTL means changes propagate faster. Long TTL means fewer lookups and a longer wait when you fat-finger a record.

Recursion is the resolver doing the scavenger hunt: root → TLD → authoritative. Iterative is you walking that chain yourself. Day to day you use a recursive resolver and only dig into the chain when something breaks.

Write that model in five lines. If you can't, you're still collecting tabs instead of learning.

Practice on real domains with dig

Flashcards without a terminal are half a skill. Open a shell and hit domains you already know.

dig example.com A +short
dig example.com NS
dig example.com MX
dig google.com TXT +short

Read the answer section first. Then add flags on purpose:

dig @1.1.1.1 example.com A
dig example.com A +trace

+trace walks the recursion path so you see root hints, TLD servers, then the authoritative answer. Do this once on a domain you control and once on a public one. The next time a CNAME looks stuck, that output stops looking like hieroglyphs.

nslookup is fine in a pinch. dig is clearer when you want the raw record story. Pick one default for a month so the flags stick.

Concrete drill: for three domains you care about, write down expected A/AAAA, whether www is a CNAME, and who the MX points at. Then dig and check yourself. Wrong guesses are the point.

Tiny questions beat another 40-minute video

After one good explainer (Cloudflare's DNS docs, or a single walkthrough you trust), stop collecting more. Turn the gaps into short questions:

What does a CNAME forbid at the zone apex that an A record does not?
If MX priority is 10 and 20, which host is tried first?
You change an A record. TTL was 3600. Roughly how long can old resolvers keep the previous IP?
What's the difference between a recursive resolver and an authoritative nameserver?
When would you reach for TXT instead of inventing a new record type?

Answer from memory the next day. Mark the ones you blanked on. Re-read only those sections. A week later, run the same five without notes. Spaced repetition here is a calendar reminder and honesty. Rewatching feels familiar; retrieval tells you what stuck.

Keep the questions next to the source. A loose dns-quiz.md beside a dead bookmark helps nobody.

Where the "I'll remember this" lie shows up

The Watch Later graveyard is full of DNS explainers. So is the bookmark folder named Infra. You save the video the day SSL breaks, feel responsible, and never open it again. Next outage, new search, new save.

When something finally clicks, say the moment +trace makes recursion obvious, capture the source and three lines in your own words. Not a transcript. Something like: "CNAME is an alias, then resolve the target," "MX lower number = higher preference," "TTL is cache permission, not a promise the world updates instantly."

That short note is what you reopen six weeks later. The video is the receipt. You should not need to scrub to minute 18 to remember what an SOA serial is for.

How I keep DNS from leaking out again

I got tired of re-Googling the same five record types. Now when I find a solid DNS write-up or video, I save it into Recl. It's a memory app: drop in links, YouTube, articles, or notes; get a TL;DR and key takeaways; land them under library topics; then get spaced-repetition recall nudges and short quizzes so the material comes back before the next outage.

For DNS that means one trusted explainer and my dig cheat-sheet live together. The summary surfaces A/CNAME/MX/TXT points so I can skim before a deploy. I still add my own three-line note so the "why" stays in my words. Months later, when a TXT verification ticket lands, I can ask the library and get an answer with sources instead of starting a fresh spiral.

There's a share sheet on mobile and a Chrome extension (Ctrl/Cmd+Shift+S) when you're already in the browser. Tagline that fits: save what matters, recall it forever.

You don't need an app to learn DNS. A dated note and a reminder beat another abandoned bookmark. The habit is the product: capture the bits that evaporate, then retrieve them on purpose.

Try this before your next DNS ticket

Before you open a new tutorial, write what you still remember about A vs CNAME vs MX. Dig three real domains. Write five tiny questions. Quiz tomorrow and again next week.

If record types feel brand new every quarter, treat the gap between learning and recall as the real bug. Close it on purpose, and the next SSL or email-auth ticket starts at "check TTL and authority" instead of "what was an AAAA again?"

Asutosh Pattanayak built Recl — a memory / second-brain app for saving links, articles, videos, and notes, then actually remembering them.

How to Learn HTTP Caching (Without Mixing Up Cache-Control, ETag, and Expires)

Spartan Rich — Sat, 07 Nov 2026 11:38:57 +0000

You push a CSS fix. Your teammate refreshes and still sees the old button. Someone says "hard refresh," someone else says "it's the CDN," and you spend twenty minutes reading the same MDN page you read last quarter.

HTTP caching is one of those topics most of us have "learned" four or five times. Each time it makes sense for about a week. Then no-cache and no-store swap places in your head again, and you're back to guessing.

I don't think the headers are that hard. The trouble is how we pick them up: under pressure, mid-bug, from a Stack Overflow answer that fixed one thing. Here's how I finally got them to stay.

Start with the two questions every cache asks

Every cache, whether it's the browser, a CDN, or a reverse proxy, asks two things about a response.

Can I store this at all?
If I have a copy, can I use it without asking the server?

Almost every header you'll meet answers one of those. Once I sorted them into those two buckets, the list stopped feeling random.

Can I store it? Cache-Control: no-store says no, never write it down. private says only the user's browser may keep it, not a shared CDN. public says shared caches are fine too.

Can I reuse it without asking? That's freshness. max-age=3600 means the copy is fresh for an hour. s-maxage is the same idea for shared caches only. Expires is the older way of saying it with a date, and if max-age is present, it wins.

Then there's the one everybody gets wrong. no-cache doesn't mean "don't cache." It means "you can store it, but check with the server before every reuse." I had that backwards for an embarrassingly long time.

Revalidation is where ETag comes in

When a stored copy goes stale, the cache doesn't have to download everything again. It can ask, "has this changed?"

That's what validators are for. The server sends an ETag (a fingerprint of the content) or a Last-Modified date. Later, the browser sends If-None-Match with the ETag, or If-Modified-Since with the date. If nothing changed, the server replies 304 Not Modified with no body, and the cache keeps using its copy.

So no-cache plus an ETag is a perfectly reasonable setup for HTML. You always check, but checking is cheap.

The one pattern worth memorizing

If you only keep one thing, keep this:

Hashed static files (app.3f9a1c.js, styles.8b2e.css): Cache-Control: public, max-age=31536000, immutable. The filename changes when the content does, so the old URL can live forever.
HTML: Cache-Control: no-cache, with an ETag. The page always checks in, so it picks up the new asset filenames right after a deploy.
Anything with private user data: private, or no-store if it really shouldn't touch disk.

That split explains most "why is the old CSS still there?" bugs. Usually someone gave the HTML a long max-age, or shipped assets without a hash in the name.

Why it keeps falling out of your head

Here's my honest read on the forgetting part. We learn caching reactively. A bug shows up, we fix it, the fix works, and we never look at the reasoning again. Nothing pulls it back up until the next bug, months later.

Re-reading the docs feels productive and doesn't help much. What works better is trying to answer from memory first, getting it wrong, then checking. That's retrieval practice, and spaced out over a few weeks, it's the difference between "I've read about ETags" and "I know when I'd use one."

So when I finally fixed a caching bug properly, I saved the MDN page and the talk that explained it into Recl. It turns a link or video into a short summary with key takeaways, files it under a topic, and then brings it back later as a quick recall question.

The useful part was writing my own note on the save. Something like: "no-cache = store but always revalidate. no-store = never store. HTML gets no-cache, hashed assets get immutable." That note is what I actually need when I'm staring at response headers in DevTools.

Let the reminders do the remembering

A few days later, a nudge shows up: "Still remember this one?" The question is something like what no-cache actually does. If I get it right, it comes back in a week. If I blank, I read my note and it comes back sooner.

You can do the same thing with plain flashcards. The tool matters less than the habit of being asked before you need the answer. I just find it easier when the cards come from things I already saved, instead of a separate deck I have to build and maintain.

A short loop you can run this week

Open DevTools on a site you work on. In the Network tab, look at the Cache-Control and ETag headers on your HTML and on one JS file.
For each, say out loud which of the two questions it answers: can I store it, or can I reuse it without asking?
Write the HTML-versus-hashed-assets rule in your own words somewhere you'll see it again.
Next week, before checking, try to explain no-cache versus no-store to yourself. Then check.

It's a small topic. You don't need to memorize RFC 9111. You need three or four rules that are still there the next time a deploy looks stale, and a way to keep them from fading between bugs.

If you want to see what summarized takeaways look like on real material, the public Recl library has a few hundred of them.

I'm Asutosh, and I build Recl, an app for saving videos, articles and notes, getting the key ideas, and recalling them on a schedule so they actually stick.