Joining a new team is intimidating. Even before our first meeting, thoughts swirled through my head: Would I be able to get up to speed with their codebase fast enough? Would I fit in with my teammates? Would I be good enough? Smart enough? Fast enough? 

On most school projects, you get to start from scratch. Everyone is on equal footing and you start with nothing. In some ways, this can be wonderful. You get to gain a deep understanding and have true ownership. Unfortunately, this isn’t how the real world works. Aside from founding a startup, there are very few projects where you start with nothing. Most of the time you join an existing team and have to get up to speed with a new codebase. 

Working on Scorch feels more real-world than any other project so far. I am on a team of 15 and report to a tech lead and a sub-team. There are fewer all-team meetings and decisions are no longer based on consensus. I thought that I’d miss being in a leadership role, but I’ve enjoyed taking a step back and spending more time working on things that matter to the player. 

All the programmers at accidental games have been incredibly welcoming and kind, but I was still too scared to touch code for the first few weeks. I didn’t feel quite comfortable messing with anything because I didn’t fully feel like a member of the team. I felt like an outsider. Almost an intruder. I wasn’t familiar with how this team did things or how they navigated conflict. 

Eventually, I had to jump in the build. A big turning point for me was seeing the messy state of their current codebase. I think I had idealized Scorch since it had made it to the second semester of development, but seeing the accumulated tech debt in the codebase brought my expectations back in line with reality. Scorch was written by humans, not demigods, and I was well within my rights to start renaming things and organizing the project files. 

Though seeing a less than perfect codebase was a big turning point for me, I would recommend cleaning up your project before bringing in new devs. Trying to understand a byzantine file structure was intimidating and slowed me down. At one point I spent 45 minutes trying to figure out which scene was the current version of the game. 

One helpful thing was a meeting that the programmers from last semester held to orient us to the codebase. They went over their version control and naming conventions. By spending time showing us around the codebase, like a manager would show a new employee to their desk, helped me feel welcome. If you are onboarding new programmers to your team, try to hold a meeting to show them around the codebase as soon as possible. Make existing team norms as explicit as possible so they don’t need to fear stepping on toes. 

Eventually, it was the respectful treatment of the other members that made me start feeling like part of the team. They never acted like I was a second-class citizen despite being new. They held me to the same standards as everyone else, and in return, I have given them my best.