Some say documentations are as important as code itself, just like testing. Though there are established, wide-spread best-practices, resources and examples for testing, but not much for documentations.
So:
Do you write documentations?
Yes, a lot. I do a lot of work on UI libraries and other things with APIs. For projects like that, anything you don't document may as well not exist at all. For other projects, I'm regularly documenting onboarding/setup guides so people (or just me in a year) can easily learn how to get the project up and running.
What role do you think documentations play in writing good code/software?
They reduce risk, increase developer engagement... basically good docs make for a happy team.
What are the best practices you've seen/heard/used in writing documentations?
What are you trying to avoid in documentation? (bad practices? common mis-conceptions?)
Kevin Pliester
Webdev
Basically I try to write the code in a way that you can understand it. Add a little bit of comments and the interactive documentation is ready.
For public projects or things I don't have to approach often, I also write documentation. But basically I stick to it and say: The code must be able to explain itself.