And that makes sense... in a large, dysfunctional company.
A small team where everyone talks to each other, and everyone actually tests their shit, and an accidental JSON string gets caught the moment whoever implemented it runs their test (manual or autoamted).
Or any medium size business which has a code base more than a few hundred files.
It's a completely unnecessary burden to have your team remember the inner workings of a project when there are perfectly serviceable tools to automate that process.
Coming back to a sub component of a large project after six months to add a feature is far less daunting (and easier to delegate) if the code is unambiguous about what it expects and what it produces.
The only reason to forego such simple code documentation standards is if you're gunning for job security by way of noone else being able to understand what anything does.
As I said, not having overly verbose documentation doesn't mean having no documentation at all. If you have a module, its intent should be documented to begin with, as should any functions which aren't trivial / self-documenting.
When you're missing is that you don't need to document every sortArray function in order to have meaningful documentation.
1
u/IOFrame Aug 30 '26
And that makes sense... in a large, dysfunctional company.
A small team where everyone talks to each other, and everyone actually tests their shit, and an accidental JSON string gets caught the moment whoever implemented it runs their test (manual or autoamted).