This is part of a series where I share my professional values and working style openly, so that future colleagues can get a sense of who I am before we ever work together.
Lead by Example
Working in an open and collaborative way is how I feel most comfortable, as a professional. I want to lead by example with how I document and communicate about my work.
Throughout my career I've gained a reputation for being thorough, and leaving a well-documented trail behind me, with whatever tasks I'm implementing.
Some of this comes from the frustration of losing work. I absolutely hate that, and so I tend to write a lot of things down. Usually that writing flows into project statuses, design documents, rules of engagement, team policies, templates, and workflow patterns.
Why I Write Things Down
I really thrive on new problems and processes. Novelty is both interesting and stimulating, but can be uncomfortable or unnerving for some. I document my work as I go along for a few key reasons:
-
What if I am struck by lightning, and cannot finish the job? I want to make sure that if I can't continue the work for any reason, it is documented well enough to give another person the best chance of picking it up and running with it.
-
I don't want to be the owner just because I touched it last. I'm hoping that if I document the problem, the solution, what we chose to implement, what was decided to be out of scope, and why, someone else will end up taking the project a little further next time. It won't become another project that I own simply because no one else has the context.
-
Documentation communicates values. Generating documentation is an excellent way to communicate norms, expectations, and desired outcomes to others on the team.
-
I'm doing a favor for future me. I know that if I do end up coming back to the work, I will really appreciate that the past version of me took the time to lay out the relevant details so that I can get re-oriented quickly.
"Oh, It Was Me"
Have you ever had this moment for yourself, or watched someone else go through it?
Here's the scenario: for one reason or another, it's time to review some code. Maybe we're tracking down a bug, maybe we are trying to understand how a feature works. There could be many reasons that inspire a walk through the codebase. Along this walk, someone exclaims: "Wow, this code is really ugly. Who would write it this way?" just before the moment of realization -- "Oh, it was me."
When you write code, develop systems, create diagrams, or generate any of these deliverables, the context and decision-making around it seems so obvious at the time. That clarity is so fleeting. Even with just another colleague picking up the work, there will be many details around the edges that they won't have in their mind, unless you wrote it down for them. Consider reviewing the changes you made in a year, or two. Will you still remember what you did and why? Perhaps, but you also will have forgotten much of it.
This is why I document as I go. Not because it's required. Because the alternative is losing context that was hard-won, and making everyone who comes after me start from scratch.