I can only speak from my own experience. In my own experience, commit messages have saved me time. Documentation has saved me time. Not having had these things

I can only speak from my own experience. In my own experience, commit messages have saved me time. Documentation has saved me time. Not having had these things has sent me down hours long rabbit holes having to figure out why something existed. Reading the code doesn't tell me anything about why the developer did something a certain way, some important bit of context. Also in my experience, developers who don't explain anything in commit messages also don't explain anything in comments or elsewhere. So my day is spent encountering dozens of Chesterson's Fences. If those fences simply had a sign on them explaining why they were there I could more easily know whether they could be torn down. As a recent example, our macOS build hosts were running an alternate sshd on port 2222. Why was it there? What was wrong with using the sshd on port 22? If I tear it down and it doesn't seem to break anything, should I worry whether there's some use case I hadn't thought of? This alternate sshd was started by a shell script, so there was a place to add a comment saying why it was there, but there was no comment. The shell script was kept in git, but there was no explanation on the commit message or its PR. Eventually I was able to track down that it was due to a bug in Xcode that hadn't been relevant in over 5 years. However much time that developer saved by not documenting their work (a minute? 5 minutes?), I lost more than an hour having to figure out. I'll bet that developer is still going around not documenting their work and maybe they get promoting for shipping things fast. But then they move on and I get their mess.