Hacker News new | past | comments | ask | show | jobs | submit login

Having the engineer pair with someone who has never used the product before who also works in your org could help. I have a blog post coming up about this soon!

I wrote documentation for a product earlier this year. A colleague with limited Python knowledge tried out the product using my documentation live, on a call. I learned so much from the process. We found bugs, we noticed that our documentation didn't have one clear usage path, which was confusing, and more.

Watching someone work through your documentation was a bit uncomfortable, but it really helped me. I plan to do it again with another documentation project on my hands.

Also, your colleague may need more direct feedback. I have picked up a lot of tips from the person who edits my work. Sometimes, I have an "aha" moment when I'm like "hm, this approach really is better!" and I take it with me in all that I write after that.

> writing documentation in a conversational style

The medium really matters. If the course was more about tutorials, a conversational style can be appropriate, if kept in check. If you are documenting open source software, it is different. Your colleague probably picked up good tips, but the course may not have shown how to use them properly.




> Having the engineer pair with someone who has never used the product before who also works in your org could help.

I wholeheartedly agree with this. If you do this, especially with a user who is known for asking good questions, you will benefit greatly from it.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: