5 Things I Learned as a Junior Software Developer

I started my first job as a software developer around 4 months back and since I was coming from a freelance background, I had my own way of writing code. Most of the time, my code wasn’t read by anyone. Yeah, not even my clients due to their lack of technical expertise.

I had never been to any software industry before so I wasn’t much aware of the coding paradigms followed by the industry. Although I was freelancing for the past 2 years, It was a completely different experience when I started coding for a company full time.

Regardless of the knowledge gained in the past 2 years, I practically had zero experience working with the experienced teams. So here are 5 things I learned from senior developers in my team.

Refactoring code matters

We were working on a project which had lots of patches, duplication, and had an overall inefficient code. One day my Team Lead advised me to have a look at our codebase and work on improving code quality.

Although everything looked fine to me at first. But soon I realized what he was trying to convey. I began to rewrite functions to make it more modular, replaced patches with an inbuilt solution, separated code into files and directories as and when I required them.

After days of refactoring, our codebase began to look much cleaner to work on as we had replaced patches, removed duplication and reorganized code into various files and folders. So yeah refactoring matters but only up to an extent.

Formatting style should be same across the team

No white spaces! Extra blank lines! Improper indentations! These are all signs of not following a single formatting style across the team. 

So who’s formatting style should we follow, the Team lead? No, this is where linters come in. A linter is chosen at the beginning of the project and everyone is required to follow it throughout the development cycle.

This helps the codebase to be cleaner and expects the same coding standard by everyone. Team leads often set up a pre-commit hook to make sure everyone abides by the set formatting style before the code gets into the remote repository.

Writing unit tests will help you in the long run

Unit tests! Meh, they are useless… I have already tested the code from my side and everything works as expected. Why do I even need to write scripts for that?

My assumption changed once and for all when other developers started modifying my code to include their changes. No one knew what could break with the changes they were about to make. This made my code hard to modify and that started to get worse when things actually broke in the production. 

If we have had unit tests in place, any bugs would have been identified in the testing phase and the blame game wouldn’t have started. This made me realize that tests are necessary to keep the code maintainable in the long run.

Patience is key

My teammate once pushed non-working and non-formatted code to the dev branch directly. We didn’t have this branch locked at that time as no one ever did such a thing. He was new at that time and since I noticed this first, I FREAKED out. 

I called him out for messing things up for everyone. He understood the thing and instantly apologized. He fixed them in a few hours but I regretted calling him out like that. 

I could have handled that situation differently by letting him know about the issue and not to repeat this in the future.

“Everyone makes mistakes. Not many learn from it.”

Seniors are not always right

As usual, Daily stand-up held, everyone started discussing the problem that was bogging us for days but there wasn’t any solution for it yet. This problem was a major bottleneck for the scalability of our app.

People came up with different ideas on how to resolve this. As we were discussing the most optimal one, our team lead jumped in with his solution and stating how can it be the most optimal implementation. Everyone agreed and I had to implement the solution.

As I began thinking about the implementation, I realized about the edge cases which isn’t taken care of by it and there’s no way to fit edge cases in the proposed implementation.

I thought for a while and figured out a new implementation for the problem. I checked with all the edge cases I thought of and found it to be covering all the edge cases.

I emailed my team lead with the proposed solution and the next day everyone discussed and agreed with the proposed solution except my team lead. He did not have a solid reason for his disagreement and I still thought my solution was a better one, so I escalated the matter to the CTO.

Our CTO called up a meeting the next day and after analyzing both of the prospects, he proposed my solution as a better one by providing valid reasons for his perception. Everyone agreed and this was implemented successfully.

If I hadn’t raised a concern about this or would have just accepted what was asked to do by my senior a.k.a the Team Lead then that might have worked for the short term but it would introduce bigger issues for us in the future. So thinking ahead of time helped me better analyze the problem.

There are a ton of more things I have learned as a junior Software Developer but these were some of the learnings that gave me huge level-ups to my soft skills as well as hard skills.

I have also learned a lot of shortcuts to better navigate my dev environments. My debugging skills and analytical thinking have shot up by learning from other’s experiences. 

For the past couple of days, I am learning to touch type to increase my typing speed which will help me become more productive and make me look like a geek 😆.