software<\/a> engineering not simply as an individual psychological problem, but also as a systemic issue that can be reinforced by team culture and the broader socio-technical environment.<\/p>\nThe paper further reports that more than half of software engineers experience frequent or intense feelings of being an impostor, with women, Black, and Asian software professionals reporting such experiences at higher rates.<\/p>\n
The former study examined the impact of structured coaching on early-career software engineers and found modest reductions in impostor feelings. Interestingly, however, the comparison group also improved. This suggests that reflection and coaching may not tell the whole story; the surrounding experience of working, collaborating, learning, and gaining professional exposure may matter just as much.<\/p>\n
These findings have strengthened my conviction that the conversation about the Impostor Phenomenon deserves to extend beyond my immediate community. I have seen its prevalence among early-career software engineers firsthand, and I believe it is worth examining what it means for people at the beginning of their careers.<\/p>\n
The Psychology of Feeling Like a Fraud<\/b><\/p>\n
The Impostor Phenomenon describes a persistent internal experience of intellectual fraudulence despite clear evidence of competence. People experiencing IP often struggle to accept their successes as legitimate, attributing their accomplishments instead to luck, timing, favourable circumstances, or the mistaken belief that others overestimate their abilities.<\/p>\n
It is commonly characterised by anxiety before a performance task, followed by over-preparation or procrastination. Even when the individual succeeds, that success may be discounted or explained away. The cycle reinforces self-doubt and prevents the development of a stable sense of competence.<\/p>\n
Over time, this pattern can undermine confidence, fuel perfectionism, and sustain a chronic fear of being exposed as a fraud.<\/p>\n
It does not take much imagination to understand the damage these psychological effects can inflict on a beginner's career if they are left unaddressed.<\/p>\n
Why Software Engineering Is Fertile Ground for Impostor Feelings<\/b><\/p>\n
Software engineering appears particularly fertile ground for the Impostor Phenomenon.<\/p>\n
The field is characterised by continuous technological change, peer evaluation, complex problem-solving, and high expectations for innovation. Engineers are expected to continuously confront what they do not know. Yet<\/b> many young engineers interpret not knowing as evidence that they do not belong.<\/b><\/p>\n
Consider a typical junior engineer's experience.<\/p>\n
They encounter an unfamiliar codebase. They search the documentation, ask a colleague for help, experiment, break something, debug it, learn from the failure, and eventually ship a working solution.<\/p>\n
That is engineering.<\/p>\n
Yet internally, the same experience can become a very different story:<\/p>\n
\u201cI should have known this. Everyone else seems to understand it. Sooner or later, they will discover that I am not as capable as they think<\/i>.\u201d<\/p>\n
This is the invisible bug.<\/b><\/p>\n
The problem is not the knowledge gap. The problem is the meaning we attach to the knowledge gap.<\/p>\n
The Deception of Comparison<\/b><\/p>\n
The Impostor Phenomenon becomes particularly powerful in software engineering because the profession is built around complexity, constant learning, and highly visible expertise.<\/p>\n
Software engineering also makes comparison particularly deceptive.<\/p>\n
You see a senior engineer's intuition, but not the thousands of repetitions that created it. You see the elegant solution, but not the failed attempts that preceded it. You see the confidence, but not the years of accumulated context.<\/p>\n
Your two hours of struggling with a problem are therefore not being compared with their two hours.<\/p>\n
You are comparing your early repetitions with their accumulated experience.<\/p>\n
There is another paradox worth considering: learning can temporarily make you feel less competent.<\/b><\/p>\n
The more you understand, the more clearly you see the complexity you previously could not see. Discovering how much you do not know is not necessarily evidence that you are getting worse. Sometimes, it is evidence that your understanding is becoming deeper.<\/p>\n
This brings to mind a concept we discuss during employability sessions at the bootcamp: the Dunning\u2013Kruger effect<\/b>. In simple terms, confidence can be disproportionately high when our knowledge is limited because we lack the knowledge necessary to recognize what we do not yet understand.<\/p>\n
As we learn and grow, however, our awareness of the vastness of what remains to be learned can increase.<\/p>\n
That declining confidence may, in some circumstances, actually represent expanding awareness.<\/p>\n
The beginner sees a problem.<\/p>\n
The developing engineer sees the architecture, dependencies, trade-offs, assumptions, and hidden failure modes surrounding it.<\/p>\n
The second person may feel less certain precisely because they can now see more.<\/p>\n
When a Knowledge Gap Becomes an Identity Gap<\/b><\/p>\n
The danger begins when uncertainty becomes an identity judgment.<\/p>\n
A knowledge gap becomes an identity gap.<\/p>\n
\u201cI don't know this\u201d becomes:<\/p>\n
\u201cI am not good enough.\u201d<\/b><\/p>\n
\u201cI needed help\u201d becomes:<\/p>\n
\u201cI am not a real engineer.\u201d<\/b><\/p>\n
\u201cI made a mistake\u201d becomes:<\/p>\n
\u201cI have been exposed.\u201d<\/b><\/p>\n
That interpretation can quietly shape an entire career.<\/p>\n
You stop asking questions. You avoid difficult assignments. You over-prepare. You work late to compensate for perceived inadequacy. You remain silent in meetings because you are afraid your contribution will sound foolish.<\/p>\n
Eventually, you may become less visible precisely because you are trying so hard not to be exposed.<\/p>\n
And that is where the invisible bug becomes costly.<\/p>\n
You Can Change Your Relationship with Uncertainty<\/b><\/p>\n
There is, however, an important distinction we must make.<\/p>\n
You do not have to wait for your organization or the software industry as a whole to change before you change your relationship with uncertainty.<\/p>\n
Start by redefining what competence means.<\/p>\n
Being a good engineer does not mean knowing everything<\/b>. It means knowing what you do not know, knowing how to research it, knowing when to ask for help, and being able to evaluate and apply what you discover.<\/p>\n
Begin with a simple discipline:<\/p>\n
Separate \u201cI don't know\u201d from \u201cI am not capable.\u201d<\/b><\/p>\n
The first is a fact.<\/p>\n
The second is a conclusion.<\/p>\n
They are not the same thing.<\/p>\n
Then change how you think about help. Documentation, search engines, colleagues, developer communities, and AI tools are not evidence that you are an impostor. They are part of modern engineering practice.<\/p>\n
The mark of expertise is not knowing everything from memory. It is knowing how to find, question, test, validate, and apply knowledge responsibly.<\/p>\n
Keep an Evidence Ledger<\/b><\/p>\n
One practical strategy is to keep an evidence ledger<\/b> of your professional growth.<\/p>\n
Record the problems you have solved, systems you have learned, mistakes you have recovered from, feedback you have incorporated, and responsibilities you can now handle independently.<\/p>\n
Impostor feelings have selective memory. They remember the embarrassing pull request and conveniently forget the twenty things you learned afterwards.<\/p>\n
An evidence ledger gives you something more reliable than feelings: evidence.<\/p>\n
When self-doubt appears, you can look back and see that your competence is not an assumption. It is something that has been developing through repeated evidence of learning, adaptation, and problem-solving.<\/p>\n
Separate Your Work from Your Worth<\/b><\/p>\n
When feedback arrives, separate your work from your worth.<\/p>\n
A rejected pull request means the implementation needs work. It does not mean you are a fraud.<\/p>\n
A difficult code review means your thinking<\/a> has encountered another perspective. That is precisely how engineering competence develops.<\/p>\nFeedback is information.<\/p>\n
It is not a verdict on your identity.<\/p>\n
Most importantly, ask questions without apologising for existing.<\/b><\/p>\n
Instead of hiding uncertainty, make it precise:<\/p>\n
\u201cI understand A and B, but I'm unclear about C. My current assumption is X. Does that match your understanding?\u201d<\/i><\/p>\n
That is not incompetence.<\/p>\n
That is engineering.<\/b><\/p>\n
The Environment Matters<\/b><\/p>\n
And pay attention to your environment.<\/p>\n
Research on the concept of Human Debt<\/b> reminds us that impostor feelings can be reinforced by the socio-technical environment around us. Workplace culture, team dynamics, expectations, communication patterns, and the way expertise is displayed can all influence how individuals interpret their own competence.<\/p>\n
We certainly cannot reform an entire industry overnight.<\/p>\n
But we can develop something more immediately valuable: the ability to calibrate our self-belief against evidence.<\/b><\/p>\n
You are not required to feel like an expert.<\/p>\n
You are required to keep becoming one.<\/b><\/p>\n
The question is not:<\/p>\n
\u201cDo I know enough to belong here?\u201d<\/i><\/p>\n
The better question is:<\/p>\n
\u201cAm I learning, adapting, solving increasingly difficult problems, and becoming more capable than I was yesterday?\u201d<\/i><\/p>\n
If the answer is yes, then what you are experiencing may not be evidence that you are an impostor.<\/p>\n
It may simply be the psychological discomfort of becoming a professional.<\/p>\n
In this age of software development, the defining skill of the next generation of software engineers will not be knowing everything.<\/p>\n
It will be knowing\u00a0what you know, recognising what you do not know, and understanding when you still need to think.<\/b><\/p>\n","protected":false},"excerpt":{"rendered":"
For several years, I have been involved in employability coaching for software engineers and aspiring software engineers at Moat Academy Coding Bootcamp. One recurring issue…<\/p>\n","protected":false},"author":1,"featured_media":1039,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,7],"tags":[],"class_list":["post-1037","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education","category-features"],"_links":{"self":[{"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/posts\/1037","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/comments?post=1037"}],"version-history":[{"count":1,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/posts\/1037\/revisions"}],"predecessor-version":[{"id":1040,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/posts\/1037\/revisions\/1040"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/media\/1039"}],"wp:attachment":[{"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/media?parent=1037"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/categories?post=1037"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/moatacademy.com\/blog\/wp-json\/wp\/v2\/tags?post=1037"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}