My first job as a web developer was a disaster. Here’s the part I wasn’t responsible for: morning stand-up was 35 people. I lived in fear of accidentally hitting play on a Twitter video. Here’s the part I was responsible for: I never got the help I needed.
I spent two weeks trying to make a Dockerfile work. Or maybe it was an image on Docker Hub? Or was it… okay I still never learned how Docker works. Years later I saw a Reddit post from someone who felt stumped by Docker no matter how much documentation they read. I felt such sympathy for that developer, and grateful to the people who gave helpful suggestions about how to grow your skills. Years after that I found that the consensus on Docker was that Docker required a specialist to use successfully, even more so in production.
I had mentioned a few times at the interminable stand-ups that I was struggling to get the next step of my project done. Then I sat down at my desk, poked at the Docker documentation for a few minutes, got an error from the CLI, and spent the next few hours nervously clicking from documentation to Twitter, and job listing sites.
This went on for five months.
I’d like to mention here that I’m not a bad person.
How did I get in this situation? How did I let a bad situation go on so long? I think it takes some discussion about the reality of impostor syndrome. Two things about impostor syndrome are totally untrue:
- Feeling you’re not qualified to do a thing means you just stop working, quit, and maybe leave tech forever.
- Once you’re cured of impostor syndrome you can do anything! Who needs pilot lessons now that you believe in yourself.
I always felt when I was just trying to stay positive, but really I wasn’t giving accurate estimates of my status. Worse, I was just answering the wrong question, not "what do I need to do this project" but ‘‘when will this be done." For me, my greatest fear was admitting "I am not able to do this on my own." I convinced myself that everyone else had the skills they need from the day they started and didn’t request the training I needed.
This can end one of several ways, but it certainly doesn’t end with successful projects. To emphasize, this was an area where lack of confidence was a self-fulfilling prophecy.
I’ve written extensively about hackathons, less so about the ones where we struggled. Very often on a randomly assigned team I would shake my head as team members refused to participate. “I’m a writer not a photographer,” “I’m more of a backend developer,” these were all excuses that team members gave to not contribute. While I always found hackathons liberating (no more worrying about writing bad code! All the code written at hackathons is bad) I saw in others the problems that I’d dealt with in my working life: I was building a list of what I couldn’t do rather than asking what I could do.
When things are going well on a team you should be helping out any way you can: if a code improvement seems obvious ask why it can’t be done. If I couldn’t fix a problem I would write up my notes for a more experienced dev. If I couldn’t write code or even interpret it I would write tests. If I couldn’t do that I would write documentation. Doing all this often felt like a defeat, but it also got me a lot of thanks and appreciation from within the team. Later, when I was the one writing most of the code, I was incredibly grateful for team members who wrote test coverage and documented the app.
Years into my development career I still felt like I wasn’t a ‘real’ programmer. I didn’t have an exact definition for what made a real programmer (anxiety means constantly moving the goalposts), but one thing I could point to was that I had real trouble building and maintaining a web service. I’d done so much hard work! Learned *nix commands, figured out port configuration, the whole bit. When I wanted to build a Twitter bot, I would carefully configure a virtual machine on Amazon Web Services (an EC2 instance), set up a cron job to regularly have the bot check tweets and act appropriately, and work out the necessary storage configuration. All well and good but within a few weeks some part of the system would break down, and I’d start getting notes saying ‘hey your Twitter bot is down’ or ‘it doesn’t seem to be working right.’
My self-regard was largely saved by a few dozen photocopied sheets of paper, and a market-leading Platform as a Service tool.
Amy Wibow’s “How Do Calculators Even” teaches the basics of electronics to the point of constructing half-adders into circuits capable of performing math. Her “Literal Twitter Bot” solders microcontrollers into a tiny robot that gives a physical interface to Twitter. The explanations are clear and don’t expect any prior knowledge. Her tutorials used Heroku to regularly schedule a Twitter client to post new content, check replies, and follow back other accounts.
Hosting my web service on a Heroku container (dyno) felt significantly easier than the virtual machines I had used before. And I feel that it was impostor syndrome that kept me from using a tool that felt ‘easier’ than configuring a server by hand. What I ended up with was something that was much easier to start than a virtual machine, and also had no trouble handling much more traffic when one of my services suddenly got a traffic spike. This is one of the many times in my career that I learned that the easiest path was also the most practical.
Heroku remains one of my go-to tools when I want to easily move from hobbyist scale to production high-traffic, and admitting that I needed help to get confidence continues to be my most important skill.