kestrelsnest-blog/content/posts/2025-12-20-i-thought-i-had-fifteen-minutes.md

title, date, draft, tags, lastmod, description

title	date	draft	tags	lastmod	description
I Thought I Had 15 Minutes	2025-12-30T12:00:00-05:00	true	Programming Neurodivergence Automation n8n	2025-12-21T01:54:55.065Z	I automated the five minutes before standup, and accidentally learned something about how my brain works.

The five minutes before standup cost more than the meeting itself—and I didn't realize it until I stopped paying.

---

I'm three lines away from fixing a bug that's been nagging me all morning. The solution finally clicked, I'm typing it out, and—

Slack ping. "You coming to standup?"

I thought I had fifteen minutes. I'm already a minute late.

So now I'm joining the call with my brain still wrapped around a database query while trying to remember what I even worked on yesterday. Or it's Monday and I'm scrolling through my commit history on mute, hoping someone else goes first so I can piece together where I was on Friday.

This isn't the meeting's fault. I actually find standups valuable. The rapid-fire "what I did, what I'm doing, my blockers" surfaces connections early, keeps work from drifting into isolation. On the kinds of projects I work on, touching multiple codebases and solving bits of different problems throughout the week, that situational awareness genuinely helps.

But there's a thing about standups nobody talks about: even when the meeting is on my calendar, the preparation costs more than it should.

---

Here's the thing about my brain: I thrive on deliberate context-switching. Rotating through multiple problems, solving bits of each in turn, building them up in parallel. A payment integration in the morning, a data pipeline after lunch, a frontend redesign the next day. That rhythm keeps me engaged in a way that single-project focus never has.

But there's a critical word in that sentence: deliberate.

An unexpected ping, a meeting I lost track of, someone pulling my attention while I'm holding a complex system in my head. That can be devastating. An hour's worth of thought, collapsed in an instant. The structure I was building just... gone. Sometimes I never fully reconstruct it.

The difference is control. Choosing to rotate through problems is energizing. Having context switches imposed on me is exhausting. And the cost isn't the interruption itself—it's the reconstruction time afterward.

Standup prep felt like a chosen context switch. It was on my calendar. I knew when it was coming. But it still carried that reconstruction cost. I had to stop holding whatever I was currently working on, shift into a different mental mode entirely, and piece together a narrative of my week from scattered artifacts. Commits in GitHub. Tickets in Jira. Memory of Friday half-erased by the weekend. Five minutes of clicking through systems trying to assemble a coherent answer to "what did you do?"

That's when I realized the meeting wasn't costing me. The preparation was.

---

I'd had n8n installed on a server for a while, an automation tool I hadn't found the right use for yet.

Then I watched Leon van Zyl's tutorial on automated standups and something clicked. Not just "I could build that" but a broader realization about where tools like n8n actually fit. They're not for the big obvious workflows that justify dedicated engineering time. They're for the quiet friction points you've learned to live with. The stuff that's annoying but not annoying enough to fix properly.

Standup prep was exactly that kind of problem.

So I built a workflow. Every morning at 8 AM it gathers my activity from the past 24 hours: commits from GitHub, tickets from Jira. It merges them together and sends them to Claude with a prompt asking for a conversational summary. Something I could read aloud without sounding like a robot.

The result lands in my inbox before I've finished my coffee. A few paragraphs telling me what I worked on, what's in progress, what's still open.

Natural and accurate, no archaeology required.

---

I expected the time savings. I didn't expect how it would feel.

There's something quietly satisfying about getting that email every morning. A small summary of what I accomplished, delivered without any effort on my part. Even on days when it feels like I didn't get much done, seeing the actual commit history usually proves otherwise.

This matters more than it might seem. My brain thrives on rotating through problems, but that rotation makes it harder to maintain a coherent narrative of what I've actually done. When I'm deep in one problem, I'm not thinking about the three other problems I solved earlier in the week. The work feels fragmented because my attention is fragmented—by design, because that's how I work best.

Having a system that automatically reconstructs that narrative turned out to be surprisingly meaningful. Beyond saving time, it's a small daily reminder that scattered doesn't mean unproductive.

---

Since building this, I've noticed more of those quiet friction points. Minor annoyances I'd normalized because fixing them felt like overkill. Triaging support emails. Generating SQL queries from natural language. Even auto-inking my kids' pencil drawings. None of them big enough to justify a real engineering project, but real enough to be worth an hour of wiring things together.

The standup automation taught me to look for them. And it taught me something about my own brain in the process—about the hidden costs I was paying without realizing it, and the value of systems that do reconstruction work so I don't have to.

If you want the technical details (the workflow JSON, the setup, the quirks I discovered), I wrote that up for Infinity Interactive's blog. This piece is the human context around it. Why a simple automation mattered more than it should have, and what it accidentally revealed about how I work.