5 lessons for entry-level software engineers

It all started with a one-line change. (No, literally.) On my first day as a software engineer at Red Canary, I was directed to put in a fix so tiny it was chuckle-worthy. I probably hit fewer than 10 keystrokes in that first pull request (PR), and upon merging, my manager —along with my entire team—promptly sent GIFs, memes, and celebrations, centered around my “first PR party”! The immediate support for such a small victory inflated me like a balloon, and taught me my first lesson: A good engineering team supports you no matter what the change is, regardless of size.

Archival footage of my first PR party 

I started with Red Canary as a software engineer in September 2021 as I was finishing my Masters in Computer Science at Brandeis University, landing my first non-internship role in my dream industry. I knew I had a lot of lessons to learn, but I could never have predicted how much my professional growth would be fueled by the brilliant people I’ve had the pleasure to work with at Red Canary.

Learning is a lifelong pursuit

As the months passed, my confidence increased along the way. In those early days, I sometimes felt as though I were blindly feeling my way forward through a crowded room of knowledge. Working with engineers who had 10+ years in the industry under their belts was both wonderful and, at times, intimidating. Two of my coworkers in particular are to thank for guiding me through this steep learning curve. Throughout pairing sessions that lasted for hours, random deep dives in our vast engine, and the ever-growing mountain of questions I had, they were encouraging, confident leaders. Around these women I did my best to make my mind a sponge to soak up the ocean of expertise they had. They both taught me my next monumental lesson: whether you’ve been in the industry for 10 years or 10 days, a good software engineer is always hungry to learn more.

Whether you’ve been in the industry for 10 years or 10 days, a good software engineer is always hungry to learn more.

Dip your toes in new waters

By month three, I was assigned a large-scale infrastructure project for which I had no prior experience. Thanks to the supportive environment created by my team, I was ready to give it a shot. All the more to learn, right?

Well, I couldn’t have guessed just how much learning this project would require, as it involved moving key components in our engine from our old cluster to our new EKS cluster (for the whole story, read our blog on What to do when you outgrow your Kubernetes cluster). I leaned on another engineer with a wealth of knowledge on the infrastructure team, and she was kind enough to steer my way through the dark forest it all was to me: Kubernetes, Helm, and Terraform. I learned my next lesson through the struggle of this project: doing something completely different from your prior experience isn’t scary, it’s exciting. Working with other teams only makes you a better, more well-rounded engineer.

Doing something completely different from your prior experience isn’t scary, it’s exciting.

Research builds confidence

As I was nearing my first year anniversary at Red Canary, I knew something big was looming on the horizon: 24/7 on-call shifts. Cybersecurity never truly sleeps, right? All I could think about was: with my luck, the worst issue Red Canary had ever seen would happen in the middle of the night when I was on my own. To prevent my nervousness from bubbling over, I spent whatever time I could spare pouring over past incidents, technical diagrams, documentation across teams—anything that I thought might fill my head with relevant information. I familiarized myself with all the tools available to me: Splunk for logs, Sentry for errors, Lens for Kubernetes, Grafana for a window into the engine, the read/write console for hotfixes.

Outside of the technical exploration, though, the most work I did before my first shift was on my confidence. Leaning on my fellow engineers (and now, friends), I did my best to banish imposter syndrome thoughts and puff up my professional self-image. But the best advice came from one of the staff developers on my team, someone who I admired professionally more than anyone. He was on call the week before mine, knew my trepidation, and pinged me something along the lines of, “Don’t feel bad if you don’t know how to fix everything. I don’t know the answer sometimes either. We get to learn everyday, and if you can’t fix something alone, your team is here to help.”

It’s okay to not have all the answers.

These words, coming from an engineer who always seemed to know what to do, were exactly the type of fuel I needed. The shift came and went, with just a couple late-night wakeups, and both Red Canary and myself ended up just fine. Wise words, supportive teammates, and having to fix stuff on the spot taught me yet another lesson: that it’s okay to not have all the answers. Taking a deep breath, and using the tools and documentation available to you, is a great start to fix an urgent problem.

You don’t have to do it alone

My next big step forward came shortly after my on-call shifts started. I was given the opportunity to be a tech lead on my own project for the first time. It’s not often that individual contributors are responsible for a project from start to finish. As I would learn, projects like these force you to confront gaps in your knowledge as an engineer. I was tasked with building out new functionality for our alerts engine, which required the fullest full stack work I had tackled yet.

The beginning of the project started with an engineering plan, wherein developers and architects of monumental insight and experience thoroughly reviewed my step-by-step planned approach. Where I thought my plan was foolproof, with everything accounted for, they found yet more details that needed handling, and asked questions that forced me to become an outright expert on what I intended to do. If I were a less confident, unsure engineer, the intensity of the first chapter of my project might’ve drained my positive mindset; instead, it reassured me. Yet another lesson learned: even as tech lead on a project, your work is never completely isolated. I had people in my corner, double-checking the specifics, and though the work was distinctly mine, I was not the only one to thank for the results.

Even as tech lead on a project, your work is never completely isolated.

Along the long, winding path of this epic, I drew on my previous experience with infrastructure (which I was now very grateful for), and I also learned a lot more about the entire data pipeline. My work spanned from terraforming new AWS buckets to UI features in Rails partials, and despite ups, downs, and plenty of bugs, I’ve never completed something so rewarding.

The road ahead is long, and that’s a good thing

My journey here at Red Canary started with one line change. At the beginning, I was a fresh little engineer whose college degree was still warm from the printing press. It seemed as though every question I asked had a follow-up question. Through my struggles, victories, pain points, and pride, I now look back on that engineer and barely recognize her. The lessons learned and taught here by some of the best and kindest technical people in the business have shaped me into someone more confident and more knowledgeable, who takes joy in learning day to day.

My horse trainer (I could fill a whole other blog post with the cool hobbies we engineers get up to) says, “You can’t build a good horse quick. You build her over years, with hard work everyday.” Take it from a now not-so-new engineer: the same is true for us. The support, understanding, and expertise passed down to less experienced engineers is invaluable, and leads us down successful, fulfilling professional paths.