6 Things I wish I Knew at My First Software Engineering Job

I got my first job during my second year of University. I was woefully unprepared for my career as a developer. All I knew at that point was basic data structures and how to copy-paste code from tutorials I read online. I was shocked that someone would pay me to write code.

Besides my inexperience with coding, I had no idea what life as a full-time developer actually meant. I knew I’d be writing code and building products, but I had no idea what else a career in tech meant. I wish someone had given me a handbook — “Software Development 101”.

There probably is a book, but I’d have been too lazy to read it. If I were to write a condensed version of that book to my past self, it’d cover the following topics.

What to talk about during 1 on 1s

About two weeks into my first job, I got a calendar invite for a 1 on 1 with my manager. I had no idea what a 1 on 1 was.

At our first meeting, my manager explained that this would be a recurring event. During this time, I could voice any concerns about my job, and we would make plans for my career growth. “Ok, makes sense,” I said.

For the next several 1 on 1s, I had nothing to talk about. My manager asked several questions, but I answered most of them with, “Nothing on my mind right now, but I’ll let you know if I think of anything.”

I didn’t think of anything for several 1 on 1s in a row, mostly because I was always trying to think of things to talk about on the spot.

After a couple of months, I knew I needed to be better prepared for 1 on 1s. So, I started a doc where I wrote anything that came up regarding my work.

• Poor developer experience issues
• I learnt something new
• Areas of the codebase I wish I knew better
• Limitations of our team’s processes
• Noteworthy interactions I had with any coworkers

I took notes on all of the above and more.

This meant that I always had something to talk about during my 1 on 1s. I would prioritize whatever was most on top of my mind. Over time we also worked together to create a career development plan. We used this to check-in periodically to ensure the work I was doing was aligned with my goals.

1 on 1s can be a weird experience when you first start working. I wish I had had a better idea of what they were and what was expected from my manager and me when I first started working.

Don’t be like me. Observe, take notes, think about your goals, and you’ll have lots of content to talk about during your first few one on ones.

Five years into my career, I never run out of things to talk about anymore. These days I heavily prioritize what I bring up. Otherwise, we would run out of time.

The importance of communication

If you look at interviewing rubrics for tech companies, I guarantee that they will all have a section for how well candidates communicate. There’s a good reason for that.

Individuals don’t write code; teams do. This means discussing different approaches, writing code reviews, talking with designers and PMs about tradeoffs, and all kinds of written and verbal communication. All of which I was completely unprepared for.

At school, I was primarily used to writing code on my own. I had thought that a coding job would involve writing code and hacking away for 8 hours a day. This was debunked less than a week in at my first job.

It took me a while before I was fully comfortable with communicating and discussing technical details. In the beginning, I found myself at a loss for words when discussing technical issues with product managers and designers. I couldn’t find the right language to convey the obstacles I had run into. Over time I’ve gotten a lot better at this.

I wish I were better prepared for the type of communication that was expected of me. I still actively work on my communication, but I’ve come miles compared to where I started.

Don’t forget the big picture

As a new software developer, I was very focused on the coding aspect of the job. It’s easy to get lost in the code and lose sight of the business outcomes we are trying to address through software. This is especially true for interns and junior developers.

It’s easy to get sucked into Twitter and Github wars about using for of loops vs forEach. But at the end of the day, unless I’m working on tooling or a library, does it really matter? The real end goal of looping over the array is probably to show something to the user.

Don’t get me wrong. There are plenty of important technical discussions that need to happen. But it can be easy to miss the forest for the trees when we first start. Bikeshedding is all too common at tech companies, and even being aware of the concept can help focus on the bigger picture.

I’ve found talking to client-facing coworkers and learning about the company’s objectives to be a simple but effective way to bring meaning and perspective to my work.

Nowadays, when I start a new project or job, I prioritize understanding the end-user and the underlying problems we want to solve before I start coding.

Stay up to date

I’ve only been a web developer for five years, and already I’ve seen countless technologies, tools, frameworks and patterns rise and fall. When I talk to people that have been in the industry for decades, they can’t believe how much the field has changed since they began.

I’ve found that it pays to stay up to date with different trends in the industry. It has helped me bring a fresh perspective to my work and make sure that we don’t fall behind.

This doesn’t mean chasing every new trend and trying to use the latest technology. It’s more about keeping a pulse on the surrounding ecosystem to understand the key themes and problems people are facing and how languages and frameworks are evolving to address those issues.

Reading code is as important as writing it

I did most of the projects and assignments at University from scratch. I had how important reading and navigating code in an existing codebase was.

As a developer, we generally work in an existing codebase—repositories of code where patterns have been established, broken and re-established. One of the most important skills I’ve learnt over the years is how to dive into a never-before-seen codebase and find my way around it.

The only thing I can think of that would’ve helped me better on this front is contributing to open source projects.

Test, test and test again

Tests were my worst nightmare at my first job. They would fail—a lot. I’d panic and ask around for help. I had never written tests outside of school projects (which have very few tests btw).

One of the first major projects at my first job was to increase test coverage from 40% to 90%, which has had a lasting effect on how I approach testing everywhere I work now. Over time, I’ve become an advocate for 100% test coverage whenever possible.

I wish I’d known different testing methods and best practices around testing code. I didn’t even know test coverage was a concept when I first began working.

Learn how to debug early

Stack traces had scared me in University. I had no idea how to read them, and even seeing them meant I’d done something wrong. Early on at my first job, I was equally unprepared on how to debug common issues. I wasted hours googling errors instead of tracing to find the root cause(granted, sometimes errors were so non-sensical, google was the only way to go).

Once I understood how to read a stack trace and discovered debuggers and logs, it was smooth sailing. They’re tools that I learnt once and use everywhere and all the time.

These days, if a debugger is present in the codebases I work with, it’s my default choice. It makes finding and fixing issues exponentially easier.

I wish I had been better prepared to debug errors. University should’ve at least taught me how to read a stack trace :(

If I had a mentor when I started my first job, these are the things I’d have wanted them to tell me. It would have helped me be a more effective developer from the get-go, rather than having to learn these principles as I went.