It’s been just a little over two years since I decided to make a serious commitment to the journey of programming. I wanted to document as much as I remember of the first hard parts of that journey because I don’t want to forget how unfeasible the idea of becoming an engineer was at that point. Now that I am one, it feels like it takes more effort to remember the challenges of setting up my environment, learning git, and understanding why time-space complexity mattered, because these are things that I now work with day to day. I’m sure that, as I gain more programming experience, the idea of not understanding fundamental programming will become more and more foreign to me.
Why is it important for me to recall what that frustration felt like in the early days of my programming journey? For as long as I’ve started programming, I’ve always felt a sense of imposter syndrome. That’s not new, and as I began interacting with more people and reading more developer blogs, I came to realize that everyone experiences imposter syndrome to some extent, from CS PhD students, to distinguished architects who have spent decades in the software industry. For me, imposter syndrome felt like it prevented me from learning what I wanted to learn, and building what I wanted to build. It made me fearful of asking questions, because asking questions meant I didn’t know the answer, and had failed in my attempts at trying to find it. Sometimes, my imposter syndrome would consume an entire day of development. Instead of asking my question, I’d peruse forums and documentation, faulting myself for not knowing how to solve a seemingly trivial problem. I was constantly comparing myself to other engineers, impressed with just about everything they did, while minimizing my own accomplishments, and did not sleep through several nights, anxious of being found out that I, in fact, could not build anything worthy of shipping. In fact, when I won a hackathon for the “Most Shippable” feature category, I chalked it up to being on a team with 3 other incredible engineers, and still mostly believe that they contributed more than I did to that project. When my manager gave me my annual performance review, I was mentally prepared for a demotion, or to be let go; when I was given a raise in salary and equity, I felt stressed instead of excited, because I felt like I’d have to bullshit twice as hard to keep up a convincing image of myself as competent. Imposter syndrome is not a self-pitying experience. I deeply believed I was incompetent at programming because I was not intelligent enough. Such are the effects of an inaccurate and unfounded assumption that engineering is a discipline that operates as a pure meritocracy.
I’m not immune to imposter syndrome today, but compared to how much imposter syndrome used to affect me, it’s much more manageable. Documenting overwhelming experiences brings me back to a place where I can better empathize with people who do feel that way. Now that I know the answer to many of the issues I encountered at the start of my journey, I also catch myself slipping into a mindset of thinking certain tasks are simple, forgetting my own struggle to understand the fundamentals as recently as a few years ago. The most important thing I learned brought about significant shifts in the way I dealt with my own imposter syndrome:
Learning How to Ask Thoughtful Questions
This is the single most impactful thing I learned to do, that helped me feel more at ease with imposter syndrome and its effects on me. I was lucky to have a mentor who gave me a good set of guidelines to asking thoughtful questions to other engineers, that I still use to this day when I’ve failed to find an answer on my own:
- Peruse related documentation and parts of the codebase. This one seems obvious, but it’s embedded in the assumption that agreements and truths are also well-documented somewhere others can reference, and in language they can understand. A friend of mine once told me he believed that it’s the authoring engineer’s responsibility to make sure their code and docs are understandable. If they aren’t, you should feel totally okay seeking clarification about anything unclear or ambiguous. I give myself a 30-minute time limit to hunt through docs, code, and Google before asking any questions, just to make sure the obvious places have been searched.
- If the answer hasn’t been found, or is unclear, it’s time to ask clarifying questions. I ask my questions to a team Slack or specific channel for that tool / technology, because if I’m wondering about this, it’s likely others have, or will in the future. Asking questions in public forums, daunting as it may seem, benefits many people besides yourself. I almost always ask my questions in the form of: “I’m trying to accomplish
x. I’ve looked at the README, the docs, and wiki page y. I expect output z, but I’m getting this error when run this series of commands instead”, followed by any relevant code snippets and error logging. The more detailed you can be, the better. As someone who has been the asker and answerer of questions now, I can confidently say that an answer is found much more quickly if more details are provided.
About 90% of the time, someone will respond with some thoughtful clarifying questions (e.g. what version of Postgres are you running?) and we figure out the issue. Sometimes, we identify it’s a bug, or that something was missing from the documentation. Either way, this approach demonstrates 3 things:
- You made an effort to solve the problem on your own first.
- You communicate about problems and the attempted solutions clearly.
- You share your findings about solutions with others who may be impacted.
Edit 5/14/20:
It’d be misleading and inaccurate to say that I made progress on coping with imposter syndrome by myself, but I wanted to emphasize learning how to ask thoughtful questions because it’s the one that most people can do without relying on factors outside of their control, which makes it the most empowering and beneficial. Here are two other factors that had major impact on my ability to overcome imposter syndrome:
A Psychologically Safe Culture
I hesitated about including this, because the word “psychological safety” has been thrown around so often in the tech industry that I feel like it’s turned into more of a buzzword than something people can actually understand, so I’ll do my best to start with my own definition of it. To me, psychological safety means feeling like I will not be rebuked in any way for being honest. In the context of asking questions, rebukes can take many implicit forms; anything from thinking of the asker as less competent, to outright patronization of their abilities in front of others. The reason psychological safety is important when it comes to imposter syndrome, is because the very definition of imposter syndrome includes psychological danger: a fear of being seen or treated as incompetent.
I got extremely lucky at work, and with my teammates. People say I totally drink the kool-aid for my team at work, but I’ve held enough jobs, in enough roles, to realize that the team I got to work on was anomalous in its emphasis on balance, culture, and openness. At the time, I was the only junior engineer on a team of senior and principal engineers, and each one of them demonstrated infinite encouragement and patience towards me when I couldn’t figure something out. Small reassurances like “Don’t worry, this is hard stuff!”, “I don’t know”, or “It happens,” when a particularly silly mistake was discovered (like the time I wondered why a commented-out variable was returning undefined, oops) added up over time and reminded me that no single engineer will have the answers to everything. So often, I tend to place those I admire on pedestals, and internalizing the fact that brilliant engineers are fallible humans also helped me trust in my own capabilities a little more.
It’s really unfortunate that this type of culture seems to be a rarity amongst engineering teams, and I have a lot to say about how lack of it also disproportionately affects underrepresented groups, who already struggle more with combating imposter syndrome’s effects. But the good thing is that, if you’re an engineer who is more senior, little gestures like the examples I mentioned above are simple ways to reinforce psychological safety within your team.
Mentors at Work
The last thing I’ll mention that was hugely beneficial for my programming confidence are my mentors. For as long as I can remember, major changes in my career have always been driven by the confidence a trusted mentor has given me, including deciding to become an engineer. I have 2 mentors at work, and if nothing else, my mentors provide me with a psychologically safe outlet to express concerns, run ideas by them, or ask for feedback in a focused way. Even though my manager and I have a great relationship at work, talking to someone who doesn’t influence my salary and career development can take away the pressure I feel with admitting shortcomings or fear. I run things I feel unsure about by my mentors, such as “What do you think of the way I worded this concern?”, to “Do you think my understanding of this problem is correct?”, to “Can you review this MR or this design document?”
Everyone’s relationship with their mentor is different, but I personally rely on mine to be my sounding boards and advisors when it comes to career development or learning a new skill. I don’t have recurring meetings with my mentors; the relationship is casual, and I message or meet with them when I have a specific topic in mind. It’s also important to remember that they, like everyone else, don’t have the answers to everything. One of my mentors shared with me that he experiences imposter syndrome at least 3 times a week! The dynamic I have with them is slightly more involved than I have with peers, in the sense that they embody skills or abilities I’d like to have in a few years. Getting their perspective on what they would do in a particular situation I’m facing helps provide me with a starting point.
Imposter syndrome is something I know I’ll never fully conquer, and if I’m totally honest, I’m not sure I want to. While it can feel discouraging at times, recognizing that I have room to grow holds myself accountable for making those improvements, and aspiring to higher standards for myself is the kind of mindset I want to embody now, and in the future. Realizing that I was fortunate to have resources at my disposal was great, but realizing that I can accomplish most of the work to turn it into a positive behavior reinforcement was even better.
