My Experience Taking Over a Colleague's Project

As you spend more time in this industry, sooner or later you’ll find yourself taking over a project from a colleague.

I still remember the first time I formally took over a project from a coworker who was leaving the company. What I did was: Clone the repository, copy the env file, configure the database IP, try to start the service, and somehow get the local Python environment working (I hadn’t written much Python before, and the project was built with Django). Then I listened while my colleague explained how to connect to the production and staging servers and how to deploy manually. Basically, I just listened to whatever was being explained, took notes as quickly as possible, and even recorded the handover sessions so I could listen again later if I needed to verify something.

Later, I had to take over another project. This time it wasn’t a web service but a data-processing pipeline. My colleague provided the IP addresses of the machines involved, what task each machine was responsible for, the dashboard used to monitor whether jobs had completed, the dashboard used to manage the machines, and so on.

In other words, it was essentially the “official introduction” to the project.

As I gained more development experience, I started approaching handovers differently. This time, I began actively looking for information and asking questions:

• If something goes wrong, how do you debug it? Where do you start looking? The monitoring dashboard? Cloud service alerts?

• What types of problems happen most often? How frequently do they occur? How do they usually show up? Does a customer report that the website is down, or do you discover the issue yourself?

• Following up on that: how did you solve it last time?

• What issues are currently still in progress? Who reported them? What do you think is causing them? How far have you gotten in the investigation? What should I watch for later to determine whether the issue is actually fixed?

• If I want to run some tests myself, which dataset can I use without affecting anyone else?

All of these questions can be summarized as looking at the project from a developer’s perspective and imagining what it would be like to be responsible for it.

I’d also like to add something else. During a handover, it’s easy to focus too much on the project itself. But in my experience:

Everything you can find in the code is the least important part. The most important things are the things that aren’t in the code, including:

• Which external services does the project integrate with? Do those services have admin dashboards? If so, what are the accounts and credentials?

• Development always involves verification. Some features require interaction with external systems. For example, when developing functionality related to an e-commerce platform, it’s common to need an online store specifically for developer testing. You install your application there and use it to verify your changes.

  (I have to give credit to Shopify here. Its ecosystem and developer experience are incredibly strong—you can create a test store with a single click, and it even generates sample data for you.)

“The things outside the project are the most important.” Here’s an example:

Suppose a production environment and a staging environment share the same API key for an external service (let’s use an email service like Brevo as an example). Production and staging are supposed to be separate environments, but from Brevo’s perspective they’re both operating under the same account. That means they’re effectively sharing the same data pool. As a result, you may run into all sorts of strange issues: duplicate records failing to be created, mailing lists that have separate IDs within each environment but end up conflicting once they reach Brevo, and other unexpected behaviors like that.

Anyway, these are a few lessons I’ve learned from my own experience. I hope they’re helpful to you.