Congratulations, you’ve started your first developer job!
Now, it’s time to amp up your learning. More than likely, you’re going to be put on a project which is larger than you’ve ever seen, more complicated than you’ve ever worked on, and involves packages and even languages that you’ve never used before. The learning has just begun, and your first few months on the job are critical to forming a good impression with your teammates.
Here’s how to get on the right track, and how CodeSee can help you understand your first real-world codebase with confidence.
Understand your team workflow
Before you dive into the code, take some time to focus on your team and their workflow. Each team is unique and will do things differently than others, but there are a few areas all teams will have in common.
Firstly, understand how your team manages code—which means learning how your team uses version control. This is more than just asking what version control provider the team uses. It means understanding how the team uses it. Here are some examples of questions you can ask:
- What should I check before making a commit?
- What needs to be in the commit message?
- What branch should I work in, and what branch do I target when creating a pull request?
- What needs to be in each pull request?
- Who do I notify once I’ve made a pull request?
Next, get an overview of your team’s current DevOps setup. This is key to understanding what happens with your code. Understand what kind of CI/CD workflows are in place. Take time to understand what, if any, manual steps must be taken, and how long each step usually lasts. At this point, you don’t need to fully understand how it all works—focus on the “what.”
Areas of responsibility
Finally, understand each team member’s areas of responsibility or expertise. Try to go beyond job titles and get a sense of informal responsibilities. Even within a fairly flat organization, people naturally tend to divide and conquer.
Pro tip: If your team doesn’t already have one, build an Ownership Map as you’re learning! Your team will love you for it, and taking ownership of the information you are learning demonstrates competence and leadership.
Now that you know how to work smoothly with your team, it’s time to start looking at the code. But don’t just rush in! Here’s how you should start...
Survey the land
Begin by surveying the land to gain a big-picture understanding of your new codebase. If there is more than one codebase, do the following for each of them. And while you do so, take notes on an Explore and Learn Map.
Dependencies and packages
Take a look at the dependencies and packages used by the codebase. Don’t just read through the list—make a note of items you are unfamiliar with for research later. For those that you already know about, sort them into one of three categories:
- Core: fundamental packages/frameworks such as React, Express, or .NET
- Major: packages that affect large sections of the codebase, such as axios or styled-components
- Minor: packages that are typically used only in a few places
Next, review the folder structure of the codebase. The way files are organized will give you insight into the mental model of those who created the code. Look for patterns in naming as well as the hierarchy. If your team has an Onboarding Map, this part of your onboarding will be much simpler.
Typical code flows
Finally, start tracing through a basic code flow. Think about a standard test case for the application and manually walk through the code which handles those cases. As you do, keep an eye out for any areas which look a bit strange. In some cases, these will be areas that you need to learn more about; usually, they will be problem areas of the code, containing technical debt which needs to be paid. Try mentioning a few of these to your team and see what they say. Your team is probably aware of those issues as well and will appreciate your observational skills.
By now, you should have a general sense of how the codebase is structured and the relevant pieces which compose the larger application.
The team lead has just assigned you your first task. Let’s discuss how to complete it well.
Tackle your first tasks
Let’s get to work. Typically, your first few tasks will be small—probably a bug fix or a minor enhancement. Here’s how to do your first task excellently.
For bug fixes, don’t just solve the bug! Fixing bugs can be a valuable learning exercise, but only if you take time to understand the why of the bug, not just the how. Try to understand why the bug exists by asking questions such as the following:
- How did this make it through our team’s development process?
- What other cases might have been missed, and does it make sense to account for them now?
- How can we prevent bugs like this from occurring in the future?
These questions will not only help you to gain a more comprehensive understanding of the codebase, but they’ll also help you fix bugs more effectively.
For enhancements, try to emulate the patterns in the code that you saw during your codebase survey. For at least the first few tasks, it’s often better to imitate rather than refactor. If you see something that is strange or needs improvement, run it by a team member first.
The key is to focus on gaining understanding rather than just pumping out code. Ask all of the “why” questions that come to mind. Make a point to understand each piece of code and its place in the larger architecture. Take notes, write comments, and update the CodeSee Explore and Learn Map you made earlier. The more you can understand now, the easier it will be for you later on, and the more likely you are to write the right code.
There’s a lot to being a good developer that goes beyond just writing code. Learning how to work well with your teammates, tackle new codebases, and make sure you write the right code are all skills that will take you far into your career. Focusing on these skills will ensure that you get started on the right foot and help you make a great first impression on your teammates.
That being said, the right tooling is always helpful! And CodeSee is here to help everyone—junior, senior, and principal-level developers—understand both new and established codebases.