miniblog.

← Back to all posts
Jun 25, 2022 at 23:37
Framing documentation work as creative solving of problems, not just writing up stuff made by other people:
How to avoid being a secretary for engineers
How to avoid being a secretary for engineers
If we just see our task as documenting solutions that engineers have solved, it removes the creativity and critical thinking dimension from tech comm. The creative dimension in tech comm comes into play as we identify and solve tech comm challenges, such as devising ways to simplify complexity or otherwise improve the user experience.

Related Posts

Jun 18, 2026 at 08:39
3
I'm exploring how I show lists in my documentation. I like boxes for tidiness, but it's much less space efficient. Which do you prefer? I should also survey how other sites handle this.
Jun 9, 2026 at 16:03
31
When talking about a match or a switch statement, I've typically seen people talk about individual 'cases' or 'arms'. TIL Zig uses 'prongs' instead!
Documentation - The Zig Programming Language
Mar 28, 2025 at 03:21
47
I'm trying to decide the best voice for PL documentation. Passive: "`let` can be used with destructuring." Reader focused: "You can use `let` with destructuring." Describing the PL: "FooLang supports destructuring with `let`." Anyone have opinions or best practices?