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. <\/p>\n\n\n\n
<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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!<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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, … Continue reading Challenges as a Junior Developer<\/span>