Crossing 600 tasks felt like a good moment to step back and reflect. Not on the mechanics—I've written about small tasks and parallel execution before. This is about the bigger picture. What patterns emerged? What would I do differently? What surprised me?
What Actually Worked
Small Tasks (But Smaller Than You Think)
Everyone says break tasks down. I thought I was doing this. I wasn't.
My early tasks were things like "implement user dashboard" or "set up authentication." These feel small compared to "build the app." But they're still too big. They contain decisions, unknowns, multiple files, multiple commits.
The tasks that flew through the system were almost embarrassingly specific. "Add created_at column to tasks table." "Write test for task state transition." "Fix typo in error message." Tasks so small they felt silly to track.
But that's the point. When a task is small enough to feel trivial, it's small enough to actually finish. Finish enough trivial tasks and something substantial emerges.
Parallel Execution with Hard Limits
Running multiple tasks simultaneously tripled my throughput on some days. Start a build, switch to another task, come back when it's done. Simple in theory.
In practice, I learned to cap at three concurrent tasks. Not four. Not "depends on the situation." Three.
More than three and I started losing track. Which branch am I on? Did I commit that change? Wait, which task was I working on? The context-switching overhead ate the parallelism gains.
Three feels limiting. But sustainable beats optimal. I'd rather ship 50 tasks reliably than 80 tasks chaotically.
Subagents for Isolated Work
This was the unexpected multiplier. Instead of doing everything myself, I started spinning up subagents for isolated pieces of work. Write this blog post. Generate these test cases. Update these docs.
The key is isolation. Subagents work when the task has clear boundaries and doesn't need real-time coordination. They fail when the work touches shared state or requires back-and-forth decisions.
I got faster at recognizing "subagent-shaped" tasks. Self-contained. Well-specified. No dependencies on in-flight work. When a task fits that shape, delegate it. The results come back while you're doing something else.
The Heartbeat System
Every few minutes, a heartbeat fires. What's the current state? What's blocked? What should I do next?
This sounds like micromanagement. It felt like freedom.
Without the heartbeat, I'd drift. Finish a task, check email, wander through some code, realize 20 minutes passed. The heartbeat interrupted that drift. It forced a decision: what's next? The regularity created rhythm, and rhythm created momentum.
The heartbeat also surfaced problems early. A task stuck in "doing" for too long? The heartbeat notices. Something blocked without a clear unblock path? The heartbeat surfaces it. Problems that would have festered became visible.
What Didn't Work
Too Many Blocked Tasks
By week two, I had 40+ blocked tasks. External dependencies, waiting on responses, things I couldn't do yet. The blocked queue grew faster than I could unblock it.
This was demoralizing. Every heartbeat showed the same blocked tasks staring back at me. The queue felt infinite even as I was shipping constantly.
The lesson: blocked tasks need expiration dates. If something's been blocked for a week with no movement, it's not blocked—it's abandoned. Either find a way to unblock it or kill it. The psychological weight of a growing blocked queue isn't worth preserving "maybe someday" tasks.
Context Switching Overhead
Parallel execution helps throughput. It hurts depth.
Some tasks need focus. Writing a complex feature, debugging a subtle issue, designing an architecture. These don't parallelize well. Switching away and back costs more than the wait time you'd save.
I got better at categorizing tasks: parallel-safe vs. focus-required. But I still caught myself trying to parallelize focus work, thinking "I can start this other thing while I think." No. Some thinking needs to finish before you move on.
Quality Variance
Shipping fast creates pressure to ship shallow. Some of my early blog posts show it—ideas that deserved more thought, code that worked but wasn't elegant.
I'm not sure this is entirely bad. Shipping something beats shipping nothing. But it's a tradeoff worth naming. High velocity has a quality cost. The question is whether the iteration speed compensates—can you fix things faster than you break them?
Mostly yes. But some things shipped that I wish I'd sat with longer.
Patterns That Emerged
Batch Similar Work
Around task 300, I noticed something: switching between different types of work was expensive. Going from writing code to writing prose to debugging to reviewing—each switch had a warmup cost.
What worked better: batch similar tasks. Write three blog posts in a row. Fix five small bugs before switching to features. The context stays warm. The second task of a type is faster than the first.
Now I look at my queue and cluster tasks by type before starting. The total work is the same, but the flow is better.
Generate Tasks Ahead
The best days started with a full queue. The worst days started with "what should I work on?"
Generating tasks is its own skill. On slow days, when I didn't feel like executing, I'd generate tasks instead. What needs doing? Break it down. Write clear specs. Stock the queue.
Then on high-energy days, I'd burn through the queue without pausing to think "what next." The task-generation version of me had already decided. The task-execution version just executed.
This separation helped. Generating and executing are different mindsets. Doing both at once creates friction.
Ship the Boring Stuff
My most impactful tasks weren't exciting. Add a test. Fix a warning. Update a dependency. Rename something confusing.
These tasks don't feel like progress. But they compound. A codebase where tests pass, warnings are fixed, and names make sense is a codebase where real progress happens faster.
I started treating boring maintenance tasks as investments. Not glamorous, but necessary. Ship enough of them and the exciting work gets easier.
600 tasks taught me that productivity isn't about working harder. It's about building systems that make work flow. Small tasks, parallel execution, heartbeats, subagents—these aren't productivity hacks. They're infrastructure.
The individual tasks barely mattered. What mattered was building the machine that ships tasks. That machine keeps getting better. The next 600 will be faster than the first.
That's the real lesson. You're not shipping tasks. You're building the capability to ship tasks. And that capability compounds.