My list of things that I wish I knew before my first day as a Software Engineer.

I've been an Associate Software Engineer for a little over 3 months now and I thought it would be a good time to write a helpful article for other junior engineers who are about to start out at a new job, or maybe for those who are actively applying for their first development position. This list may not be as relevant for you, however for me these were my five big points. Honestly, I wish that my school work covered these areas more. Collaboration is such a huge part of development and I feel like most of what I learned through school was theory and how to program as an individual engineer, not as part of a team.

So without further ado...

1. I wish I had more experience setting up and troubleshooting my work environment

It's day 1, my only responsibility is getting my work environment setup and meeting my peers. Easy... right? Not so fast...

So throughout my university experience and while doing personal projects, I had not setup Visual Studio one time. While I did have experience setting up Netbeans @WGU, Eclipse @CSU and Rider and IntelliJ at home, I had no experience using Visual Studio. This isn't too surprising considering all of the IDEs I've used prior (except for Rider) were to development Java applications and now I am writing C# in .NET Core.

My first day I ran into a handful of errors while trying to compile my code. I was troubleshooting most of the day and while our documentation was really well done, there were areas that were not covered in it, like handling specific errors that I was running into. I really think that a course on setting up an IDE work environment could be a valuable class in college. Apparently, some of my co-workers take their whole first week to setup their work machine, which now I can understand as it takes time to get everything exactly how you want it to be. Finally, a few days later I was able to get everything working smoothly with the help of our principle engineer.

Tip to make it easier: Once you accept a job offer, contact your boss and ask about the IDE and any plugins that the team uses. Take your time to learn the IDE and try downloading some projects from the internet and try getting them setup.

2. Wish I was more familiar with Git and using it with a team

Git... Perhaps one of the most important areas of modern programming. Almost every company is either using git or some version of source control. For me, in school Git was simply not used, at all. There was no course on how to use Git, what it was, or why it was important. Luckily, I had used Git in some of my personal projects so I was not completely lost, but it was only to store projects on Github and not to collaborate.

The problem is that git really shines at collaboration but there are some scary problems that you can run into while trying to merge your branch's code back into the trunk. These problems are especially scary at a junior level when you're afraid to make mistakes. Once you go to merge your code, if you see the build fail, I guarantee as a first time recently employed junior developer your heart will fall right into your stomach. It will be okay. You can fix pretty much any Git problem that you run into and your senior engineers know this.

Tips to make it easier: Practice! Find projects that you are interested in and try to contribute to them, github is probably the best source for this. Take some of Gitlab's courses on Git... They're free. Finally, I have found that if I rebase my branch first before merging, I have a greater success rate because of how rebase works versus merge. Here's a great article on rebase vs merge.

3. Debugging code and using break points

During my first week as a junior developer, I was tasked with writing some Unit Tests for existing code that was confirmed to be working. By the way, writing Unit Tests for existing code is a great way to learn the code base and get familiar with the structure of the application you're working on. During this time, I was very green at using break points and debugging. You can imagine how ill-prepared I felt to write tests, but I did it and I even found my first bug.

In retrospect; I don't recall writing any Unit Tests at all during my time in college. I remember taking some software testing classes, but they were manual testing/ quality assurance classes. These were helpful for sure, but they helped very little with unit testing. While writing my first set of tests, I didn't realize that I could place a break point in the controller I was testing. Writing that now makes me feel a little silly, OF COURSE I can put break points in the controller I am testing but while I was writing the tests, I only thought to put break points in the test class.

Tips to make it easier: Write some unit tests for your personal projects. Test Driven Development is a big deal and a lot of companies use it. Where I am at now, we are not allowed to push out RESTful Web API Controllers/ end points without Unit Tests to go along with them. Also, ask your new team what they use for Unit Tests prior to starting and try to get familiar with it. At my job we use xUnit and I wish I had spent a little time with it prior to starting. It's not particularly difficult, but having that confidence boost in familiarity goes a long way.

4. Learning how to navigate my IDE better

This could technically go with "I wish I had more experience setting up and troubleshooting my work environment" and "debugging code and using break points" but I felt it was important enough to have it's own section.

Imagine this; You're in a 1-on-1 code review with your new supervisor. You bring your laptop into the room and you fumble around the shortcut keys and tabs while trying to run through your code with them. Sure, you're new and it's understandable that you may not be able to explain your code quickly, but fumbling around because you're unfamiliar with your IDE is something that you should be able to workout in a few weeks.

Tips to make it easier: Learn the shortcut keys for your IDE (Visual Studio, VS Code, Intellij, etc...), it will help a ton! On your next home project, code in the IDE your job uses, just to get a bit more familiar with using it. Also if you're company uses extensions or plugins, it's a good idea to get familiar with those as well.

5. It's okay to learn on the job

Okay, this is the most important point. Impostor syndrome is real. It is okay to learn on the job, in-fact it is generally encouraged. There's a line of course; you still need to complete your work and focus on work related tasks, but learning is a continuous part of programming. When I got a job offer at my current job, I was very nervous about learning C# when I had previously only used Java and Python. I did some self-learning at home, but most of my C# coding skills definitely come from learning on the job.

It's important to remember you are trying to land a junior level position. These positions are created with learning in mind. My company pays for a PluralSight and LinkedIn Learning subscription for it's developers so that we can learn new technologies or help junior engineers learn our current stack better. It's okay not to know everything and it's okay to ask questions. My advice is try to solve the problems on your own first, then try Google/ StackOverflow and if you are still stumped, ask one of your senior engineers if they can help you learn how to X.

Tips to make it easier: Learn to go with the flow and take advantage of the resources that are available to you. Become comfortable asking for help but become even more comfortable searching for solutions to your own problems. Again, it's a balance. You need to spend time trying to solve your own problems, that's expected... but it's also known that you are still learning and will need to ask for assistance at times. Also, please don't let impostor syndrome stop you from applying to junior level jobs. Get your resume out there, if you're passionate and know the basics, you can learn everything else!

And that's my list of things that I wish I knew prior to my first day as a software engineer. Hopefully this list helps someone relax and prepare for their first junior software engineer position. Also, your results may vary... All companies are different, but this should be a good starting point for most any company. Good luck on your position as a software engineer!

Please subscribe and follow me on my website for more posts like this: https://iamtravisw.com