Starting a new job is extremely exciting and nerve-racking. So if you are reading this because you just got an offer, or started a new job and are drowning in all the new information, or maybe you are still in the process of looking for a most suitable job, then keep on reading. Here I will talk about all the lessons I learned as a junior developer that will also help you succeed.

When you are a junior developer, there is an insane amount of things to learn. This feeling does not go away for a long time. But it's good because it will keep prompting you to leave your comfort zone and stretch your intellectual boundaries. As a junior developer, your job is to get good at the technical side of projects. Senior engineers will conduct the business meeting, discuss project requirements and plan out the architecture. Of course, you should try to stay aware of those activities too rather than burying yourself in code. In addition to getting really good at the tech stack that your job uses, get really good at navigating the codebase. Many junior developers feel like their contribution should be grand, like changing how code is written or how features are implemented. You can't do that or even think that way. Your job as a junior engineer is to learn the habits and procedures of the engineering team. Dive into the codebase, carve out a piece you will tackle, make diagrams, and get really good at it. Continue like that with the rest of the app!

Your mentor will always start you off with the front end of the app because that’s the most visual part. If you are impatient like me, you will want to know about data flow, CRUD operations, database structure, etc. One of the best ways for me to get a better understanding of all those above-mentioned topics is to make the backend visual as well. Your company might use something like Swagger that allows you to look at all the endpoints in the app. Use it! Study it, experiment with all kinds of requests like GET, POST, PUT, and DELETE (as long as you are using a local database instead of production and a testing branch), and maybe even break it. However, I wanted to have the ability to save my work in files. So I started using Postman, which was my frequent life-saver at my previous job. The other tool to help you understand and visualize the tables in the database is LucidCharts. Making diagrams out of tables will help you understand not just the relationship between the tables but also understand the concepts in the business domain you are in.

At some point, you will be asked to start reviewing pull requests. Not just small PRs that need an approval stamp, where it doesn't matter which developer approves, but the real meaty PRs. You might feel intimidated and ask yourself what you can contribute to a senior engineer's code. I still feel intimidated. Code reviewing is difficult. But you can't get good at it just by virtue of being a senior, you also need experience. How do you get experience? By practicing, of course. One thing that helped me become comfortable with code reviews is pair programming. If another developer is "driving" and I am "navigating", I am becoming more familiar with the feature they are working on. So when I review, I know what to look for, what vulnerable spots to be aware of, and just generally what edge cases to test. When I have a good context of the PR, I can be more meticulous with their code.

I already mentioned pair programming. Start pair programming now! I try to meet with each developer from our team at least once a week. Mostly I have been the "driver" (writing code) and the other developer is the "navigator", talking through the process. A few times I got to be a navigator, I realized how hard it is to reason through logic without having my hands on the keyboard. It will force you to untangle the jumble of your thoughts into clearer directions or suggestions to your driver.