> Docs aren't hard to write, and if you have to, you should just copy paste them from your comments and/or unit tests (unless you haven't written any of course)

> Docs aren't hard to write, and if you have to, you should just copy paste them from your comments and/or unit tests (unless you haven't written any of course). I've seen some companies doing that (worse, I've seen them doing it with their programmers' reference guides -- not for libraries, but for hardware devices). The result is nothing short of catastrophic. They are, by far, the worst and least usable docs I've ever read. They are so mind-bogglingly bad that it would probably be better if they didn't publish them at all, and just made it easier to get a hold of sample code for their development boards. I don't know if dedicated technical writers with no technical experience are the way to go, and I am more partial to paying big bucks to software developers who also know how to write well, but I might be a little biased here :-). But coming from a "docs aren't hard to write" perspective is a really bad idea. Good documentation is extremely hard to write (anecdotally, if I'm covering a complex topic, it sometimes takes me more time to figure out which terms to introduce and in what order than it takes me to actually write the damn thing). Once you know the language, writing stuff that computers understand is orders of magnitude easier than writing stuff that people understand well -- unlike people, computers work the same way, and many instances of unclear language are also syntax errors, so there's less potential for disastrously misunderstanding things. (Sauce: many lifetimes ago, I used to work for a computer magazine, the printed kind, so I'm the one who always gets sent to confer with the tech writers, I write "getting started" guides for new colleagues and so on.)