Saying too much is a very good way to frustrate your audience. They don't want to know everything; they can't absorb it all and they lose the important parts. So follow the cardinal rule of documentation:
Describe the unusual.
Let's assume for the moment that documentation is about describing interaction. It attempts to explain to the reader how to successfully work with the system - whether that interaction is through an API, a GUI, or whatever - and how to understand what the system is doing (i.e., error states, message meanings, etc).
Describing interactions is a huge thing, which is why it's so easy to write a whole lot of documentation. But that's the wrong thing to do. The truth is, most of the time you can assume some basic knowledge, and just describe what's different.
For example, I'm working right now on a logging module for a system. The system right now does ad hoc logging; each component logs in its own way. My logging module will provide centralized logging so we get consistency in log level, storage location, format, etc. When I'm documenting this, what can I assume, and what should I write about?
My audience is other developers who work for this company. They pretty much understand the system, the language, and general development concepts. Great!
So I describe the things that are unusual:
- instantiating this (custom) logger I wrote
- requirements around uniqueness and sharing of loggers (class instances)
- whether it is thread safe (yes) and process safe (no)
- deployment requirements and the configuration format, for the IT guy
- log size and rotation rules, which I got from the IT guy
I don't describe the things that developers generally expect from logging:
- the existence of log rotation and aging
- when to log at various levels (DEBUG vs INFO, etc)
- the format of the log entry
I can skip what people already know, which makes the documentation much shorter and makes the important parts more readily apparent. It's easier for the consumers to read and much more likely to be actually useful.
So when you have to document something, whether it's a multi-day tutorial or a simple comment describing how to use a method, focus on the things that make it unique. Describe the unusual.