This. Yes! Tests are documentation. And sometimes documentation and tests are called specs. Naming is hard. So is documentation. I did that just to trigger fal

This. Yes! Tests are documentation. And sometimes documentation and tests are called specs. Naming is hard. So is documentation. I did that just to trigger fallacy trolls, but sometimes smart naming is documentation. Maybe that hard work of naming is worth it. Verifying that code flow makes sense via code review guarantees that code is documented well enough. As does handing it to the intern, without any "training," and asking for a new feature. Or an expert in a different part of the stack but not this code. As does playing "spot the bug" and having most people understand the code, even if they don't see the bug. Heck, just passing through some linters and style analyzers can get you pretty close to not needing documentation. There are many things that count in different ways. What does your team want/need/desire? Does the answer change when it's someone else's code and their own? The flip side is a lot of prose in the human lingua franca wherever you code. (Probably American English but that's another screed.) That means people with coding chops also need literary chops. Or a friend who has them. It means that you're not only judged on how well you solve problems with code, not only with how easy that code is to inherently understand, but also judged on how well you can explain to someone else what it is and how to use it. If you really need that heavy documentation, hire a tech writer. Just like you probably specialize in a kind of dev, you can find specialists who specialize in making things make sense to devs. (I often recommend diagrams just to make boundaries clear to everyone "at a glance" but don't think those really count as documentation in this context.)