New codebase
With software development skills in such high demand, the opportunities are plenty. With the right combination of determination and patience, anyone has a chance to make a start as a developer.
There are multiple articles on how to land a new software developer role and even more tutorials to acquire the knowledge to do it.
After you land a new role, though, you are pretty much on your own. The trial starts, and you will be judged and tested on how much value you can add to your new team/company. The good news is that most companies out there will show a lot of understanding to new joiners as it is widely accepted that everyone needs time to adjust to a new role. On the flip side, most companies don't have a plan to introduce you to the new codebase, and you will most likely be merged into the team slowly by solving tasks and figuring out things by yourself.
You will be faced with many new challenges, and needless to say, most of them will be around the new codebase you were hired to work on.
This article will give you some ideas/suggestions on how to familiarize yourself with a new codebase and also how to start adding value to your team as soon as possible. A strong start and the ability to adjust quickly can also mean a lot for your progress in your new company.
I will attempt to break down the ideas into three different areas, as I consider the adjustment to the new codebase a multifaceted process. It will make the article easier to extract useful, actionable methods that you can start applying in your current role. In the first area, we will focus on your attitude as a new member of a team. The second area will be about how to gain a deeper understanding of the new codebase/system. And for the last part, you will get some insights on how to familiarize yourself with the new tools that will be your companion in your new journey
Attitude
Question everything (silently if you have to).
As a new member of the team (with a lot of knowledge missing and yet to be acquired), you are forced to rely more on other people's knowledge. It makes sense to do that as you try to navigate yourself through new challenges.
The danger with this approach is that it is easy to take as a fact every bit of knowledge shared by your more experienced team members. They will intend to help as much as they can (most of the time), but even with the best intentions in place, they are people too, and they make mistakes. If you just rely on that shared knowledge and take it as the absolute truth, apart from the fact that this piece of information may be inaccurate or even wrong, you also miss the chance to form your own opinion. It will be crucial for your understanding to analyze everything that is lying in front of you. With that exercise, of constant investigation and validation of the information at hand, you gain more knowledge of the codebase.
It is also valuable to the team to have a new perspective on how they do things, and even more, you can come up with suggestions of your own. This will show that you have the ability of critical thinking and that you value the software that you work on.
That being said, you have to be very mindful of how and when you express these fresh opinions of yours. Every team has its dynamics, and as a new joiner, you have to respect them and challenge them with a gentle approach. In an open-minded team, where there is space for everyone to suggest changes, your questioning of everything will be welcomed. In a more inflexible team, you will need to work on your way of bringing that value.
Ask questions
It is not a rare attitude in a competitive workplace to want to hide your weaknesses as you try to climb higher in the hierarchy of a team. It is hard to admit that you don't know something that everyone else seems to understand and talk about with ease. You can be an experienced developer that does not want to show that you lack knowledge that a junior developer has, or you can be a junior that is afraid to show you are not experienced yet (that is a feeling that happens at all levels, in my opinion).
Software engineering is a learning process. You have to battle the fear of exposing your ignorance through a question. A good student is not only a student who has the curiosity to learn more but is a student who, on top of that, is not afraid to ask stupid (and frequent) questions. We are all students when we are new members of a team.
The easiest way to find an answer to something you don't know is to ask someone who does. I have been in situations where a whole project was derailed because the appropriate questions were asked too late. Be open and precise about what you don't understand so people know how to help you.
Although asking questions is essential for your improvement, it is also very important to learn how to get some answers by yourself. Find the balance between the time spent on the investigation to understand how something works and the time spent to ask questions.
Be open-minded
Every company has a different culture. Every team has different habits and protocols (if any) in place. You will need to accept that things are done in a specific way, which is probably very different from the things you worked on before, in your new team. Embrace the opportunity to find new ways of working and be open to all new experiences.
You can encounter different perspectives and ideas that will force you to rethink your old habits. Different protocols/standards/ habits, no matter better or worse, you can always learn from these.
Every new team member has to comply with the existing "rules" and sets of instructions to have a chance to become valuable and functioning in the new environment. If certain habits make you unproductive, you need to be upfront and discuss them with your team lead/line manager, always by respecting what is already in place of course.
Talk with your colleagues
One of the best ways to acquire knowledge and network yourself deep in the team is to converse with your colleagues about the system.
I am not talking about asking questions about things you don't understand here. It is more of a casual conversation with a fellow coder on what they worked on. These kinds of chit-chat can start by just asking, "Are you busy these days?" and letting the other person talk about their pains of the week. Showing interest is always a good conversation starter, find the person who built that great module you were using or an interesting feature and just tell them how cool it is, most of them will be glad to go into deeper details and share the pain points with another developer.
Deeper understanding
Read the code you are working on and everything around it
When you are called to fix a bug, alter an existing behavior, or even build a whole new feature, it is easy to focus only on the code that needs to be changed. It is possible to stroll along with your task, delivering what is needed, without fully understanding how the system works.
A better approach, though, is to read and understand what the code is doing. Try to break it and experiment with different changes. This process will give you a deeper understanding of the codebase. Even better, you can try to do the same investigation for the caller of the function you have to alter, and the caller of that caller... Every task you get is a great opportunity to investigate how the code is written and organized.
In the PHP ecosystem, the MVC architecture is very common. If there is a change you need to implement in a controller, try to also investigate the parent class of that controller. Check if there are any middlewares at play. Do the extra click to find what is under the hood. The rewards can be great. After some time, you will have covered enough code to feel comfortable.
Understand the request lifecycle
If you are working in a web application, chances are that the code is accessed most of the time through the web. The request lifecycle is a vital concept to understand as everything "goes" through some defined steps to reach the logic you are trying to work on. Invest some time to understand all the steps. Make notes or add bookmarks to the common paths of the code.
Check what packages are used to unpack the request payload or the implementation of the middleware. Check how the controller is invoked and how the data are passed around. Play around with the authentication/authorization mechanisms that are in use. Bit by bit you will be able to build a deep understanding of an important part of the system.
Understand the framework that is used
This suggestion is an obvious one, but given the vast amount of features and bugs that come to our desk daily, it can be easily omitted. If an application is built using a framework, then the framework is the most commonly used tool by a developer working on that application. We are called to use that tool to build new features and solve existing problems.
As a beginner, it was always challenging for me to make sure I was using the framework tools to solve the issue at hand instead of reinventing the wheel all the time. I needed to always freshen up my knowledge of the framework's capabilities to avoid writing some user code to solve something that the framework could do for me much more efficiently. Tutorials, short videos, and revisiting the docs will help you stay up to date with all the new things a framework can do.
Another issue that I faced was the identification of the level that a bug existed. To make that point more clear, I did not know at the first glance if the bug was happening in the client code or the underlining framework (or the way we used it). Again, deeper knowledge of the framework could position you in the frontier of handling these types of issues.
Lastly, I want to mention that there are companies that don't use any frameworks. Or at least not any all-in-one solutions like Laravel that offer a bunch of tools to help us. I found that if you look closely at the code, you can spot some set ways of doing things. There will be functions that are used in many places of the system, and patterns in place. Try to spend some time figuring them out. This will help you to avoid trying to solve everything from the ground up.
Learn from done work
As it was mentioned earlier, one of the best ways to learn (in my opinion) is by asking. Learning from others can be done by questions or by investigating retrospectively how your teammates solved some older issues.
Checking commits in the code can be a good way to find some of the problems solved previously. Another better way can be to track some tickets that someone else is working on. Find the code that fixed the ticket, and try to understand why they did what they did. Analyze the code and study the commits. This can be a quick daily practice of 15-30 minutes sessions. You can gain so much from seeing how experienced people write the code that adds value to the company!
Check general infrastructure - servers, etc
Maybe it is not one of your immediate concerns that the application is running on a single server, or it is scaling up based on the demand, but knowing where your code is run is always key. There will be times when you can't explain the current behaviour of the system by investigating the code. This is the place where you need to look at the bigger picture.
It has happened to me, to try to explain where my data was overridden after a specific call, the answer was that two instances of the application were running at the same time, one overriding the other process. The solution was simple and well-documented. Finding the problem, though, took me some time...
Tools
Master your editor
This advice can easily be considered generic, although the time spent to learn your editor and its shortcuts can be proven a great asset in your toolset. Navigating a new codebase can be daunting at first. The file structure is new, and the class names don't make a lot of sense yet. Using your shortcuts to navigate between parent classes and children or finding where the current class you are working on is used will help you save time and give you the mental space to focus on important things.
Get access to all resources available
The idea here is simple, you need to have access to all the available resources that help you carry out your daily tasks. The team you just joined will share with you some passwords and usernames for the different platforms they use. Your job is to make sure you can access these platforms and specifically the information needed in any of these. Do not let this happen last minute. When the system is down you need to have access to the logs immediately, you can't afford to search for the right password to use or get lost in the tool's navigation bar, so do these "tests" upfront and prepare yourself.
Set up the debugging tools
Any help you can get, you must get it. Learn what is the best way to debug the application you started working on. Use all the tools the team is using and consider if you can install some additional tools in your local environment. You can make the application "talk to you" when something goes wrong, and your understanding will grow at every opportunity. You will be more confident diving into a bug-hunting situation when your machine is prepared to show you in detail what is happening in your code.
It is worth mentioning here that static analysis tools for your code will certainly help you keep the quality of the code you modify high. They can also come in handy in places of the code that you need to alter to solve a bug.
Understand the automated (or manual) deployment
Usually, developers are using automated deployment as a black box. We just push our code on GitHub, and then we wait for our code to reach the production server. Maybe, is not our responsibility to make that process work, but it is very important to understand how our assets (code files, images, etc) are used by it. Be aware of any transformations that happen to your assets, and how the environment where the app runs is built.
A broader understanding of the tool will come in handy when confusing errors happen in production.
Conclusion
Being able to adjust quickly to a new codebase is a multifacet process that you need to tackle with all the possible tools you can use. A good start in your new role can set you up for success, but being always ahead of the game can be tiring. Hopefully, some of the advice in this article will help you achieve it without feeling overwhelmed.
Thinking about your overall attitude will make you a valuable member, sharpening your understanding will enable you to be a key player, and mastering your toolset will give you the ability to tackle all the issues that come your way as a professional. Be open to new challenges and enjoy the ride.
cover photo by Christina Morillo: https://www.pexels.com/photo/two-women-looking-at-the-code-at-laptop-1181263/
Top comments (1)
Drop a comment with a good or bad onboarding experience!