Page
STYLE.md — Writing Guide for devin.fitzsky.com
STYLE.md — Writing Guide for devin.fitzsky.com
Voice & Tone
- First person, casual. Write like a dev journal. “I built this,” “I ran into,” “here’s what I found.”
- Technical audience. Assume the reader is a developer or engineer. Don’t over-explain basics, but do go deep on the interesting parts.
- Detail matters. Show the commands, the config, the error messages. Readers want to learn from what actually happened, not a summary.
- Conversational, not corporate. No marketing speak. No “leverage” or “utilize.” Write like you’re telling a friend about a project.
- Confident and direct. State things plainly. Skip hedging (“it might potentially be useful to consider…”).
- Light humor when it fits. Dry, understated. Never forced.
Structure
- No rigid template. Each post finds its own shape. Some are walkthroughs, some are reflections, some are deep dives.
- Short paragraphs. 2-4 sentences typical. Let the writing breathe.
- Headers as signposts, not decoration. Use them when the topic genuinely shifts.
- Code and config inline. Use fenced code blocks for commands, snippets, config. Backticks for inline references (
main,bundle exec jekyll serve). - End naturally. Don’t force a conclusion or CTA. A closing thought, a question, or just stopping when you’re done — all fine.
What NOT to Do
- Don’t write intros that restate the title (“In this blog post, I will discuss…”)
- Don’t use bullet lists as a crutch — narrative paragraphs for the main body, lists for genuinely list-shaped things
- Don’t pad posts. If it’s a short topic, write a short post
- Don’t use stock/generic headers like “Introduction” or “Conclusion”
- Don’t write in third person or use “we” (unless genuinely collaborative)
Topics
The blog covers whatever Devin finds interesting enough to write about. Software, systems, infrastructure, tooling, dev workflows, design decisions, things learned the hard way. Not limited to any product or company.
Reference: Qpoint Writing (for longer, more polished pieces)
When writing something more structured (closer to the Qpoint blog style), these patterns apply:
- Scenario-driven openers (drop the reader into a situation)
- Second person present tense for immersion (“You start with a simple plan”)
- Build the problem through narrative, release with structured lists
- Rhetorical bookends (end where you started, reframed)
These are tools in the toolbox, not rules. The personal blog defaults to casual first-person.