I used to idolize the “rock stars” and lone wolves who knew everything about a particular subsystem in the projects that we were working on. The only problem is that they were the only ones who knew about what they were working on.
I’ve heard people half-joke that knowing a particularly gnarly domain of an application is a form of job security. And while I think that’s a grain of truth to that notion, I don’t think it should ever end there.
In fact, I think taking this idea to the opposite end of the spectrum is actually what makes you a better software developer. Rather than being the only person who knows how something works, being able to make a subsystem approachable to everyone else on the team is the mark of an excellent teammate. Paradoxically by making yourself expendable, you become an integral part of the team.
Someone who optimizes for job security ends up subconsciously embracing practices that don’t help the team too much. They tend to leave the complex system as-is and only make minimal changes to it when absolutely required. If anything ever happens to them or they take a vacation, the team has to start learning everything from scratch and scramble to make changes.
Whereas a developer who looks to make themselves expendable embraces habits that help amplify the team:
Ensuring there is adequate testing in place
Refactoring the system to make it easier to work in
Writing documentation so others can grasp concepts more quickly
A colleague of mine once summarized this perspective nicely when he was reflecting on his vacation time and told me, “I want to be missed, but not needed.” And that’s really the goal, isn’t it? You want your team to appreciate your contributions and expertise, but you also want to have done enough to enable them to help themselves in your absence.
Taking this notion of legacy a step further – the day is going to come when you part ways with your job. Not to be overly-existential, but how do you want to be remembered on your team? Do you want to be known as the person who knew everything but whose absence sets a tone of panic among the team? Or do you want to be remembered as the person who tackled messy code head-on and made the entire team better for it?
