In my previous blog, I mentioned that I started my position as a software engineer intern at my company. I work as a full-fledged software engineer now, but was the path easy? No, it was very challenging.

Overwhelming codebase

When I started the position, all I knew was some introductory level C++ and JavaScript. However, at my work, we use the .NET framework with C#. Although, C# supposed to be easier than C#, those two languages looked very different to me. I thought I could write/read code okay because I was doing really well in my classes, but I realized that I was only familiar with a small amount of code that I worked on at school. I was completely overwhelmed at the size of the code base and all the downstream items that my changes could affect.

It took me one year to overcome this feeling. How did I do it? I just kept reading code and spent endless time trying to understand what was going on. I created several notes (most of them didn’t make sense because I was lost most of time) and I even created some diagrams to understand the flow of our systems. I wanted to ask questions to senior developers. However, they were all busy, and I didn’t want to bother them. I just kept on reading code everyday. The first half year was miserable. Facing all the unknowns was very frustrating, and the code base was just too overwhelming. Every once a while, things started to click. Once it started clicking, a lot of the code base started to make sense, and things became much easier. I probably spent too much time trying to figure out things by myself and often went down rabbit holes. Asking more questions would have probably sped things up, but I think that solving the issues on my own was integral to my development as a software engineer. Solving these unknown issues is now one of my strengths, and I am confident that I can figure out a lot of issues by myself!

Writing code that fits in with the existing code

One day, I was given a task to fix a small bug. I wrote several lines of code, tested it, and confirmed that everything worked nicely. I submitted the code for review. Soon after, the ticket came back and said “Hey, you can just call this method, ABC()”. All my work ended up just being a single line of code.

As mentioned in above section, reading the codebase definitely help learning the existing style and methods that we use, but I can’t spend all day reading and wasting time to just fix a small issue. To overcome this issue, I just started looking for similar functions. If I was working on scraping a website, I looked for another job that did something similar. I checked what libraries and classes they were using and imitated those. This worked pretty well for me, but we have some legacy code that I have to be careful with sometimes.

Another issue was that sometimes I thought I had a great fix, but I broke something else! This happened to me several times in the beginning, because I was only focused on the one issue that I was given. I wasn’t paying attention to the the bigger picture and how it would affect other processes. I did two main things to overcome this issue. First, I worked on understanding the reason behind the code. If I was dealing with data, it meant understanding what the data was for and how it was being used. Next, I checked what else was using the same method that I modified and verified that my change didn’t affect other sections of the code.

Ticket management

At the beginning, I easily spent hours working on one ticket, because I got stuck on a problem that I couldn’t figure out. I also felt like I would forget everything if I had to work on another ticket that was higher priority. Unlike the assignments from school, I usually had multiple ongoing issues or tickets that I needed to work on. I couldn’t work on one ticket all the time.

I was able to overcome these issues by implementing a few changes in my workflow. One crucial item was leaving good comments in the code and tickets. Another thing I found helpful was creating sub-tasks and dividing work as small as possible. Once a small task was completed, I would either keep working on the next issue on the ticket or move on to another ticket that was higher priority. Using this method, I was able to easily multi-task for some tickets, and it was easier to keep track of my progress.

Finally…

There were a lot more challenges that I faced in the beginning, and there are still a lot of things to learn everyday. Now, I can confidently say that I am a software engineer. Although, there are times that I feel like I am still not good enough. I think a lot of junior developer face the same issues that I had, and I hope this blog will make someone feel better in the future.