I don't know why this is such a common opinion. I'm reluctant to write docs exactly for the reason of not knowing the best tool for the job (or even an "ok-tool

I don't know why this is such a common opinion. I'm reluctant to write docs exactly for the reason of not knowing the best tool for the job (or even an "ok-tool"), and I don't really have a luxury of finding it out exactly because I'm a developer and have stuff to do aside from writing docs. If I already had developed a workflow for writing docs, I assure you, writing a manual would be no different to me from writing a parser or some RPC-server or whatever. The only difference is I already have a workflow suitable to write parser, because I've written tens of them, maybe over a hundred already. I'm only thinking about the business-logic, my fingers just do the job. On the contrary, when I'm trying to write a manual larger than a few screens, say, docs for an API with more than 20 entries, I have to think about the tools to write, compile and display the documentation in a way to be comfortable for both the developer and the user. I'm not in a mood to write my own, and the Internet recommends me to use something that requires installing whole Ruby dev-stack (and I don't use Ruby) and produces something hardly even readable. That's why using markdown + pandoc, or even google docs might be something I resort to. If somebody would show me "The Way", spending a day or even a week to get fluent with the tooling I can use from now on would seem to me a minor nuisance, hardly even noticeable.