Like TFA suggests, right at the end, this is where code review shines. Keeping documentation valuable is a discipline challenge, and we all fail from time to ti

Like TFA suggests, right at the end, this is where code review shines. Keeping documentation valuable is a discipline challenge, and we all fail from time to time at keeping ourselves disciplined. If you have team agreement on the level of documentation that gives good ROI for time spent maintaining it, you can rely on your team to help catch your slips just as they can rely on you to help catch theirs. Using something like ADRs[0] can help provide the structure the team can look for when it comes to "why" documentation. I recommend a standardised README across projects. If it's "what" comments look for language tooling that will execute documented examples as test cases. If it's "how" then make sure there's value in it - do you have disaster recovery exercises, does your incident response team use your "how" documentation to triage issues, do stakeholders outside your development team get consulted on contextual changes in your application, etc. [0]: https://brunoscheufler.com/blog/2020-07-04-documenting-design-decisions-using-rfcs-and-adrs https://brunoscheufler.com/blog/2020-07-04-documenting-desig...