Time for another of those pieces that upon reading the subject, I had something to say.
This month’s topic comes from Jon Shaulis (b|g). Impostor syndrome is hard to bypass no matter your level of skill. I’ve been mindful of impostor syndrome as I have become more experienced and found myself in senior roles. I dealt with it unwittingly early in my career when I first got out of college. I currently deal with it as I’ve gradually waded into the speaker circuit and put a renewed focus on the blog.
The number of instances with impostor syndrome is countless; I am not sure the ranking of bouts versus others in the community, and there’s no real database to quantify this among people in the SQL Community, and tech in general. Naming all these moments would be difficult. For my take on the topic, I’m going to focus on two specific instances in my career as examples, at different points in life.
On the job when I started
My first permanent post-college gig was as an e-commerce analyst, where at least 40% of the job was glorified data entry. I got a chance to do some coding in SQL Server later into the gig (about one decade ago). Around this time, I learned that the two semesters of SQL coding or working with Access were only scratching the surface. Then I made it into a true data analyst job in 2011, after somehow showing the potential to do good things. I got to work with strong data analysts and developers, having moments where I fumbled around at first. One day, I had an SSIS package that I had taken responsibility for, but I had not accounted for a file name change, and was taking too many manual steps. It turns out a foreach loop was necessary, yet I was trying to force something that others in the company knew how to solve already. Having learned some SSIS basics, and being able to run those basic packages, but not knowing how to utilize the product in full, I was already an impostor, right?
Curing this bout: This is where I learned how important it was to learn stuff in my free time. I read up some more on not just foreach loop containers, but also all of SSIS to gain greater understanding of the product. I also finally checked out a fundamentals book by an author that I had not known of yet…and by the end of 2012, I discovered the existence of a group called TriPASS, and how it was part of a worldwide organization.
On the job today
Fast forward to 2019. I recently had the help of a fellow developer to tune a stored procedure to help with some timeout issues. We had stacked two CTE previously, and turned it into a temporary table. If I had to pick between temporary tables and table variables, my default preference has been table variables. I had asked him why this was a temporary table, and he had a great explanation, also demonstrated in the execution plan. He’s quite good at the performance aspect, and references the same SQL community resource that I will; it’s easy for me to take his explanations.
When I checked in my code for deployment, the DBA did ask about the temporary table use. I noted that my colleague had explained it well, but I could not repeat it. DBA approved it, yet also noted that as the lead, I should be able to explain the solution as well. Definitely an impostor moment, as “it depends” is a blanket term, but this was a specific instance.
Curing this bout: It was rather simple. I went back to the other developer to ask for a more thorough explanation, one which I could write down directly in the code. I then made a note about comparing execution plans. We can definitely learn from each other on the job, but we also need to see it in practice if we work with people outside of our teams or companies. Sort of like solving issues with #sqlhelp.
Sounds like I learned from each experience, so what does this mean?
I learned to embrace impostor syndrome by remembering that as long as we learn when we don’t know how to do something, we won’t be impostors anymore. We’re in an industry where it is important to keep learning, so we need to find what interests us, along with what we should know for our current roles or technologies we aspire to master. As it’s been mentioned multiple times over, we have to invest in ourselves in order to not be impostors. I’ve only started to figure out ways to be consistent with the investment and returns on it.
Tying the post back to this SQL Server community, and its major focus on sharing knowledge through writing and presentations, my realization was that I was afraid to speak because everyone knew more than me. If I tried to do the same, I would be exposed as someone who doesn’t belong. That could not be farther from the truth. If we teach others, we can have the confidence in what we are discussing, yet encourage the feedback from others in our blog posts or presentations. If there is a question I am unsure of, I have traded business cards and attempted to figure it out afterwards. Sometimes running through a talk at a user group can allow for someone with a good deal of knowledge to provide constructive feedback, and that person will not consider me an impostor just because I didn’t get more advanced or approached the topic differently.
Even those we look up to as “experts” have their moments of self-doubt, as not everyone arrives at the same solution. A novice in a particular area, or even someone with experience who was ignorant to a new way of solving a problem, is not an impostor, especially if the person stays humble and keeps learning.
Impostor syndrome can come at me; I’ll conquer it with competency.