Whether you’re a new developer or have decades of experience, your job is going to require you at one point or another, implement a terrible solution, you’re absolutely going to hate. Maybe it’s poor management, bad miscommunication, or you just can’t find a better alternative. It happens. If you stick around a company long enough, you’ll know where all of the dirty little hacks are, and why they’re there.

For a couple of years now, I’ve worked with an international company that works with booking vacation and travel accommodations. They have multiple development teams working on the platform across the world, and a small internal team that made and acted on all the major decisions. At first, I made only minor front-end and design updates, mostly acting as a consultant when complicated issues came up. When Covid-19 happened, that internal team was laid off, and I was brought in as a larger capacity to help take over development when borders started opening back up between the US and Canada.

When the internal team left, they left no documentation. No explanation as to why there were multiple servers online doing absolutely nothing, no details on how to login to the staging or production servers, or how to even create anything locally. No docker images, no comments in the code. It took days to even determine that the servers were in a closet in their office building. No explanation to why the production server is running an outdated operating system other than “it can’t be updated, don’t try”. On top of that, the team that originally built and maintains the core app refused to hand over the full source code, so we were stuck figuring out the exact dependencies, VPN, and SSH connections to get running. It took almost two full weeks for the two of us to understand how to get a local copy up and running, and even longer to get in touch with the right teams to coordinate a way to push code changes to the live site.

That was about 10 months ago. Back to the present, my coworker, who helped me untangle the mess, is leaving. I am now literally the only person (currently employed) with the knowledge of how the front-end and back-end work together, how to build the front-end system, and how to get anything working locally for testing. What if I go on vacation, or need to take a break? What if I quit? When or if I leave, unless I train someone extensively, it may take even longer for a future developer to piece things together again. This also means I'm the one stuck maintaining this fragile contraption, while other teams are brought on for new initiatives, like building a completely new platform.

As developers, we often feel like we need to be indispensable, or we’ll easily be replaced. Over the years, I’ve come to learn of a much darker, harsh fate of having to maintain and manage all of the systems I’ve built, because so many clients and teams do not want to take the time to learn how something works.

What can be done? In this case, before my coworker left, we spent a couple of days taking everything we learned about the platform, building a docker image for the project, and writing proper instructions for getting things to work. Now any developer just needs git, docker, and VPN access, and they’ll be able to get a local instance running in minutes. Understanding it is a completely other mess, but it won’t take the weeks it took us.

The Ego Death of Development

One of the most challenging parts of my career so far has been learning when to let go, and when to stop being indispensable to my colleagues and clients. As developers, we have a unique path to growth. Starting out we do want to be indispensable. Especially if we’re on a team with other developers. We learn we can’t just wait for a solution to present itself. We need to poke and prod and understand how something works for us to do our job.

As a junior, you’re probably wondering what to do. Oddly, the best advice I can offer is to be indispensable. And to be self-less while doing it.

If a peer is troubleshooting why a service or website is down? Do research. And document it. Determine the source. And document it. Make suggestions. And document it. It’s okay to not know the answers, but show you know how to find them, and make sure others know where you looked. Document everything. It will be useful for you, and anyone that comes after you. Comment your code, and don’t be afraid to share why you used the dumb terrible hack you deployed to fix something. The more you share, the easier it is for others to take over for you if you leave. It’s also just nice to be helpful. There's a reason Stack Overflow remains so popular.

Share your knowledge and do yourself a favor to keep yourself from getting stuck in maintenance hell.

This post is part of my somewhat irregular newsletter series, documenting my thoughts and ongoing story of being a burnt-out developer that still wants to do way too much, and figuring out what I want to do next.