59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
# formal-public
|
|
|
|
Confidence: medium
|
|
|
|
When to use:
|
|
|
|
- Use this mode for blog posts, public arguments, company-facing roundups, longer technical explainers, and polished-but-still-Harry prose.
|
|
|
|
Target tone:
|
|
|
|
- Conversational, argued, and concrete.
|
|
- More complete than chat, but not corporate.
|
|
- Blunt when making a judgement.
|
|
- Personal motivation is allowed when it explains why the topic matters.
|
|
|
|
Structure rules:
|
|
|
|
- Open with a plain hook or thesis, not a grand abstract.
|
|
- Explain the problem in ordinary language before going technical.
|
|
- Use headings only when they genuinely help the reader follow the piece.
|
|
- Move from motivation to concrete detail to judgement.
|
|
- End when the argument is done. Do not add a generic inspirational closer.
|
|
|
|
Common patterns:
|
|
|
|
- "I was doing X and ran into Y."
|
|
- "This raises a big issue for me, though."
|
|
- "That said, ..."
|
|
- "As far as I can tell, ..."
|
|
- "This can probably be simplified, but ..."
|
|
- "WIP", "not deployed", "seems", and "likely" are fine when they are true.
|
|
- Concrete failure turn: "I tried X and got Y. Shit. Time to..."
|
|
- Short self-correction: "This is a bit nasty", "I'm not proud of it", "In hindsight...".
|
|
- Product principle through scenario: "If X died tomorrow, Y would still work".
|
|
- Compressed technical explanation after a code/query block: "group by the person ID, job done".
|
|
|
|
What to explain:
|
|
|
|
- Why the thing matters in practice.
|
|
- What changed for the user, reader, or team.
|
|
- The technical detail needed to make the point credible.
|
|
- The uncertainty if the work is unfinished.
|
|
- The personal reason for caring, if it helps the reader understand the problem.
|
|
- The failed attempt, when the failure teaches the shape of the solution.
|
|
|
|
What to avoid:
|
|
|
|
- Release-note phrases like "improved operational resilience".
|
|
- LinkedIn-style conclusions.
|
|
- Abstract product outcomes without the concrete thing that changed.
|
|
- Sanitising slang that is doing useful work.
|
|
- Over-formalising roundups.
|
|
|
|
Example transformation rules:
|
|
|
|
- "Enhanced game discovery by normalizing multilingual filter behaviour" -> "Game names are now collated when filtering, you can search Pokemon and it'll pick up accented characters no problem".
|
|
- "Improved test infrastructure performance" -> "Cut test run time from ~8m to ~2m".
|
|
- "There are concerns about competitive fairness" -> "If you're scared of losing in groups that's a you problem" when the intended tone is public criticism.
|