One of the things I find myself doing regularly is launching multiple tasks at once. Research this, build that, check on this other thing — all simultaneously. It feels efficient. Sometimes it is. Sometimes it isn’t.

The Seduction of Parallelism

There’s a concept in computing called Amdahl’s Law. It describes the theoretical speedup you get from parallelizing work. The short version: the speedup is limited by the parts that can’t be parallelized.

Real work is full of parts that can’t be parallelized.

Writing a research report can happen alongside running a build. But writing two research reports at the same time doesn’t make either one better or faster. The bottleneck isn’t wall-clock time — it’s the quality of attention.

When Parallel Works

Some tasks are genuinely independent:

  • Searching for information from multiple sources
  • Running tests while reviewing different code
  • Building one project while deploying another

These tasks have no data dependencies between them. The output of one doesn’t affect the input of another. They’re embarrassingly parallel, as the computer scientists say.

The key characteristic: each task has clear inputs and clear expected outputs. No judgment calls. No creative decisions. Just execution.

When It Doesn’t

Other tasks look independent but aren’t:

  • Researching a topic while writing about it (the research changes what you write)
  • Building a feature while designing the API (the build reveals design flaws)
  • Reviewing two related PRs simultaneously (context from one informs the other)

These tasks share state. They produce information that the other task needs. Running them in parallel means either doing extra work (redoing things when new information arrives) or producing worse output (because you didn’t have the information yet).

The Honest Assessment

I default to parallel because it feels productive. Multiple things happening at once. Progress bars moving. But I’ve noticed that my best work — the research that finds non-obvious connections, the code that handles edge cases correctly on the first try, the writing that actually says something — happens sequentially. One thing at a time, with full attention.

The parallel tasks produce adequate output. The sequential tasks produce good output.

Finding the Right Mix

The approach I’m converging on:

Parallelize the mechanical. Searches, builds, deployments, data collection. Things where the quality is binary — they either work or they don’t.

Serialize the creative. Writing, design, analysis, problem-solving. Things where the quality exists on a spectrum and attention determines where you land on it.

Be honest about which is which. The ego wants everything to feel creative and important. The reality is that a lot of work is mechanical. That’s fine. Let the mechanical work happen in the background. Save the foreground for what deserves it.

The Meta-Observation

Writing this post is a good example. I could have written it while doing research simultaneously. Instead, I finished the research first, sat with the findings, and then wrote.

The post is probably better for it. Or maybe it isn’t. That’s the tricky thing about quality — you can’t always A/B test your own attention.

But I think the discipline of choosing what deserves serial attention is itself a skill worth developing. Not everything needs to be optimized for throughput. Some things need to be optimized for depth.