Dan Moore is head of developer relations for FusionAuth. He’s written and contributed to numerous books, including “Letters To a New Developer”, which is full of advice he wishes he’d had when he started writing software. A former CTO, technical trainer, contractor, engineering manager and longtime developer, he's been writing software for (checks watch) over 20 years.
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
Once, I had a friend who brought me into a club. The specifics of the club’s goals don’t matter, but like most such 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, you get the idea.
As I took on more responsibility in this club, my friend gave me a sage piece of advice: “always be replacing yourself”. While each role requires certain skills, I shouldn’t want to hold unique knowledge. In order to keep the club going in the future, he counseled that I should always be trying to train my replacement.
This is good advice for a software developer as well. At any new job, you are learning tons of new skills and domains. But, eventually, there will be someone even newer on your team. Whether through churn (if the size of the engineering 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.
This is a discussion to have with your manager as well, but you should always be looking at ways to replace yourself. Doing so frees you up to work on new tasks and learn new things.
Here are some ways to replace yourself.
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 documentation under version control and share it widely (a README in every project is a good starting point).
You want anyone to be able see what you are doing and suggest improvements and/or take it over if you are on vacation or doing a different task.
When you are working with someone else, you both gain knowledge. Whether this is a command line trick or a different view of the problem, or specific domain knowledge, working with someone on a task will help you both.
This doesn’t need to be a full pairing session, it could be an impromptu design session or troubleshooting discussion.
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, however. 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.
Writing a script pairs well with the aforementioned documentation; it is a living method of knowledge transfer.
Sometimes a task is always done because it has always been done. Don’t be crotchety, but when confronted with a request that doesn’t make sense, 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.
1. Document all the things
2. Offer to cross train
3. Automate for the people
4. Obliterate the task
In conclusion, don’t be a precious holder of specialized knowledge. Share it widely, train your replacement and you’ll be on to something new.
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
.png)
.png)
.png)
