Impostor syndrome never ends (and that's normal)

Starting Background

I discovered that impostor syndrome never ends at a very specific moment in my career. Not at the beginning, when I had just a few months of experience and every code review session felt like an oral exam from which I could emerge exposed. It was later - when I already had years of production work under my belt, had already solved real problems, had already contributed to architectural decisions that had worked. And yet, sitting in a meeting with people more experienced than me in a specific domain, that familiar voice was still there: "You don't know enough. You're about to embarrass yourself. Sooner or later they'll figure you out."

That moment was an uncomfortable revelation. I had implicitly believed that impostor syndrome was a passing phase - something that accompanies you at the beginning, when the gap between what you know and what you should know is palpable, and that then fades with time and experience. That's not how it works. Psychological research says so clearly, and lived experience confirms it.

I'm bringing this up in the first cluster article of the series for a specific reason: if you came to software development from an unconventional background - law, economics, philosophy, pure mathematics, literature - your relationship with impostor syndrome is probably more intense and more frequent than that of a developer with a CS background. Not because you're less capable. But because you have an implicit comparison point that starts at a disadvantage: "Others have the right degree. I don't." This thought, if left unexamined, becomes fertile ground where the syndrome grows.

What I want to do in this article is clear away some illusions - including the one that says the syndrome ends, sooner or later - and replace them with a more honest and useful framework: not how to eliminate impostor syndrome, but how to live with it so it doesn't block your work and your growth.

This is not a motivational article. You won't find an infallible technique here to "defeat" impostor syndrome. None exists. What you will find is a map of the territory, with some concrete practices that have made a difference for me.

Typical Difficulties

Impostor syndrome for those coming from non-CS backgrounds manifests in specific and recognizable ways. It's worth naming them for what they are - without minimizing them, but also without amplifying them.

The asymmetric comparison with those who have the "right degree"

The mechanism works like this: you see a colleague with a computer science master's degree who instantly grasps a distributed architecture concept, and you think "he already knows this. I still need to understand it." What you don't see is that even he, in his domain of origin, needs time to acquire contexts that you already have - the ability for contractual analysis, philosophical critical thinking, economic modeling. The comparison is asymmetric because you're looking at his consolidated vertical bar and ignoring your already-built horizontal bar.

Pauline Clance and Suzanne Imes, in their 1978 paper that first defined the concept of "imposter phenomenon," observed this mechanism in high-achieving people: the selective focus on one's own gaps and the inability to internalize one's own successes as genuine. The result is a systematic cognitive distortion that leads to constantly underestimating one's actual competence.

Vocabulary as a psychological barrier

In tech teams there's a consolidated jargon that CS developers absorbed during years of study: "race condition," "technical debt," "refactoring," "API contract," "idempotence." If you come from a different background, you learn these words on the job, often after the fact compared to when they're used in conversations. Every time you encounter a term you don't know that others seem to take for granted, the thought triggers: "I should have known that."

This creates a form of linguistic performance anxiety that goes beyond technical content. It's not the algorithm you don't know how to implement - it's the feeling that you don't yet speak the language of the place fluently. And this feeling, if not recognized for what it is, feeds impostor syndrome in a transversal way, independent of actual technical content.

The inverted "desk check"

In many tech teams there's an implicit variant of the "desk check": when someone explains something and you don't understand, your first reaction is to doubt yourself, not the explanation. Those with CS backgrounds tend to have more confidence in their own reasoning: if the explanation isn't clear, the explanation is the problem. Those from non-CS backgrounds tend to invert the attribution: if I don't understand, I'm the problem.

This has a practical consequence: you ask fewer questions - not because the questions aren't there, but because asking a question means revealing a gap, and revealing a gap means being found out. The result is that you stay in a state of confusion for longer, and the confusion further feeds the sense of not keeping up.

The good news is that this mechanism is reversible. The ability to ask precise, timely questions can be trained like any other professional skill. And in healthy teams - those worth working for - asking good questions is perceived as a positive trait, not a sign of weakness. The problem is not asking questions: it's not knowing how to ask them well. A vague question ("I don't understand how the system works") is less useful than a specific question ("I don't understand why this endpoint returns 200 even when validation fails - I read the code but don't see where this case is handled"). The specificity of the question signals that you've already thought about the problem and that your gap is precise, not general.

Moments of apparent crisis

There are specific moments when impostor syndrome intensifies acutely: the first difficult code review, the first critical bug in production, the first senior technical interview, the first time you're invited to give a technical presentation in front of people you perceive as more competent than you. These moments are not distributed evenly over time - they concentrate at transition points, when the level of responsibility or visibility increases.

For those from non-CS backgrounds, these moments carry additional emotional weight: there's always the implicit risk of confirming the suspicion that the unconventional path was a problem. "If I get this wrong, it proves I didn't have the right foundations." Failure gets loaded with an identity meaning that goes beyond the single episode.

What I've learned over time is that these moments of apparent crisis are also moments of accelerated learning - provided you go through them instead of avoiding them. The critical production bug that you resolved with difficulty teaches you more than ten theoretical tutorials on the same topic. The difficult code review that forced you to rewrite half your code taught you something you couldn't have learned any other way. The failed technical interview is precise feedback on where you need to study more. Impostor syndrome tends to make these moments be filed away as failures. The alternative work is to file them as data.

Impostor syndrome in technical interviews

The technical interview is the context where impostor syndrome manifests most acutely for those from non-CS backgrounds. Not only because technical interviews are stressful by definition, but because the format - questions on algorithms and data structures, coding problems on a whiteboard or online editor - is optimized to evaluate exactly the skills that those with CS training have consolidated over years of study. For those from a different path, this format is objectively disadvantageous, at least in the early stages.

The response to this difficulty is not to think the format is unfair (though in part it is) but to prepare systematically, as any other candidate who knows they have gaps in a specific area would do. But to do that, you first have to recognize that the difficulty is real and specific, not a confirmation of your general inadequacy.

What Has Worked (Federico)

I'm sharing some concrete practices that have made a difference for me. I'm not offering them as a universal recipe - people are different, contexts are different. I'm offering them as a starting point, something to test and adapt.

1. Separating process from identity

The first practice is cognitive: learning to distinguish between "I'm learning something I don't yet know" and "I'm not good enough." The first statement describes a state of the learning process - temporary, modifiable, normal. The second is an identity judgment - static, totalizing, and very often false.

The distinction seems obvious until you try to apply it in real time, in the middle of a difficult code review or debugging a system you don't yet understand. In those moments, the impostor's voice speaks in identity judgments, not process descriptions. The work is to notice when it happens and reformulate: "I don't yet know this pattern" instead of "I'm not technical enough."

Cal Newport in So Good They Can't Ignore You (ISBN 978-1455509126) describes this as the shift from "following passion" to "building competence": the focus shifts from the question "am I good enough?" to "what do I need to learn to do this better?" The second type of question is actionable. The first is not.

2. Keeping a log of concrete evidence

Impostor syndrome thrives on vagueness. If you ask yourself "have I made progress in the last year?", your mind will tend to select negative evidence - the problems you didn't solve, the things you still don't know - and minimize the positive ones. The countermeasure is to make progress concrete and visible.

I started keeping a text file - not public, just for me - where I write once a week: one problem I solved this week, one thing I learned, one situation where I contributed positively. Not to show anyone: to counter the mind's tendency to select only negative evidence.

After six months, rereading that file was a revealing experience. The progress was there, documented, specific. Impostor syndrome works on abstraction and vagueness - "I don't know enough" - but it doesn't hold up against concrete data.

3. Using confusion as a learning signal

One of the most useful reframings I've made was learning to read confusion as a positive signal rather than a negative one. Confusion means you're engaging with something you don't yet master - which is exactly what you should be doing if you want to grow.

Developers who are never confused are working on things they already know how to do. It's comfortable in the short term, but it's stagnation in the long term. Productive confusion - the kind that resolves through study, exploration, and questions - is the raw material of learning. Learning to distinguish it from paralyzing confusion (the kind that manifests as a block and inability to proceed) takes practice, but it's a developable skill.

4. Asking questions, systematically

One of the things I learned to do over time is to raise my hand systematically when I don't understand something, instead of waiting to figure it out on my own. Not indiscriminately - there are questions worth asking after you've made an effort to answer them yourself. But that tendency to not ask questions to avoid revealing gaps is precisely the mechanism that keeps impostor syndrome alive.

What I discovered is that asking good questions - precise questions, on a specific point, after already trying to answer them yourself - is perceived in good teams as a sign of competence, not ignorance. The senior developers I respect most ask many questions. Not because they don't know the answers, but because they know that asking the right questions is part of the craft.

5. Finding a realistic comparison context

Impostor syndrome is often fed by comparing yourself with people who are many years ahead in the journey. If you compare yourself with a senior developer with 10 years of experience when you have 2, you're using the wrong measuring stick. Not because growth isn't possible, but because the comparison is not informative: it measures the current distance, not the trajectory.

The most useful comparison is with yourself six months ago. The question is not "do I know what they know?", but "do I know more than I did?" If the answer is yes - and in the vast majority of cases it is - the signal is that the process is working, even if the result isn't yet what you'd like.

Cognitive Framework

Beyond concrete practices, there are two theoretical frameworks that have helped me understand impostor syndrome in a more useful way - not just as a subjective experience, but as a psychological mechanism with a precise structure.

Career capital and perceived competence (Newport)

Cal Newport in So Good They Can't Ignore You distinguishes between objective competence - the real skills you've acquired through deliberate practice - and perceived competence - the subjective evaluation you have of yourself. Impostor syndrome is essentially a misalignment between the two: objective competence is higher than perceived.

The problem is that perceived competence is influenced by factors that have nothing to do with objective competence: the comparison context chosen, the narrative you tell yourself about your path, the tendency to internalize failures and externalize successes ("the project went well by luck," "the bug was complicated because I hadn't studied enough"). Newport suggests that the answer is not to "work on self-esteem" in a generic way, but to build concrete evidence of competence through deliberate practice, and learn to read it correctly.

Fixed mindset vs growth mindset (Dweck)

Carol Dweck in her work on growth mindset describes two opposite ways of interpreting one's own abilities. The fixed mindset sees abilities as fixed attributes - "you're good at math" or "you're not cut out for code" - and interprets difficulties as evidence of these fixed characteristics. The growth mindset sees abilities as developable through effort and practice, and interprets difficulties as part of the learning process.

Impostor syndrome is intimately linked to the fixed mindset: "If I get this wrong, it means I'm not good enough" only works if abilities are fixed. In a growth mindset framework, getting something wrong means there's something to learn, not that you are defined by that failure.

For those from non-CS backgrounds, the fixed mindset about code is particularly common: the narrative "I don't have a CS degree so I'll never understand some things" is an extreme version of the fixed mindset applied to an entire category of skills. The empirical data - dozens of excellent developers with unconventional backgrounds, all documented - directly falsifies this narrative.

The imposter phenomenon: the original research

Clance and Imes in 1978 observed the phenomenon in high-achieving academic women who, despite objective successes, continued to perceive themselves as "imposters" on the verge of being found out. Since then, research has extended the phenomenon to much wider populations: it's cross-cutting across gender, background, education level, and professional sector.

A particularly relevant data point for this article: impostor syndrome tends to intensify at moments of transition and in new contexts, not to decrease with experience overall. Every time you join a new team, take on new responsibility, or engage with a new technical domain, the syndrome reactivates. It's not a pathology - it's a response to an environment of uncertainty. The problem is not eliminating it, but learning not to be blocked by it.

Gill Corkindale's research on HBR (2008) identifies some strategies that correlate with effective management of the phenomenon: talking about it with others, keeping track of real successes, distinguishing between "doing something perfectly" and "doing something well enough," and accepting that there are things you don't yet know without interpreting them as evidence of inadequacy.

Reading List and Resources

Impostor syndrome is a topic with a lot of psychological literature and a lot of low-quality motivational literature. I've tried to separate the two categories and to recommend only resources I find genuinely useful and grounded in real research.

Essential books

• Cal Newport, So Good They Can't Ignore You (ISBN 978-1455509126) - The career capital framework as a response to impostor syndrome. Newport argues that professional self-esteem is built through real competence, not self-convincing. Essential.
• Carol Dweck, Mindset: The New Psychology of Success (ISBN 978-0345472328) - Research on fixed vs growth mindset. The chapter on the workplace is particularly applicable to the non-CS developer context.
• Cal Newport, Deep Work (ISBN 978-1455586691) - Building deep competence as a countermeasure to impostor syndrome. Newport shows how deliberate practice produces concrete evidence of growth.

Free online resources

• Gill Corkindale, "Overcoming Imposter Syndrome" (HBR, 2008) - The most useful article I know on impostor syndrome in a professional context. Short, practical, not motivational.
• Clance and Imes (1978): "The Imposter Phenomenon in High Achieving Women" - The original paper. Worth reading the abstract and conclusions even if the body is academic. Normalizes the phenomenon powerfully.
• Madhuri Ramesh, "How I dealt with impostor syndrome as a self-taught developer" (DEV.to) - A direct testimony from a self-taught developer. Relatable and practical.

If you're building your training autonomously, the 6-month study guide I've prepared includes a weekly framework designed to handle the stalling and doubt moments that inevitably come. You can download it for free above.

Next Step in the Series

This is the first cluster article in the series. It addresses a cross-cutting theme that affects every background, regardless of where you come from. Over the coming weeks, the series branches into more specific topics.

Next Tuesday: What I wish I'd known when I started coding - an honest inventory of things I learned too late that I wish someone had told me at the start. It's still a first-person narrator article, oriented toward universal themes rather than specific backgrounds.

If you'd like to receive each article directly in your inbox, you can subscribe to the newsletter below. One issue every Tuesday. No automated sequences.

Return to the series cornerstone for the complete view of all 20 planned articles and the career matrix with 12 paths.

What I Learned Writing This

Writing an article about impostor syndrome is a particular experience. While you write, the impostor's voice comments: "Who are you to write about this?" It's a meta-irony that doesn't escape notice.

But it's also, in a certain sense, the answer to that voice: write anyway. Not because you're certain of having all the answers - I don't. But because you have something concrete to share, something that comes from direct experience and reflection on that experience. And the impostor's voice is not a sufficient reason not to do it.

One thing I clarified writing this is the distinction between "managing impostor syndrome" and "getting rid of it." I eliminated several versions of this article that promised the second - because that promise is false, and false promises are the type of content I don't want to produce. The honest goal is management: learning to live with that voice in a way that doesn't dictate decisions, doesn't block actions, doesn't ruin work.

Another thing I clarified is the tone. I had written some parts in too directive a way - "you must do X," "you must not do Y." I rewrote them in the first person, because what I can say with certainty is what has worked for me, not what will work for everyone. Context matters, people are different, situations vary. What I can offer is the map, not the path.

I made a deliberate choice not to cite specific cases of people I know directly - colleagues, mentors, friends who have gone through this transition. Not for lack of stories, but because the respect for the privacy of those who shared their experiences with me is worth more than the illustrative value of an anecdote. The stories I've cited in this article are from public sources, documented, from people who chose to tell them.

One last thing I learned: impostor syndrome is not the same for everyone. Its manifestations depend on context, background, personality, and the type of team you work in. What I described in this article is the version I've observed most frequently in developers with non-CS backgrounds in the Italian market. But there are variations. If your experience is different from what I've described - if you recognize the phenomenon but not the specific modalities - your version is probably equally valid and equally manageable. The starting point is always the same: name what's happening, without judging it.

If you recognize something of what I've described - if the impostor's voice is part of your daily experience - I'd like to know. Not to collect testimonials, but to understand whether the themes I'm addressing in the series respond to real questions. Write to me at federico@federicocalo.dev.

I'll reply. Always.

Related deep dive: Non-CS Developer Track: percorso, autostima e consigli pratici.