Impostor syndromeâdoubting your abilities to the point where you feel like a fraudâis an evergreen topic of conversation among software developers. Weâve written about it here and there, and there are countless other articles about how to understand and overcome your feelings of impostorism.
Recently, we talked with Dr. Cat Hicks, Director of Pluralsight Flowâs Developer Success Lab, on the Stack Overflow podcast. Hicks studies the socio-cognitive factors and processes behind how people learn and achieve success, and sheâs written about what makes developers prone to feelings of impostorism.
Our conversation with Hicks got us interested in whatâs going on behind the impostor-syndrome conversation. For instance, what does it tell us about the industry that so many developers identify with the concept of impostor syndrome? How does our emphasis on impostor syndrome keep us from having bigger, harder conversations about how to improve life for developers? And what should organizations be doing to support their dev teams?
What makes developers feel like impostors?
No industry is immune to impostor syndrome, but certain aspects of how software developers work can leave them particularly vulnerable to feelings of impostorism.
Technology and best practices are constantly evolving, which means that software developers have to embrace a culture of continuous learning, always open to acquiring new skills or polishing existing ones, rather than believing they have nothing left to learn. Thereâs always something new to learnâwhich means thereâs always something you donât know how to do. As the saying goes, the more you learn, the less you know (the dark side of this aphorism is the Dunning-Kruger effect).
People tend to gain more confidence in their abilities when they can acquire new skill sets incrementally, according to Hicks, but software engineering doesnât always seem to reward or even allow incremental learning. Instead, Hicks explained, âItâs just âlearn Python,â or âlearn React.ââ This way of looking at things makes new skill sets loom like monoliths, too intimidating to approach.
Many devs also feel intense pressure to re/upskill with whatever time is left over from their day jobs. They spend their time away from work learning new languages, contributing to open-source projects, and compiling a portfolioâworking, in other words. For plenty of developers, it feels like the choice is between sacrificing necessary recharge time and non-work obligations or faltering in their careers.
Especially with tech influencers sharing their side hustles or hobby projects on social media, it can seem like everybody is working on something more complex, creative, or innovative than you. And with so many developers working remotely, itâs sometimes hard to form a realistic picture of how your peers are working or how theyâre really spending their time.
The runaway pressure on devs to learn new skills, languages, and frameworks can trap them in what Hicks describes as a stress cycle, âa form of physiological conditioning where you associate learning with high-stress environments.â When learning seems stressful, high-cost, and low-reward, people avoid situations where theyâre challenged to develop new skills: a vicious cycle that amplifies feelings of impostorism.
The explosion of GenAI and AI-powered coding tools make feeling like an impostor more inevitable than ever, as people who scramble to add AI prompt engineering and other related skills to their repertoires. But while many organizations claim to support devs in seeking opportunities to learn at work, too many fail to recognize or reward time spent learning or teaching new skills, focusing instead on devsâ quantifiable output: code, commits, and PRs.
âLike coding in the darkâ
In a qualitative research project involving more than two dozen software developers and engineers, Hicks identified a significant tension between âthe work that code writers needed to do to understand codeâ and the work most likely to be rewarded in a professional evaluation.
For Itâs Like Coding in the Dark: The need for learning cultures within coding teams, Hicks evaluated 25 âfull-time code writers [who] completed a âdebuggingâ task and an in-depth interview on their learning, problem-solving, and feedback experiences while onboarding to an unfamiliar, collaborative codebase.â
In the interviews, Hicks found that âcode review often did not recognize code writersâ effort when it did not result in lines of code.â In spite of âstated ideals about knowledge sharing,â Hicks writes, âthis work was often contradicted with negative cues from colleagues about what was âtrulyâ valued. This tension was exacerbated by code writersâ fears about ânot looking like an engineer,â and their desire to perform to the expectations of their environments.â
In response to this tension, the code writers â[divested] from their own learning and from the âinvisibleâ work of knowledge transfer, leaving future collaborators without guidance in their own ramp-up to unfamiliar code. As a result, code writers frequently expressed a poignant loneliness, even in highly resourced teams.â
This loneliness and isolation can, as we suggested above, exacerbate feelings of impostorism at work. And fear of not looking like an engineerâwhich probably sounds familiar to many people reading thisâis easily interpreted as impostor syndrome. But itâs worth asking whether impostor syndrome is the diagnosis or merely the symptom.
Just because youâre paranoidâŠ
Hereâs another expression you might have heard: âJust because youâre paranoid doesnât mean they arenât after you.â Implicit in the definition of impostor syndrome is the understanding that youâre not an impostor; you might lack confidence, but you donât truly lack skills.
But what if itâs other people who see you as an impostor? âImpostor syndrome is not a syndrome at all if it is instead an accurate expectation that people will be more skeptical and worse to you than other people with a similar record,â writes Hicks.
The problem with impostor syndrome is that âit puts the blame on individuals, without accounting for the historical and cultural contexts that are foundational to how it manifests,â write Ruchika Tulshyan and Jodi-Ann Burey in the tellingly titled article Stop Telling Women They Have Impostor Syndrome (Harvard Business Review). âImpostor syndrome directs our view toward fixing women at work instead of fixing the places where women work.â
Tulshyan and Bureyâs article focuses on women, but their critique of impostor syndrome speaks to a broader tendency to ascribe structural problems to individual failings. In other words, if you feel like an impostor at work, you are the problem, not the company that fails to recognize your contributions or the coworkers who make assumptions about your abilities based on your gender, your race, your age, or your educational background.
From this perspective, âimpostor syndromeâ starts to seem like a convenient explanation for problems that are bigger than any one personâs flagging confidence.
Whatâs the solution?
None of this is to say that impostor syndrome isnât real or that developers arenât widely and perhaps especially likely to feel like impostors at work. The highly specialized nature of software development, the pressure to constantly re/upskill, and the comparative isolation of developers (many working remotely, many as individual contributors) all contribute to how many developers identify with the idea of impostor syndrome.
But while advice to âembrace the suckâ or stop cutting yourself short on the job market is absolutely valid and helpful for some people who feel like impostors, adjusting your own approach isnât going to solve the problem if it lies with colleagues who donât perceive you as a ârealâ developer or an organization that doesnât value your work (and make you feel it). The onus is on the organization as a whole to create a workplace that:
- Makes continuous learning an integral part of the job, allowing developers to acquire new skills incrementally in a supportive environment and self-serve knowledge when they need it.
- Treats employees equitably and is inclusive of everyone.
- Understands developersâ confidence and happiness at work as a collective responsibility, not an individual problem.
At Stack Overflow, weâre on the record about how a learning-centered environment is essential to developer happiness and success, and our annual Developer Survey has shown that access to learning opportunities at work is very important to devs.
An important part of cultivating this kind of environment is empowering your teams to banish feelings of impostorismâand the power to do that lies as much with your organization, and your society, as with the individuals who work there.
If youâre thinking about making a change in your career, this article about how to land a career pivot is a good starting point.