How to take on an existing project.

Working as a developer means you need to know how dive into existing code bases. When you inherit a project, there are a lot of specifics that you don't know, like why some of the code is written a certain way. So when it's time to go into a hand off meeting you need to know what to ask about. This is your time to get the information you need to get up and running.

These questions come up in every project. You could be starting a new job or working on a different project at your current company. Regardless, here are a few things you should bring up in transfer meetings.

Know what it's supposed to do

What exactly is this application used for and who uses it? Without this context, it's going to be really hard figuring out how to implement new features or fix bugs. Ask about the overall use of the app. Learn about the workflow for different parts of the app. If there's a task list, get a walkthrough or more details about each of them.

This is one of the times everyone is prepared to focus on answering questions about the project. So if there is anything you're unclear on, don't leave that meeting without clearing it up. Of course things come up when you start digging in, but this is your chance to preempt a large chunk of confusion. Try and get a high level understanding of the app before you dive into specific questions. Learning about the industry the app operates in can help answer questions that come up in your development as well.

Know how source control is handled

While most projects use Git, not everyone uses GitHub. Some projects could be hosted in BitBucket, Azure DevOps, or even on a SVN. You need to know where code is kept in version control so you can pull it down to your machine and also so you can do troubleshooting when those inevitable production bugs appear. Make sure that you have access to the code and that you have the right level of permissions to do the work you need to. When you receive the your login credentials, check them immediately.

The sooner you can find little problems like these, the smoother the project will go in the long run. Fix a small bug and do a quick commit to make sure that you can push up your local branches to wherever the remote repository is. Also, take a quick look at who all has access to the repo. This will be useful info when it's time for pull requests and code reviews. This is also the time to ensure that only the necessary people have access to the code. Note any users you are unfamiliar with and check with a project manager or someone to see if they still need access.

Know how to run the project

The hardest part of taking on a new project can be getting it set up and running on your machine the first time. There are a lot of one-time commands that can be lost if the process hasn't been well documented. A few things you need to check that might not be obvious include your PATH variables, the versions of the software you're running, and the file names you are referencing. Other things that might come up are setting up a new local database and getting the seed data in there and changing any connection strings to APIs or databases.

If you are going through setup and you notice yourself running into issues, make sure you're documenting them so that it's easier for the next developer to do it. Plus you never know when you'll need to factory reset your computer and those notes will come in handy. Once you have the app running, check that everything is functioning like it does in development or production. You should see the same behavior across all of the environments until people start pushing changes.

Know the testing process

There are many different forms of testing that your app can go through and you need to know how to jump into that flow. Unit tests are common in most projects to some degree so always check for those. Some places do integration testing to make sure no breaking changes sneak into the build or deploy pipelines. Other places even have dedicated software testers that will run through user scenarios to see how things will work for real users. You need to be aware of all the steps your app will go through.

When you start this new project, looking at the tests can give you a good idea of how the app works. If there aren't any tests in the project then this is your chance to start adding them. Having some code coverage sets the tone for the app in the future that there should probably be more tests added as code developed. Working with software testers is a different process you'll have to learn. Usually there's some kind of system in place like Jira or Basecamp where bugs and features can be discussed and tracked through sprints. Follow the process they have in place and it'll help get your code to the pull request phase faster and more consistently.

Know the deploy process

Although cloud services have just about taken over the hosting needs for most companies, you might still need to work with a physical server. Having this information will help you understand the deploy strategy you will be working with. Is there a continuous build/deploy process in place or will you need to do manual deploys from your machine? Know how migrations should be handled across the different environments. Get all of the common parts of deploying an app clarified for this particular app.

Little wonky things happen with the cloud services that only the people that handled the deploys before know about so make sure you ask about any weird things you should look out for. Since you've already fixed a small bug to check that you can push up your changes, go ahead and deploy that small fix to the development environment. This is your test to see if you really understand how the deploys will work. Hopefully you won't have to do many manual deploys and you'll work with CI/CD pipelines so the process will stay consistent.

Taking over an existing project is a special skill because it's not something you do all of the time. Some people work on one product or product line for a bulk of their career so setting up new projects only happens every now and then. Although if you ever do consulting or freelance work, you'll need to know how to do this with confidence on a regular basis. Usually there are small configuration changes that you have to figure out and once you set then you never have to worry about them again.

These are just a few things I try to check for when I'm setting up a new project. Some of these tips apply to open source projects as well. Do you have anything you always check for when you're getting set up?