Have you ever sat in a room and felt like you weren’t smart enough to be there? Maybe the conversation moved too quickly for you to follow, or perhaps your coworkers debated a topic you weren’t familiar with. It’s an uncomfortable feeling that every programmer experiences at some point in their career. When you start to doubt your own abilities and feel insufficient at your job, you’re experiencing impostor feelings.
exampleFeeling like an impostor can come on suddenly in a number of different situations:
You question your ability to complete a task you’re stuck on.
You feel like you don’t belong on a team or at a company because you’re not capable enough to follow along during discussions.
You feel completely overwhelmed, especially when starting a new role, a new project, or learning a new codebase.
You have trouble articulating how something works on a technical level or when someone asks you why you made a certain decision.
If you’ve ever found yourself in one of these situations, it’s hard not to feel like a phony. The good news is that it’s probably not as bad as you think, and it’s way more common than you realize. Nearly everyone has these feelings at some point. Unfortunately, part of the problem is due to the stigma surrounding impostor feelings, which often discourages people from discussing their feelings openly and seeking advice from others. It’s especially hard during the first few years of your career because you’re learning so many different things all at once:
Your team’s codebase and the technologies they use.
Your team’s development processes and methodologies.
Your company’s business logic and business model.
Your manager’s management style.
How to work well with your team members.
How to work with stakeholders, product managers, designers, and executives.
It’s common for software developers to feel overwhelmed with the pace of things during the first few years of their career. Things move incredibly fast when you’re still getting up to speed, and decisions happen quickly. Try not to get discouraged if you’re having trouble keeping up with your coworkers as you’re still learning. Some of your coworkers have been with your company for years, so they will naturally have built up more domain knowledge over time and gained a deeper understanding of the problems that need to be solved. They’ve probably written large portions of the codebase, so they will know the system better.
important The key thing to remember is that you shouldn’t be intimidated by coworkers who know more than you. In fact, you should view it as an opportunity to learn from them and ask them questions. Leverage their knowledge so that you can learn faster from their experience.
Chances are you’ve heard people talk about feeling like an impostor, although they probably referred to it as having “impostor syndrome.” While this phrase is commonly used, it’s misleading because it tends to oversimplify the issue, but it does help you easily communicate the feelings you’re experiencing. It also does a good job of capturing a feeling of being overwhelmed or inadequate that you may be struggling with. While this may seem like a good thing, there are some negative consequences that come from using the term.
The solution is not to label yourself as having a medical syndrome that needs to be treated; it’s to recognize your feelings so that you can work towards improving yourself and building confidence. Slapping a label on something you’re feeling doesn’t make it go away, but recognizing that feeling is the first step towards self-improvement.
Additionally, the term “impostor syndrome” tends to imply several things for some people:
You either have it or you don’t.
It’s abnormal.
As with many medical syndromes, you likely won’t get better without treatment.
None of these points are true, at least for most people. Think of it more as a natural feeling you have, like stage fright or feeling uncomfortable. It may come on suddenly and with varying intensity, but it’s a temporary feeling that will eventually pass. It’s good to remember this when you’re having these feelings so you can manage them and try to reduce the accompanying negative thoughts.
On top of all that, what most people don’t understand is that there’s no officially recognized “impostor syndrome” among medical professionals. There is not a single mention of impostor syndrome in the Diagnostic and Statistical Manual of Mental Disorders (DSM), which provides a common language and standardized criteria for classifying mental disorders and is widely used by mental health professionals.
In fact, the term impostor phenomenon was first described by Dr. Pauline R. Clance and Dr. Suzanne A. Imes in 1978.* Clance and Imes first defined the impostor phenomenon as an “internal experience of intellectual phoniness,” or, in other words, feeling like a fraud. While their study focused on high-achieving women who experienced these feelings, further research has revealed that both men and women are equally susceptible to the impostor phenomenon. Clance and Imes’s study also showed that these feelings are prevalent in highly successful people and those that have worked hard to build their careers.
In essence, impostor feelings can happen to anyone and can come on at any point in one’s career. Rather than trying to fight it, it’s more effective to embrace it and use it to motivate yourself to improve. Let’s dig deeper into what you can do when you suddenly start to feel like an impostor.
As programmers, we’re expected to know a wide array of things in order to do our jobs. On top of fundamental skills like writing code that compiles without errors, we also need to know how to design our programs to be future proof, how to write automated tests so we can be sure the code works as expected, and how to deliver results consistently and efficiently.
It’s easy to feel overwhelmed with the amount of knowledge required in order to complete our day-to-day tasks, in addition to answering questions from project stakeholders, defending our technical decisions during code reviews, and planning for the future.
There will be plenty of times throughout your career where you won’t know the answer to a question or won’t know what someone else on your team is talking about. It happens to software engineers of all levels, not just junior engineers. The thing that makes good engineers stand out from the rest is that they are humble and aware that they don’t know everything, and they use that knowledge to learn and grow.
exampleSituations that might bring on impostor feelings include:
Your boss might ask you a question in front of your team that you don’t know the answer to.
A senior engineer might ask if you considered an obvious edge case when fixing a bug.
A senior product manager might ask you to estimate how long it would take to build a new feature in a part of the codebase you’re not familiar with.
Your boss might ask you to clarify how something you built six months ago works, and you might not remember all the details about it.
It’s okay to admit that you don’t know something, or that you hadn’t considered some obvious edge case. In fact, admitting that you don’t know something is a sign of maturity. If you want to be successful in your career, you need to put your ego aside and accept the fact that you won’t know everything. It’s nearly impossible to know everything there is about programming. It’s such a broad industry that is still evolving each and every day, and it’s simply not possible to be an expert on every topic.
Additionally, there’s even more to learn about the process of delivering software, because writing code is only one part of the equation when it comes to doing our jobs. There are planning, analysis, design, implementation, testing and integration, and maintenance phases in a modern software development life cycle, and each phase comes with its own nuances and best practices. While you may not be great at all of those phases, a senior engineer must understand the entire process. It’s normal to feel like an impostor if you don’t have a lot of knowledge in one or more of these areas, but that doesn’t mean you’re not a good engineer.
Let’s look at what you can do to minimize those impostor feelings and leverage them to become a better software engineer.
You have gaps in your knowledge. We all do. It’s natural, so don’t worry about it too much. What’s more important is that you seek out and acknowledge these shortcomings so that you can take steps to close the gaps. Accepting your limitations allows you to put your ego aside and open your mind to new ideas and opportunities to grow.
Too often we fall into the misconception that we know more than we really do, which leads us to be stubborn and closed-minded when we’re presented with new information. Believing you know more than you do can have a negative effect on your ability to learn, and in some cases, it can stagnate your career growth. It can also make it easy to get defensive when your ideas are challenged. How you react in those situations can lead to conflicts with your coworkers or hinder your ability to make impartial decisions, which is why it’s important to be honest with yourself about the limitations of your knowledge and your skills.
When you accept that you don’t know what you don’t know, it opens the door to opportunities to improve the situation:
When you’re honest with yourself about what you don’t know, you naturally identify areas where you need to seek more information and learn more.
When you accept you don’t know something about a topic, it takes the pressure off when you need to ask for help. It gives you confidence to reach out to someone else who may be an expert in that topic and can help you, or they may be able to point you to someone who can.
Knowing what you don’t know helps prevent you from making an uninformed or biased decision.
So, how do you identify what you don’t know? A good first step is to write down in your notes things you already know that you don’t know. This could be things like topics, phrases, or acronyms that you’ve heard before but don’t know what they are. Write down as many things as you can think of.
important Use your favorite note-taking app or even a physical notebook: something that you’ll be able to access at any time and be able to reference later on.
It’s important to be honest with yourself during this step. Don’t be embarrassed if the list is long or you think it’s full of basic topics—you don’t need to share it with anyone. And these don’t necessarily have to be technical topics either. They can be related to business in general, some unique aspect of your company, or something industry-specific. And finally, while it’s important to write down things you don’t know or understand, it’s also important to write down what you don’t understand about it too. This will give you some indication on what you should focus on when it’s time to learn.
I don’t understand how containers are different from VMs. It sounds like they do the same thing.
I don’t understand dependency injection or why I would need it.
I don’t understand our company’s sales process. Where do our customers come from and why do they want our product?
I don’t understand React hooks. When would I even use them?
I don’t fully understand the difference between an abstract class and an interface, and when to use one over the other.
I don’t understand the difference between stack vs. heap memory.
I don’t understand the economics of our industry. How do we determine the price point to sell our product competitively?
The next step is to observe. Take note of any new terms, phrases, acronyms, or concepts that pop up during conversations, video calls, chats, or comments from your coworkers or things you come across online. Anytime you come across an idea that you’re not familiar with, add it to your list. And every time you hear someone mention a topic that’s already on your list, add a checkmark or a +1 next to it.
What is ARR? And why is the leadership team interested in tracking that metric?
My boss keeps mentioning the need for static code analysis. What is it and why is it so important?
I keep seeing people mention Kubernetes. I know it has to do with containers but why is it so popular?
Before you know it, you’ll have a long list of topics of things to learn about. Whenever you have some time to spare, you can use this list as a starting point for things to research.
Once you’ve compiled a list of topics that you know you don’t know, you can begin to work towards learning and closing those knowledge gaps. At this point, you’ve essentially compiled a roadmap for expanding your knowledge. Now, you can begin to chip away at this list and start to close those gaps in your knowledge.
You can start with any topic, whether it’s something you’re really interested in or something you think will help you during your career. Another option is to rank the topics by what you think is the most important or what will have the highest impact in your day-to-day work.
An important thing to remember during this step is that you shouldn’t try to learn everything at once. Your list may be long, but that’s okay! Focus on learning one topic at a time so you can give it your full attention. Try to learn as much about it as possible before moving on to the next topic. If you try to learn too many things at once, you won’t be able to give each topic the attention it deserves, and you may not remember each thing you’re trying to learn.
You may be able to learn about some topics in a day, while others may take days or weeks to fully comprehend. Feel free to dive as deep into a topic as you see fit, but always try to learn more than just surface-level details about something.
Let’s look at the ARR acronym from the previous example.
exampleThrough your research, you learn that “ARR” stands for annual recurring revenue. Great! Now you’ll know what the executive team means whenever they say “we need to focus on growing ARR.” But don’t stop there—try to dig further and understand why focusing on growing ARR is so important.
Why is ARR an important metric for a SaaS company?
How is ARR calculated? (knowing this will help you understand how to increase it)
What does it mean if ARR is growing? What about declining?
How does my work fit into the company’s goal of growing ARR?
Spending time to do your own research and teaching yourself a topic is invaluable. Try to learn the foundational concepts behind each topic, and what makes them important. Once you start to learn about a topic beyond just the basics, you may come up with more questions and want to dig deeper. Use this as a good opportunity to reach out to others and ask some questions. Try to identify coworkers or people in your network that are familiar with the topic and let them know you’d like to learn more.
confusion Sometimes, the hardest part is in determining exactly what you should ask, who you should ask, or how you should frame your questions. Asking questions is harder than it sounds, so we’ll cover that topic in greater detail in How to Ask Better Questions.
Identifying and closing your knowledge gaps is just one thing you can do in order to counteract negative thoughts when you’re feeling like an impostor. It’s a great way to build confidence, expand your knowledge, and learn new skills and ideas that could help you throughout your career. Next time you’re feeling like an impostor, try writing down things you don’t know or want to learn, and start chipping away at them to learn something new.
We’ve all been criticized at some point in our careers, and it’s safe to say that it’s never a great feeling. It can be difficult to receive criticism, even if it’s intended to be constructive. Criticism can be a hit to your ego and sometimes leave you feeling lost and confused, especially when you feel so confident in your work.
Whether you like it or not, criticism is sometimes necessary in order to foster a healthy engineering organization and to maintain an organized codebase that can grow and evolve over time. As a developer, you’ll receive feedback throughout your career in many different areas, such as:
Code reviews. Other engineers may find issues with the syntax, logic, or readability of the code you submit for review.
Design reviews or brainstorming sessions. There is always subjectivity when it comes to architecting solutions to solve problems. Sometimes your proposed design will differ from your coworkers’ ideas, or they may pick apart your design.
Your manager. You may receive direct feedback from your manager about specific things that you need to improve, such as your organizational skills, attention to detail, work ethic, ownership, or attitude.
Product managers. Although you may have spent weeks on a feature, the solution you deliver may not be in line with what the product owner or customer was expecting.
While no one ever wants to be criticized, how you process the feedback can make a big difference. Accepting constructive criticism at work is an important stepping stone towards developing maturity and becoming a better developer. The hard part though is to learn to separate the content of the suggestion from the way that it was delivered. Criticism is not always delivered well, so it’s easy to get upset if it’s done in an insensitive way. And if the criticism is delivered over chat, email, or some other form of written text, the tone is often lost and can be interpreted differently than the author intended it to be.
The thing to keep in mind is that you can often still learn a great deal from criticism, even if it’s delivered in a way that’s insensitive or not as constructive as it could have been. If you are able to mentally separate the essential content of the criticism from the style or tone of the feedback, you’ll still be able to learn from it, even though it may not be what you wanted to hear.
Additionally, it’s important to separate the criticism from the person giving it. There may be coworkers who you don’t always agree with, that get on your nerves, or that have rubbed you the wrong way in the past, but that doesn’t mean you should automatically discount their feedback. You could learn some valuable things from these people, if you’re able to let go of any biases you may have towards them.
So, what can you do in these scenarios? Let’s look at a few things you can do to turn a negative situation into a positive one.
This is the most important and often the most difficult aspect of dealing with criticism. The way you respond to criticism is an indicator of your maturity and professionalism as a software engineer. Your reaction may be visible to your manager and your teammates, and if you’re not able to control your emotions when responding to criticism, you may risk hurting your reputation or your teammates’ trust in you.
The first step is to be aware of your emotional reaction. If you notice you’re getting upset about someone or something, ask yourself why it’s making you so upset. Having self-awareness about your emotional state helps you process your feelings and be more mindful about how you should respond.
If possible, wait to respond until you’ve been able to reflect on the feedback and gather your thoughts. It’s often best to refrain from responding immediately to feedback because your emotions may get the best of you. You may say something you will regret later, or you may not be able to think clearly in the moment. Instead, it’s better to accept the feedback and allow yourself to process and internalize the suggestions first. Giving yourself some time allows you to reflect and think about how you should handle the suggestions instead of responding immediately with excuses or defensiveness, and you will avoid saying something you may later regret.
No matter how good you are at your job, there is always room for improvement. When faced with constructive criticism from your boss or coworkers, try to reflect on the reason behind their feedback. Why are they giving you this feedback? There may be a good reason behind their actions, and if you’re able to understand fundamentally why you’re receiving criticism, you’re more likely to learn from their suggestions and make better decisions in the future. There may be important details you’ve overlooked that they’re bringing to your attention.
Try asking yourself these questions when you receive constructive criticism:
Are there reasons why I might have approached the problem in the wrong way?
Where does my design fall short?
Did I misinterpret the problem or task?
If there is a better solution proposed, what makes it better than mine?
Are there solutions that combine benefits of my approach with a suggested alternative?
caution Note that it’s never 100% certain that the feedback you’re getting is correct and that your approach was wrong. Sometimes, developers who review code don’t have the full context or may misinterpret something.
Asking yourself these questions, along with others designed to get to the root of the issue, will help you better understand the downsides of your approach. Perhaps there was additional context that would have been helpful to know when making a decision, or maybe there was a design pattern you weren’t aware of that was a better fit for the problem. Whatever the case may be, it’s important you understand why you’re receiving the feedback in the first place. This self-awareness alone will show that you are mature enough to handle criticism in the first place.
Receiving unexpected feedback may hurt your confidence, but don’t lose sight of the bigger picture. This is your opportunity to grow as an engineer. Once you’ve accepted that you can be better, the hard part is over. Then, it’s time to figure out what you can do to improve. These small changes compound over time and can help you become a better engineer quicker than you think.
There’s a lesson to learn every time you receive constructive feedback, so don’t squander an opportunity to improve yourself. If you choose to ignore the feedback, you could be missing opportunities to grow as an engineer, especially if it comes from people with more seniority than you. They may have years’ worth of experience that they’re trying to pass on to you. Perhaps they made a mistake when they were younger, and they don’t want to see you repeat those same mistakes. Or maybe they’ve noticed something that you could be doing better that helped them earlier in their career. Whatever the reason, don’t take advice from your senior coworkers for granted. They’ve been in your shoes. They’re trying to help you avoid the same mistakes they once made themselves.
As developers, we have to maintain incredibly complex mental models about how codebases work, and those models change continuously as new code is written, merged, and deployed to production. Over time it becomes harder and harder to recall what you worked on. When you think back on what you’ve built over the last few months, it may be difficult to remember everything you worked on. Days, weeks, and months go by, and you may not feel like you’ve accomplished a whole lot, which sometimes leads to impostor feelings. In reality, you complete a lot more work than you probably realize. The hard part is remembering everything you’ve done.
A simple but effective way to curb those impostor feelings is to keep a log of what you’ve worked on each week. Keeping track of what you’ve accomplished has a number of benefits:
If you’re ever feeling like an impostor, it helps to look back at all the features you’ve built, bugs you fixed, and your major accomplishments throughout your career.
When it comes time for your quarterly or annual review, you’ll already have a list of accomplishments you can refer to when asking for a promotion or a raise.
If you find yourself looking for new employment opportunities, you can refer to this list when updating your resume.
All it takes is a few minutes every week to write down what you worked on, and you’ll benefit down the road when it’s needed.
It’s never too late to start logging your accomplishments, and if you can’t remember what you worked on, you can always go back to your project management system and filter for the closed tickets that were assigned to you. There may be other things you’ve done that weren’t logged in your ticketing system, but it’s at least a good place to look if you’re just getting started.
exampleSo what things should you track?
Any goals or OKRs (objectives and key results) you reached and how you reached them, along with facts, quantifiable analytics, or financial data points to back it up. Basically, anything you improved that has a number, percentage, or dollar amount attached to it.
“I helped increase conversion rate by 1.2% last quarter by fixing multiple UX issues on our checkout flow.”
“I was able to reduce customer service calls by 19% by building out a self-service knowledge site for our customers.”
Difficult situations or challenges with coworkers, customers, or third parties that you navigated successfully. Take note of the path you took towards a resolution.
“I identified and fixed a critical bug that caused downtime for one of our largest customers.”
“I helped our team reach an agreement on a new database schema by identifying areas where one design scaled better than the other.”
Tasks or projects that you completed on time or ahead of schedule.
Take note of times when you exceeded expectations.
When you take the time to write down your accomplishments, you’ll be able to reference them any time. It’s a good habit at the end of every week, month, or team sprint. It only takes a few minutes each time, and it helps you focus on your wins rather than your gaps in skills or knowledge. And remember, anytime you’re feeling like an impostor, you can always come back to read through everything you’ve accomplished.
Hopefully, you now understand that feeling like a phony or a fraud is common among all software developers, and that you shouldn’t get too hard on yourself when you’re going through a period of feeling like an impostor. The most important part is to try to identify why you’re experiencing those feelings and accept that nobody is perfect. Once you understand the root cause of why you’re feeling a certain way, you can begin to take action to improve yourself and your skill.
With a little persistence and determination to get better, you’ll be able to build the confidence to take on any situation, no matter how daunting.
Actual impostors don’t get impostor syndrome (zapier.com)
I’m An Impostor (dev.to/bytebodger)
How to Live with Chronic Imposter Syndrome (eugeneyan.com)
Dealing with Imposter Syndrome (dev.to/jingjing142)
Your professional relationship with your manager is one of the most significant factors affecting your career growth. You are ultimately responsible for your own career, but your manager has more influence over your career trajectory than anyone else in your company, so it’s critical that the two of you work well together. They sit above you in the organizational hierarchy, which gives them power to make decisions that can affect your career, both positively and negatively. This relationship has far-reaching consequences, such as which projects you work on and the opportunities you’re given. Many say that your relationship with your manager is the single biggest factor that affects your job satisfaction.
Some managers are great to work with, but others may prove more difficult. No matter how good or bad your manager is, it’s your job to make the relationship work. Every professional relationship between a manager and a programmer is unique, and you’ll have to work hard to figure out what works best between the two of you. Your relationship with your manager will evolve over time, and you’ll have to continue to adjust and make changes to how the two of you work together.