Realistically, my advice is. Document as little as possible. Build processes into your tools so it can be tested and repeated. Documentation that can get outdated, will be outdated and even worse be wrong. And, for example APIs can be organized in a way that documentation can be automated, so its never wrong or outdated, by choosing to use API contract first, like Protobuf or implementing via OpenAPI specifications. If you are implementing a specification of some kind, keep a copy of the specification version you have implemented checked in with the code.
Other things I have seen is f.ex. code that implements a business process, also can output itself as a Graphviz drawing, describing the parts of its own structure.
My team has been using swashbuckle in the dotnet API ecosystem which generates an open-api document based on your code, commemts and c# attributes (for the things it can't infer from the former). The documentation and code have a symbiotic relationship.
"For example." It's a favorite phrase of the various Polish devs I've known, for some reason.
I like it! It looks fun and a little mischievous. I hope someday we start using fx in the same places we use ie or eg.
EDIT: My beautiful Finnish wife informs me t.ex. is also used in Swedish in a very similar way, till exempel or something like that. So maybe it's a Northern European thing too?
I believe it's something along the lines of "flagrant excision" (of established language conventions).
The resultant confusion from such communication innovations may be justifiable in service to a larger goal, e.g. making a clean cultural break from ancient lion-torturing Latin speakers.
Be the change you want to see. Et cetera, et alii.
Other things I have seen is f.ex. code that implements a business process, also can output itself as a Graphviz drawing, describing the parts of its own structure.