Make Yourself Replaceable
The best system you build will be the one that doesn’t need you. Whatever you are building should not need you. The service, the app, the process, none of it should depend on you. You are a bottleneck. You are a single point of failure. When another person attempts to change what you’ve built in some way they will do it differently than how you would do it. They will make the change based what they feel is right. How will they know what is right?
Some of the most difficult, painful systems I’ve worked on are those that depend on the knowledge of one or a few key individuals. If those people aren’t around everything seems to go wrong. Their expertise is necessary to keep the ship pointed in the right direction or no one seems to know what to do. This is an impediment to growth, velocity, and general team satisfaction. I should know: I’ve often been that bottleneck.
Why be replaceable?
It will make your team more effective
Bottlenecks and gatekeepers are a great way to slow a process down. If you want your team to be more effective they need to be able to safely extend and modify the system you built without you. Giving them to the tools and knowledge necessary to work without you will allow them to move faster and keep your time free for your own work.
It will make your code more enjoyable to work on
Some of the worst codebases I’ve ever worked on were the ones where most people were afraid to make changes. Components were not well understood, myths about what could go wrong were pervasive, and when you wanted to make a change it was difficult to know where to start. People feel empowered when they have the knowledge to work with autonomy and the confidence that they will be successful in what they are trying to accomplish.
It will help you grow in your career
Some day you will want to move on to another project. To grow yourself, you need to let go of what you are working on now. To do that, others need to be able to pick up where you left off.
It will improve your work life balance
Even when management gives generous time off policies and encourages their teams to take time off, sometimes people feel they can’t. Sometimes there is a fear that things will go wrong without them around. Even if they do take time off they don’t fully disconnect. By making yourself replaceable you remove the dependency on yourself and free up your own time to relax and recharge when not at work.
How are they going to know what you intended? How will they know what changes are dangerous and what are safe? How will they know where the dragons live?
How to make yourself replaceable
Communicate intention
Engineers are opinionated. Those opinions carry into our work. We have opinions on the right and wrong way our systems should evolve. These opinions have affected what you have built. Document how you intend for the system to change and evolve over time. Where are the best extension points? What is the most effective way to test it? Look for ways to ensure your intention is obvious in the design of the system.
Document your assumptions
All designs are based on some assumptions. You assume the number of users you will have. You assume what type of operating system your app will run on. You assume how users will use your app. You have to make assumptions because the future is inherently uncertain and you have to push forward in the face of that uncertainty. This is good. But eventually your assumptions will turn out to be wrong. You may gain three times as many users as you expected. You may discover advantages to running on a different operating system. Your users will use your app in ways you don’t expect.
If you write down your assumptions as you make them you leave behind clues to when your design will need to be changed. The type of web service you build to support 10 requests per second is very different from one that needs to handle 10,000 requests a second. If someone else can see that your assumptions no longer hold true they can be more confident in how your design will need to be changed.
Use code comments liberally
Code should be self documenting. But code can only self-document what it does, not why it does it. In the future, another engineer will look at something you wrote and proclaim “this is the dumbest thing ever. I’m going to re-write it.” You need to leave that engineer the necessary context to understand why you did what you did so they don’t accidentally break something or regress a problem you fixed.
Work in public
To be replaceable you need to be able to leave at a moments notice and have someone else pick up what you were doing and carry it to completion. Sometimes this is easy if you are working closely with a team of people who are familiar with your work. However just because you are working on a team doesn’t mean anyone on that team could pick up what you were doing. Use a public task tracking system and post regular updates about what you are doing. Write down obstacles, challenges, or insights you’ve come across along the way.
Teach
Use your time to spread your knowledge of that system as far and as wide as possible. Host and record brown bags on what you’ve built. Invite new people on the team to have a deep-dive into the code base with you. Participate in code reviews. Share everything you know at every opportunity.
Coach
If there is a part of the codebase that you know very well and needs to be changed you should not be the person making those changes. Instead, find someone else who doesn’t know. Have them take on that work. You may give suggestions about how you might approach the problem, but let them drive. Be a resource to help clarify areas as necessary and be the first to give feedback on their changes. By the time they are done, you will have another person on the team who is one step closer to replacing you.
Summary
To build better software you must remove the dependency on yourself. In the long run it is in the best interest of both you and your team to do so. Start today to make yourself replaceable by incorporating these practices into your work:
- Communicate Intention — Make it obvious how you intend for the system to operate and to change.
- Document assumptions — Write down for others the assumptions you’ve made that influenced your thinking.
- Use code comments liberally — Document at the deepest levels the little details about how things work and why they work the way they do.
- Work in public — Keep your work available for everyone to see. Make it easy for them to find out what you are doing and why without asking you.
- Teach — Proactively teach others about what you’ve built and learned along the way.
- Coach — Let others take the lead to maintain and extend what you’ve built while providing feedback and guidance along the way.
