Steering Clear of Impostor Syndrome: A Guide for Software Developers
Impostor syndrome […] is a psychological pattern in which an individual doubts their skills, talents, or accomplishments and has a persistent internalized fear of being exposed as a “fraud”[…] despite external evidence of their competence. — Wikipedia
“Hey, Foo Bar! Congratulations on your new job. You deserve this!" summarizes most of what you’ve heard since you landed that new big role. Everyone thinks you’re a great guy who knows his onions — and you know this too — because you’ve been pivotal to the making of some cool software out there and have contributed greatly to the success of software engineering teams. But weeks into your new job, you are battling with accepting your achievements or the image that your former colleagues held about you. You downplay your own expertise and feel like you fooled everyone to get here. You struggle to live up to the expectations set for you in your new cohort, blaming your new struggles on lack of competence and degenerating into a shadow of your self. Wait! You may be doing some things wrong. Maybe the real problem is not what you think.
It’s quite easy to forget some things that help to drive Impostor Syndrome miles away. Let’s see if you know them and are doing them.
1. Avoid Closed Ecosystems
Closed ecosystem: a self-replenishing ecosystem in which life can be maintained without external factors or outside aid.
Does your new company use some closed framework that you must learn? Probably a framework with insufficient documentation unlike a React, Angular, Laravel or Spring with superb documentation and a large community to provide help? Are you in an environment where the bulk of answers you need must be asked from other devs within the company, not on Google search or Stackoverflow? Are those developers available to you every time you need answers? Are the answers that they provide clear-cut like you would find in the documentation of some popular open-source framework? If your answer to the last two questions is “no” while others have a “yes”, then you are most likely in a closed ecosystem.
Every company has her secrets and intellectual property — some of which may be at the cost of developer happiness in improperly structured environments. However, as long as the job gets done, everyone lives with it. Living with it becomes normal and it looks abnormal to not adapt to it. It gets bad when these closed systems have a poor documentation that leaves you wondering how anyone was able to live with it. When you request for clear explanations, you might get a response similar to “Hey! You’re a dev! You should be able to find answers yourself [amidst bad documentation and shallow answers]. There was a time when documentation was one large book without copies, there was no internet and programmers survived. Why can’t you now?” That’s pretty correct. However, there was also a time when there were no vehicles and people had to walk miles to get to their destination. Now that there are cars and bikes everywhere, why should you have to walk miles when the goal is to get to your destination as soon as possible? Is productivity the priority or showing-off ability to find answers on your own amidst poor documentation?
Closed Ecosystems can beat you down if you don’t handle things correctly. No company is perfect, and the seemingly perfect ones have their buts. Nonetheless, avoiding closed ecosystems is a good way to steer clear of impostor syndrome. If you can’t avoid them, master the art of steering your boat through their currents or find where you truly belong lest you find yourself battling with the thought that you are an impostor and a fraud who can’t handle the challenges put before you.
Is productivity the priority or showing-off ability to find answers on your own amidst poor documentation?
2. Replicate that Bug First
An issue was reported and you’ve been assigned a ticket to fix. Maybe the ticket has a good description or maybe not. One mistake you should never make is to not replicate whatever issue was reported. Even if the root cause of the issue was communicated by a Principal Software Engineer or the CTO who has a wealth of experience and knows where everything is, replicate the bug on your local machine first. Ask all the questions you need. You don’t want to fix a bug, write unit tests for it, send the code for review, have it merged and discover that you fixed nothing — because what was communicated as the problem was not the problem in the first place.
The reality of having negative comments on your ticket because you did not ask the right questions can plunge you into self-distrust — a close cousin to Impostor Syndrome. So ask all the questions and replicate the bug before fixing it. Ask for screenshots if it’s a UI/UX related bug. Which project is affected? What was the customer trying to do? At what point did the action fail? Is there a log of the error on some error reporting tool such as Sentry, Bugsnag, AWS Cloud Watch or Raygun? Is this a new error or was it reported before? If it was reported before, who was in charge of fixing it back then? You might need to get some understanding from that person. Get that ticket busy with questions because you need answers! If you can’t replicate the bug, you can’t fix it. If after asking all those questions and getting answers, you discover that the bug can’t be replicated, then draw the attention of the whole team to it. There’s a crazy bug at hand and we need all hands on deck. The goal is to fix the bug and the first step is to replicate it. If you have to call-out the whole team, you’re still doing your job because your job is to find a solution — and here you are doing exactly that!
If you can’t replicate the bug, you can’t fix it
3. New feature? Ask All That There is to Ask
You are headed for a frustrating adventure if all you have is incomplete pieces of the map to a treasure chest.
There is a feature request and a ticket has been created with your name on it. Does the ticket have very good description of what is expected from this new feature? Can we have some UI mockup? What’s the purpose of the feature? You definitely need some acceptance criteria to write unit tests and to confirm that your implementation satisfies expectations. Never overlook acceptance criteria. Never! If there’s none on the ticket, create a list of acceptance criteria based on the ticket description, put it on the ticket as a comment and call-out your Product Manager to confirm that the acceptance criteria are correct. Also comment on the ticket for physically testable parts and those that may only be tested via unit testing. You can’t follow this approach and get things wrong. You can’t do things right and end up with negative reviews. You can’t fall victim of Impostor Syndrome if you, your colleagues and your employer feel good about your work.
You can’t fall victim of Impostor Syndrome if you, your colleagues and your employer feel good about your work.
4. Push for Change and Know When to Quit
You deserve to be happy while getting your job done. So challenge the environment if things aren’t the way they should be. If your questions and requests on clarifying tickets aren’t respected, that’s probably a toxic environment. You don’t want to stay around waiting for things to get better. The result will be you thinking that you are inadequate when the reality is that you don’t have what you need to work. Stand up and stand firm. If no one is ready to listen to your call for a change, walk away peacefully. You need your sanity.
5. Update Your Knowledge Daily
Endeavour to read books on your stack and stay up-to-date with your skills for at least one hour daily. Knowledge gives confidence. If you’re not confident, you’ll find yourself begging to be tossed around.
6. Play. Yes, play!
Being a workaholic doesn’t drive productivity. It’s a recipe for languishing. Having fun isn’t an enemy of efficiency. It’s fuel for finding flow. Play isn’t a reward for finally making it through your to-do list. It belongs on your to-do list.
What happens when you lack vigour and excitement? Ever heard the saying that “all work and no play makes you pretty dull”? Dullness can plunge you into seeing only the negative side of things around you. So put play into your daily routine. Take out 20 minutes to play a video game or do something playful and fun. Maybe catch up with a movie series.
You need play to stay mentally afloat. If you avoid closed ecosystems or manage them properly, ask all the questions in the world to guide you in replicating bugs or implementing new features, and update your knowledge daily without having play on your to-do list, you risk a developer’s most important asset — the mind. You need to stay sane and healthy!
