One issue with making documentation longer is that if the product is not completely static, e.g. an API, then there is a lot more documentation that needs regular updating, and if there are redundant explanations, the chance of them differing is non-zero. Most of the time when our customers tell me the documentation wasn't extensive enough, I quickly notice they didn't actually read what was offered. They were looking for a specific example and if that wasn't offered on a silver platter, they would just immediately give up, instead of reading the actual text (which would have given them the tools to construct the example)
You might enjoy the manuals for kits produced by https://qrp-labs.com. They have been likened to Heathkit manuals more than once, and they are extremely thorough and extensive, with a full discussion of the engineering behind each kit, troubleshooting guides, PCB layouts, schematics, the whole 9 yards.
One issue with making documentation longer is that if the product is not completely static, e.g. an API, then there is a lot more documentation that needs regular updating, and if there are redundant explanations, the chance of them differing is non-zero. Most of the time when our customers tell me the documentation wasn't extensive enough, I quickly notice they didn't actually read what was offered. They were looking for a specific example and if that wasn't offered on a silver platter, they would just immediately give up, instead of reading the actual text (which would have given them the tools to construct the example)
You might enjoy the manuals for kits produced by https://qrp-labs.com. They have been likened to Heathkit manuals more than once, and they are extremely thorough and extensive, with a full discussion of the engineering behind each kit, troubleshooting guides, PCB layouts, schematics, the whole 9 yards.
FWIW, IMO, the 'key binding people' are the most efficient computer users.