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?
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.
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] We completed “debugging” tasks and conducted in-depth interviews about our learning, problem-solving, and feedback experiences during onboarding to an unfamiliar and collaborative codebase. ”
“Code reviews often fail to recognize the efforts of the coders when no lines of code are produced as a result,” Hicks said in an interview. Despite “expressing his ideals regarding the sharing of knowledge,” Hicks writes: “This research was often contradicted by negative instructions from colleagues about what was ‘really’ valuable.” It was further exacerbated by anxiety and the desire to meet the expectations of the environment. ”
In response to this tension, coders have[divested] The “invisible” work of one’s own learning and knowledge transfer leaves future collaborators without guidance when working with unfamiliar code. As a result, coders frequently expressed a painful sense of isolation, even in well-resourced teams. ”
As suggested above, this feeling of loneliness and isolation can exacerbate feelings of imposters in the workplace. And the fear of not looking like an engineer (probably familiar to many reading this) is easily interpreted as impostor syndrome. However, it’s worth asking whether impostor syndrome is a diagnosis or just a symptom.
Another expression you may have heard. “Just because you’re paranoid doesn’t mean they’re not after you.” Implicit in the definition of impostor syndrome is the understanding that you have impostor syndrome. do not have con man. He may lack confidence, but he doesn’t really lack skill.
But what do you do if others think you’re an impostor? “Impostor syndrome is when people are more skeptical and treat you worse than others with similar backgrounds.” “Impostor syndrome is not a syndrome at all if it is an accurate expectation that it will be,” Hicks writes.
The problem with impostor syndrome, says Ruchika, is that it “puts the blame on individuals without taking into account the historical and cultural context underlying how impostor syndrome manifests.” – Turshan and Jodianne Bewley write in an article with the memorable title, “Stop Telling Women About Cheaters.” Impostor syndrome (harvard business review). “Impostor syndrome turns our perspective on fixing women in the workplace instead of fixing where women work.”
Although Tursian and Bewley’s article focuses on women, their critique of impostor syndrome speaks to a broader tendency to blame structural problems on individual flaws. In other words, if you feel like an impostor at work; you The problem isn’t a company that doesn’t recognize your contributions or a colleague who makes assumptions about your abilities based on your gender, race, age, or education.
Seen from this perspective, “impostor syndrome” seems a useful way to describe a problem bigger than a person’s shaky self-confidence.
This isn’t to say that impostor syndrome isn’t real, or that developers aren’t widely, or perhaps especially likely, to feel like imposters at work. The highly specialized nature of software development, the pressure to constantly reskill, and the relative isolation of developers (many working remotely, many individual contributors) all make it difficult to This is partly why so many developers identify with the idea of impostor syndrome.
But while the advice to “embrace the haters” or stop shortcutting yourself in the job market is absolutely valid and helpful for some people who feel like frauds, the problem is If you have a colleague who doesn’t, adjusting your approach won’t solve the problem. Don’t recognize yourself as a “real” developer, or as an organization that doesn’t value your work (and make you think so). The entire organization is responsible for creating a workplace that:
- Continuous learning will become an integral part of the job, allowing developers to gradually acquire new skills in a supportive environment and gain self-service knowledge when they need it.
- Treat employees fairly and be inclusive of everyone.
- We understand that developer confidence and happiness at work is a collective responsibility, not an individual problem.
Stack Overflow has documented how a learning-centered environment is essential to developer happiness and success, and our annual developer survey found that access to learning opportunities in the workplace is critically important to developers. It has been shown that there is.
The key to fostering this type of environment is to help your team overcome any feelings of fraud. And the power to do this lies not only in the individuals working there, but also in organizations and society.
If you’re considering a career change, this article on how to establish your career axis is a good starting point.
