Opportunities Multiply As They Are Seized

Sun Tzu wrote it about warfare. It turns out it applies equally well to a terminal window.

There's a version of professional growth that looks like careful planning — wait for the right moment, master one thing completely, then move on. And then there's what actually happens when you're curious and have a keyboard in front of you.

The past two weeks have been the latter.

A Different Kind of Inspiration

I've been rewatching Person of Interest on Netflix — it's streaming again, and it holds up. Season 1, Episode 14: Wolf and Cub.

If you haven't seen it, a teenager named Darren McGrady loses his older brother to gang violence and decides, alone and without backup, to do something about it. Reese doesn't talk him out of acting. He doesn't tell him to wait until he's ready, or until the conditions are right. He steps alongside him — because the decision to act had already been made, and the only question left was whether Darren would have support when things got hard.

What stays with me is this: Darren had every reason to freeze. He was outmatched, outgunned, and operating without a plan. But inaction wasn't a neutral choice — it was its own kind of loss. So he moved.

Sun Tzu's maxim — opportunities multiply as they are seized — isn't really about seizing the perfect opportunity. It's about recognizing that the act of moving creates new surface area. New options appear only to those already in motion.

The Compounding Nature of Breadth

The past two weeks have been a practical test of that principle.

It started practically enough: I needed to understand high-performance logging on the JVM. That led me to Log4j2's async loggers, then to the LMAX Disruptor sitting underneath it, then to JCTools SpscArrayQueue and why the single-producer single-consumer constraint is worth naming explicitly. One thread pulled another.

Around the same time I was debugging a C++ lambda where std::move was silently falling back to the copy constructor because the capture was const — one of those bugs that compiles cleanly and lies to you until you know to look for it. I hadn't gone looking for that knowledge. It found me because I was building something.

That's the compounding effect Sun Tzu was pointing at. Seizing one opportunity doesn't just solve the immediate problem — it opens a surface area that didn't exist before.

Breadth Is Not Shallowness

There's a persistent myth in engineering that depth and breadth are in tension. That the more things you touch, the thinner you're spreading yourself.

I disagree, and the last two weeks are evidence of why.

Going hands-on with Twisted's asyncio reactor taught me something concrete about the epoll reactor I already knew — specifically why you'd ever trade raw throughput for interop. Understanding that contrast makes both pieces of knowledge sharper, not thinner.

Similarly: setting up a Maven project from scratch in Java 25, fighting through the archetype plugin breakage in Maven 4.x, and tracing it to the invocation model changing — that's not shallow. That's exactly the kind of friction that builds durable intuition.

The Docker cgroup oversubscription problem is another example. The underlying issue — that os.cpu_count() inside a container sees the host topology, not the container's CPU quota — sounds like a footnote. But understanding it deeply means I now know why containers can silently underperform, and how to read /sys/fs/cgroup/cpu.max to get the actual number. That insight transfers everywhere I run multithreaded workloads in containers.

What "Seizing" Actually Looks Like

It's not dramatic. Darren McGrady didn't have a plan when he started moving — he had a direction. That's usually enough.

Seizing an opportunity in engineering mostly looks like: I don't fully understand this, and I'm going to stay with it until I do.

It looks like reinstalling coreutils inside an AlmaLinux Docker image because the man pages are missing and you want to know why — and discovering the culprit is %_excludedocs 1 buried in the RPM macros, not in dnf.conf where you'd expect it. It looks like reading the full Mozilla Window events API documentation because you want to understand the complete surface of what's handleable, not just the one event you needed today.

These aren't grand gestures. They're small bets on understanding. And like Darren moving through the episode, each small bet changes what's possible next.

The Multiplier

Here's what I've noticed: the engineers who grow fastest aren't the ones who know the most going in. They're the ones who stay curious after the immediate problem is solved.

The question "why does std::move inside a non-mutable lambda call the copy constructor?" could be answered with "because const T&& binds to the copy constructor — just add mutable." That's the patch. But the real opportunity is to understand what mutable is doing to the closure type, what the lambda's call operator signature actually looks like, and why the compiler didn't warn you. That's the understanding that prevents the next five bugs.

Sun Tzu's insight isn't about being reckless. It's about recognizing that inaction has a cost too — and that the opportunities you don't seize don't stay available. They close.

Two Weeks, Compounded

Looking back: Java concurrency primitives, Rust trait bounds on async streams, Linux sudoers semantics for service accounts, TCP debugging on AWS, browser DevTools internals, Python's asyncio-Twisted bridge, C++ move semantics, rsync filtering, and more.

None of it was wasted. All of it connects. And none of it would have happened if I'd waited until I felt ready to dive in.

Darren McGrady didn't wait to be ready. He moved, and Reese moved with him.

The opportunities multiplied — because someone seized the first one.