What I Learned in my First Year as a Junior Software Engineer
Today I’m sharing what I have learned in my first year as a software engineer
A year has passed since I finished my software engineering studies and started working for a small startup in Spain. Back then, I was nervous and had a lot of doubts when I was looking for my first job. I wasn’t sure how I should behave in interviews, how to choose a good company, or how the day-to-day would be.
After several interviews with different companies, I decided to join a small startup with a full-remote philosophy after my last summer holiday as a student. These are the things that I wish I were told before my first months working.
You don’t need to do everything by yourself
When you start working, specially if it’s your first job, you want to demonstrate that you are a valid developer and that your company hired the right candidate. The reality is, after finishing studies, you don’t really know anything about how a real software project works and how things need to be done. In university or other education program, you were doing everything yourself most of the time or sometimes with a small team, giving the impression that help is not something you need on a daily basis.
The reality is, you are going to need help and work as a team. Ask questions and propose ideas without fear, and ask for help if you get stuck, because staying quiet and unproductive is not doing any favours to anyone.
Using the latest technologies is not always the right option
Maybe you did a personal project with the latests technologies before starting your first job, and you feel that everyone should be using that technology. This is not the way to go, you are going to need to adapt to whatever your company is using at the moment. Refactors are hard, take a lot of time and most of the cases, even with a good test coverage, bugs are going to be introduced.
Think very carefully about why you want to do a refactor, because you have to convince not only yourself, but your team too, and sometimes the people in the upper levels of your company. I suggest doing a small demo of what those changes could bring to the team and the product. If the refactor goes ahead, it’s better to release it in small pieces instead of doing the entire thing and then launching it to production. This way you can monitor how the change is going with confidence and reduce the users that may be affected with possible bugs.
Giving positive feedback is as important as pointing out mistakes in the code
In my case, I never had to do real code reviews about the work of other people, so this was my first experience doing so. A code review is usually done to check if any mistakes were made and because of that, the natural thing to do is pointing out the things that you, as a developer, consider that are not done correctly.
Try to give positive feedback too. We as persons who care about our work, need it, and people are going to give back if you recognized them positively, improving your relationship with the team. It’s also a good idea to impersonate comments so that it doesn’t feel as personal when giving negative feedback, and leave behind personal preferences about code formatting, naming and thinks like that. That’s why code style rules exists, and your company chose them for a reason.
Take notes of everything you are told
You may think that you are going to remember everything or that you can ask someone else if you don’t recall something, like I used to do when I was studying 😁. So try to annotate everything you are told, specially process that are not yet automated, and you are going to need to repeat with frequency.
Seniors make mistakes too, learn from them
You are going to make mistakes, it’s the truth. You may think that is only because you are a junior and don’t really know how to do your work, you may compare with your seniors teammates and think that they are free of failure. But they make mistakes too, it’s natural and sometimes, although you may not believe it, you know things that someone with more experience doesn’t. Don’t be afraid to throw a hand from time to time. Or even if you don’t know about the topic, offering your help and doing some pair programming is going to make you learn from the mistakes that someone with more experience has made. At the same time, you are showing that you care about your work.
Conclusion
These are some concepts that I learned from my first year working. They are mostly about behaving at work and working with a bigger team to what I was used to. I didn’t take into account specific things about code or framework, as those are super specific to the job.
If you have any suggestions or want to share your thoughts, don’t forget to leave a comment.
If you want to read more content like this and support me, don’t forget to check my profile or subscribe here to get an email every time I publish new content.
