Always be replacing yourself

Dear new developer,

I had a friend who brought me into a club. The specifics of the club don’t matter, but like most clubs, it had a variety of executive roles. Someone had to run the meeting, other people had to take notes, someone needed to keep track of the finances.

As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. You don’t want anything to be your particular special area of knowledge. You should always be trying to train your replacement.

I think this is good advice for a software developer as well. At any new job, you are learning tons of new things. This is doubly true when it is your first or second job.

But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the eng team is relatively stable) or new hires (if you are on a rocket ship), in a year or so you won’t be the new kid on the block.

Obviously this is a discussion to have with your manager, but you should always be looking at ways to replace yourself. This will free you up to work on new tasks and learn new things.

Here are some ways to replace yourself.

Document all the things

Don’t rely on your memory. When you are performing a task for the second or third time, write down what you are doing and why. (If you only do a task once, this is not usually worthwhile.) Keep this under version control and share it widely. That way anyone can see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.

Offer to cross train

When you are working with someone else, you both gain knowledge. Whether this is a command line trick or a different view of the world, or specific domain knowledge, working with someone on a task will help you both. This doesn’t need to be full pairing, it could be an impromptu design session or troubleshooting discussion.

Automate for the people

If you are doing a task and have time, write a script or program to do all or part of it. Don’t let the perfect be the enemy of the done. If you can write a script to do 70% of the work in 10% of the time it would take to automate the entire task, write that script. This pairs well with documentation and is a living form of knowledge transfer.

Obliterate the task

Sometimes a task is always done because it has always been done. With your beginner’s eyes, you can ask “why”. Don’t be crotchety, but try to get to the root of the problem to be solved, rather than focusing on learning the solution. There may be other ways to resolve the issue. There may not. But by understanding the root of the solution, you’ll be better able to see if you can avoid doing it altogether. This isn’t strictly training your replacement, but it will be welcome and does make the organization more efficient.

Don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.

Sincerely,

Dan