Clarity is the benefit of hindsight and when I reflect on my career so far I think of all the things I wish I had done earlier/differently when I first began writing code for money.

I’ve spoken with a LOT of junior developers in the last few years through LinkedIn, mentorship programs, bootcamps where I’ve taught and companies where I’ve worked. Many of the same issues that I thought were unique to me as a beginner in the software industry seem to be incredibly common.

This epiphany would have comforted me a bit more during those first 2–3 years where I wrestled with impostor syndrome and the ever present fear that I would be outed as a fraud at each company I went to. …

Our dev team recently became responsible for building micro front-ends using React for e-commerce sites. After building our second site, we noticed there was a lot of duplication among our redux actions and how they handle common backend interactions. For example, a user adding an item to a cart or logging in is the exact same across applications.

Inevitably, we discovered a bug affecting an action with carts and ended up applying a fix to reducers on both sites… while it’s trivial to copy and paste a fix across two sites, we could only imagine having this problem span dozens. What about refactors? This was not sustainable. …

So you survived your first day on the job. First week. First month… now what? At the end of my first 4 weeks as a software developer I felt useless at best and like I might get fired at worst. Here I was making more money than I ever had while barely contributing to a codebase that I did not understand and pestering my co-workers about the processes for deploying, reviewing and creating code on a daily basis. Maybe I’m not cut out for this I thought.

Did my co-workers resent me for all my questions? Was the boss waiting to fire me? Why did they even hire me? I was filled with self-doubt for the better part of my first year and as my end of year review approached I increasingly felt like I might get ripped apart and resigned myself to the fact that my review would probably be pretty critical. Did I mention I’m a but neurotic? …

There seem to be two camps of people in the software engineering world: those who live and die by LeetCode and those that write it off as a kind of a parlor trick or an exercise in memorization.

“I’ll never use this in real life!” they protest! Meanwhile, every FAANG company and many others, will test you on problems that are similar to LeetCode or ripped directly from their site (I’m looking at you Facebook).

I approach LeetCode like exercising: 30mins — 1hr a day will keep you in good shape, while 4 hours or more is really only helpful if you plan on being a body builder or in this case, a competitive LeetCoder. …

You know you’re supposed to be writing tests. You know this. If you’re a developer using React on the front end and using CRA to bootstrap your application then your app ships with testing-library, React’s suggested testing framework. Now, all you have to do is write some tests!

If you are completely new to writing tests, any testing framework can be daunting. It can seem like you’re about to double your efforts for each feature you want to ship and now you have the additional cognitive load of understanding the nuances of a testing framework. The testing-library docs leave a lot to be desired in my opinion. …

Software is rarely written in a silo. Whether you’re building the next social media app for mimes at some SF startup or maintaining a legacy system for a faceless company in Idaho, you are almost certainly working on a team. But working on a team and being a team are different things. It’s entirely possible to have a team of individuals, basically rogue coding their way through tickets, cohesiveness be damned.

But, Why Does It Matter?

There are two developers, Abe and Lenora (John and Sally were out that day), working with some data from an API that requires formatting dates to display on a graph. …

Our team lead sent me a slack one afternoon after a particularly rough epic release. Nothing had gone according to plan and we were all thoroughly chewed out during the demo of these new features. I actually had nothing to do with this particular epic, save for a simple code review. This was a problem.

“Hey, I noticed you reviewed this story for the epic” the team lead wrote. Ruh roh. …

I had been a software engineer at my last company for about a month when my manager let me know I’d be going on-call during the next rotation. “Cool” I replied. Not cool.

I installed PagerDuty, a popular app that is as necessary as it is hated, to alert me when any critical ticket was created. I had casually been keeping tabs on the kinds of bugs that were deemed critical to see what I could expect during my shift. Basically, anything that prevented our customers from normal usage of any one of our many applications would trigger an alert. Button to export a CSV is broken? Critical ticket. API returning 500’s on a Saturday at 2 a.m.? …