Summary of "Writing for Software Developers"

Core Idea

Technical writing is a craft for software-adjacent people, not just “real writers,” and the book argues that good tutorials, docs, and essays can be learned through repeatable process.
The payoff is both practical and cumulative: writing builds skill, reputation, audience, income, teaching ability, and long-term career value because good technical content is scarce.
The book’s core promise is a full workflow for turning an idea into publishable software content, plus the business realities of finding clients, editors, and durable publishing homes.

Kiely’s 9 Questions Process starts with language, topic, experience, and environment to generate article ideas without forcing expertise you do not yet have.
He repeatedly stresses that intermediate knowledge can be an advantage, because you remember beginner confusion and can teach from that position.
Strong ideas often come from prior projects, domain-specific knowledge, or reverse-engineering real systems, which reduce research friction and produce clearer structures.
Before writing, he recommends a rough market check: is there demand, is the topic too broad, and does the idea have a fresh angle or niche.
He distinguishes one-year content from ten-year content: timely pieces may suit clients, while timeless essays and essays-as-blog-posts preserve value for personal brands.
In Chapter 2, “publisher” is broad: magazines, company blogs, documentation projects, and corporate clients all count, and editors are valuable because they improve ideas, structure, and execution.
Pitches should be targeted and concise: brief self-introduction, evidence of credibility, and two or three ideas matched to the publisher’s audience; send one idea to one prospective client at a time.

The book treats technical research as a discipline of cross-checking personal knowledge against multiple sources, because the internet contains a lot of misinformation.
Useful sources include existing projects, market research, academic papers, docs, source code, and interviews; academic material adds credibility, but writers should make their own code samples.
Interviews are split into informational and quoted forms, and the best questions come from deep prior research rather than obvious prompts.
Outlines are working artifacts, not polished documents: define audience, structure, scope, section order, and approximate word counts before drafting.
Audience choice is a narrowing act, not a failure; articles are often better when they assume specific prerequisites instead of trying to explain everything.
For tutorial structure, Kiely favors a linear, onion-like explanation that starts high-level and peels toward details, code, and prerequisites in order.
Sample code should be complete, runnable, and readable; when full projects are too large, provide enough context plus a repository or prepared environment.
He emphasizes Git as a development tool for tracking changes, updating samples, and collaborating, and he prefers Markdown because it fits code and version control.
Graphics are supplements, not substitutes: screenshots help with GUIs, pictures add context, and diagrams are best for structural relationships.

Writing is the hardest part, so the book leans on routines like short scheduled sessions, shitty first drafts, and revising by cutting rather than waiting for inspiration.
Drafts should function like a bridge: code blocks, cited facts, and diagrams are the pylons, while prose explains the why and how between them.
Editing is a second pass after a break, focusing on paragraph logic, missing information, repetition, naming, emphasis, and correctness; code should also be tested in a clean environment.
He recommends reading aloud, following publication style guides, and using beta readers who can say where they were confused, bored, or left with questions.
Technical publishing is easier when writers are easy to work with: editors value responsiveness, clean copy, and the ability to revise without endless back-and-forth.
Self-publishing shifts quality control to the author; formats range from blogs to Ghost, WordPress, static sites, PDFs, ebooks, and print, with tradeoffs in security, durability, effort, and monetization.
The book’s publishing advice is unusually practical about lifecycle: legacy content can still be useful, but deprecated notices and maintenance matter because readers arrive through search.

Teach from the overlap of what you know and what you can research, rather than waiting for complete expertise.
Scope is the main technical-writing skill: the right audience, right depth, and right format matter as much as the topic itself.
Good tutorials are engineered, not improvised: outline, sample code, research, revision, and testing all serve the final reader experience.
Write for durability when you can, because the best technical content compounds in usefulness, reputation, and opportunity over time.