I don't know of any resources offhand, but the principles of technical writing are very similar to code writing. The biggest difference is that computers only need to be told once, whereas humans need a few (controlled) repetitions and some examples in order to digest something.
- Don't Repeat Yourself: Describe it in one place, and then refer to it elsewhere in the document.
- Componentize: Build up smaller concepts and then use those smaller concepts to build up bigger concepts, etc. Then you can continue to use simple language with the bigger concepts that are easily broken down because they in turn are described in full.
- Each part does one thing and does it well. Don't mix many different concepts in one description. Describe one thing well, and reference it elsewhere.
- Keep things short. The longer a section is, the harder it is to absorb.
- Naming is important. Use memorable, descriptive names for your concepts.
- Have examples that demonstrate your concepts. Don't try to pack many concepts into a single example; that just makes it harder to figure out.
- Have a glossary if there are more than 10 new concepts.
- Test your documentation on people who are unfamiliar with the project. Ask them where they're getting confused. Confusion is the human manifestation of a bug in your documentation.
- Always keep your goal in mind. What should the end result be with your reader? Anything taking longer than 10 minutes is a chore, and only the most dedicated would continue that far.
- U/X is important. UI layouts, source code, and documentation all have U/X components to them because a human will be interacting with them / consuming them in some form. Make it easy for them to navigate to what they need.
- Don't Repeat Yourself: Describe it in one place, and then refer to it elsewhere in the document.
- Componentize: Build up smaller concepts and then use those smaller concepts to build up bigger concepts, etc. Then you can continue to use simple language with the bigger concepts that are easily broken down because they in turn are described in full.
- Each part does one thing and does it well. Don't mix many different concepts in one description. Describe one thing well, and reference it elsewhere.
- Keep things short. The longer a section is, the harder it is to absorb.
- Naming is important. Use memorable, descriptive names for your concepts.
- Have examples that demonstrate your concepts. Don't try to pack many concepts into a single example; that just makes it harder to figure out.
- Have a glossary if there are more than 10 new concepts.
- Test your documentation on people who are unfamiliar with the project. Ask them where they're getting confused. Confusion is the human manifestation of a bug in your documentation.
- Always keep your goal in mind. What should the end result be with your reader? Anything taking longer than 10 minutes is a chore, and only the most dedicated would continue that far.
- U/X is important. UI layouts, source code, and documentation all have U/X components to them because a human will be interacting with them / consuming them in some form. Make it easy for them to navigate to what they need.