---
date: "2023-09-06"
title: "On imposter syndrome"
description: "I had imposter syndrome when I entered the tech industry and I still have it years later. I imagine most folks have it to one degree or another."
draft: false
tags:
  - Development
---
I had imposter syndrome when I entered the tech industry and I still have it years later. I imagine most folks have it to one degree or another.<!-- excerpt -->

I went to school for business and economics, fell backwards into a job working on a local newspaper website without interviewing and have basically hop scotched to where I am now. On any given day I'd probably tell you I still don't know exactly what I'm doing (I'm not sure anyone does — absolutes are tricky though).

The first JavaScript I wrote was because I wanted to theme [Bowtie](http://bowtieapp.com/) and [Ecoute](https://en.wikipedia.org/wiki/Ecoute) controllers[^1]. Then I graduated to working on sites of bands I know for free and/or merch[^2]. I stumbled around in PHP, JavaScript and some basic server administration to keep things online. I wrote a single HTML/CSS/JS page on that newspaper's website to complement their lagging text editor, autocomplete search and simplify navigation around their archaic CMS[^3].

My first proper dev job was at a startup wrangling a custom Python e-commerce site into a mobile friendly layout. We had a production incident my first month there when another dev (I swear, it wasn't me) started a production deployment, walked out the door and had let his phone die. I quickly learned the ins and outs of `git revert`[^4] while our designer hopped in her car to try and find him in traffic. That same developer also stressed that I should always learn the language because frameworks will come and go. Everyone has their days and that advice has proven invaluable.

I could go on, but over the years, I've learned a few important things:

- Don't be afraid to admit when you don't know something.
- Don't dig on a problem when you're stuck — get up and take a break or ask for help. Do both. Someone else on your team has probably seen the issue before or the answer will come to you by the time you get back to it.
- *If* there's documentation, read it. If you still don't have an answer, whatever you took away from it should help frame the discussion when you ask for help.
- Everyone on your team quite likely has different backgrounds and took different paths there — everyone will excel at something. Leveraging those overlapping and interlocking skillsets and expertise is what makes good teams great.
  - Comparing your work with someone else's is never 1:1. Maybe it's different — it could be better than the approach you took. Learn from that — you'll likely be on the opposite side of the same situation soon enough.
- The best way to be sure you understand something is by teaching it effectively to someone else.
- Share what you know — mentor juniors and folks coming into the industry. Someone else probably did the same for you along the way.
- If you're wrong about something, cool. Learn from it and do it better next time.

Today, I don't know what I'm doing. Maybe tomorrow[^5].

[^1]: macthemes.net was **the best**.
[^2]: The lack of any meaningful stakes were *great* at the time since the consequences of breaking things were similarly low.
[^3]: Then they used it to train my replacement — it's long gone now though.
[^4]: Our "CI" was a Jenkins job that ran `git pull` and restarted the appropriate processes.
[^5]: I can feel that baseline hum of anxiety while I think about posting this.
