Introduction

I remember my first year as a software engineer back in 2016. I was working for a digital marketing agency and thought I was ready to take on the world. I had just graduated, I had several freelance projects in my portfolio and had a decent GPA. I was pretty sure I knew everything I needed to be a decent software engineer. Boy, was I wrong.

As you’ll soon come to find out, not everything is writing code and drinking coffee. The purpose of this article is not to scare you, but rather let you know about certain things nobody tells you during your first year as a software engineer.

Whether you’re a fresh-faced intern or a seasoned veteran in Software Engineering, I hope you can find some value in this article.

Nobody Cares About Your Grades

So, you turned in every assignment, you ace’d every test and you were the the teacher’s pet in every class at college. Guess what? Nobody cares.

While some companies may take your GPA into consideration (if it’s good enough), your grades will rarely be a deciding factor during the hiring process. They don’t care if you were able to retain information for 6 hours before a big test or if you had a lot of time to do homework and were able to turn in every assignment with an A+ grade.

What they do care about is how you think. How do you solve problems? What do you do when you get stuck? Do you understand the requirements for the job? Have you done something like this before? How do you approach learning a new skill? These are the type of things that matter. Outside of school, it’s all about what you know and what you can do.

It’s more important that you actually understand how to use Data Structures and Algorithms rather than just memorizing the time and space complexity of your favorite data structures. If you’re a student and are reading this article, don’t worry so much about your grades. Worry about actually understanding the material that is being presented to you.

If I knew this before I graduated, it would have saved me A LOT of stress.

You Will Get Rejected

So, you just graduated and you’re sending your resume to every big tech company you can find. You already have a few interviews lined up with Google and Facebook, or whatever tech company is trending at the time that you read this article. You’ve studied up on Data Structures and Algorithms and are totally ready to wow the engineer during the technical interview.

If you did get an offer, congratulations. You deserve it.

But guess what? Chances are you’re not going to get the job offer. And that’s okay. This could be because you don’t have enough experience/knowledge for that position. Or it might be due to a circumstance completely unrelated to you.

You should be comfortable with being rejected. Most companies will allow you to apply again after about a year (unless you did something horribly unforgiveable, like yelling at your interviewer). This is the perfect time to evaluate yourself and continue sharpening your skills.

This isn’t meant to discourage and you should continue applying for the jobs you want. The failed interview is a learning opportunity. While you (most likely) won’t get explicit feedback from the engineer on what you did right and what you did wrong, you should take the time to understand where you felt uncomfortable, what gaps you found in your knowledge during the process and what you can do to improve.

Introspection is the catalist of improvement. Not only in software engineering, but in life.

You Will Make Mistakes

Senior devs, junior devs, frontend devs, backend devs. We all have one thing in common. We’re human and humans make mistakes.

That Sr. Software Engineer on your team that seems to know everything? Probably brought down the production server more than once. That Database Admin you respect so much? He’s probably deleted critical data at one point of his career.

In my first year as a developer, I accidentally introduced a bug into our code that ended up giving away 500+ Samsung A5 smartphones for free. I just made our small agency lose about $200,000 USD. My heart sunk while I thought about searching LinkedIn for a new job.

We quickly rolled back the code and apologized for the inconvenience. Our client was furious, my colleagues poked fun at me and my friends still bring it up at parties. But I was never fired. I was barely reprimanded.

During your junior tenure, you will most likely be very worried about making a mistake that will bring down the production environment or cause some sort of damage to the platform. As you should.

However, on a long enough timeline of writings lines and lines of code, countless deployments to production and rushed database queries, you’re going to make a mistake sooner or later..and that’s okay. The important thing is that you recognize your mistake, look for a solution rather than someone to blame and come up with a way to avoid it from happening again.

In my case, I learned the importance of writing unit tests for my code.

Burnout Is a Real Thing

Burnout is a funny thing. You never realize you’re burning out until you hit rock-bottom. This is caused by excessive and prolonged stress. Overworking, not taking breaks or spending every minute of every hour looking up the latest framework that is popular that week and trying to master it out of fear of being irrelevant in this industry.

Next thing you know you’re sleeping 2 hours a day and working weekends. You start waking up irritable, work meetings become arguments and you hate being alive. You’re wondering why you ever chose to be a software developer in the first place. Maybe your uncle will still give you a job helping him sell time shares.

This is what burnout feels like. And you’re never too young to experience it. Some people may have a larger threshold for stress, but they too will succumb to it once they reach that limit. We are not robots.

You should take breaks from coding every now and then. Explore other interests completely unrelated to programming,make sure you get enough sleep, make time for friends, family or simply activities you enjoy doing.

Having a healthy work-life balance is important and will make a huge difference in how much and how fast you progress as a software engineer.

You Weren’t Hired to Write Code. You Were Hired to Solve Problems.

I used to hate the “business” side of things at work. Working out time frames for releases, explaining to product designers that the new feature that they’re requesting is not possible or simply having to update managers with daily e-mails in regards to progress.

Well, for better or for worse, this is all part of the job description. You’re not just some code monkey that translates instructions into code. You’re an engineer that has to build solutions that solve problems. And building these solutions requires more work than just sitting in front of a text editor for 8 hours (although, you’ll probably do just that on some days).

As a software engineer, your job is not to write code in a specific language. Your job is to fix the problem with the tools you have at your disposal. Your client most likely does not care if you used Flask instead of Django, if you’re using the latest version of Angular to write your code or if you used spaces instead of tabs. They just care that the task gets done.

Don’t Specialize (Yet)

I remember when I was looking at job postings. Do I wanna be Java Developer or a .NET Developer? Should I do front-end development or back-end development? I was hired as a “.NET Developer” for my first software engineering job. I would get angry when my job required working with Javascript, managing databases or helping out another team that has an entirely different tech stack.

While you’re main activities will most likely be in a specific tech stack, you should not be afraid to venture into using new programming languages or tools. I started out hating Javascript. Now, I love it. Hell, this website was built using Gatsby.js.

You will soon learn that programming languages and frameworks are just tools. Not only that, but you will come to realize that you can pretty much do anything in any programming language. For the most part, they all have similar features.

Have you ever met a plumber that ONLY works with a hammer? Didn’t think so. The same applies to software engineering.

When you specialize in a single tool when starting out, you limit the tools at your disposal. That doesn’t mean you shouldn’t become really good at Java or a specific framework of choice, but that should not be your first priority. Once you have explored various tools, you can choose one the ones that makes sense to specialize in. But for now, play around with different things and figure out which tools work for which problems and which tools you prefer to work with.

Do not limit your toolbox.

Sometimes, “Good Enough” is Better Than “Perfect”

If you’re passionate about writing code, you’re probably a lot like me. You weigh every little detail and want to make sure everything runs as fast and smooth as it possibly can. Often, this means falling deep into the rabbit hole of investigating different technologies, investigating best practices and comparing all possible approaches against each other.

While this is often a good way to go about your craft, real life projects have deadlines and, sometimes, the best way to get some momentum going during development is by acheiving an MVP, or a Minimum Viable Product. You should attempt to build an MVP to get the ball rolling and come back in further iterations to add more functionality and optimize performance.

As Winston Churchill once said, perfection is the enemy of progress.

You Will Never Know Everything

You probably don’t know as much as you think you do…and that’s OK.

Software engineering is an always-changing, never-stagnant field. There are countless languages, tools, specializations and methodologies that currently exist that you most likely will never get to learn at a deep enough level to consider yourself a master in it.

Not only that, but the one’s you do know are constantly changing. The techniques we use today may be obsolete before lunch tomorrow. That’s why software products are usually built by teams, not individuals. The knowledge requirements for a product are usually covered by multiple engineers, each one with bits of knowledge that they can contribute to collaborate and teach the other engineers on their team.

Always keep an open and receptive mind when somebody else tries to teach you something, even if the other person is less experienced. You’d be surprised at some key details or techniques that you might pick up. I was oblivious to the fact that we could use the Alt+Shift+Tab shortcut to shift back to a previous tab until a Jr. Developer pointed it out to me.

Communication Is Important

In my experience, software engineering attracts a lot of quiet and/or introverted people. I think it has something to do with the fact that you can just zone out with a text editor and a terminal and come back 6 hours later with a finished product (albeit, not a great one), no human interaction required.

However, teamwork is more often than not the main difference between a nice, personal side project and a great, usable software product. Unless you are a one-man, all-dancing, all-singing software development team (in which case, I pity your soul), you are most likely working with a team.

This is why communication skills are almost as important as technical skills when it comes to being a software engineer. You should be able to communicate abstract ideas and concepts to both low-level engineers and high-level, “non-techie”, business associates.

If you can’t explain a concept in a way that even a layman can understand it, then you don’t understand that concept well enough.

Conclusion

These are some of the things that I believe would have been helpful to find out earlier in my career rather than later. While these things may seem more obvious to experienced engineers, they don’t seem too obvious when you’re first starting out. I hope this information provides some insight and is helpful to your software development journey.