A while back, I wrote a blog post about IDEs vs text editors. Ultimately, I was really writing about whether using an IDE made me less of a software developer. My conclusion was that while it definitely didn’t make me less of a software developer, there were things experienced software developers did that I wasn’t doing that were worth learning. So I’ve been trying to do what it takes to earn the right to call myself a “software developer.” I’ve learned a lot in the process: about shortcuts, vim and bash, but, mostly, about myself.
The Woman in the Mirror
For some time, I’ve been fighting my software developer Impostor Syndrome. It probably comes from many things:
- Being a woman: According to Wikipedia, “Some studies suggest that impostor syndrome is particularly common among high-achieving women.” It shouldn’t be like this, but sadly it is.
- Personality: Tenacious self-esteem issues.
- Career change: I moved from electronics to software two years ago and still have a hard time calling myself a software developer.
The first two factors will probably continue to be a struggle all of my life. But for that last one, I’m starting to see a light at the end of the tunnel.
The Perfectionist Within
When I wrote code for embedded microcontrollers, I was very confident in my programming skills. That, in itself, is interesting because I’m usually insecure about almost everything else. So what was different about the programming I do now?
After much soul-searching, I’ve discovered that I had no problem being asked to do something and showing the final product, but I am panicked thinking about showing the code to someone else. In software, there is a much higher chance someone will look at your code than there is in firmware. So, with my career shift, I lost a good deal of confidence. I know I can accomplish the tasks I’m assigned. There is no question in my mind about that. But I experience constant stress thinking that my solution might not be perfect. That it could have been done in a better way. And I’m afraid someone is going to look at my code, find that and judge me for it.
It doesn’t help that I work with super programmers. I sometimes question why the company would want to work with me if these people know a lot more than me and most probably will write better software. In my mind, their solution will be closer to the “perfect” solution.
And then there is another aspect of our roles as code whisperers: writing “technical” blog posts. Talk about scary! Again, what if it’s not perfect? What if someone finds errors?
I’m worried I’m not enough, I’m worried I’m not the best. But… If I’m not enough, why am I still working here? I’ve been with Corgibytes well over a year. I’ve been assigned top clients who ask for me specifically, time and again, because of my output and skills. So, maybe we are enough even though we are not “the best.”
What is “enough?” I think enough is being the best software developer we can be. And this is what it looks like for me:
- I’ll continue to, first and foremost, deliver what I’m asked for.
- I’ll write good code. Spending time in getting a beautiful, efficient, good performing solution, but not worrying about getting it perfect. It’s never going to be perfect, probably not even for the super programmers.
- I’ll continue to add value to my company and our clients through my good code. Yes, the super programmers’ code is better, but I have things to contribute too.
- I will focus on what strengths I bring. I’m probably better at some things than others in my company, as others are better than me in other things. But I will make sure to allow my superpowers to shine whenever possible.
The best developer is not what is most valuable to a company. What is most valuable is all of us that give our all and deliver our best code, our best communication, our best support. That is what makes each one on the team valuable and enough.
There probably isn’t even such a thing as the best software developer. For sure, some developers are better than others, but we all have something we are good at. We all can add value to the company.
Trying to be the best is emotionally exhausting and trying to write the perfect code is paralyzing. Instead, our efforts should go toward continuously improving, not to be the best, but to add more value every single day in whatever it is that we are good at. Big or small.