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?
Top comments (5)
I love the idea behind this, Alex!
And this bit:
Really sums things up succinctly!
Saying it like that makes it feel so obvious that it's better to have someone who is creating a system that everyone can understand and help work on rather than walling it off and making it something that just one person understands.
Also, really dig your colleague's line "I want to be missed, but not needed." Well said!
Thanks Michael! You phrased it nicely - it's all about creating a system. Another similar analogy I've heard is building a car vs building a car factory. It's easy for a team to build one feature in isolation, but it's harder (but also much more rewarding and effective) to build a system that allows you to build more cars indefinitely.
Oh wow, that's a great analogy!
I've called this the "bus factor" or "how detrimental would it be if I was hit by a bus tomorrow?"
Most things should have enough documentation and stuff to follow that anyone can pick up where I left off, so it has a low bus factor. Things I haven't fully pieced together or passed to anyone else have a high bus factor.
I still look both ways before crossing the street just in case...
@marissab this is a super helpful mental model! Definitely a big fan of using the bus factor to help think about knowledge gaps on teams.