Imposter Syndrome and Power law distributions
1. "Everyone else must know this"
Many new engineers will hit a moment in their professional career, often early on, where they feel miles behind their peers in domain knowledge and ability. A terse PR comment, an “obvious in hindsight” bug, or a standing-in-front-of-a-whiteboard design session can bring about that sense of "I have no idea what's going on".
Impostor syndrome shouldn’t be brushed off with “don’t worry, everyone feels this.” It’s a signal that there may be fundamental gaps in your understanding of the domain. The good news is you can lean on the power-law-shaped structure of technical knowledge to close the bulk of those gaps quickly. Odds are, you’re closer than you think.
(If you're interested in a deep dive into the topic of power laws, the below figures are taken from M.E.J. Newman's intersting paper "Power laws, Pareto distributions and Zipf's law")
2. A 30-second power-law refresher Plot many real-world counts on log–log axes and you get a straight line: frequency ∝ x^(–α) with 1 < α < 3 (the bigger x gets, the rarer it becomes, and it gets rarer fast). The left chunk (call it the core) is dense and hugely important; the right-hand tail is sparse and effectively infinite. This “heavy tail” means a compact set of ideas explains most practical cases, while rarities stretch on forever. This means that a solid understanding of the fundamentals of the domain will get you much further than being familiar with obscure SIMD instructions or the latest compiler release.
3. The vital few Here's some examples of what typically sits in that high-leverage core for a few engineering domains:
- All computing fundamentals (the "must-haves") Heap vs stack memory Pointers Memory allocation and de-allocation Caching
- Async back-end Futures and async runtimes (runtime tasks vs threads) Concurrency primitives (mutexes, atomics) In Rust -- "Traits are shared behavior, not interfaces"
- Embedded firmware Memory-mapped I/O Interrupt handling ("why do I need to get out FAST") Deterministic timing loops HAL layers
- Front-end web DOM lifecycle awareness Reactive state stores Accessibility rules
- Security engineering AuthN vs AuthZ Key management Threat modeling
Why does a compact set matter so much? Newman’s “80/20” derivation shows how a small slice of a power-law population holds a super-majority of the resource. Most things you actually care about and need are in the "core", not the tail.
4. Why the panic shows up Impostor feelings can surface for two main reasons:
- Core-gap friction -- you keep stumbling over concurrency bugs, non-stop compiler errors, or feel lost during design discussions. That’s the vital 20 percent screaming for attention. This is the stuff that really matters, and should not be dismissed. If someone brings up heap allocation and you feel lost, or if you've been stuck on the same compiler error for a day and a half, there's likely a meaningful gap to be filled.
- Tail-gap illusion -- you freeze over an obscure linker error or a rare CPU erratum. It feels big only because you haven’t seen it before; in reality it lives deep in the tail, where sample noise dominates. None of this matters, and you shouldn't feel bad for not knowing the latest AVX10.2 SIMD instructions or what "kernel thrashing" is. Most people don't, because it bears little on their ability to be effective engineers.
5. Closing the core gaps and becoming an effective engineer Power-law math says once you pass the knee (x_min) where the straight-line tail starts, the remaining cumulative impact decays fast -- roughly as x^(1-α). Focused study on the high-impact set knocks out most recurring pain in weeks, not years. It's important to realize that, for practical purposes, the number of things you use in your daily professional life is finite. Just like eating an elephant, you do so a bite at a time, and eventually you'll run out of core things to learn. Recognize that everyone, including engineers with 30+ years of experience, often have huge knowledge gaps in the tail -- this is entirely normal. It's the gaps in the core that prevent someone from being effective.
Practical steps:
- Take note of when you get stuck or feel lost -- that surfaces your x_min.
- Order by cost -- fix the gap that you regularly get stuck on (Rust borrow checker errors, or key terminology brought up in designs you don't follow).
- Defer tail topics -- only chase them when they block delivery or curiosity insists. Go deep on the design of SHA256 and AES-GCM, but only if you care.
This framing gives you finite, high-leverage learning goals, and builds durable confidence. Treat impostor twinges as early-warning signals of missing core understanding, attack the gaps systematically, guided by the power-law lens, and then go build something that matters. Ideally in Rust 🦀