Write the docs
Writing docs, in contrast to writing code, is where you can experience delayed gratification in its purest form. The gratification may be so delayed, that sometimes you may ask yourself - is it even worth it?
When implementing a new feature, the answer to this question is pretty simple. Every single line of code can be considered as a part of some bigger initiative - a value-added activity, that your customers will benefit from in a more or less direct way. But what about docs?
Some teams, especially those that prioritize speed of delivery over healthy engineering practices, may be proud that “there’s no time for writing the docs”. To some extent - I get it. I was also part of those teams. I understand that early in the product lifecycle you prioritize the run toward product-market fit above anything else, but what if you already know what to build, and now you want to take it to the next level?
Writing docs is one of the easiest solutions for scaling yourself and your team.
Every time you onboard someone who just joined your team, or when someone gets sick and you want to push things forward, or when the incident happens and you want to save time on troubleshooting, or when someone casually asks “how does it work?” and you don’t want to lose focus, or when you want to convert your internal research into external publication, or when you want to unify the domain language, or when you want to zoom out and reflect on some past events or decisions…
…it is when you get rewarded for having docs ready.
Write the docs - it’s that simple.