I think the real underrated skill to learn as an engineer is how to test. Documentation can take many forms: ADRs, system diagrams, specs, JIRA tickets, commit

I think the real underrated skill to learn as an engineer is how to test. Documentation can take many forms: ADRs, system diagrams, specs, JIRA tickets, commit messages and descriptions, PR descriptions, code comments, idiomatic/intuitive code, etc. etc. and much of that requires maintenance or review to ensure it's still up to date. Outdated tests quickly become broken tests, and they serve a purpose as documentation as well, but aside from throwing around buzzwords like TDD and BDD and all that, it's rarely a skill that is explicitly developed. Or maybe it's handed over to an SDET or something. Build a decent set of tests that can survive the implementation being refactored, rather than coupling them to the runtime code or filling them with mocks and stubs, and you can get a good way to documenting complicated routines simply because you are explaining how it works through numerous well-described assertions. That means you never need to bother with the 'how' or 'what' when commenting code, and you have multiple levels of 'why' as you go up from the code to commits to the issue tracker and beyond.