The following article explains the why’s and how’s developers feel impostor syndrome, as well as ways to remediate this feeling in an organization.

https://stackoverflow.blog/2023/09/11/what-we-talk-about-when-we-talk-about-imposter-syndrome/

How does our emphasis on impostor syndrome keep us from having bigger, harder conversations about how to improve life for developers?

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.