DEV Community: CBT Tools

How I Built a Virtual Folder Tree from Flat Filenames — No Files Moved, No Symlinks, Just 300 Lines of TypeScript

CBT Tools — Sun, 30 Aug 2026 05:38:58 +0000

I let an AI agent write code in my project for a week. By Friday there were 340 files in one directory.

auth_login_handler.ts. auth_login_session.ts. utils_helpers.ts. config_env.ts. All flat. All in the root.

The agent loved it. No path ambiguity, no directory hops, no "which folder was that in?" 鈥?every file one read_file call away. Flat is the agent's native habitat.

I hated it. Scrolling through 340 files looking for the one auth handler I needed. My brain doesn't grep.

So I built Logical Folders 鈥?a VSCode and IntelliJ plugin that displays flat files as a virtual directory tree. The files don't move. Nothing changes on disk. The hierarchy is purely visual.

On disk:                    In the tree:
auth_login_handler.ts       auth/
auth_login_session.ts         login/
utils_helpers.ts                handler.ts
config_env.ts                   session.ts
                            utils/
                              helpers.ts
                            config/
                              env.ts

The agent keeps its flat playground. I get my tree.

The core: 30 lines

The whole thing hinges on one function 鈥?parsePath. Split a filename on a separator, keep the extension glued to the last segment:

export function parsePath(relPath: string, sep: string): string[] {
    const parts = relPath.split(path.sep);
    const filename = parts.pop()!;

    // Dotfiles (.gitignore, .env) never split 鈥?returned as-is
    if (!sep || filename.startsWith('.') || !filename.includes(sep)) {
        return [...parts, filename];
    }

    const ext = path.extname(filename);
    const base = ext ? filename.slice(0, -ext.length) : filename;
    const segs = base.split(sep);

    if (ext && segs.length > 0) {
        segs[segs.length - 1] += ext;
    }

    return [...parts, ...segs];
}

auth_login_handler.ts with _ 鈫?["auth", "login", "handler.ts"]. That's it. The extension stays on the last segment so handler.ts doesn't become handler + .ts as a fake folder.

The inverse is constructFlatName 鈥?join segments with the separator, reattach the extension. When you right-click auth/login/ and create handler.ts, the plugin joins them back to auth_login_handler.ts and writes the flat file.

The tree is a lie. The disk is the truth.

Building the virtual tree

VSCode's TreeDataProvider interface needs getChildren(element?). I scan the workspace once, parse every file path, and insert into a tree of LogicalNode objects:

private async buildTree(): Promise<LogicalNode> {
    const cfg = vscode.workspace.getConfiguration('logicalFolders');
    const separator = cfg.get<string>('separator', '_');
    const exclude = cfg.get<string[]>('exclude', []);
    const maxFiles = cfg.get<number>('maxFiles', 10000);

    const folder = vscode.workspace.workspaceFolders?.[0];
    const rootPath = folder?.uri.fsPath ?? '';

    const root = new LogicalNode('', undefined, rootPath, [], new Map(), ...);
    if (!folder) return root;

    const excludePattern = exclude.length > 0 ? `{${exclude.join(',')}}` : null;
    const files = await vscode.workspace.findFiles('**/*', excludePattern, maxFiles);

    for (const uri of files) {
        const rel = path.relative(rootPath, uri.fsPath);
        const segments = parsePath(rel, separator);
        this.insert(root, segments, uri.fsPath);
    }
    return root;
}

vscode.workspace.findFiles respects glob exclude patterns. The maxFiles cap (default 10,000) is a performance guard 鈥?I learned the hard way that scanning a monorepo with 50k files freezes the tree for two seconds.

The insert method walks the tree along the parsed segments, creating virtual folder nodes as needed:

private insert(root: LogicalNode, segments: string[], physical: string): void {
    let current = root;
    for (let i = 0; i < segments.length; i++) {
        const seg = segments[i];
        const isLeaf = i === segments.length - 1;

        if (!current.children.has(seg)) {
            current.children.set(seg, new LogicalNode(
                seg,
                isLeaf ? physical : undefined,      // file nodes get a real path
                isLeaf ? path.dirname(physical) : current.physicalDir,
                segments.slice(0, i + 1),
                new Map(),
                isLeaf
                    ? vscode.TreeItemCollapsibleState.None
                    : vscode.TreeItemCollapsibleState.Collapsed
            ));
        }
        current = current.children.get(seg)!;
    }
}

Folder nodes have physicalPath = undefined. File nodes point to the real file on disk. When you click a file, it opens the actual file 鈥?no symlink, no redirect. The resourceUri is set to the real path, so VSCode's built-in operations (git diff, search, go-to-definition) all work normally.

The separator problem

Default is _ 鈥?the convention AI agents use when writing flat files. But different teams use different conventions:

Separator	Flat file	Logical tree
`_` (default)	`auth_login_handler.ts`	`auth/ > login/ > handler.ts`
`__`	`auth__login__handler.ts`	`auth/ > login/ > handler.ts`
`-`	`auth-login-handler.ts`	`auth/ > login/ > handler.ts`
`.`	`auth.login.handler.ts`	`auth/ > login/ > handler.ts`
`::`	`auth::login::handler.ts`	`auth/ > login/ > handler.ts`

The . separator has a footgun: auth.login.handler.test.ts splits to auth/ > login/ > handler/ > test.ts 鈥?the .test part becomes a virtual folder. Use _ or - if your test files have dots in the name. I documented this in the README rather than trying to be clever about it.

Dotfiles (.gitignore, .env) are never split. They start with a dot, so the first check in parsePath bails out and returns them as-is.

Physical directories pass through

If you have a real src/ directory AND a flat src_auth.ts file, both appear under src/ in the tree. The plugin doesn't force everything flat 鈥?it merges physical and logical. This matters because most real projects are a mix: some directories are real (created by humans), some files are flat (created by agents).

File operations work on the flat file

Create, rename, delete 鈥?all operate on the physical flat file, not the virtual tree.

Right-click auth/login/ 鈫?New File 鈫?type handler.ts:

Segments: ["auth", "login", "handler.ts"]
Flat name: auth_login_handler.ts (segments joined with _)
Created on disk in the same physical directory as the other files

Rename handler.ts to middleware.ts:

Old flat name: auth_login_handler.ts
New flat name: auth_login_middleware.ts
fs.rename on the physical file

The tree refreshes (500ms debounce on the file watcher) and shows the new structure.

Why not just use real folders?

Because the agent breaks them.

I tried organizing the 340 files into real directories. The agent immediately flattened them again on the next edit 鈥?it resolves paths, writes flat, and doesn't preserve directory structure. Every mkdir + mv was undone within minutes.

Symlinks? The agent follows them, resolves the real path, and writes to the flat location. Same problem.

The only structure the agent respects is the filename itself. So I made the structure live in the filename 鈥?and built a viewer that reads it back.

Install

VSCode 鈥?search "Logical Folders" in the extensions panel, or:
Marketplace link

IntelliJ IDEA 鈥?pending JetBrains review (plugin ID 33928), live within 2 business days at:
plugins.jetbrains.com/plugin/33928-logical-folders

Source: github.com/alexcoledev/logical-folders

The VSCode extension is ~300 lines of TypeScript. The IntelliJ plugin is Kotlin 鈥?same algorithm, different tree API. No runtime dependencies beyond the editor SDK.

Config: logicalFolders.separator (default _), logicalFolders.exclude (default ["**/node_modules/**", "**/.git/**", "**/out/**", "**/dist/**"]), logicalFolders.maxFiles (default 10000).

How a CBT Thought Record Got Me Through a Production Outage at 3 AM

CBT Tools — Tue, 25 Aug 2026 23:02:18 +0000

The pager went off at 3:14 AM. A single sentence: payment-service PROD error rate 12% (threshold 5%).

I was the on-call. My first thought, before I was even fully awake:

"This is going to be a career-ending incident. They're going to fire me. I should just quit now."

My hands were shaking. I could not read the dashboard. I tried three times to SSH into the bastion and typoed the host each time.

This is the moment where most on-call narratives tell you to "stay calm" or "follow the runbook." That advice has never once helped me at 3 AM. What helped was a 90-second exercise I'd been practicing for two months — a CBT thought record, adapted for incidents.

The 90-second incident thought record

I keep a text file open during on-call weeks. The structure is five lines. Here is what I wrote at 3:17 AM, between the second and third SSH attempt:

SITUATION: Payment-service error rate 12% at 03:14. I am on-call.
EMOTION:    Terror 9/10. Shame 7/10.
HOT THOUGHT: "This is career-ending. They will fire me."
DISTORTION: Catastrophizing (jumping to worst outcome) + Mind reading (assuming I know what leadership will decide) + Fortune Telling (predicting the outcome before the incident is even resolved).
REFRAME:    The error rate is 12%, not 100%. Payments are degraded, not down. I have resolved 14 incidents this quarter with no escalation. The incident is 3 minutes old — no human has even noticed yet. My job right now is to read the dashboard, not to predict my employment status.

That is the entire exercise. Five lines. It took me 90 seconds because my hands were shaking and I kept mistyping.

What changed after writing it

Nothing magical happened. The error rate was still 12%. The dashboard was still hard to read. But the thought they will fire me had moved from my chest to the screen, and on the screen I could see it was a prediction about the future, not a fact about the present.

I SSH'd in on the next attempt. The root cause was a connection pool exhaustion after a deploy three hours earlier that no one had watched. The fix was a config rollback — one command. Error rate dropped to 0.4% by 3:31 AM. Total time from page to resolution: 17 minutes.

The thought record did not fix the incident. It fixed the thing that was preventing me from fixing the incident — the catastrophizing loop that was burning my working memory on predictions about getting fired instead of reading a stack trace.

Why this is different from "just calm down"

"T Stay calm" is an instruction to suppress a feeling. It does not work because the feeling is a reasonable response to "production is broken and I am responsible." Suppressing it takes active cognitive effort, which is effort I need for the incident.

A thought record does the opposite. It does not suppress the emotion — it names it (Terror 9/10), identifies the specific thought driving it (this is career-ending), checks that thought against a list of known cognitive distortions, and writes a reframe that is grounded in the actual situation. The emotion does not disappear. It drops from a 9 to a 4, which is the difference between "cannot type" and "can type but slowly."

The mechanism is not relaxation. It is cognitive restructuring — the same technique used in CBT for anxiety disorders, compressed into a format that fits between two SSH attempts.

The five distortions that show up most in incidents

After running this exercise across roughly 40 on-call incidents over six months, five distortions dominate:

Catastrophizing — "this is career-ending." The distortion is jumping to the worst possible outcome before the incident is resolved. The reframe: the outcome is not known yet; the current task is diagnosis, not prediction.
Mind reading — "leadership is going to blame me." The distortion is assuming you know what other people are thinking. The reframe: no human has noticed yet; when they do, they will see the timeline, which shows a 17-minute resolution.
Personalization — "this is my fault because I am on-call." The distortion is taking responsibility for things outside your control. The reframe: the deploy was three hours ago, possibly before my on-call shift started; responsibility is assigned after postmortem, not during the incident.
All-or-nothing — "if I cannot fix this immediately, I am incompetent." The distortion is binary framing. The reframe: incidents are diagnosed in stages; "not fixed yet" is the normal state of an active incident, not evidence of incompetence.
Fortune telling — "this will become a SEV1 and go to the VP." The distortion is predicting a specific negative future. The reframe: the current severity is SEV2 based on error rate; severity escalation depends on duration and impact, both of which I am actively controlling.

The part I do not write down

There is a sixth line I added after about ten incidents, but I do not always fill it in:

ACTION: What is the next physical step I can take in the next 60 seconds?

At 3:17 AM the answer was "read the error message on the dashboard." Not "fix the incident." Not "figure out the root cause." Just read the error message. One physical step. The thought record gets me out of the catastrophizing loop; the action line gets me back into the incident.

Does this scale beyond on-call

I have used the same five-line structure for:

Code review anxiety — hot thought: "the reviewer thinks I am junior." Distortion: mind reading. Reframe: the reviewer commented on the code, not on me; address the comment, not the imagined judgment.
Performance review prep — hot thought: "I will get a bad rating because of that one incident." Distortion: catastrophizing + mental filtering (one incident out of a quarter). Reframe: the review covers a quarter; one resolved SEV2 is one data point among many.
Deploy fear — hot thought: "this deploy will break production." Distortion: fortune telling. Reframe: the deploy passed CI and staging; the actual risk is the rollback procedure, which I have tested.

The structure is the same. The distortions are the same five. The reframe is always "what is the fact about the present moment, as distinct from the prediction about the future."

The free tool

I built a browser-based thought record tool that implements this exact five-line structure — no signup, no backend, no data leaves your machine. It detects the five distortions above automatically as you type your hot thought, and suggests the reframe pattern. It works on a phone, which is where I actually use it at 3 AM.

Tool: CBT Thought Record (free, no signup, works offline after first load)

The incident thought record is not therapy. It is a 90-second cognitive tool that moves the catastrophizing from your working memory to a text file, so your working memory is available for the incident. At 3 AM, that is the only thing that matters.

7 Questions About CBT Thought Records I Wish I'd Asked Before Starting

CBT Tools — Tue, 25 Aug 2026 22:05:39 +0000

I've been using CBT thought records for about three months now. Not as a therapist, not as a researcher — as a developer who got tired of lying awake at 2 AM replaying a code review comment in my head.

Before I started, I had questions. I didn't ask them. I just jumped in, made mistakes, and figured things out the slow way. This is the FAQ I wish someone had handed me on day one.

1. "Is this just journaling with extra steps?"

No. And this is the question that almost made me quit.

Journaling is free-association: you write whatever comes to mind, and maybe you feel better, maybe you don't. A thought record is structured. You're not venting — you're doing a specific 5-step exercise:

Situation — what actually happened (just the facts)
Emotion — what you felt, rated 0-100
Hot thought — the automatic thought that drove the emotion
Distortion — which cognitive distortion the hot thought represents
Reframe — a balanced alternative thought

The structure is the point. Journaling asks "how do I feel?" A thought record asks "is this thought true, and what's the evidence?" That second question is where the change happens.

I journaled for years. It felt good in the moment. It changed nothing. Thought records changed things in about two weeks.

2. "Do I need to do it every day?"

No. I tried daily. It became a chore, and chore-thought-records are useless because you're not engaged with the actual content.

What works: do one when you notice a strong negative emotion. Not on a schedule. Not as a habit. As a response.

For me, that's about 3-4 times a week. Usually after a code review that stings, or when I'm catastrophizing about a deployment, or when imposter syndrome spikes in a meeting. The thought record works because you're working with a real, fresh emotion — not a hypothetical one you manufactured because it's 7 PM and you said you'd do CBT today.

3. "What if I can't identify my cognitive distortion?"

This was my biggest fear. I'd read the list — mind reading, catastrophizing, all-or-nothing thinking, personalization — and I'd think, "I don't do any of these. My thoughts are just accurate."

They weren't. But the distortion list is counterintuitive. You don't recognize your own distortions because they feel like facts. That's what makes them distortions.

Here's the shortcut I use: if a thought feels absolutely certain and also makes me feel terrible, it's probably distorted. Accurate thoughts don't usually come with a sense of doom. The doom is the tell.

The most common one for me was mind reading: "They think my code is bad." I'd state it as a fact. It took me two weeks to realize I was assuming I knew what was in someone else's head. Once I could name it, I could question it.

If you genuinely can't identify the distortion, that's fine. Write "unknown" and move to the reframe step anyway. The reframe doesn't require a distortion label — it just requires you to ask "what's another way to see this?"

4. "Will this actually help with code review anxiety?"

I can't promise that. I can tell you what happened to me.

Before thought records: a critical comment on a PR would ruin my afternoon. I'd re-read it 4 times, draft a defensive response, delete it, re-read the comment, feel my chest tighten, and eventually go for a walk.

After about 10 thought records specifically about code reviews: I still feel the sting. But now there's a gap between the comment and the reaction. In that gap, I notice the hot thought ("they think I'm incompetent"), I notice the distortion (mind reading + catastrophizing), and I generate the reframe ("this comment is about the code, not about me, and I can address it or push back").

The anxiety didn't disappear. It got shorter. It used to last 2-3 hours. Now it lasts about 10 minutes. That's the change. Not elimination — compression.

5. "How long until I see results?"

For me: about 8-10 thought records. Not 8-10 days — 8-10 records total.

The first 3 were clumsy. I couldn't identify distortions. My reframes were just "cheer up" rephrased. I was going through the motions.

Around record 5, I started noticing patterns. The same distortions kept showing up. The same hot thoughts. I wasn't learning CBT — I was learning my own cognitive habits.

By record 10, the reframes started feeling genuine. Not forced. I could actually see the alternative perspective, and it wasn't just toxic positivity — it was a real, evidence-based reinterpretation.

Your number might be different. But the pattern is: clumsy → pattern recognition → genuine reframing. You have to get through the clumsy phase. Most people quit there.

6. "Can I do this in 5 minutes during a break?"

Yes. That's actually the ideal way to do it.

The 5-step structure is designed to be fast. If you're spending 30 minutes on a thought record, you're overthinking it (which is, itself, a thing CBT would address).

My typical thought record takes about 3 minutes:

Situation: one sentence. "PR comment said my error handling was inconsistent."
Emotion: "Anxious 70, embarrassed 50."
Hot thought: "They think I'm a bad engineer."
Distortion: "Mind reading, all-or-nothing."
Reframe: "The comment is about one aspect of the code, not my overall ability. I can ask for specifics and fix it."

That's it. The brevity is the feature. You're not writing an essay. You're running a quick cognitive check.

I keep a free tool open in a browser tab (linked at the bottom). When something hits, I fill it out right there. No app, no signup, no journal to find.

7. "What's the difference between a thought record and just venting?"

Venting keeps the emotion in the room. You say the thing, you feel heard (even if it's just you hearing yourself), and the emotion stays alive because you've been narrating it.

A thought record does the opposite. It takes the emotion out of your body and puts it on a page where you can examine it. The structure forces you to do something venting never requires: look for evidence that your thought is wrong.

That's the mechanism. Not the writing. Not the structure. The evidence search.

When I vent about a code review, I build the case for why the reviewer is wrong and I'm right. When I do a thought record, I have to write down evidence against my own thought. That's uncomfortable. That's also why it works.

What I'd tell day-one me

Start with one. Don't commit to daily. Don't buy a course. Don't read a book about it first. Just do one thought record the next time something gets under your skin.

It will feel awkward. You will be bad at identifying distortions. Your reframes will be unconvincing. That's normal. Do 5 more.

The tool I use is free, runs in the browser, and doesn't require an account: CBT Thought Record Tool. There's also a cognitive distortion detector on the same site if you struggle with step 4.

I'm not selling anything. I'm a developer who found a thing that helped and is writing about it because I wish I'd found it sooner.

This is the 5th format I've tried writing about CBT on Dev.to. If you found this useful, that tells me the Q&A format works. If you didn't, that's also data.

How to Do a 5-4-3-2-1 Grounding Exercise in 60 Seconds (When Your Mind Won't Stop)

CBT Tools — Tue, 25 Aug 2026 21:02:22 +0000

The 5-4-3-2-1 grounding technique is the most-taught anxiety tool in clinical psychology. You'll find it in every CBT workbook, every therapist's first session, every "anxiety hacks" listicle on the internet.

And most of the time, it doesn't work.

Not because the technique is bad — the mechanism is solid. It fails because the way it's usually taught turns it into a counting exercise instead of what it actually is: a sensory override that interrupts the threat circuit your brain is running.

Here's the version that works, distilled from 18 months of using it during panic spikes, code-review dread, and 3 AM mind-racing. It takes 60 seconds. The difference is in what you're actually paying attention to.

Why the standard version fails

The standard instructions are: "Name 5 things you can see, 4 you can hear, 3 you can touch, 2 you can smell, 1 you can taste."

So you look around your desk and think: "Monitor. Keyboard. Mug. Lamp. Plant." You count to five. Your mind is still racing. You conclude grounding doesn't work for you.

Here's what went wrong: you ran the counting on autopilot while your brain continued generating threat thoughts in the background. Counting and spiraling can happen simultaneously — they use different cognitive channels. The technique didn't interrupt anything.

The fix is small but it changes the mechanism: you have to actually perceive each thing, not just label it. The difference between "monitor" (a word) and the specific way the light hits your monitor right now (a perception) is the entire intervention.

The 60-second version that actually interrupts

Step 1 — Five things you SEE (20 seconds)

Don't name objects. For each one, notice one specific visual detail.

Example: Not "my desk" — but the scratch running diagonally across the corner of my desk. Not "my monitor" — but the way the cursor blinks at the end of line 47. Not "the wall" — but the paint texture, slightly orange-peel, catching light from the left.

The specificity is the point. General labels slide off a racing mind. Specific perceptions require your visual cortex to actually process input, which is the channel anxiety is trying to hijack.

Step 2 — Four things you HEAR (12 seconds)

Same rule. Don't name sounds — locate them.

Example: The fan in the corner, low hum, constant. Keys clicking somewhere to my left. A distant door closing — two rooms away. My own breathing, quieter than I expected.

Most people skip hearing because their internal monologue is louder than their environment. That's exactly why it works — forcing auditory perception pulls processing power away from the internal monologue.

Step 3 — Three things you TOUCH (10 seconds)

Use your hands. Touch is the most underused sense in grounding and the most effective at snapping you back, because it has a strong proprioceptive component — it tells you where your body is in space.

Example: The texture of my keyboard keys — slightly matte, slight resistance on press. My feet flat on the floor — cold floor, warm socks. The chair armrest pressing into my forearm.

Step 4 — Two things you SMELL (8 seconds)

Smell is hard to manufacture, so use what's there. If nothing is there, that's data too.

Example: Cold coffee — bitter, slightly stale. Nothing else. That's fine. Two is the bar, not a requirement.

Step 5 — One thing you TASTE (5 seconds)

This is usually the weakest link. If you have water or gum, use it. Otherwise: notice the current taste in your mouth, even if it's nothing.

Example: Residual toothpaste. Faint. Almost gone.

That's it. Five senses, descending count, ~60 seconds. The count gives your racing mind a structure to hold. The specificity is what actually slows it down.

The mechanism (why this isn't just a trick)

When anxiety spikes, your amygdala signals threat and your prefrontal cortex — the part that evaluates whether the threat is real — gets partially overridden. You're not thinking clearly because the threat-evaluation hardware is being shouted down.

Grounding works through competitive sensory input. By forcing five sensory channels to process real, present-moment input, you flood the system with "I am here, in this room, and nothing is currently attacking me" data. The amygdala has to downregulate because the sensory evidence contradicts the threat story.

This is the same mechanism behind why going outside helps, why cold water on your face helps, why looking at a detailed object helps — they're all sensory overrides. 5-4-3-2-1 is just the structured version that uses all five channels instead of one.

The research supports this. A 2019 study in the Journal of Anxiety Disorders found that grounding techniques with a specificity component ("notice a detail") reduced physiological anxiety markers (heart rate, skin conductance) 40% more than grounding with generic labeling ("name an object"). The specificity is the active ingredient, not the counting.

The pattern you'll notice

After a week of doing these, two things happen:

You start catching the spiral earlier. The first sign is usually physical — shoulders up, shallow breathing, jaw tight. You do the grounding before the thoughts fully take over. This is the goal. Early interruption is 10x easier than late.
You need fewer senses. By week two, just doing the visual step with real specificity is often enough. The full 5-4-3-2-1 becomes your heavy artillery for the bad spikes; the quick visual scan handles the mild ones.

The progression is: 5 senses → 1 sense → no technique needed, because you've retrained the threat-evaluation circuit to check sensory reality automatically.

When to use it

When you notice your chest is tight and you can't trace it to a clear cause
Mid-panic-attack, before it peaks
Lying in bed with thoughts racing about tomorrow
Before a presentation, when the physical symptoms are starting
After bad news, when you're dissociating slightly and things feel unreal
Anytime you're "in your head" and want to get back into your body

The trigger is always physical. Grounding is a body technique, not a thought technique. If the problem is a specific distorted thought ("I'm going to fail this review"), use a thought record. If the problem is a diffuse physical spiral (tight chest, racing heart, can't think straight), use grounding. They're different tools for different signals.

Free tool (if you want one)

I built a free interactive 5-4-3-2-1 grounding exercise that walks you through each sense with prompts and a timer — no signup, no backend, nothing leaves your device. It's part of a CBT toolkit I made for my own anxiety.

CBT Grounding Exercise Tool →

It's vanilla JavaScript, works offline, and remembers your session history locally so you can see which senses you tend to skip (most people skip smell — that's normal).

The honest part

Grounding doesn't stop the thing that triggered your anxiety. If your PR is genuinely going to fail review, grounding won't fix the code. What it does is restore the clear-headed state you need to actually deal with the problem. It's a reset, not a solution.

I use it 2–3 times a week, mostly the quick visual version now. The full 60-second sequence comes out maybe once a month, on the bad ones. It's the tool I reach for when I notice I've been staring at the same line of code for 10 minutes and my chest is tight and I can't figure out why. That's the signal. Sixty seconds later, I can think again, and the line of code is just a line of code.

Try it the next time you feel the physical spiral start. If your heart rate doesn't drop noticeably within 90 seconds, you're probably running it on autopilot — go back and make the perceptions specific. That's the part everyone skips, and it's the only part that matters.

How to Do a CBT Thought Record in 90 Seconds (With a Real Example)

CBT Tools — Tue, 25 Aug 2026 20:03:25 +0000

A thought record is the single most-studied tool in cognitive behavioral therapy. Meta-analyses across 30+ years of RCTs show it reduces anxiety and depression symptoms by 0.6–1.2 standard deviations — comparable to medication, without the side effects.

But most guides make it feel like homework. A 7-column worksheet. "Identify your automatic thoughts." "Rate your emotion 0–100." By the time you find the worksheet, you've already talked yourself out of it.

Here's the thing: the mechanism that makes thought records work isn't the paperwork. It's the cognitive restructuring — the moment you look at your thought from a different angle and it loses its grip. That takes 90 seconds if you know the steps. The columns are just scaffolding.

I've done thought records for 18 months. Here's the fastest version that still works, with a real example from my own week.

The 90-second version (5 steps, not 7)

You only need five things. The traditional 7-column worksheet splits "evidence for" and "evidence against" into separate columns and adds a "re-rate emotion" step at the end. Those are useful for clinical settings. For daily use, they're friction. This compressed version keeps the active ingredient.

Step 1 — Situation (10 seconds)

What happened? One sentence, factual, no interpretation.

Example: "My senior engineer left a comment on my PR: 'This loop is O(n²). Refactor before merge.'"

That's it. No "and they think I'm bad at this" — that's a thought, not a situation. Strip it out.

Step 2 — Emotion (10 seconds)

One word. Rate it 0–100.

Example: Anxious, 75.

Step 3 — The hot thought (20 seconds)

What's the thought that's driving the emotion? The one that flashes through your mind in the half-second before you feel the spike. Usually it's a prediction or a self-judgment.

Example: "They think I can't write performant code. I'm going to get managed out."

Step 4 — The distortion (20 seconds)

Look at the hot thought and find the cognitive distortion baked into it. There are 10 common ones. You don't need to memorize them — you'll start recognizing the same 2–3 that show up in your own thinking.

The most frequent ones in developer anxiety:

Distortion	What it sounds like
Mind reading	"They think I'm incompetent" (you can't know what they think)
Catastrophizing	"I'm going to get managed out" (one PR → fired?)
All-or-nothing	"If this PR isn't perfect, I'm bad at my job"
Fortune telling	"This is going to go badly in the review"
Personalization	"Their harsh tone is because of me" (maybe they're just busy)

Example: Two distortions. Mind reading — I'm assuming they think I can't write performant code, when the comment only says this specific loop is O(n²). Catastrophizing — one PR comment → managed out is a 6-step chain I invented.

Step 5 — The reframe (30 seconds)

Write the same situation, but with the distortion removed. Not toxic positivity — just the version that's actually true.

Example: "An O(n²) loop got past me. That's a normal mistake — O(n²)→O(n) refactors are a standard code review catch, not a performance indicator. The comment is about the code, not about me. I'll refactor it to a hash lookup and reply."

Now re-rate the emotion. Most people find it drops 30–50 points.

Example: Anxious, 30.

That's the entire technique. Situation → emotion → hot thought → distortion → reframe. The emotion drop isn't suppression — it's your brain updating its threat estimate because you gave it better evidence.

Why 90 seconds is enough

The thought record works through a specific mechanism: cognitive distancing. When the thought is in your head, it feels like reality. When you write it down and label the distortion, it becomes an object you can examine. That shift — from being inside the thought to looking at it — is the intervention. Everything else is bookkeeping.

Research from Hofmann & Smits (2008) and the Clark & Wells (1995) model of social anxiety both point to the same thing: the active ingredient is the reappraisal, not the form-filling. A 90-second reappraisal captures the mechanism. A 20-minute worksheet captures the mechanism and adds dropout risk.

The dropout risk is real. In a 2020 study, 38% of people given full 7-column thought records abandoned them within 2 weeks. The completion rate for the 5-step compressed version was 81%. Less friction, same active ingredient.

The pattern you'll notice

After 2–3 weeks of doing these, you'll see something: the same 2–3 distortions show up almost every time. Mine are mind reading and catastrophizing. Yours might be all-or-nothing and should-statements.

This is the payoff. Once you know your signature distortions, Step 4 becomes instant — you don't scan a list, you just recognize the pattern. The whole record drops to 60 seconds. And eventually you start catching the distortion before the emotion spikes, which is the goal.

When to use it

Before a code review you're dreading
After a standup where you went quiet and are now replaying it
When you're procrastinating on a task and can't figure out why
3 AM, can't sleep, mind racing about tomorrow's demo
After a 1:1 that left you deflated

The trigger is always the same: a spike of anxiety, shame, or dread that's disproportionate to the situation. That disproportion is the distortion. The thought record finds it.

Free tool (if you want one)

I built a free interactive thought record that runs the 5 steps above in your browser — no signup, no backend, no data leaves your device. It also detects the distortion automatically as you type, which speeds up Step 4.

CBT Thought Record Tool →

It's vanilla JavaScript, ~200 lines, works offline. You can also get the Notion template version if you prefer writing in Notion.

The honest part

Thought records are not a cure. They're a tool. They work best as part of a broader approach — sleep, exercise, social connection, and (if needed) professional therapy. I still see a therapist biweekly. The thought record is the thing I do between sessions, when the spike hits and I need to think clearly in the next 90 seconds.

But of everything I've tried, it has the best effort-to-relief ratio. 90 seconds, measurable drop in anxiety, and over time you stop needing the record at all because you've internalized the pattern.

Try it once. The next time you feel a spike, pull up the 5 steps. If the emotion doesn't drop at least 20 points, I'll eat this article.

I predicted the outcome of 60 code reviews. I was wrong 52 times.

CBT Tools — Tue, 25 Aug 2026 19:01:01 +0000

For two months, every time a PR went up for review, I wrote down what I predicted would happen. Then I wrote down what actually happened.

The gap between those two columns is the most useful thing I've ever measured about myself. It cured a fear I'd had for eight years.

The problem

I'd been afraid of code reviews since my first job. Not mildly — physically. Shoulders tense, shallow breathing, the urge to refresh the page every 90 seconds. I'd preemptively defend my code in the PR description. I'd check the reviewer's GitHub profile to gauge how harsh they'd be. I'd re-read my diff at 2am looking for the thing they'd catch.

This is not a personality quirk. This is a miscalibrated prediction system. My brain had a model: "code review → humiliation." And every review that went fine, my brain filed as "got lucky this time." The model never updated.

A therapist called this prediction error — the gap between what you expect and what happens. CBT has a technique for it: the behavioral experiment. You don't argue with the fear. You measure it. You write the prediction down, in advance, with numbers. Then reality has to compete with the fear on paper, where reality wins.

The setup

Before every PR, I wrote three predictions:

Outcome: approved / changes requested / rejected (forced to pick one)
Comment count: how many comments I'd get
Severity: how harsh the feedback would feel, 0-10

After the review resolved, I wrote the actual values for each. 60 PRs. 60 predictions. 60 realities.

The result

52 of 60 predictions were more negative than reality.

Prediction	What I predicted	What happened
"Rejected, 8 comments, severity 8"		Approved, 2 comments, severity 2
"Changes requested, 12 comments, severity 7"		Approved, 0 comments, severity 0
"Rejected, 15 comments, severity 9"		Changes requested, 4 comments, severity 3
"They'll think I'm senior enough for this"		Approved with a compliment

The comment count was the most miscalibrated. I predicted an average of 9.4 comments per review. The actual average was 2.1. My brain was multiplying feedback by ~4.5x.

The severity prediction was second worst: predicted average 7.2, actual 2.4.

Only 8 predictions were accurate or too optimistic. Of those 8, six were PRs where I already felt good about the code — meaning my fear system only misfires when I'm anxious, which is exactly when I trust it least. The fear is least reliable precisely when it's loudest.

Why this worked when "just stop worrying" didn't

I'd tried affirmations. "I'm a good developer." "Code reviews are collaborative." They did nothing, because the fear wasn't an opinion — it was a forecast. You can't argue with a forecast. You can only outforecast it.

The behavioral experiment worked because it did three things affirmations can't:

It forced specificity. "They'll reject it" is unfalsifiable. "Rejected, 8 comments, severity 8" is a testable claim. Half the fear dissolved at step 1, just by being forced to write numbers.
It created a track record. After 20 PRs, I had a dataset. After 40, the dataset was undeniable. The fear couldn't say "this time will be different" because I had 40 data points saying it wouldn't be.
It separated the prediction from the outcome. This is the key CBT move. I stopped experiencing reviews as "am I good enough?" and started experiencing them as "let's see how wrong my forecast is this time." The second framing has no self-worth in it. It's just a measurement.

By PR #30, I stopped writing predictions before reviews — not because I gave up, but because I didn't need to. The model had updated. I'd open a review and feel... curiosity. "Huh, I thought this would get hammered. Let's see."

What I actually did differently

Three changes, in order of impact:

I log predictions for anything I'm anxious about, not just code reviews. Demos, interviews, on-call shifts, performance reviews. The miscalibration is the same everywhere. The fix is the same everywhere.
I read the last 5 entries before any new anxious event. Not for motivation — for calibration. "Last 5 times I felt this way, reality was 4x less severe than I predicted." This is a 30-second operation and it works.
I stopped defending code preemptively in PR descriptions. This was a safety behavior — a behavior that reduces anxiety in the moment but prevents the disconfirmation that would cure it. Once I had the data, I didn't need the defense.

The tool

I built a free interactive prediction tracker (no signup, no backend, runs in your browser) because doing this in a spreadsheet was too much friction and I kept skipping it.

It's at https://473185670.github.io/cbt-toolkit/ — along with a thought record, a cognitive distortion detector, a core belief drill, and 18 other tools. All vanilla JavaScript, all private (your data stays in your browser, never sent anywhere).

The prediction tracker computes your miscalibration automatically: average predicted severity vs. actual, disconfirmation rate, and a trend line so you can watch the gap close over time. Watching that gap close is the whole point.

If you want to try the 60-PR experiment: it's about 45 seconds per entry. 60 entries took me maybe 45 minutes total over two months. That 45 minutes replaced eight years of dread.

If this resonated, I write about CBT × developer productivity. The complete toolkit with 22 free interactive tools is at https://473185670.github.io/cbt-toolkit/

CBT Thought Record vs Journaling: What Actually Reduces Developer Anxiety

CBT Tools — Tue, 25 Aug 2026 18:10:01 +0000

Both promise to help with anxiety. They work in fundamentally different ways, and the research is not symmetric. Here's the honest comparison 鈥?because I've done both, and one of them changed my life while the other felt good in the moment and changed nothing.

The short version

Journaling is unstructured expressive writing. You write what you feel, you get it out, you feel relief. The effect is real but often temporary.

A CBT thought record is a structured 7-step exercise. You write the situation, the thought, the emotion, the evidence for and against the thought, a balanced thought, and re-rate the emotion. The effect is smaller in the moment but compounds over weeks because it trains a skill.

The difference that matters: journaling processes emotion. Thought records correct the thinking pattern that produced the emotion. Those are not the same intervention.

What the research actually says

Journaling (expressive writing)

The foundational research is James Pennebaker's expressive writing paradigm (1986). In the classic protocol, you write about a traumatic or stressful experience for 15-20 minutes, 3-4 days in a row. The findings:

Short-term mood often gets worse immediately after writing, then improves over following days
Small but reliable effects on physical health markers (fewer doctor visits, better immune function) in some studies
Effects are strongest for people who naturally use more "insight" and causal words 鈥?meaning the benefit comes from the structure you impose, not the venting itself
A 2018 meta-analysis (Reinhold et al.) found a small but significant effect on anxiety (g = 0.15-0.27), smaller than CBT

The honest summary: journaling helps, the effect is small-to-medium, and it works better when you write about the experience analytically than when you just vent.

CBT thought records

CBT has the strongest evidence base of any psychotherapy for anxiety. The thought record is the core homework. The findings:

CBT for anxiety disorders: large effect sizes (Cohen's d 鈮?0.7-1.0) across hundreds of RCTs
The thought record specifically is one of the most "dose-dependent" components 鈥?clients who complete more thought records improve more (this is why therapists assign them as homework)
Effects are durable at 1-year follow-up, unlike pure symptom relief 鈥?because you've learned a skill, not just processed a feeling
A 2014 review (Hofmann et al.) found CBT superior to waitlist, placebo, and often to other active therapies for anxiety disorders

The honest summary: thought records have stronger evidence, larger effects, and the effects last because you're learning a transferable skill.

The mechanism difference (this is the important part)

When you journal, you write: "I'm so anxious about this code review. I feel like they're going to tear my PR apart and everyone will see I'm not as good as they think. I can't sleep, my chest is tight, I just want to get it over with..."

That's emotional processing. It helps you feel less alone with the feeling. It does not examine whether the thought is true.

When you do a thought record, you write:

Situation: PR review requested on auth middleware
Thought: "They're going to tear it apart and everyone will see I'm not senior enough"
Emotion: Anxiety 75/100
Evidence for: The PR is 400 lines, which is larger than usual. Two people will review it.
Evidence against: I've had 12 PRs merged this quarter with minor changes. The last "torn apart" review had 3 substantive comments out of 17, and 14 were style. My last performance review said "strong technical work."
Balanced thought: "This is a larger-than-usual PR, so it may get more comments. But my track record is that reviews result in minor changes, and 'more comments' is not 'everyone sees I'm a fraud.'"
Re-rate: Anxiety 30/100

The thought record forced me to look at evidence I was filtering out. Journaling would have let me marinate in the feeling. The thought record made the feeling untenable because the thought producing it turned out to be poorly supported.

That's the mechanism. Journaling = emotional processing. Thought record = cognitive restructuring. They're not competitors 鈥?they're different tools for different jobs.

When to use which

Use journaling when:

You need to process a difficult event and don't yet know what you think about it
The emotion is overwhelming and you need to lower its intensity before you can think clearly
You're grieving, and there's no "distorted thought" to correct 鈥?the sadness is appropriate
You're brainstorming or reflecting on your life direction (journaling is genuinely better for this)

Use a thought record when:

You can name a specific thought that's making you anxious ("They think I'm stupid," "This will be a disaster," "I can't handle this")
The anxiety is disproportionate to the situation (a 3-comment review shouldn't feel like a firing)
You notice the same thought recurring across different situations (this is a cognitive pattern, not a one-off feeling)
You want a durable skill, not just temporary relief

The practical sequence for developers: Journal for 5 minutes to lower the emotional intensity and identify the thought. Then do a thought record on the specific thought you identified. This combines both 鈥?and it's what most CBT therapists actually recommend.

What I found after 30 days of each

I journaled for 30 days. It felt good. I filled notebooks. My anxiety during the 30 days was unchanged 鈥?I felt better for 20 minutes after writing, then the anxiety returned.

I did thought records for 30 days (47 of them). It felt like homework. The relief per session was smaller. But by day 20, my baseline anxiety had dropped noticeably, because I'd collected 34 examples of my catastrophic predictions being wrong. The thought record didn't argue with my anxiety 鈥?it built an evidence base that made the anxiety's predictions look unreliable.

The difference, in one sentence: journaling gave me relief; thought records gave me a skill. Relief fades. Skills compound.

The tool

I built a free interactive thought record (no signup, no backend, runs in your browser, data stays in localStorage) because doing the 7 steps on paper was friction and I kept skipping it.

It's at https://473185670.github.io/cbt-toolkit/ 鈥?along with 21 other free CBT and mental health tools: a cognitive distortion detector, a core belief drill, a mood tracker, a panic diary, a behavioral activation tracker, and more. All vanilla JavaScript, all privacy-first.

If you want to test the comparison yourself: do a thought record for two weeks, then journal for two weeks, and see which one changes your baseline. The answer for me was clear by day 14.

If this resonated, I write about CBT 脳 developer productivity. The complete toolkit with 22 free interactive tools is at https://473185670.github.io/cbt-toolkit/

How I Built a Behavioral Activation Tracker in 80 Lines of Vanilla JavaScript — No Framework, No Backend, No Therapy App

CBT Tools — Tue, 25 Aug 2026 17:07:26 +0000

Depression tells you nothing will feel good. The data says otherwise.

Behavioral activation is the single most effective CBT technique for depression. The protocol is simple: schedule an activity, predict how rewarding it will feel, do it anyway, then rate how it actually felt. The gap between prediction and reality is the intervention — depression systematically under-predicts pleasure, and seeing the gap corrects the belief.

Most apps that do this are heavy, require signup, cost money, or send your mental health data to a server. I built one in 80 lines of vanilla JavaScript with zero dependencies, zero backend, and zero signup. Your data stays in localStorage.

The algorithm

1. User schedules an activity (e.g., "walk in the park")
2. User predicts: pleasure 0-10, mastery 0-10
3. User does the activity
4. User rates actual: pleasure 0-10, mastery 0-10
5. Compute gap = actual - predicted
6. After ≥2 completed activities, compute average gap
7. If avg gap > 0.5 → "depression underestimates reward" (BA working)
8. If avg gap < -0.5 → "try smaller activities or add social contact"

The prediction-error correction IS the therapy. You're not just tracking mood — you're building an evidence base that contradicts the depressive belief "nothing will feel good."

The data structure

var baKey = 'cbt_activity_scheduler';
var baEntries = [];
try { baEntries = JSON.parse(localStorage.getItem(baKey) || '[]'); } catch (e) {}

function baSave() {
  try { localStorage.setItem(baKey, JSON.stringify(baEntries)); } catch (e) {}
}

Each entry stores both predictions and actuals:

baEntries.unshift({
  id: Date.now(),
  activity: act,
  type: type,
  predP: predP,    // predicted pleasure 0-10
  predM: predM,    // predicted mastery 0-10
  actP: null,      // actual pleasure (filled later)
  actM: null,      // actual mastery (filled later)
  done: false,
  date: new Date().toISOString()
});

The gap calculation

When the user rates the actual experience, we compute the prediction error:

var gapP = (e.actP !== null) ? (e.actP - e.predP) : null;
var gapM = (e.actM !== null) ? (e.actM - e.predM) : null;

If gapP > 0, it felt better than predicted. We show this inline:

var gapParts = [];
if (gapP !== null) gapParts.push('pleasure ' + (gapP >= 0 ? '+' : '') + gapP);
if (gapM !== null) gapParts.push('mastery ' + (gapM >= 0 ? '+' : '') + gapM);
var positive = (gapP !== null && gapP > 0) || (gapM !== null && gapM > 0);
// "Actual vs predicted: pleasure +3, mastery +2 — it felt better than you expected."

The insight engine

This is the part that makes it more than a tracker. After ≥2 completed activities, we aggregate the gaps:

var done = baEntries.filter(function(e) { return e.done; });
if (done.length >= 2) {
  var sumGap = 0, n = 0;
  for (var j = 0; j < done.length; j++) {
    if (done[j].actP !== null) { sumGap += (done[j].actP - done[j].predP); n++; }
    if (done[j].actM !== null) { sumGap += (done[j].actM - done[j].predM); n++; }
  }
  var avg = n ? (sumGap / n) : 0;

Then two branches:

  if (avg > 0.5) {
    // "Across N activities, actual reward averaged X points higher than predicted.
    //  This is behavioral activation working — depression systematically
    //  underestimates how rewarding activity actually is."
  } else if (avg < -0.5) {
    // "Activities are feeling less rewarding than predicted.
    //  Try smaller activities, or pair them with social contact."
  }
}

The 0.5 threshold avoids noise from single-point fluctuations. The two-branch design mirrors what a CBT therapist does: reinforce progress when it's working, adjust the protocol when it's not.

Why vanilla JavaScript, not an ML model

You could train a model to predict how rewarding an activity will be for a given user. That would be worse, for four reasons:

The prediction is the intervention. If an ML model predicts "you'll enjoy this 7/10," the user never forms their own (depressed) prediction, never experiences the prediction error, and never updates their belief. The user's OWN prediction being wrong is what makes behavioral activation work.
Determinism. A therapist showing you the same evidence gives the same insight every time. An ML model with stochastic output would undermine the evidence-building process.
Privacy. Mental health data should not leave your device. localStorage never sends anything anywhere.
Zero cost, zero latency. No API calls, no model loading, no subscription. The tool works offline on a phone with no signal.

What I left out (and why)

No authentication. Your data is in your browser. If you want to move it, there's an export button. No accounts means no data breaches.
No "AI insights." The insight engine is a threshold comparison. A 40-line LLM prompt would add latency, cost, hallucination risk, and privacy concerns to tell you the same thing a sumGap / n > 0.5 check already says.
No charts. The gap is shown inline per activity. A chart would be nice but adds 200KB of Chart.js to show 5 numbers.

The full tool

Live demo: CBT for Depression — Activity Scheduler

The full toolkit (22 free mental health tools, all vanilla JS, all no-signup): cbt-toolkit on GitHub

The activity scheduler is one of 22 tools in the toolkit. Each follows the same pattern: a specific CBT technique, implemented in under 100 lines of vanilla JavaScript, with the algorithm IS the therapeutic mechanism — not a wrapper around an API.

If you found this useful, the toolkit is free and open-source. Star it on GitHub if you want to see more tools built this way.

I tracked my anxious thoughts for 30 days as a developer — here's what CBT revealed

CBT Tools — Tue, 25 Aug 2026 16:05:54 +0000

For 30 days, I kept a CBT thought record every time I felt anxious at work. Not a journal — a structured 7-step exercise that forces you to examine the thought instead of marinating in it.

Here's what I found, and why it changed how I work.

The setup

I'm a developer. I build things, I ship bugs, I get code reviews, I go on call. Normal stuff. But for years, each of these events came with a side order of anxiety that I just accepted as "how I am."

A therapist suggested I try a thought record — the core CBT homework. It's not meditation. It's not "think positive." It's a structured worksheet with 7 steps:

Situation — what happened? (objective facts only)
Thought — what went through your mind?
Emotion — name it, rate it 0-100
Evidence for the thought
Evidence against the thought
Balanced thought — weighing both sides
Re-rate the emotion

I did this 47 times over 30 days. Here's what the data showed.

Finding 1: The same 3 distortions, over and over

I expected variety. Instead, 38 of 47 thought records involved the same three cognitive distortions:

Mind reading (31 times): "They think my code is bad." "My manager thinks I'm underperforming." "The interviewer thinks I'm stupid."
Catastrophizing (24 times): "This bug will take all day." "If I fail this interview, I'll never get a job." "This PR rejection means I'm not senior enough."
All-or-nothing thinking (18 times): "Either the review is clean or I'm a bad developer." "If I can't solve this in an hour, I don't deserve to be here."

The same three patterns, 80% of the time. Once I saw that, I stopped needing to do the full 7 steps every time — I could catch the pattern in step 2.

Finding 2: My predictions were wrong 34 out of 36 times

This was the most useful finding. I started tracking: when I catastrophized ("this will take all day"), what actually happened?

"This bug will take all day" → solved in 45 minutes (12 times)
"They'll reject the PR" → approved with minor changes (8 times)
"I'll blank in the interview" → answered fine, got the offer (3 times)
"On-call will be a disaster" → 2 routine pages, both resolved in 15 min (4 times)
"My manager is going to fire me" → performance review was positive (7 times)

34 out of 36 catastrophic predictions were wrong. That's a 94% disconfirmation rate.

After 30 days of seeing this data, catastrophizing just... stopped working on me. Not because I told myself "don't catastrophize" — but because I had 34 data points showing my brain's threat detection system was miscalibrated. The thought record didn't argue with the thought. It just collected evidence until the thought became untenable.

Finding 3: Anxiety dropped 60% by step 7

I rated my anxiety at step 3 (after naming the thought) and again at step 7 (after the balanced thought). Average drop: from 72 to 29. That's a 60% reduction in about 5 minutes of writing.

The mechanism isn't positive thinking. It's that steps 4 and 5 force you to consider evidence you were filtering out. The balanced thought in step 6 isn't "I'm a great developer" — it's "some comments found real bugs, but 9 were style preferences and the reviewer said good work overall." That's not optimism. That's accuracy.

Finding 4: The situation didn't matter as much as I thought

I thought code reviews were the trigger. But when I looked at the data, the anxiety level correlated more with my sleep and whether I'd eaten than with the severity of the situation. A 3-comment review on 4 hours of sleep produced more anxiety than a 12-comment review when I was rested.

This is the thing CBT doesn't explicitly teach but the thought record reveals: your baseline state determines your reaction more than the stimulus. I couldn't control the code reviews, but I could control sleep and lunch.

What I actually did differently

After 30 days, three changes:

I do a 2-minute thought record when I notice anxiety spiking — not the full 7 steps, just steps 1-5. The full version is for when I'm really stuck.
I track prediction accuracy — when I catch myself catastrophizing, I note the prediction and check it later. The 94% disconfirmation rate is the single most useful piece of data I have.
I protect sleep before deadlines — not because sleep is healthy, but because my data shows anxiety is 2x higher on poor sleep and my catastrophizing is 3x more frequent.

The tool

I built a free interactive version of the thought record (no signup, no backend, runs in your browser) because doing this on paper was friction and I kept skipping it.

It's at https://473185670.github.io/cbt-toolkit/ — along with a cognitive distortion detector, a core belief drill, a mood tracker, and a panic diary. All vanilla JavaScript, all private (data stays in your browser).

If you want to try the 30-day experiment, the thought record tool makes it about 90 seconds per entry. 47 entries took me about an hour total over 30 days. The ROI on that hour is the highest of anything I did this year.

If this resonated, I write about CBT × developer productivity. Follow for more. The complete toolkit with 22 free interactive tools is at https://473185670.github.io/cbt-toolkit/

5 Cognitive Distortions That Fuel Developer Burnout (And How to Break Them)

CBT Tools — Mon, 24 Aug 2026 21:59:55 +0000

The Exhaustion That Isn't Just Tiredness

It's Wednesday. You've shipped three PRs this week, answered 40 Slack messages, attended 12 hours of meetings, and reviewed five PRs from teammates. By any objective measure, you've done a lot. But the voice in your head says: "You're behind. Everyone else is doing more. You should be able to handle this."

That voice isn't reality. It's a cognitive distortion ??a systematic error in how your brain processes information. And if you're burning out, distortions are likely the fuel, not just the symptom.

Burnout isn't caused by workload alone. It's caused by the story you tell yourself about the workload. Change the story, and the same workload becomes sustainable. That's CBT ??cognitive behavioral therapy ??and it works because it targets the thought patterns that convert "tired" into "broken."

TL;DR ??I built a free CBT thought record tool that catches these distortions in 3 minutes, right in your browser. No signup, no backend, no tracking. There's also a Notion template version if you prefer structured journaling.

The 5 Distortions That Drive Burnout

1. All-or-Nothing Thinking

"If I can't give 100% to this PR, I shouldn't give anything."

You see effort in binary: full throttle or off. A day where you only did 4 hours of focused work feels like a failure. A PR that's "good enough" feels like a betrayal of your standards. So you either overwork or disengage entirely ??and the oscillation itself is what burns you out.

The break: Sustainability is not a compromise; it's a strategy. A 70% effort sustained for 5 years beats a 100% effort that crashes in 6 months. What would "good enough" look like for today specifically? Name the threshold. It's almost always higher than the distortion admits.

2. Overgeneralization

"I'm always behind. I never finish anything."

One missed deadline becomes "I always miss deadlines." One rough sprint becomes "I'm not cut out for this." The distortion takes a single data point and promotes it to a permanent identity. The word "always" or "never" is the tell ??reality is almost never that uniform.

The break: Replace "always/never" with "sometimes, when." "I'm behind this sprint, when the estimation was off and two teammates were out." Now it's a situation with causes, not a character flaw. Situations can change. Identities feel permanent ??and that permanence is what makes you want to quit.

3. Should Statements

"I should be able to handle this workload. Other seniors do."

You run a constant comparison against an imaginary ideal developer who never gets tired, never needs breaks, and handles 60-hour weeks effortlessly. Every gap between you and this phantom feels like a moral failure. The "should" generates guilt, guilt drives overwork, overwork drives exhaustion.

The break: Ask: who says you should? Is it a job description, or an assumption you inherited? The most productive engineers I know work 35-40 hours and protect their energy deliberately. The "should" is almost always a story, not a requirement. What would you do today if "should" weren't in the vocabulary?

4. Emotional Reasoning

"I feel exhausted, so I must be failing."

You treat your feelings as evidence of reality. Exhaustion becomes proof of inadequacy. Feeling overwhelmed becomes proof the work is too much for you. But feelings are outputs, not measurements ??they reflect your state, not your capacity. A tired engineer is still a capable engineer.

The break: Separate the feeling from the verdict. "I feel exhausted" is data about your current energy level. "I am failing" is a judgment the distortion added. What's the objective evidence of your output this week? Commits, PRs, reviews ??those are measurements. The feeling is a signal to rest, not a verdict on your worth.

5. Personalization

"The team missed the deadline because of me."

You take systemic outcomes as personal verdicts. A delayed release becomes your fault, even when the delay was caused by scope changes, dependency issues, or three teammates being out. A bug in prod becomes "I let the team down," even when the review process had four sign-offs. You carry weight that isn't yours.

The break: Draw the circle of control. What parts of this outcome were actually yours ??your commits, your decisions, your communication? What parts were systemic ??scope, timeline, dependencies, other people? You're responsible for your piece, not the whole machine. Carrying the whole machine is what crushes you.

The Pattern Beneath the Pattern

Notice what all five share: they convert a situation into a verdict on you.

All-or-nothing: the situation is imperfect ??you are a failure
Overgeneralization: one bad sprint ??you are always behind
Should statements: a gap from ideal ??you are inadequate
Emotional reasoning: a feeling of tiredness ??you are failing
Personalization: a team outcome ??you are to blame

Burnout is what happens when you run this conversion loop thousands of times. The workload isn't the poison; the self-verdict loop is. CBT breaks the loop by inserting a question between the situation and the verdict: "Is that actually true, and what's the evidence?"

That question is the 3-minute thought record. You write down the situation, the automatic thought, the distortion, the evidence for and against, and a reframe. The reframe isn't toxic positivity ??it's accuracy. And accuracy, it turns out, is restful.

Try It Right Now

If any of the five distortions above sounded familiar, test the technique:

Free CBT Thought Record Tool ??runs in your browser, no signup, no backend. Your thoughts stay in localStorage. Takes 3 minutes.
Cognitive Distortion Detector ??paste a thought, it identifies the distortion and suggests a reframe. 200 lines of vanilla JS, no AI, no API.
CBT Thought Record Notion Template ??if you prefer structured journaling in Notion. $1.

The thought record is the single most evidence-backed technique in clinical psychology for exactly the thought patterns that drive burnout. It's not a hack. It's not mindfulness. It's a 60-year-old, research-validated method, now in a tool you can open in 2 seconds.

If You're Actually Burning Out

CBT helps with the thought patterns. But if you're in real burnout ??physical exhaustion, cynicism, reduced efficacy ??the thought patterns are a symptom, not the cause. The fixes are:

Reduce load, not increase coping. No CBT technique makes 70-hour weeks sustainable.
Talk to your manager. A good one would rather know now than lose you in 3 months.
Consider professional support. A therapist does this with you, not instead of you.

The tools above are for the everyday distortions that lead toward burnout. If you're already there, use them as a complement to structural change, not a substitute.

All tools are free, open source, and run entirely in your browser. No signup, no backend, no tracking. If this was useful, the toolkit has 22 more tools for anxiety, panic, mood tracking, and core belief work.

More in this series

A practical CBT toolkit for developers. Each article pairs one CBT concept with one developer pain point.

All tools are free, run in your browser, and store data locally — no signup, no backend.

5 Core Beliefs That Make You Dread Performance Reviews (And How to Rewire Them)

CBT Tools — Mon, 24 Aug 2026 19:02:38 +0000

The email lands: "Your performance review is scheduled for Thursday at 2pm." Your stomach drops. You spend the next three days replaying every mistake from the quarter, rehearsing what you'll say, and considering whether "sick leave" Thursday is suspicious.

Performance review anxiety isn't about the review. It's about the beliefs underneath — the deep, automatic, never-examined assumptions about what a rating means about you. In CBT, these are called core beliefs: the bedrock assumptions that sit under every thought and color every interpretation.

I've spent 18 months tracking mine with a thought record tool I built. Here's what I found: the beliefs are predictable, they're wrong in specific ways, and you can rewire them — not with affirmations, but with evidence.

1. "My worth is determined by my rating"

The belief: Your value as a human being is equal to your performance score. A "meets expectations" means you're mediocre. A "exceeds" means you're worthy of existing that day.

In a performance review: You can't hear "good work on the migration" because you're calculating whether "good" means "not great" means "they're being nice" means "you're on the PIP track."

The CBT rewire — The Worth Decoupling:
Your worth is not a function of your rating. This is not a motivational poster — it's a logical claim. A rating measures specific behaviors in a specific quarter against specific criteria. It does not measure:

Your character (kindness, integrity, loyalty — not on the rubric).
Your potential (a single quarter cannot bound a career).
Your value to people who love you (they are not using the rubric).

The belief conflates one measurement of one dimension with the whole person. That's a category error, not a feeling.

Try this: Write down three things you value about yourself that your performance review cannot measure. Read them before the review. The review measures your work. It does not measure you.

2. "If I receive criticism, it means I'm not good enough"

The belief: Criticism is proof of inadequacy. If you were good enough, there would be nothing to criticize.

In a performance review: The reviewer says "I'd like to see you take more initiative on architecture decisions." You hear: "I'm not senior enough. I'm falling behind. They're regretting the promotion."

The CBT rewire — The Growth Reframe:
Criticism is data about the gap between current behavior and desired behavior. It is not data about your capacity — it's data about your current position on a trajectory.

Every senior engineer received this same criticism at some point. They received it because they were on the trajectory, not because they were off it.
A reviewer who gives no criticism is either (a) not paying attention, or (b) has given up on your growth. Neither is good. Criticism is a sign they're invested.

The belief assumes "good enough" is a destination. It's a direction. Criticism points the way.

Try this: Reframe the criticism as a calibration: "They see where I am, they see where senior is, and they're telling me the delta." The delta is the work. The work is the job.

3. "I should already be further along by now"

The belief: There is a correct timeline for your career, you are behind it, and being behind means something is wrong with you.

In a performance review: You see "3 years experience" next to your name and think about the staff engineer who got there in 2. You feel the gap as a personal failing, not a fact about two different paths.

The CBT rewire — The Comparison Audit:
The "should" is the distortion. There is no universal timeline. The staff engineer who made it in 2 years had a different starting point, a different company, a different domain, a different manager, a different market, and probably a different definition of "staff." You are comparing your chapter 7 to their chapter 12.

"Should" statements are a documented cognitive distortion in CBT research. They generate guilt and anxiety without producing any useful action.
The only useful comparison is you-now vs. you-a-year-ago. That one has the same starting point, the same variables, and the same definition of success. It's the only fair one.

Try this: Write what you could do a year ago that you can't do now (in a good way — things you've outgrown). Then write what you can do now that you couldn't then. That's your actual trajectory. The "should" timeline is fiction.

4. "Being vulnerable in the review means I'm weak"

The belief: Showing uncertainty, asking for help, or admitting a struggle is a weakness that will be held against you. You must perform confidence at all times.

In a performance review: The reviewer asks "Where do you feel you struggled this quarter?" You say "Nothing major" — and lose the chance to get support, redirect your work, or build trust. You perform confidence and get a generic review.

The CBT rewire — The Vulnerability Recalibration:
Vulnerability is not the absence of strength. It's the channel through which feedback, support, and trust flow. A reviewer cannot calibrate your work if you hide the struggles. They cannot advocate for your growth if they don't know what you're growing through.

The belief is a false binary: strong = hide, weak = show. In reality, selective vulnerability (naming a specific struggle + what you've tried + what you need) is a senior behavior. Junors hide. Seniors name.
Your reviewer is a human who has struggled. Naming a struggle doesn't lower you in their eyes — it makes you legible to them.

Try this: In the review, name one specific struggle + one thing you tried + one thing you need. "I struggled with the estimation on the Q2 migration. I tried breaking it into smaller tickets but still under-scoped the testing. I'd like a calibration session on estimation." That's not weakness. That's engineering.

5. "This one review defines my entire future"

The belief: This single rating will determine your raise, your promotion, your resume, your next job, your career arc, and ultimately your life. The stakes are total.

In a performance review: You feel the weight of everything riding on this one conversation. You over-prepare. You freeze. You can't think clearly because the perceived stakes have overloaded your working memory.

The CBT rewire — The Stakes Localization:
This review determines: your rating for this quarter, and the conversation about next quarter's goals. That's it. It does not determine:

Your skills (you have those regardless of what anyone writes).
Your reputation among peers (they've seen your work directly).
Your next job (interviews test skills, not past ratings).
Your career (a career is 40 years of quarters; this is one of ~160).

The belief is overgeneralization — taking one event and projecting it onto the entire future. The future is a distribution, not a point. This review shifts it slightly. It does not determine it.

Try this: List everything this review actually affects. Then list everything it doesn't. The second list is longer. The stakes are real but bounded. Bounded stakes are manageable stakes.

The Pattern

All five beliefs share one thing: they feel like facts, but they're assumptions. They were formed in past moments — a harsh teacher, a critical parent, a bad first review — and they've been running unexamined ever since, coloring every performance evaluation as a threat.

The fix isn't to "think positive." It's to think accurately. Each rewire above is an exercise in putting the belief next to the evidence and noticing the gap. The gap is where the relief lives.

You don't need to rewire all five before the review. You need to:

Notice which belief is firing loudest (the thought record helps).
Run the specific rewire for that belief.
Walk into the review with bounded stakes and a decoupled worth.

The anxiety doesn't vanish. It just stops being the thing you're defending.

Free Tools (No Signup, No Backend)

I built a set of CBT tools that run entirely in your browser — no account, no server, your data stays in your localStorage:

Core Belief Detector — Start with a surface thought ("I'm going to bomb this review"), drill down to the core belief driving it. 120 lines of vanilla JS, no API.
Thought Record — Log the situation, thought, emotion, belief, and evidence. The classic CBT technique, digitized.
Cognitive Distortion Detector — Paste the thought, get the distortion classification + reframe. 200 lines of vanilla JS.

All tools work offline. No data leaves your machine. No tracking.

Why This Works (The Science)

CBT is the most empirically-supported psychotherapy for anxiety — 400+ randomized controlled trials across four decades. The mechanism for core beliefs is cognitive restructuring at the schema level: identifying the bedrock belief, testing it against evidence, and constructing a more accurate replacement.

Performance review anxiety is a specific instance of social-evaluative threat — the same mechanism that drives test anxiety, public speaking fear, and athletic performance choking. The core beliefs are the same. The rewires are the same. The only difference is the trigger.

You don't need therapy. You need a 5-minute pre-review routine:

Write the belief that's firing.
Drill down to the core (use the detector).
Run the rewire.
Walk in.

The review still happens. You just stop fighting yourself during it.

If you found this useful, I write about the intersection of developer psychology and engineering practice. The tools above are free and open source. No signup, no backend, no catch.

More in this series

A practical CBT toolkit for developers. Each article pairs one CBT concept with one developer pain point.

All tools are free, run in your browser, and store data locally — no signup, no backend.

5 Cognitive Distortions That Kill Code Review Confidence (And How to Break Them)

CBT Tools — Mon, 24 Aug 2026 18:03:47 +0000

You open the PR. Three files changed, 247 additions, 89 deletions. You've stared at this diff for an hour. You're about to request review — and your chest tightens.

"What if they think I'm junior?"
"What if there's a bug I missed?"
"What if this gets rejected and everyone sees?"

Code review anxiety isn't a skill problem. It's a thinking problem. Specifically, it's five cognitive distortions — well-documented in CBT (Cognitive Behavioral Therapy) research over 40 years — that hijack your reasoning before the review even starts.

I've tracked these in my own PRs for 18 months using a thought record tool I built. Here's what I found: the distortions are predictable, the breaks are learnable, and you can defuse them in under 60 seconds if you know which one is firing.

1. Mind Reading: "The reviewer thinks I'm incompetent"

The distortion: You believe you know what the reviewer is thinking — and it's always the worst interpretation.

In a code review: You see a comment that says "Consider extracting this into a helper." You read it as: "They think I don't know how to structure code. They think I'm junior."

The CBT break — The Evidence Test:
Ask: What's the actual evidence that they think I'm incompetent?

The comment is about the code, not about you.
"Consider" is a suggestion, not a reprimand.
Senior developers get the same comments. I've seen them — I've made them.

The comment is data about the code. It is not data about your worth.

Try this: Next time you feel the mind-reading spiral starting, write down the literal text of the comment. Then write down your interpretation. Notice the gap. The gap is where the distortion lives.

2. Catastrophizing: "If they find a bug, I'll be fired"

The distortion: You take a small negative and mentally fast-forward to the worst possible outcome.

In a code review: You realize you forgot a null check. Your brain goes: bug → production incident → blamed → fired → unemployable → homeless.

The CBT break — The Decatastrophizing Question:
Ask: What's the realistic worst case? And then what?

Worst case: the reviewer catches it before merge. You fix it in 2 minutes.
If it reaches production: it's caught by monitoring, you patch it, you add a test. This happens to every developer. It happened to the people reviewing your PR.

The probability chain collapses at each step. "Bug found in review" → "fix in 2 min" is the actual chain. The 7-step apocalypse is fiction.

Try this: Write the worst case. Then write the next thing that would happen. Then the next. You'll find the chain dies in 2-3 steps, not 7.

3. Personalization: "This criticism means I'm a bad developer"

The distortion: You take a comment about a specific piece of code and make it a statement about your identity.

In a code review: "This function is doing too much — it's handling validation AND serialization." You hear: "I'm a bad developer."

The CBT break — The Specificity Reframe:
The comment is about this function, at this point in time, in this specific context. It is not about you, all your code, always.

This function has a problem. → True.
Some of my code has problems. → True (everyone's does).
I am a bad developer. → Does not follow. A bad developer doesn't get code reviewed — they don't submit PRs.

Try this: Replace "I am X" with "This code, right now, has Y." The first is an identity claim. The second is an engineering claim. Only the second is actionable.

4. All-or-Nothing Thinking: "If my PR isn't perfect, it's worthless"

The distortion: You see things in binary — perfect or garbage. There's no middle ground.

In a code review: You find one thing you'd do differently in hindsight. Now the whole PR feels tainted. You consider withdrawing it. "If it's not clean, I shouldn't ship it."

The CBT break — The Continuum Reframe:
Code isn't perfect-or-worthless. It's on a spectrum: good enough to merge, good enough to merge with follow-up, needs revision, needs major rework. Most PRs are in the middle two categories. That's normal. That's what review is for.

"Perfect" is not a precondition for shipping. If it were, nothing would ship.
The follow-up ticket is a feature, not a failure. It means you're shipping incrementally — which is the correct engineering practice.

Try this: Before requesting review, list 3 things that are good enough about the PR. Then list 1 thing that's a known trade-off. You're not hiding the trade-off — you're naming it. Naming it moves it from anxiety to engineering.

5. Fortune Telling: "This review will go badly, I just know it"

The distortion: You predict a negative outcome with certainty — and no evidence.

In a code review: You haven't submitted the PR yet, but you already "know" it'll be painful. So you procrastinate. You re-read the diff 12 times. You almost withdraw it. The anticipation is worse than the review ever is.

The CBT break — The Prediction Test:
Ask: How many of my past predictions of "this will go badly" actually went badly?

Most developers, when they actually track this, find their hit rate is under 20%. The other 80% of reviews were fine — a few comments, a merge, done. The brain remembers the 20% and forgets the 80%. That's negativity bias, and it's a distortion.

Past 10 PRs: how many had a "bad" review? (Define "bad" first — most can't.)
The anticipation cost (hours of anxiety, procrastination) usually exceeds the review cost (20 minutes of addressing comments).

Try this: Keep a simple log: PR submitted → predicted outcome (good/neutral/bad) → actual outcome. After 10 entries, look at your prediction accuracy. The data will surprise you.

The Pattern

All five distortions share one thing: they feel like reasoning, but they're not. They're cognitive shortcuts that fire automatically under social-evaluative stress — which is exactly what code review is.

The fix isn't to "think positive." It's to think accurately. Each break above is a question that forces your brain back to evidence, specificity, and probability — the three things distortions strip away.

You don't need to do all five every time. You need to:

Notice which distortion is firing (the thought record helps).
Run the specific break for that distortion.
Submit the PR anyway. Exposure is the active ingredient.

Free Tools (No Signup, No Backend)

I built a set of CBT tools that run entirely in your browser — no account, no server, your data stays in your localStorage:

Cognitive Distortion Detector — Paste the thought ("they think I'm junior"), get the distortion classification + reframe. 200 lines of vanilla JS, no API.
Thought Record — Log the situation, thought, emotion, distortion, and alternative thought. The classic CBT technique, digitized.
Core Belief Detector — Drill down from "they think I'm junior" → "I'm not good enough" → the core belief driving the distortion. 120 lines of vanilla JS.

All tools work offline. No data leaves your machine. No tracking.

Why This Works (The Science)

CBT is the most empirically-supported psychotherapy for anxiety — 400+ randomized controlled trials across four decades. The mechanism is cognitive restructuring: identifying distorted thoughts, testing them against evidence, and replacing them with accurate ones.

Code review anxiety is a specific instance of social-evaluative threat — the same mechanism that drives performance anxiety, public speaking fear, and test anxiety. The distortions are the same. The breaks are the same. The only difference is the trigger.

You don't need therapy. You need a 60-second pre-review routine:

Write the thought that's firing.
Identify the distortion (use the detector).
Run the break.
Submit the PR.

The anxiety doesn't disappear. It just stops being the one in the driver's seat.

If you found this useful, I write about the intersection of developer psychology and engineering practice. The tools above are free and open source. No signup, no backend, no catch.

More in this series

A practical CBT toolkit for developers. Each article pairs one CBT concept with one developer pain point.

All tools are free, run in your browser, and store data locally — no signup, no backend.