Imposter Syndrome is the persistent belief that you are not as competent as others perceive you to be, that your successes are the result of luck rather than skill, and that you will be exposed as a fraud at any moment — a belief held most strongly by the people who are least likely to be frauds.
The developer who has shipped 200 features thinks they got lucky 200 times. The developer who has resolved 50 production incidents thinks they stumbled onto the fix each time. The developer whose name appears on every critical path in the codebase — the one everyone asks when things break, the one whose Slack handle is forwarded seventeen times a day — thinks they are one question away from being revealed as someone who does not belong.
Meanwhile, the developer who has shipped nothing and broken everything presents their “Technical Vision” slides with unshakeable confidence.
This is imposter syndrome’s cruelest feature: it is inversely correlated with actual incompetence. The people who have it shouldn’t. The people who should don’t. The Dunning-Kruger Effect is imposter syndrome’s evil twin — one makes the incompetent confident and the other makes the competent doubtful, and between them they ensure that the people making decisions in any organisation are the wrong people.
The Mechanism
Imposter syndrome operates through a self-reinforcing loop:
Step 1: Success. The developer ships a feature, fixes a bug, resolves an incident, or receives a positive Performance Review.
Step 2: Attribution. The developer attributes the success to luck, timing, the team, the framework, the weather, or the specific alignment of Jupiter and Saturn that afternoon. The developer does not attribute the success to competence, because the developer does not believe in their own competence.
Step 3: Anxiety. If the success was luck, the luck will run out. The next feature will fail. The next incident will expose them. The next performance review will finally see through the illusion. The developer works harder — not to excel, but to maintain the disguise.
Step 4: More success. The harder work produces more success. The success feels even less earned, because the developer knows how much effort it took, and real experts wouldn’t need this much effort. The loop tightens.
The developer who resolves a production incident at 2 AM — calmly, methodically, correctly — experiences a brief moment of confidence. Then the imposter syndrome recalibrates: “I got lucky. I happened to remember that one obscure edge case. Next time I won’t.” The evidence of competence is reinterpreted as evidence of luck, and the luck is always about to run out.
The Rescue Pattern
A person familiar with this pattern spent years in what the lifelog calls “The Blazer Years” — walking into enterprise crises, drawing diagrams on whiteboards, and leaving chaos organised. Billing three thousand pounds a day to blink. The consultant who arrives when things are broken and leaves when things work.
The rescue pattern and imposter syndrome are symbiotic. The rescuer needs the crisis because the crisis provides proof of competence — but only temporarily. The fire is burning, the rescuer puts it out, and for a moment the rescuer believes they can put out fires. Then the fire is out and the doubt returns: “The fire wasn’t that bad. Anyone could have done it. I was just in the right place.”
The rescuer takes the next crisis, not because they want to rescue, but because the crisis is the only context in which the imposter syndrome quiets down. The burning building does not care about your self-doubt. The burning building needs water. The urgency overrides the doubt. The fix works. The doubt returns.
The cycle produces a career that looks, from the outside, like expertise confidently applied. From the inside, it feels like a series of narrow escapes from exposure.
The Borrowed Palace
The lifelog chronicles an episode called “The Borrowed Palace” — seventy-eight days in which riclib violated his own manifesto, worked on someone else’s platform, and eventually came home.
This is imposter syndrome’s architectural expression: the belief that the correct approach is somewhere else, being built by someone better, on a platform you should be using instead of the one you built. The developer who builds a tool, uses the tool, and ships with the tool — and then abandons it for someone else’s tool because surely the other tool is better, because surely the developer’s own tool is not good enough, because surely the developer is not the kind of person whose tools are good enough.
The developer came home. The developer’s tool was good enough. The developer’s tool was always good enough. The seventy-eight days were the tax that imposter syndrome charges for the right to believe in your own work.
The Senior Developer’s Burden
The Senior Developer article describes the person whose Slack handle is forwarded seventeen times a day: “Have you asked Sarah?” Sarah does not manage anyone. Sarah does not have “Lead” or “Principal” in her title. Sarah has been at the company for seven years and has built a map of the codebase that exists nowhere except in her head.
Sarah has imposter syndrome.
Sarah resolves production incidents calmly because she has resolved hundreds before. Sarah writes code reviews that say “this will deadlock under load” because she shipped that exact bug in 2019. Sarah provides architectural guidance that prevents dead ends because she has walked into every dead end in the codebase personally.
Sarah thinks she got lucky. Sarah thinks the production incidents were easy ones. Sarah thinks the code reviews are just pattern matching. Sarah thinks the architectural guidance is obvious and anyone would see it. Sarah does not think she is a senior developer. Sarah thinks she is a mid-level developer who has been accidentally promoted and is one bad week from being found out.
The rest of the company thinks Sarah is the only person who knows how the system works. Both perspectives are sincere. One is correct.
The Lizard’s Exemption
The Lizard does not have imposter syndrome. The Lizard does not have any syndrome. The Lizard has a terminal, a text file, and forty years of shipping.
The Lizard’s immunity is not confidence. It is indifference. The Lizard does not ask “am I good enough?” The Lizard asks “does it work?” The code works or it doesn’t. The system ships or it doesn’t. The question of whether the developer deserves the success is a question the Lizard does not understand, in the same way that the Lizard does not understand organisational politics, career ladders, or LinkedIn.
“The Lizard has never felt like a fraud. The Lizard has also never felt like an expert. The Lizard types. The code compiles. The Lizard types more. This is sufficient.”
— The Lizard, unburdened by self-assessment
Measured Characteristics
- Developers experiencing imposter syndrome: estimated 60-70%
- Correlation with actual competence: inverse
- Correlation with seniority: positive (the better you are, the worse it gets)
- Successes attributed to luck: most of them
- Failures attributed to self: all of them
- Performance reviews that should cure it: all of them
- Performance reviews that do cure it: none of them
- “Have you asked Sarah?” messages per day: 17
- Sarah’s self-assessment: mid-level at best
- Sarah’s actual level: the system would not function without her
- Crises needed to temporarily silence the syndrome: 1
- Duration of silence after crisis: 2-6 hours
- The Dunning-Kruger counterpart: the person presenting “Technical Vision” slides
- Slides presented by the imposter: 0 (too afraid)
- Slides presented by the Dunning-Kruger sufferer: all of them
- The Lizard’s self-assessment: does not compute
