Over the past few months, I have finally been able to dip my toes into the world of software engineering. My first real tech job was as a software engineering intern at a cybersecurity company, called Tanium. The job lasted for 10 weeks during the summer. Following this, after about six weeks of job searching, I lucked out and got a full-time job as a Junior Software Engineer at a different company, called Applied Research Associates. I have been working there now for around a month.
Both work experiences have been inviting, if intimidating, learning experiences. I have learned a lot about what being a good software engineer looked like. I have also learned a lot about how far I am from being at that level just yet. Ultimately, I have learned how much is involved in the process of engineering, not only in terms of writing code, but also outside of that as well.
There are meetings, presentations, pitches, design conversations, slack messages, and emails. A good engineer needs to know how to ask the right questions at the appropriate times, how to find answers to questions you don’t know even how to ask yet, how to wade through ambiguity, and how to decipher murky assignments and unclear directions.
It’s these tasks, far more than the code, that make me realize that learning the ins and outs of any new industry is a long process. It’s easy to fall into the trap of imposter syndrome. During my entire internship, I felt completely out of my depth. I was confused most of the time, and didn’t understand much of the code I was looking at. More importantly, I didn’t understand the processes and techniques my co-workers relied upon. I didn’t have the industry knowledge to gauge whether or not I was doing a good job. I also didn’t recognize patterns. Without the industry experience, I couldn’t look at a problem and say, “oh yeah, I know how to do this. I’ll just do the same thing as (fill in the blank).” I didn’t have that knowledge base to pull from.
And yet, despite these shortcomings, I have seen massive progression in my abilities over the last few months. Even now, only a few months in since my first real engineering job, my knowledge base is significantly deeper than it used to be. Now, I can look at a problem and at least recognize that there are patterns I should be using to solve it. I’m now slowly understanding a bit of the tried and true processes used by most engineers. I’m learning that becoming a great software engineer takes time and that it’s important to trust the learning process.
In light of that learning process, I’d like to share some lessons I’ve learned within the first few months as a software engineer. These lessons are not only technical, but also personal and career-related. Hopefully, you find them interesting or helpful. At the very least, I’m sure I’ll look back on these lessons one day and appreciate how far I’ve come.
So, here are the lessons I’ve learned since becoming a software engineer:
No one knows everything
Even senior engineers have to ask questions and learn things over again. Thus far into my career, I’ve been surprised with how many questions senior engineers have had to ask. Often, if they’re tasked with a new problem, I’ve seen senior engineers be as confused about a problem as I am. Granted, what separates them from me is that they have a clear process for figuring out new problems much quicker than I can. They also generally have much more context into a particular problem or issue. However, it is still really interesting and encouraging to know that you will always be faced with things you don’t know, even long into your career.
Imposter syndrome is real
It’s not easy to know if you’re up to par. It’s not easy to know if you’re as capable as the other engineers on the team, especially within the first couple of months on the job. I don’t know if this is true or not, but multiple engineers on my team have told me that most companies don’t really expect you to contribute much until at least a year or so into the job. These companies are aware that getting up to speed takes time, and generally expect that you will need time to get up to speed. This principle in mind, I’m learning that it’s okay to feel out of my depth in terms of my coding abilities. I am learning that this is just part of the territory. It’s part of the process. Everything takes time to learn.
Metrics for success are difficult
It’s tough to know if you’re doing a good job or not. Much like the previous point, it’s tough to know if you’re being as productive as you should be while on the job. I’m learning that being a knowledge worker is very different from being in other types of industries. Generally, as a software engineer, there is no one looking over my shoulder at every second of the day, expecting me to be slavishly typing away at 50 words per minute. That is part of the wonderful benefit of being a software engineer. The freedom. That is also the potential downside. With lots of freedom, comes lots of room for distraction and falling behind. I’m learning that setting clear metrics for myself everyday is the only way to stay on task. If I fail to set these metrics for myself, I start to lose sight of what success in the job means.
Being a software engineer involves a lot more than coding.
This is a fact that I didn’t necessarily take into consideration prior to be a software engineer. In fact, I’ve learned that the coding is the enjoyable part. It’s fun to write code. It is not fun to read through JIRA tickets and try to decipher the unintelligible scribblings that a product manager has left you. It is not fun to read through corporate emails. It is not fun to do HR training videos. All these points illustrate is that it’s not enough that the company you work for has a cool product or a really fancy codebase with all the bells and whistles. If a company’s processes and style of work bothers you, you most likely won’t be happy at that company. Likewise, if you don’t like the team you’re on, you probably won’t be very happy sticking around. At the end of the day, software engineering is still about people, and people are not just code (…sorta, kinda anyway).
Giving code reviews is so much harder than receiving them
Now that I’m actually a full-time engineer on the team, I’ve learned that I am expected to give code reviews almost as much as I receive them. As an intern, I don’t think I left a review on a single pull request. I thought I had no useful feedback to give any more experienced engineer on the team. I’m learning that this is not the case, however. There have been numerous times where I’ve left a review that I thought was obvious or not very useful that actually turned out to be really important. Often, it’s something simple that the other engineer just missed. Moral of the story is that you never know when you’re fresh perspective on something might prove useful.
