Imposter 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 imposterism.
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 imposterism.
Our conversation with Hicks got us interested in what’s going on behind the imposter-syndrome conversation. For instance, what does it tell us about the industry that so many developers identify with the concept of imposter syndrome? How does our emphasis on imposter 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 imposter syndrome, but certain aspects of how software developers work can leave them particularly vulnerable to feelings of imposterism.
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 imposterism.
The explosion of GenAI and AI-powered coding tools make feeling like an imposter 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] accomplished a ‘debugging’ job and an in-depth interview on their studying, problem-solving, and suggestions experiences whereas onboarding to an unfamiliar, collaborative codebase.”
Within the interviews, Hicks discovered that “code evaluate typically didn’t acknowledge code writers’ effort when it didn’t lead to traces of code.” Despite “said beliefs about data sharing,” Hicks writes, “this work was typically contradicted with unfavourable cues from colleagues about what was ‘actually’ valued. This stress was exacerbated by code writers’ fears about ‘not trying like an engineer,’ and their want to carry out to the expectations of their environments.”
In response to this stress, the code writers “[divested] from their very own studying and from the ‘invisible’ work of information switch, leaving future collaborators with out steerage in their very own ramp-up to unfamiliar code. Consequently, code writers ceaselessly expressed a poignant loneliness, even in extremely resourced groups.”
This loneliness and isolation can, as we instructed above, exacerbate emotions of imposterism at work. And worry of not trying like an engineer—which in all probability sounds acquainted to many individuals studying this—is definitely interpreted as imposter syndrome. However it’s value asking whether or not imposter syndrome is the prognosis or merely the symptom.
Right here’s one other expression you may need heard: “Simply since you’re paranoid doesn’t imply they aren’t after you.” Implicit within the definition of imposter syndrome is the understanding that you just’re not an imposter; you may lack confidence, however you don’t actually lack expertise.
However what if it’s different individuals who see you as an imposter? “Imposter syndrome will not be a syndrome in any respect whether it is as a substitute an correct expectation that folks will likely be extra skeptical and worse to you than different individuals with an identical document,” writes Hicks.
The issue with imposter syndrome is that “it places the blame on people, with out accounting for the historic and cultural contexts which might be foundational to the way it manifests,” write Ruchika Tulshyan and Jodi-Ann Burey within the tellingly titled article Cease Telling Ladies They Have Imposter Syndrome (Harvard Enterprise Assessment). “Imposter syndrome directs our view towards fixing ladies at work as a substitute of fixing the locations the place ladies work.”
Tulshyan and Burey’s article focuses on ladies, however their critique of imposter syndrome speaks to a broader tendency to ascribe structural issues to particular person failings. In different phrases, for those who really feel like an imposter at work, you are the issue, not the corporate that fails to acknowledge your contributions or the coworkers who make assumptions about your talents primarily based in your gender, your race, your age, or your instructional background.
From this angle, “imposter syndrome” begins to appear like a handy clarification for issues which might be larger than anyone particular person’s flagging confidence.
None of that is to say that imposter syndrome isn’t actual or that builders aren’t broadly and maybe particularly more likely to really feel like imposters at work. The extremely specialised nature of software program improvement, the strain to continually re/upskill, and the comparative isolation of builders (many working remotely, many as particular person contributors) all contribute to what number of builders determine with the concept of imposter syndrome.
However whereas recommendation to “embrace the suck” or cease reducing your self brief on the job market is totally legitimate and useful for some individuals who really feel like imposters, adjusting your individual method isn’t going to resolve the issue if it lies with colleagues who don’t understand you as a “actual” developer or a corporation that doesn’t worth your work (and make you’re feeling it). The onus is on the group as an entire to create a office that:
- Makes steady studying an integral a part of the job, permitting builders to accumulate new expertise incrementally in a supportive setting and self-serve data after they want it.
- Treats workers equitably and is inclusive of everybody.
- Understands builders’ confidence and happiness at work as a collective accountability, not a person drawback.
At Stack Overflow, we’re on the document about how a learning-centered setting is crucial to developer happiness and success, and our annual Developer Survey has proven that entry to studying alternatives at work is essential to devs.
An necessary a part of cultivating this type of setting is empowering your groups to banish emotions of imposterism—and the ability to try this lies as a lot along with your group, and your society, as with the people who work there.
If you happen to’re eager about making a change in your profession, mark your calendar for September 20, 2023 at 10am EST: Stack Overflow is partnering with Certainly on a studying and improvement webinar the place you possibly can hear from specialists about the right way to method your subsequent profession transfer, with examples and learnings from Stack Overflow’s tech workforce. Register for the webinar right here.
