Technical Writing Best Practices for Engineers
A practical guide to the writing engineers do every week, checked against Google's free technical writing courses, the Diátaxis documentation framework, Google's engineering practices on change descriptions and GitHub's documentation. It covers audience and purpose, clear sentences, structure, design docs, READMEs and documentation, pull request descriptions, async updates, blog posts and editing.
9
Sefism · Oct 2026
31
Sefism · Oct 2026
8
Sefism · Oct 2026
Career
Sefism · Oct 2026
Best practices
Career Growth
Sefism
18 min read
All
Free
What this best practices guide is
A practical guide to the writing engineers do every week, checked against Google's free technical writing courses, the Diátaxis documentation framework, Google's engineering practices on change descriptions and GitHub's documentation. It covers audience and purpose, clear sentences, structure, design docs, READMEs and documentation, pull request descriptions, async updates, blog posts and editing.
It has 9 chapters and 31 practices, each with why it matters, what to do and what to avoid. For developers who write docs, PRs and updates.
Chapter by chapter
1. Know your audience and purpose (4 practices)
Every good technical document starts with two decisions: who is reading, and what they need to do or know afterwards.
2. Write clear sentences (4 practices)
Short, active, consistent sentences are the cheapest improvement you can make to anything you write.
3. Structure documents for busy readers (4 practices)
Most readers scan before they read. Put the point first, use headings that say something, and make tables and lists do the work.
4. Write design docs people can review (3 practices)
A design doc is a tool for getting feedback before code exists. Write it so reviewers can find the decision and challenge it quickly.
5. Write READMEs and documentation that get used (4 practices)
A README is the front door of a project. Documentation keeps it usable after the people who built it move on.
6. Write pull request descriptions and commit messages (3 practices)
The description is the first thing a reviewer reads and the record future engineers find in the history. Make it carry the why.
7. Write async updates and messages (3 practices)
Distributed teams run on written updates. Make them quick to read, honest about risk and clear about what you need.
8. Write technical blog posts (3 practices)
A good technical post teaches one thing to one kind of reader, with real examples and honest limits.
9. Edit and get reviews (3 practices)
First drafts are for getting ideas down. Editing, and a second pair of eyes, is where writing becomes clear.
How it works on Sefism
The guide reads like a short course: a syllabus, then one chapter per page in a focused reader, with a quiz at the end of each chapter for members. The opening chapters are open to everyone. Adding it to your account uses credits, opens every chapter and keeps your progress.
Every claim is checked against the sources listed on the page (8 cited).
Ready to start?
Opens on Sefism in a new tab.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.