First of all, congratulations! Starting a new role whether it be in a new team or a new company is always a combination of exciting and nerve-wracking. It’s a new opportunity to learn something new, make yourself more known, and grow as an individual. But how to get started effectively in your new position? Here are some tips and recommendations on how to approach your new role as a developer.
I’ve worked at 5 different companies in my career as a software engineer, in companies with only 12 employees and companies with over 40,000. Every company is slightly different and each team within the company is unique as well. Between culture and technology, joining a new team is often as challenging as switching companies. In this article, I’m going to lay down some things I’ve learnt over my career to help you start more effectively in your next company and team.
1. Draw the architecture and get the flow
Learning the architecture and flow of data is crucial in any application. Whether it be a simple Frontend application or a cluster of docker containers. Understanding where things flow, how data gets modified along the line, and where it ultimately ends up is one of the first steps to understanding how a system functions.
Simple flowcharts work great here, but make it your own. Getting started in a new role means that you will quickly be exposed to many new things, and having tools and diagrams to aid you in your understanding can quickly speed up your effectiveness as a developer. Likewise, it will also help you learn the bottlenecks and “workarounds” an inherited system will have, whether accidental or purposeful.
If you are working with a web application, for example, you going to start with understanding the incoming request. Is it from a browser? Is authentication a part of this request? Where does the request end up? Do we store the data anywhere? Are there “pass-through” or “middleware” elements interacting with the request before it is ultimately handled?
This type of approach also works well on a modern Frontend. Where is the request coming from? How is the request being made? How does the data get stored? What is the structure of the stored data? How can I interact with this data and ultimately display it? These are all excellent questions to ask in the beginning.
Story time
I had just started my second role in my career and I was working on NodeJS apps in a manufacturing environment. Our apps were responsible for helping the manufacturing line manage issues and resolve problems in a timely manner. The manufacturing business is cut-throat and efficiency is key. Downtime on the manufacturing line causes lots of cascading financial losses. Since this system interacted with a lot of different manufacturing systems, I felt it would help me learn quicker if I drew a flowchart of the data flow. Lucky for me, this ended up being indispensable a few weeks later when we had a production issue appear that was causing some downtime on the manufacturing line. The flowchart became a great tool because in a time of great stress, the engineers could quickly come together and assess the potential problem areas. The flowchart almost became a checklist of places to look for issues, and that meant many of us could break apart and look at different pieces separately to narrow down the problem more quickly.
2. Start Squashing Bugs
Bugs are given a bad reputation. They’re definitely not desired and can cause major issues, like completely miscalculating your trajectory. On the other hand, they can be windows into the depths of a system. Simple bugs, even something as trivial as incorrectly displaying a number, can be great resources to learning the flow of data and finding where weaknesses lie.
Every team I’ve joined has had a backlog of bugs that need to be addressed. From the viewpoint of the rest of the team, these can be seen as a burden. At the end of the day, starting a new role usually means they need more help on a project. Bug squashing is great because it lets you get down and dirty with the code and can help chip away at the looming burden which others can’t address. It’s really a win-win — you can get technical and help relieve some pressure from your teammates.
Story time
I had just started a new role writing web applications. I wanted to find some simple changes to make so I could get a feel for the development process and decided to make a simple version update of our New Relic package. Since the change was small, the code review was quick, and the production deployment was underway in no time. As we began to deploy we noticed the new relic stopped working altogether. It didn’t make any sense because our lower pre-production environments didn’t experience any issues. After a little digging, we had found a conflict between a request library and our new relic package that was causing conflicts. Our build process varied ever so slightly from environment to environment and uncovered this conflict. Fortunately, the issue was documented in our request libraries GitHub repo, so we were able to resolve it without much hassle. Throughout the debugging phase of this issue, I was able to learn more deeply how our applications get built and deployed in each environment, something I may not have gotten the opportunity to do as quickly otherwise.
3. Learn the Teams Work Style
- How do they deploy? - How do meetings work? - What are individual communication styles? - How do they prioritize work?
From a product standpoint, each team has different philosophies on how they build a product. Some teams like to do two-week sprints and a deployment. Other teams may not have the infrastructure to enjoy quick deployment or there may be external regulations that hinder quick deployments, medical device manufacturing for example.
Each team is different and each individual on that team has different styles of work and communication. Joining a new team means there is also some relationship building that occurs between you and the people you work with. These relationships are crucial because these are the same people who will help you learn and become effective quickly on the team. One of my favourite books around learning how to communicate is this book by Dale Carnegie. This process can also be the hardest and requires patience because each person is different and ultimately some people may just want to focus on their work. There’s not really a correct method for how teams should work, because teams can be so different given their context in the company and the people involved. Understanding those differences and strengths is a great step towards becoming a strong contributor quickly within a new environment.
Between the few different teams I’ve worked on, I’ve learned how the different personalities in those teams work best together. The team I was on in the manufacturing space was much more collaborative and communicative than some of the other teams I’ve been on. That team preferred to talk out problems and create a plan to solve that issue. It was a lot more pair programming then I was used to. Other teams tended to have more “heads down” developers that worked independently but were still available to questions. Both teams were successful, however, being able to identify how each team operated helped us work better together with less conflict or miscommunication.
Summary
Joining a new team means being open to new processes and people. It’s a fine balance of patience and determination to learn plenty of new things without getting frustrated and overwhelmed. With these few tips, both technical and interpersonal, you will be off to a great start in your new role 🎉
