The Complete Developer Writing Guide: Design Doc, RFC, Blog, Book, Conference Talk (2025)

Intro — "My coding is the best on the team. Why can''t I get promoted?"

A 5-year Senior Engineer:

"My technical skills are top on the team. My code quality is top. But every time, I get rejected for Staff promo."

The answer: Staff+ levels are evaluated by writing. The Design Docs, postmortems, RFCs, blog posts, and memos you''ve written — that''s your influence. A single well-written Design Doc helps more with promotion than 10,000 lines of code.

A well-known Google internal study: Staff+ engineers spend 30–50% of their time writing. They''re less "developers" and more "technical writers."

This post covers:

Design Doc — structure, templates, failure modes
RFC process — Rust/Python/Node compared
Tech blogs — dissecting Julia Evans, Dan Luu, Stratechery
Tech books — O'Reilly, Manning, self-publishing
Conference talks — from CFP to the podium
Staff+ promo packets
Writing in the AI era — Claude/Copilot workflows
Korean vs English — strategy for Korean developers

Season 3 Episode 7. The previous post covered OSS maintainer README files; this one zooms out to cover every form of developer writing.

Chapter 1: Design Doc — the writing that comes before the code

1.1 What is a Design Doc?

A Google-rooted culture since around 1999. Before writing non-trivial code, you write a 4–30 page document and get it reviewed.

Purpose:

Clarify your thinking (if you can''t write it, you don''t understand it)
Gather better reviewer feedback
Organizational learning (searchable in the future)
Onboarding material for new hires

1.2 Google''s Design Doc template

1. Title
2. Author(s) + Date + Status
3. Summary (1 paragraph: problem + proposal)
4. Background (terminology, current system, problem)
5. Goals / Non-Goals
6. Design Overview (diagram + main components)
7. Detailed Design
   - Data Model
   - API
   - Algorithms
   - Error handling
8. Considered Alternatives (2-3 alternatives + comparison + why not chosen)
9. Cross-cutting Concerns (security, privacy, performance, cost, observability)
10. Rollout Plan (stages, rollback, migration)
11. Open Questions
12. Appendix (raw data, benchmarks)

1.3 What a good Design Doc looks like

Start from the problem: what is wrong and why. Not "let''s adopt microservices" but "deploy time is 45 min, users are complaining."
Measurable goals: not "faster" but "p99 under 200ms."
Honest alternative comparison: not "ours is the best" but "A is faster but costs 2x; B is cheaper but more complex."
Address dissent: include a FAQ section that anticipates "you might be thinking..."
Evidence via numbers: benchmarks, cost estimates, QPS estimates.

1.4 Common bad Design Doc mistakes

"What" without "Why": only says what will be done, not why
Too long: 50 pages, no one reads it
Too short: 1 page, missing details
Terminology drift: same concept named differently in different places
No conclusion: lots of discussion, no decision

1.5 Getting it reviewed

Reviewer selection:

Tech Lead of the directly impacted team
Cross-functional (Security, SRE)
Staff+ engineers (overall direction check)

Review period: 1–4 weeks. Too short, insufficient feedback; too long, you miss the window.

Handling feedback:

Respond to every comment (agree / partially agree / disagree)
Log major changes in a changelog
Unresolved issues go into Open Questions

1.6 Case study — Amazon''s narrative memo

Amazon uses a 6-page narrative memo. Less structural, but:

Prose sentences (no bullets)
Concrete data
Preempts dissent (FAQ)
Customer perspective

Jeff Bezos''s bar:

"A great memo reads like it was written by a good journalist covering a complex story."

Chapter 2: RFC — community-wide decisions

2.1 When you need an RFC

Impacts multiple teams / organizations
Potentially breaking changes
Critical to long-term direction
Requires external community consensus

Design Docs stay within a team or org. RFCs target a broader community + a formal process.

2.2 Rust''s RFC process

Discussion: brainstorm on Rust Internals forum
Submit PR: Markdown PR to the rust-lang/rfcs repository
Community discussion: weeks to months
Final Comment Period (FCP): 10-day final feedback window
Merge or Postpone: core team consensus

Public examples: async/await, GAT (Generic Associated Types), const generics.

2.3 Python''s PEP

PEP 1: the process itself
PEP 8: style guide
PEP 20: Zen of Python
PEP 8016: Steering Council model

PEPs are more formal than Rust RFCs. Notable PEPs:

PEP 492 (async/await)
PEP 572 (walrus operator :=)
PEP 657 (fine-grained error locations)

2.4 Node.js TSC

Node uses no formal RFC; instead it relies on the TSC (Technical Steering Committee) vote + Collaborator consensus.

Small changes: Collaborator PR
Large changes: TSC meeting + vote

2.5 IETF RFC vs Project RFC

Don''t confuse them: IETF RFCs (internet standards like HTTP/TCP) and project RFCs are different beasts.

IETF: internet standard documents. Permanent numbers. Example: RFC 9110 (HTTP/1.1)
Project RFC: individual project proposals.

2.6 Tips when writing an RFC

Don''t aim for a perfect one-shot: publish a draft, iterate across versions
Motivate fully: "why now, why this approach"
Alternatives considered: mandatory
Migration path: if it breaks things, show the migration
Backwards compatibility: state it explicitly

Chapter 3: Tech blog — long-term asset

3.1 Why blog?

A common trait among Staff+ engineers: a blog. Because it gives you:

Writing practice: the cheapest training
Clarified thinking: writing deepens understanding
Network: readers → colleagues → opportunities
Search pull: opportunities find you through Google
Promo evidence: external influence

3.2 Types of blogs

1) Deep-dive: 10,000+ words on one topic. Example: Julia Evans''s "How does a database work?"

2) Notes: quickly writing up what you learned. Example: Simon Willison''s weblog.

3) Opinion: industry analysis. Example: Stratechery (Ben Thompson), Overreacted (Dan Abramov).

4) Tutorial: step-by-step. Example: Josh Comeau, Kent C. Dodds.

5) Newsletter: regular curation. Example: Pointer, TLDR.

3.3 Julia Evans analysis

Blogging since 2013
Signature: comic-style technical explanations ("zines")
Topics: Linux, systems, debugging
Income: zine sales ( $20–$ 40), Ruby Central consulting
Left Stripe in 2022 → full-time writer

Lesson: niche expertise + distinctive style = fandom.

3.4 Dan Luu analysis

Stack / hardware / performance specialist
Signature: long posts (10k–30k words), paper-grade research
"Why are computers slow?" and other deep research pieces
About 20 posts per year
Income: mostly from his day job (Microsoft → Twitter → current)

Lesson: rare topics + depth = authority.

3.5 Stratechery (Ben Thompson)

Tech business analysis blog + podcast
Independent via a $12/month subscription model
Estimated several million in annual revenue
Introduced frameworks like "Aggregation Theory"

Lesson: don''t chase the news cycle; build analytical frameworks.

3.6 Starting a blog

Platform options:

Self-hosted: Next.js + Vercel, Astro, Hugo (like this blog)
Medium: easy, discoverable, but you don''t control it
Substack: newsletter + blog combined
dev.to: developer community
Hashnode: free custom domain

Recommend self-hosting: long-term assets should be yours.

3.7 Finding topics

Something you learned recently (best — explaining locks it in)
Questions you get asked often
Correcting misunderstandings
Adding your take to an industry debate
A topic you deep-dove (10 other blogs/papers + your own experience)

3.8 Publishing cadence

1–2 per week: too much, quality drops
1–2 per month: sustainable, maintains quality
1 per quarter: deep long-form

Consistency beats volume. One monthly quality piece beats five rushed weekly posts.

3.9 SEO and distribution

SEO:

Keywords in the title
Meta description
H2/H3 structure
Internal links (related posts)
Image alt text

Distribution:

Twitter/X
Hacker News (good times: weekday US morning)
Reddit (relevant subs)
LinkedIn (industry readers)
Slack communities

Chapter 4: Publishing a tech book

4.1 Choosing a publisher

O'Reilly:

Top industry brand ("the animal books")
Advance: $10K–$ 30K
Royalty: 10–15%
Rigorous editing, strong brand leverage
1–2 years to publication

Manning:

Practitioner-focused
MEAP (Manning Early Access Program): sells unfinished drafts
Fast reader feedback
Lower bar than O'Reilly

Pragmatic Bookshelf:

Developer audience
Technical depth
Author-friendly terms

Packt:

Fast turnaround, high volume
Variable quality

Self-publishing (Leanpub, Gumroad):

80–95% royalty
Full control
Marketing is on you

4.2 How long it takes

Reality: 1000–1500 hours on average. Over 18 months that''s 15 hours/week (weekday evenings + weekends).

A ** $30K advance** works out to$ 20–$30/hour. Far less than your day job.

So why write one?: not the money — brand, authority, career. "Published author" is a lifetime asset.

4.3 Success story — DDIA (Designing Data-Intensive Applications)

Author: Martin Kleppmann
O'Reilly, 2017
200,000+ copies sold
Required reading for Silicon Valley interviews
Author is a Cambridge researcher + various consulting gigs

Secret: the definitive book for one field (distributed systems).

4.4 Success story — Rust books

The Rust Programming Language (free + paid publisher edition)
Rust for Rustaceans (Jon Gjengset)
Programming Rust (O'Reilly)
Zero to Production in Rust (Luca Palmieri, self-published)

Lesson: official book + deep-dive + applied — the full combo.

4.5 The evolution path of writing

Blog post → Series → eBook → Print book
     ↓
  Conference talk → Course → Book

If a blog post resonates, expand it. Gradual growth beats a big-bang launch.

Chapter 5: Conference talks

5.1 Why speak?

20x the impact of a blog post (focused audience)
YouTube turns it into a permanent asset
Explosive network expansion
A major weapon for a promo packet

5.2 CFP (Call for Proposal)

Submit talk title + abstract
Acceptance rate: 5–20% at major conferences
The abstract quality decides your fate

A good abstract:

Specific title ("What we learned migrating X to Y")
Problem + solution + lessons
Explicit audience takeaways
Speaker credentials

5.3 Major Korean conferences

FEConf: frontend
JSConf Korea: JavaScript
PyCon Korea: Python
SIF (Samsung Innovation Forum)
NHN FORWARD
NAVER DEVIEW
Kakao if(kakao)
Woowacon: Baemin
Toss PLANET

5.4 Global conferences

KubeCon (CNCF): K8s/cloud-native
Strange Loop (ended 2023): deep CS
QCon: practitioner-focused
RustConf, GopherCon, PyCon, RubyConf
JSConf, React Summit, Next.js Conf
Monktoberfest: developer culture/career

5.5 Preparing the talk

8–12 weeks out:

Submit abstract
Draft slides

6 weeks out:

Internal rehearsal (2–3 colleagues)
Demo scripts

2 weeks out:

External rehearsal (similar community)
Time check

Day of:

Arrive 1 hour early
Test equipment
Bring a backup laptop

5.6 Slide design

1 idea = 1 slide
Minimal text (let the speaker talk)
28pt+ font
High-resolution screenshots
Build up complex architecture diagrams in stages

5.7 Handling Q&A

"Good question, I''m not sure — I''ll follow up" is fine if you don''t know
Contentious questions: leave emotion out
Long questions: summarize, then answer

5.8 Success story — Bryan Cantrill (Oxide CTO)

Co-created DTrace at Sun Microsystems
Talks are story-driven, heavy on humor
Technical drama like "Scheduling Policy Hang"
Hundreds of thousands of YouTube views

Lesson: technical depth + storytelling.

Chapter 6: Staff+ promotion packet

10–50 pages
Written jointly by manager + self
4–7 peer reviews
Reviewed by a calibration committee

6.2 Structure

Summary: one-line recommendation
Impact: major contributions over 6–12 months
Complexity: technical difficulty
Scope: team → org → company level
Leadership: mentoring, interviewing, external work
Feedback: peer comments

6.3 The STAR format for each contribution

Situation: context Task: your responsibility Action: what you did Result: measurable outcome

Example:

"[S] Payment system p99 was 800ms, user drop-off was 12%. [T] As Staff Eng, I owned the performance effort. [A] Added distributed caching, optimized queries, moved to async processing. [R] p99 dropped to 150ms, drop-off fell 5%, revenue up $2M."

6.4 Scope matters

Senior: solves team problems
Staff: impacts beyond the team
Senior Staff: entire org
Principal: entire company

Same project, different framing: "I built it alone" vs "I standardized it across 5 teams."

6.5 Requesting peer feedback

Diverse perspectives (up / down / lateral)
Ask for specific examples
Quality over quantity

6.6 If you didn''t make it

Honest conversation with your manager
Identify the gap (Impact? Leadership? Writing?)
Draft a 6-month plan
Go for the next cycle

Chapter 7: Writing in the AI era

7.1 What not to do with AI

Generate entire posts: easy to spot, no personality
Copy-paste rough output: hallucination risk
Lean on it without your own thinking

7.2 What AI is great for

1) Idea brainstorming:

"Suggest 3 alternatives for this Design Doc topic, with pros and cons."

2) Structural feedback:

"Point out the logical weaknesses in this blog draft."

3) Grammar / awkward phrasing:

"Polish this sentence into natural English, keeping the meaning."

4) Anticipating questions:

"List 5 pushbacks a tech lead might have on this RFC."

5) Summary drafting:

"Write a 3-line TL;DR of this long post."

7.3 AI ethics

Disclose: say "the draft was AI-assisted"
Fact-check: always verify AI output
Preserve voice: your style comes first

7.4 Copilot in writing

Autocomplete for Markdown in VS Code
Sentence completion, bullet generation
Caution: let it finish sentences, but decide the meaning yourself

7.5 Claude/GPT workflow

You: write a draft
AI: structural feedback
You: revise
AI: grammar/phrasing polish
You: final check, restore your voice
AI: suggest 10 titles → you: pick one

Chapter 8: Korean vs English

8.1 Writing only in Korean

Pros:

100% reach for Korean readers
Emotional nuance flows naturally
Tighter community connection

Cons:

Limits global opportunities
Hard to build a global brand

8.2 Writing only in English

Pros:

Global readership
Leverage for overseas hiring / consulting
English skills improve

Cons:

Fewer Korean readers
Painful early on

8.3 Bilingual strategies

Option A: English original → Korean summary translation Option B: Korean original → short English summary Option C: Split by topic language (local issues in Korean, global issues in English)

A fully bilingual site like this blog is possible but expensive.

8.4 English writing tips for Korean developers

Short sentences: avoid deeply nested relative clauses
Active voice: "We decided to..." beats "It was decided that..."
Clarity over flourish: hard words do not equal good writing
Editing tools: Grammarly, Claude, DeepL Write

8.5 Good Korean-language blogs

Park Jae-sung (Javajigi)
Kim Young-han (Inflearn lectures + blog)
Woowahan Brothers tech blog
Kakao Tech blog
Toss Tech blog
Daangn Tech blog

8.6 Korean developers writing in English

Dan Luu (video interviews, Twitter)
Evan You (Vue creator — Chinese, but globally active)
A few Korean developers active abroad (Jaejin Kim, Jake Seo, etc.)

English blogging by Korean developers is still wide open.

Chapter 9: Good documentation

9.1 Divio''s 4 documentation types

Divio Documentation System proposes:

Tutorials: learning-oriented (for beginners)
How-to guides: complete a specific task
Reference: precise technical information
Explanation: background and why

Mixing the four causes confusion. Write them separately.

9.2 A good README

Hero: what the project is, in one line
Install: start in under 3 lines
Quickstart: code example
Badges: CI, version, license
Table of contents: for longer READMEs
Contributing, License, Acknowledgments

9.3 Changelog

Keep a Changelog style
Added / Changed / Deprecated / Removed / Fixed / Security
User-centric wording (call out "Breaking:" explicitly)

9.4 API docs

OpenAPI/Swagger auto-generation
Request/response examples are mandatory
All error codes
Rate limits spelled out

Chapter 10: Building writing muscle

10.1 100 words a day

Consistency is the point. 100 words per day = 36,500 per year ≈ 30–40 blog posts.

10.2 Reading = writing

Read good writing. Read analytically. Ask "why did they write this sentence this way?"

Recommended reading:

Paul Graham essays (conciseness)
Dan Luu (depth)
Julia Evans (clarity)
Simon Willison (consistency)

10.3 Getting feedback

Peers who also write
Writing channels on Discord/Slack
Family/friends (does a non-expert understand?)

10.4 The art of revision

Pass 1: does the meaning land? Pass 2: is the structure clear? Pass 3: are the words precise? Pass 4: does it flow?

Let it sit for at least a day before rereading.

Chapter 11: 10 writing antipatterns

1) Missing the "Why"

Only the "what," no "why." Why first, what second.

2) Jargon overload

Using terms the reader doesn''t know without definitions. Define on first use.

3) Passive-voice abuse

"It was decided" versus "The team decided." Make the actor clear.

4) Bullet overuse

Every sentence is a bullet. No narrative. Prose paragraphs force logical flow.

5) Hedging language

"maybe," "perhaps," "might." Lack of confidence. Assert when you''re sure.

6) Unnecessary preamble

"In this post I will cover the following topics..." is a weak intro. Go straight to the point.

7) No diagrams

Missing architecture or sequence diagrams. Use Excalidraw/Mermaid.

8) No conclusion

Long discussion with no "so what?" Add a call to action or takeaways.

9) Skipping proofreading

Typos and grammar errors erode trust. Read through twice before publishing.

10) Audience confusion

Unclear whether it''s for beginners or experts. State the audience in the first paragraph.

Chapter 12: The 12-item writing checklist

Closing — writing is an engineering skill

Principle 1: writing is thinking

If you can''t write it, you don''t understand it. Einstein: "If you can''t explain it simply, you don''t understand it well enough."

Principle 2: writing often beats writing well

Drop the perfectionism. The first 100 posts will be awkward — keep going. Compounding wins.

Principle 3: multiple formats

Design Doc, RFC, blog, book, talk — each is a different muscle. Mastering only one caps you.

Principle 4: feedback is the fastest path to growth

Ask peers and readers. Swallow the embarrassment.

Principle 5: authenticity over polish

Unvarnished experience is the best content. Don''t be shy about failure stories.

Principle 6: read the originals

Next post — "The complete developer finance guide: salary, stock options, RSU, 401k, startup funding"

Season 3 Ep 8 will cover:

The science of salary negotiation (using Levels.fyi, Blind)
RSU vs stock options: exercise timing, taxes
ESOP and Korean tax law
401k / IRA (US), retirement pensions (Korea)
Startup equity — vesting cliffs, exit scenarios
Real estate vs stocks vs company equity
US relocation taxes (H1B, L1 visa issues)
FIRE (Financial Independence, Retire Early)
Cash flow and dilution when founding a company
Financial planning for developers in their 40s

See you in the next post.