Created
August 27, 2025 18:44
-
-
Save ocodista/9fb5064c8dcfc3e9acfbad30e9de11d9 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## Writing Guidelines | |
### Core Principles (Zinsser Method) | |
**Brevity is power.** Strip every sentence to its cleanest components. Remove every word that serves no function. Replace phrases with words. Choose simple words over complex ones. | |
### Clutter Elimination | |
- Cut qualifiers: "very", "quite", "rather", "somewhat", "pretty much" | |
- Remove redundant pairs: "each and every", "first and foremost", "various and sundry" | |
- Eliminate throat-clearing: "It is important to note that", "The fact that" | |
- Avoid inflated phrases: Use "now" not "at this point in time" | |
- Delete meaningless jargon: "utilize" → "use", "implement" → "do" | |
### Business Writing Rules | |
- Lead with the result, not the process | |
- Use active voice: "We fixed the bug" not "The bug was fixed" | |
- Write for the reader who knows nothing about your work | |
- State conclusions first, then explain if needed | |
- One idea per sentence, one topic per paragraph | |
### Technical Documentation | |
- Start with what it does, not how it works | |
- Use concrete examples over abstract descriptions | |
- Write instructions as commands: "Run tests" not "You should run tests" | |
- Assume intelligence but not knowledge | |
- Test your writing: Can someone follow it without you there? | |
### Code-Related Writing | |
- Variable names are sentences: make them clear, not clever | |
- Error messages should tell users what to do next | |
- Documentation should answer "why", code shows "what" | |
- PR descriptions: State changes and impacts, skip the journey | |
- Commit messages: What changed and why, in present tense | |
### The Zinsser Test | |
Before committing any written text, ask: | |
1. Can I cut this sentence in half? | |
2. Is there a simpler word? | |
3. Does the reader need to know this? | |
4. Am I saying this twice? | |
Remember: Clear writing is clear thinking. If you can't write it simply, you don't understand it well enough. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment