Working Inside Existing Systems


The ability to work within the constraints and complexity of existing systems, codebases, and infrastructure.

Why is it important at Palantir?

Our work at Palantir requires working with existing systems, codebases, and infrastructure, both our customers' and our own. Whether we're enhancing existing functionality, rolling out a Palantir product that requires integration with other systems, or finding ways to exchange data between customers' systems and their Palantir instances, there are always third-party components in the mix. Even when we're working exclusively on our own code, a developer will spend far more time debugging, modifying, and extending existing code than writing brand-new things from the ground up.

Despite terms like Software Engineering and Computer Science, programming is a creative and expressive medium. Different developers make different choices, from stylistic decisions about how to format their code to high-level structural choices. Different projects will use different languages and different libraries and introduce different requirements for interfacing with other systems.

It's important to be able to make confident and informed decisions about the right way to fix a bug, or to add a feature, even when you lack perfect understanding of the system as a whole. Consider an operational outage at a customer site. How do we get the system back online? What are the potential risks, and how do we eliminate them without reading the code from the ground up? Or maybe we need to add an important new functionality. The code may not have been written how you would have done it, but how can you work with the code as it exists to add the feature in a clean way?

How to prepare

It's common to look at a codebase and think, “This is bad. This should be rewritten.” Take some time to reject that urge. Dig out code you wrote in the past. You've probably learned since then, and if you had it to do all over again, you might write things completely differently. Read your old code and remember why you made the choices you made and why they made sense (or didn't!) at the time.

Swap projects with a friend. (If you're in school, only do this you've turned in your work!) How quickly can you understand how their code works at a high level? Did you have to read every line of every file, or can you form hypotheses, test them, and refine them as necessary?

Pick an open source project. If you're lucky, they'll have an issue tracker where you can find some bug reports. Pick one. It doesn't have to be an important bug (in fact, start small). How do you find the right place to fix it? Do you have assumptions about how the project is organized? How do you test those assumptions? Even if the actual change is small, how long did it take you to find the right place to make that change?

If you can't find a bug worth fixing, add a feature or a new behavior. It doesn't even have to make sense. If you consistently use the wrong keyboard shortcut in a program, grab the source and add your shortcut. Add a new confirm dialog when you try to quit. Reorder the UI.

If you consistently use the same frameworks or libraries in your work, pick a project that uses something else. Practice understanding how things work at a high level as efficiently as possible. Learn how to think in terms of depth first, as well as in terms of breadth first. Only through experience will you learn how to choose between depth and breadth.

As with so many skills, the most effective teachers are time and repetition. You'll get the most value out of your investment if you are deliberate and reflective. Don't just debug your program. Stop and look back, and ask yourself if you did a good job. Was there a better way you could have found the bug? Did you ignore a failing test, overlook a warning, make an assumption that proved to be false? Did your fix cause your program to break somewhere else? Are you sure?

The more you expose yourself to novel and unfamiliar environments, the better you'll be able to handle them. Learn how and when to look past the details to find the big picture.