This is one of my favorite topics! The basic process I follow is:
1. Imagine you are a use who knows nothing about your framework. What would you need to know next?
2. Write that.
Step one is really really hard. It takes a powerful imagination to pretend that you don't know something and hop the fence from framework producer to framework consumer. There's no easy way to do this aside from practice and talking to users lots.
In terms of just generally writing better, here's some basics:
1. Revise. Revise. Revise. That writer you love's first draft is just as shitty is yours. The difference is you never see their first draft, you see their eighteenth.
2. Reading out loud helps a lot. Yes, even for technical docs. Yes, it feels weird. Do it anyway.
3. Brevity matters: you want to distill your knowledge to its essence. But note that it's a distillation process. In your first draft, just dump it all out. Worry about condensing when you revise.
4. The written word, especially technical writing, by default, comes across as emotionally cold and unfriendly. Words don't have facial expressions and tone of voice. While technical writing isn't read purely for pleasure, you'll get a lot of value out of trying to make it a little more engaging and pleasant to read. Don't be afraid of a little emotional language. You'd be surprised how much of a different starting a paragraph with "I'm really excited about this feature..." makes.
5. Give someone a couple of examples and they'll delight in finding the generalization on their own. Going the other direction is a lot less fun.
6. Different readers have different learning styles. You may have to say the same thing in a few different ways or a few different orders to reach them all. Balancing this with #3 is an art form.
The fact that you're asking at all is a great sign. (See! More positive language!) If you care about your docs as much as you do about your code, that is, by far, the most important ingredient to being a good writer.
1. Imagine you are a use who knows nothing about your framework. What would you need to know next?
2. Write that.
Step one is really really hard. It takes a powerful imagination to pretend that you don't know something and hop the fence from framework producer to framework consumer. There's no easy way to do this aside from practice and talking to users lots.
In terms of just generally writing better, here's some basics:
1. Revise. Revise. Revise. That writer you love's first draft is just as shitty is yours. The difference is you never see their first draft, you see their eighteenth.
2. Reading out loud helps a lot. Yes, even for technical docs. Yes, it feels weird. Do it anyway.
3. Brevity matters: you want to distill your knowledge to its essence. But note that it's a distillation process. In your first draft, just dump it all out. Worry about condensing when you revise.
4. The written word, especially technical writing, by default, comes across as emotionally cold and unfriendly. Words don't have facial expressions and tone of voice. While technical writing isn't read purely for pleasure, you'll get a lot of value out of trying to make it a little more engaging and pleasant to read. Don't be afraid of a little emotional language. You'd be surprised how much of a different starting a paragraph with "I'm really excited about this feature..." makes.
5. Give someone a couple of examples and they'll delight in finding the generalization on their own. Going the other direction is a lot less fun.
6. Different readers have different learning styles. You may have to say the same thing in a few different ways or a few different orders to reach them all. Balancing this with #3 is an art form.
The fact that you're asking at all is a great sign. (See! More positive language!) If you care about your docs as much as you do about your code, that is, by far, the most important ingredient to being a good writer.