Many things can be reliably said about almost all web developers:
- They’re willing to fight it out over what tools, conventions, and frameworks are best.
- They’re never 100% satisfied with what they name something.
- They have stickers on their laptops.
- They drink lots of coffee (I’m an exception to this one).
But of all the blanket statements/annoying stereotypes, the worst will always be:
- They’ve dealt with Impostor Syndrome.
Impostor Syndrome is Prevalent in Web Development
Impostor Syndrome (IS) is a feeling of not being able to accept or internalize one’s successes. Basically, one isn’t confident in themselves, feels like a fraud, and is afraid of being exposed. It’s not exclusive to web development, but it’s extremely common in it. Go ahead and search “impostor syndrome web dev” online and just see how many results pop up. Popular and respected devs deal with it. Virtually everyone in my front-end Slack channel has talked about struggling with it. Now as the only junior dev in a company full of much more experienced ones, it’s certainly hit me hard these last few months. Left unchecked it can make one’s life extremely stressful, which hurts their health and their career in the long run.
It’s not surprising IS is such a problem for devs. It’s an industry built on knowledge, full of people who will always know more than another. No matter how much someone learns there’s always more, so it’s hard any progress was made.
This drag on for weeks, months, years, for one’s whole career. It will hit hard. It will sting. It’ll be hard to get back up. And once they do it’ll happen again. And again. And again.
What Defines a Developer?
Overtime I’ve found my own solution to IS. It’s rooted deeply in what devs do everyday and how we view ourselves, so I adjusted my definition of a web developer. I define my career less around how much I know in total, and more around how much I learn each day. This is something I can control over regardless of the dev landscape, or how much smarter other devs are. It makes me a better dev and helps me feel accomplished. So far it’s worked great, even as the only junior dev at my current company.
Devs should measure themselves more by how much they learn, not how much they know.
I break down this “learn fast and often” mindset into four specific habits:
1) Focus more on fundamentals than specifics
Regardless of what tool is hot or been overused by a company, 95% of the time the principles behind it will be the same as others. For example, most frameworks in many languages use the MVC model, so knowing that will cover the basics of how most work right away. Syntaxes can easily be looked up or searched. The principles and fundamentals are what smart devs remember and emphasize instead.
2) Learn at least one thing a day, even if it’s small
This is less about building a obscure knowledge toolbox and more about being able to absorb new things fast -that’s much more valuable. Even if it’s just skimming new info on something different, it should be a habit. This week my focuses are Vim and Git on the command line. Even if it’s just a few new tricks or basics, I spend an hour a day looking them over.
3) Ask questions, even if they’re silly
No question is stupid in the sincere pursuit of new knowledge. Even if it is, it’s better (and cheaper) to ask a stupid question now than to make a stupid mistake later. Lately I’ve been asking “stupid” questions, but they paved the way to do more useful work while relying less on co-workers.
4) Experiment, even in small ways
A dev doesn’t need to make a groundbreaking app with every new tool or language they learn. It’s more important to get just comfortable enough with something. That way if a serious project comes up, it’s easy to dive right in. Set up the basics, know the problem areas, and make a scalable starting point. One only needs to play with something for a short time to get that far. Save it as a skeleton and then see if there’s something else you want to try. It’ll be waiting when you need it later.
Redefining what a Dev Does
All the above has helped keep IS almost completely out of my mind for weeks. When I see devs making advanced apps, writing about topics over my head, or making great stuff with shiny new tools, I keep these four habits in mind. I remember that for me, a dev isn’t defined by the amount they learned, but instead how they learned it. That tightness in my chest and biting in my skull quiet down.
As long as I keep my learning fast and flexible, those knowledge gaps will never get to me. As far behind as I may get, I’m still in the same race. I won’t be leaving anytime soon. I’ll only get faster.