> For a long time it has been accepted that you had to read a manual before using something relatively complex, as not everything can be expressed intuitively,

> For a long time it has been accepted that you had to read a manual before using something relatively complex, as not everything can be expressed intuitively, and because intuition is not really universal. Do you know how many pages of software documentation the average person will read in their entire life? Zero. Why? They don't have to, and imposing that requirement yields no benefit. I'm always astonished by the perennial hubris required to glibly assert chemical engineers or historians or teachers or physicists or lawyers or doctors or librarians or literature professors (or even other developers who want to concentrate on other tasks) only avoid software tools with prerequisite study because they're too lazy to read. The purpose of software is to help people more easily solve their problems. The bigger the barrier to entry— prerequisite study for example— the harder it is for most people. That's acceptable if the complexity is genuinely necessary to afford or augment expert usability in purpose-built software, but it almost universally compensates for ham fisted interface design. Interfaces that stop expert users from doing things efficiently and only afford beginner workflows are also poorly designed. Expert vs dumbed down is a false dichotomy. For many FOSS developers and users, tolerating counterintuitive interfaces turned into a badge of honor, and that turned into an aesthetic preference. It's not the default state of software, it does exclude non-technologists, and is why FOSS alternatives are still alternatives for every application not specifically designed to be used by technologists, even though they're free. Every single one. Every professional photographer on the planet who relies on Adobe Photoshop would jump for joy if Gimp even came close to being a sufficient replacement. That preference is also why developers don't generally make significant interface decisions in any professionally managed software project. Not having a technologist's domain knowledge or priorities isn't a contemptible moral failure. Having it doesn't come with design expertise— learning design takes a lot of study and practice, but I'm guessing you have other things you'd prefer to concentrate on learning. Which is fine. Just realize that assuming documentation is sufficient to guide users through software is primarily informed by your not understanding software usability rather than everybody else misgauging the importance of software documentation.