Joining a new team as a software engineer can be daunting. There is so much to learn in such a short period of time. The pressure can be high and deadlines for feature releases are expected to be met before you even begin. Having worked on many different teams in Tech, I’ve made many mistakes during onboarding. I wrote this article to help new engineers on-board effectively and avoid the mistake I made. Sometimes new engineers are fixated on building stuff as quickly as possible but many times we forget about the social/human element of creating software.
Remember that code reviews are typically conducted by HUMANS (and sometimes machines). So it’s a good idea to get to know your team, the culture, and the dynamics before getting your keyboard dirty. It is equally important to begin preparing for development work. I’ve compiled a list of soft and technical aspects of software engineering that would help you onboard more efficiently. I’ll start with the soft aspects first and then discuss the technical.
Note: each section will have a designation of either first day, first week, first month, or first year and organized by priority.
Soft
Recognize your flaws as an engineer – first week
No one is perfect and it’s important to know your weaknesses. I sometimes lack attention to detail and have trouble prioritizing my time. Stating these weaknesses clearly and succinctly can help me address these flaws in my day-to-day. But simply acknowledging is not enough, we should practice mitigating these weaknesses as well. Knowing that I sometimes lack attention to detail, I will review my code twice or three times thinking about edge cases before submitting a PR. I will be satisfied if there are no fixes recommended by senior engineers (which rarely happens). Nevertheless, these are career-long goals that I do not expect to be resolved overnight. This takes consistent effort and patience.
Get the right experience given tech market trends – first month
Usually, during the interview process, you have already defined a broad scope with the hiring managers and understand what projects you will be working on, but regardless, you should actively advocate for projects that are consistent with market trends. For example, I don’t want to write COBOL code because this won’t advance my career. No future job that I am interested in will require COBOL programming language knowledge. Therefore, any time that I spend writing COBOL is not necessarily consistent with my long-term goals. Ultimately the experiences gained during these new positions must prepare you for the future. So it is important to think about what you anticipate will be the future of technology such as cloud computing, Docker containers, Terraform, Python, etc. Then advocate working on projects with these technologies.
On the other hand, you can’t expect to work exclusively on the technologies you are interested in. I’ve always viewed my relationship with my employer as a Venn diagram where there are my interests, their interests, and hopefully a lot of overlap. If I wanted to use Python and so did my employer, then represents an overlap in interests. But if my employer wanted me to use a windows machine, but I wanted to use Linux, then this would not be part of our joint interests. There should be significant joint interests, if not, then you should likely look for a new job or talk to your manager about getting projects more aligned with your interest.
Get to know your team – first month
Software engineering is a team sport so it is crucial to get to know your team. Nearly every significant project that I’ve worked on required collaboration. There is sometimes pre-existing code that is important for maintenance or support. Hopefully, if the code is not commented and you don’t understand the logic then you need to schedule a meeting with the authoring engineer. Maybe this authoring engineer recently had kids and is only available to sync in the late morning or early afternoon. I am not necessarily advocating asking personal questions during your initial meetings but being aware of a colleague’s personal circumstances can be important.
It’s also useful to understand your colleague’s motivations and interests. For example, I had colleagues who enjoyed writing unit tests while others enjoyed automating mundane tasks. The next time I am tasked with either I know who to ping another second opinion or a review. Furthermore, you should communicate your interests to your colleagues as well. Demonstrating expertise in your interests will lead to more similar projects. In this way, it’s important to express your interests as well as understand your colleague’s interests.
Find a mentor (technical and business/career) – first month/first year
When starting a new position, I recommend speaking with your manager or team lead to find a technical and business mentor. The technical mentor can help you navigate the stack, understand the architecture diagram, deployment flows, etc. This person is usually on your team but depending on your organization they can be on another sister or brother team. A business mentor will help you understand the bigger picture and broader business goals. Ideally, this person is within the engineering org but also understands the company domain. This person might be a director, product manager, senior engineering manager, etc. Ultimately software solves business problems and it’s important to understand what your code accomplishes.
A technical mentor should be found first, then a business/career mentor. I would organize a loose bi-monthly cadence limited to 30 to 45 minutes max. I view these sessions as career therapy. Depending on who I am speaking to I might vent about different things. With my technical mentor, I might discuss some frustrations about a particular project. When speaking to my business/career mentor, I would brainstorm projects to pitch and think about my long-term goals more concretely.
Understand the broader motivations behind the projects assigned to you – first year
Understanding the broader motivations behind a project is useful for a number of reasons. When you interview for future positions recruiters or hiring managers typically ask about projects you’ve worked on and understanding the broader purpose behind your work demonstrates thoughtfulness. In other words, you don’t want to come off as a drone doing what you are told. For example, "I wrote a script which tests the throttling limits for our internal API" as compared to saying "to better understand the internal user experience and mitigate unnecessary throttling for creating a compute instance, we wrote some scripts to test the limitations for creating such resources".
If applicable, you can also add some financial or [Service Level Indicator (SLIs)](https://www.atlassian.com/incident-management/kpis/sla-vs-slo-vs-sli#:~:text=An%20SLI%20(service%20level%20indicator,actual%20measurement%20of%20your%20uptime.) around your testing and possible solutions: "after testing our API, we noticed that there is 15-minute delay from the time the request is created to the time that the resource is created due to the throttling." Remember, time is money. If something is taking more time than necessary, then this represents a cost. Having context around the bigger picture will help you tell a better story and also understand the purpose behind your work. These can also be bullet points in your resume if the achievement is significant.
Tech
Set up your local environment – first day
Prioritizing setting up your local environment is crucial for efficient future development work. In the past, I would push setting up my local environment because I thought I would do it when needed. But spending that initial time to set up your local machine will save significant time when costing work and starting projects. If someone joined the team slightly earlier than you, take advantage of their setup knowledge.
Have your team tell you what is important to set up and what is of lower priority. I would also encourage using the same Integrated Development Environment (IDE) as the rest of the members of your team. Basically, I would mimic whatever they have configured on their local machines even if you are not necessarily comfortable. I made the mistake of using Jupyter Notebooks when nobody else on my team was familiar and there were issues pushing and reviewing code.
Create a trivial Pull Request (PR) to understand the flow – first week
A good first step to acclimating to the new team development environment is creating a trivial PR. Here, add a comment or change the code format or something simple to justify a PR. Besides committing the code investigate how syntax is checked, whether there is a local environment for testing, and perhaps how these changes are deployed into production. These are just some of the questions worth asking. Learning how that code is reviewed and what approvals are needed to merge to master is also crucial.
Gather a list of resources (confluence, slack channels, subject matter experts (SMEs) contact info, IT personnel) – first week
There is a pretty good chance that the issues you face are issues that other developers on your team, organization, or network have faced at some point. These learnings are often documented in different ways. Sometimes teams like to post their learning as messages in a slack group, they create confluence pages or have notes saved on their local machine. Regardless of how problems are solved, it’s important to gather a list of resources to help resolve issues that you will likely face. For example, when I learned how to search Slack for error messages, it opened a whole new world for troubleshooting issues. Understanding the resources available as well as how to leverage these resources is absolutely critical to efficiently resolving this issue. You should assume that someone else has seen the error you are seeing.
Study service – first month
Regardless of whether you are creating a new service or supporting a pre-existing service, understanding that service will often take a lifetime. A simple architecture diagram can introduce an infinite set of questions about the pros/cons and purpose of the service. Services are dense. A service is an argument with many references about the best way to solve a particular problem. It is also a living thing with unique anatomy which must be understood to be improved and maintained.
Though I can likely write an entire article about how to study a service, I will attempt to summarize what an organized effort consists of. First, understand how the service will or is being used. If the service or an MVP is already built, try to use the service yourself. Really test the limitations of the service. If it’s an API, try entering the wrong values and seeing how the service responds. Obviously, make sure that there is a safe environment where this testing can take place.
Second, speak to a product manager or tech lead responsible for the service to understand future improvements and goals. What might be even more helpful is if there are metrics about the current performance detailing 5xx%, 429%, and latency metrics. Nevertheless, discussing the current pitfalls of the service as well as the future goals will help you gain a better handle on expectations and goals.
Third, gain an architecture diagram for the service and study it thoroughly. What are the various components involved? What are the positives and negatives of those components? What does a better architecture diagram look like given the current and future goals? I would even recommend sketching the diagram yourself to test your knowledge. One step further would be to question the tech lead or whoever designed the service you are building and supporting.
Fourth, go from a high-level to a low-level view of the service. Start by writing a few sentences describing the service. Next, provide a more detailed description abstractly referencing the architecture. Then describe the technical details of that workflow. If there are APIs, then detail how those APIs work together to solve the broader problem. You can also detail how each of those APIs work abstractly and then in detail. Finally, you can get to the code base and essentially describe the functions. The goal is to understand each line of code but sometimes that is not possible in our lifetime. Getting this granular will take time so don’t get to fixated on being able to understand each line the day or even month after you join.
Conclusion
I wrote this article to organize my thoughts before joining a new team as a software engineer. Given my tech background and experience, I know the mistakes I made when I first joined. These mistakes were compounded by the fact that I was remote given the global pandemic. I wanted to create a list of sorts to help new engineers onboard more effectively and avoid the mistakes I made. Organizing this list into the soft and technical domains might help new engineers realize the importance of both to help their teams. However, this list is not comprehensive. Is there something I missed? Please comment below.
Substack:
I recently created a substack to learn how to program and solve LeetCode questions in Python.
