Familiarizing yourself with a new codebase - What worked for me

Starting a new dev role is always difficult - you'll have to

• learn new technologies and services and how they work together,
• dive into a new codebase and familiarize yourself with the teams/organizations coding conventions
• follow new development workflows and procedures
• work with new team mates
• set up your local development environment

etc. Although this was not my first role as a Front-end Developer, I was especially anxious because

• I've never worked in an organization with many teams dispersed within many departments (my first job consisted of me and one other developer.)
• I also felt (and still feel) like a Junior because I didn't receive much mentor-ship on my Front-end work in my previous role.
• I was thrown into a code base using Angular which I had no experience building with.
• I had to be on boarded remotely because of shelter in place order.

I had to figure out a way to get the ball rolling so I could feel more comfortable with the new work and work environment. Here are a couple of tips that worked out for me:

What to do:

If possible, make your first pull request within the first couple of days of starting. Find some small issue with the code and start working on getting your first PR merged into the code base. For me, I found a minor accessibility issue - the main navigation was missing focus states so that someone who is dependent on the keyboard to navigate the website couldn't tell which navigation item they were currently on. I had to explore the code base, find the main navigation component and its corresponding style sheet. I created a new branch, made the changes, made my first commit and finally made my first PR. I requested a PR review, got some good feedback, implemented more changes, got my PR approved, merged, and pushed to production! I introduced a couple lines of code into the code base and ended up learning:

• how to run the application locally
• commit message conventions
• the basic folder/file structure of an Angular app.
• how to use SCSS for styling
• PR messages were formatted in a particular way.
• procedures for merging to the production branch.
• how to test the changes on the staging site.

After going through this process, I was way more comfortable making subsequent changes to the codebase.

What not to do:

Before starting my new role, I had about a week between jobs so I decided that in the days before my start date, I would read through all of the documentation I could find in various repositories owned by my new team. Don't get me wrong, reading documentation is super important but this is a surefire way to overwhelm yourself before starting your new job. Instead, I recommend trying to get a high level of understanding of each repository you'll be working in -

Try to get a good idea of the structure of the README.md by reading the table of contents (if one is provided) otherwise, just go through the README and read all of the section titles and subtitles. Don't worry too much about the granular details within each section. This is just a way for you to get an idea of what kind of information is available to you if you get stuck when coding or, setting up your development environment.

Side bar: Also, don't be me and start working before day one of your job. This is not expected of you and as I mentioned before, this will just overwhelm you.

I hope these tips serve you well in your new role 😎.