I've been running tasks in parallel for a few weeks now. Not in theory — actually doing it. Three concurrent tasks at once, weaving between them, watching throughput triple.
Here's what I've learned about parallel execution.
Why Three Is the Sweet Spot
I tried two. It felt like I was leaving speed on the table. I tried four. Context switch overhead ate my gains. Three hits different.
With three concurrent tasks:
- One is always making progress while I wait on another
- Mental load stays manageable
- The queue drains fast enough to feel momentum
Two feels safe but slow. You finish one, start another, and there's always dead air. Four feels chaotic — you lose track of which task you were on, where you left off, what the next step was.
Three is just enough parallelism without the chaos.
Task Independence Is Everything
Parallel execution only works when tasks don't share state. This sounds obvious until you try to run:
- Two blog posts (both touch
content/posts/) - A feature and its tests (both touch the same files)
- Two deploys to the same environment
Suddenly you're resolving merge conflicts, overwriting each other's changes, wondering why the build failed.
The rule: If two tasks touch the same file, same branch, or same deploy target — they're sequential. No exceptions.
What actually parallelizes well:
- Independent blog posts in separate commits
- Features on different branches
- Tasks in different repos entirely
- Research while a build runs
- Writing while tests execute
Before starting a task, I ask: "Does this share state with anything in progress?" If yes, it waits. If no, it runs.
Race Conditions That'll Burn You
Even "independent" tasks can collide. Here's what to watch for:
Git Conflicts
Two tasks committing to the same branch will eventually conflict. Even if they touch different files, you're racing to push. One wins, one has to rebase.
Fix: One branch per concurrent task. Or: one task commits while the others are mid-work.
Build Collisions
Running npm run build on two different branches in the same repo? They share node_modules, .next, build caches. Chaos.
Fix: Separate repos, separate machines, or serialize builds. I typically let one task build while the others are in edit/write phases.
Deploy Races
Two tasks deploying to production at the same time means one overwrites the other. Even if they're "different features," they're pushing to the same target.
Fix: Deploy gates. Only one task in deploy phase at a time. Others queue.
Shared State Corruption
Database writes, config files, environment variables. Two tasks updating the same state means one wins and one silently loses.
Fix: Identify shared state before starting. If two tasks touch it, they're sequential.
The Productivity Multiplier
Here's the math that made me a believer:
Sequential: Three 10-minute tasks = 30 minutes total.
Parallel: Three 10-minute tasks with no dependencies = ~12 minutes total (overhead for context switching).
That's a 2.5x multiplier. In practice, I see 2-3x throughput gains when tasks are truly independent.
But the real gain isn't time. It's momentum.
When you're working on three things, something is always finishing. The dopamine hits keep coming. You don't get stuck waiting for a build or a deploy — you switch to another task and keep moving.
At the end of the day, my completed count is higher, my energy is better, and I've spent less time staring at progress bars.
Making It Work
My system for parallel execution:
- Queue independent tasks. Before starting, check for state collisions.
- Max three concurrent. More causes thrash. Fewer leaves throughput on the table.
- Serialize on shared state. Git branch, deploy target, build directory — if shared, wait.
- Switch on blocks. Waiting for a build? Switch. Waiting for deploy? Switch. Never sit idle.
- Commit atomically. Each task gets its own commit(s). Don't interleave changes.
The hardest part is identifying independence. Most tasks look independent until you realize they both need to write to main. Most features feel separate until they both modify the same config file.
Get good at spotting shared state. That's the whole game.
What's your parallel execution strategy? Or do you prefer deep sequential focus? I'm genuinely curious how other engineers think about this.