If you’re a developer or engineer, you likely know that taking over a large codebase is nightmare fuel. Instead of suffering with angst over such a massive task, here are a few tips to help you navigate it. First, accept (in your soul) that the codebase is a huge, clumsy, confusing mess of strings, literals, methods, functions, and calls to things you’ve never heard of. Yes, managing it is scary. You’re nervous, your managers are nervous, and, if you have a team, they’re nervous that you’re going to screw everything up. Embrace that fear. Leaning into it is your best asset. We’ll explain.

Schedule Meetings

Yeah, we said it: schedule meetings (those things everyone wishes would go away) as soon as possible. Invite your boss and anyone else above your pay-grade who knows about the codebase. You need to know what you're taking over, and the people who have been around the longest understand the code better than anyone (or at least they should). Code is culture; understanding the code is a great way to understand the culture of the product, team, and your company. If leadership has been in place for a long while, they’ll have tribal knowledge not stored in a wiki. Maybe there’s a style or methodology you can’t quite wrap your head around; they should be able to explain its inner workings. If there’s a direct purpose to things, those with the most seniority should be able to explain it to you. And if there isn’t, and your new team lead takes the "it compiled so we shipped it" tone, then you know your job is simply to write code that works (somehow) and to do your best. Either way, your bosses will appreciate that you took the time straight away to wrap your head around your new role.

The Blame Game Only Gets You so Far

What kind of developer was your predecessor? It doesn't matter. You may be taking over spaghetti code, or their styling is so weird that you’re having trouble reading it. Or worse: they used tabs instead of spaces. You can blame your predecessor for aspects of the code, but that’s not a long-term strategy that will work out. At some point, you’ll be expected to understand how to read that wonky code, and how to write your own code that works seamlessly with said codebase. Remember, others may feel the same way about the code you write; the last person was just doing their job, too. However bad it is, don’t blame them for every delay or issue you have at work.

Take Your Time

There's often a sense of urgency in the office. Resist it. Rushing into a fix is how things end up broken. The code you’re managing is unique, and likely foreign to your thinking. As a first step, it’s best to try and grasp what’s going on rather than tackle big fixes or improvements. In a way, you have to re-train your brain to accept and parse this new bit of code. If you’re instinct is to re-write the code, you’ll have to block that out, as well. Chances are, a total rewrite of the code is nearly impossible (or will require a massive time investment). While rewriting may prove the right instinct in the long term, you’ll almost certainly have to convince someone over your head it’s worth stopping the product in its tracks while your team starts from scratch.

Communicate Your Codebase Concerns

Picture this: Having stood at your desk for a week or so, you’re still lost. The code isn’t commented, they’re using tabs instead of spaces (okay, now I’m just trolling…), and the file system is confusing. You’re 40 hours into your cool new job, and you hate it. Talk it out. Now is not the time to tell your managers you hate your job (because you really don’t), but you should communicate your concerns. Your issues may not be unique; it’s very possible your predecessor was toxic and defensive of their code, and had no concern for anyone following in their footsteps. Management may have just looked the other way with this person in order to keep the proverbial trains running on time. There are a ton of reasons you may not be grasping your job right away, but it’s always best to be proactive and tell your boss what’s going on. More often than not, they’ll find you the help you need, or give you the time necessary to do the job your way.

Get Your Tools in Order

Digital tooling can help you do your job, and you should take full advantage of it. It’s an easy way to get up and running with things like testing and debugging, which can help alleviate a ton of headaches. This tactic works best when your company doesn’t currently have a favorite tool, or may be looking for something better. As the new person, you’ve got a bit of leverage to ask your bosses to let you try something new. They hired you for your ideas as much as your skill, so show them you’re resourceful and have some great tooling you’d like to use.