Split View: 개발자 글쓰기 완전 가이드: Design Doc, RFC, Blog, 책, 컨퍼런스 발표까지 (2025)

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:

1. Design Doc — structure, templates, failure modes
2. RFC process — Rust/Python/Node compared
3. Tech blogs — dissecting Julia Evans, Dan Luu, Stratechery
4. Tech books — O'Reilly, Manning, self-publishing
5. Conference talks — from CFP to the podium
6. Staff+ promo packets
7. Writing in the AI era — Claude/Copilot workflows
8. 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

1. Start from the problem: what is wrong and why. Not "let''s adopt microservices" but "deploy time is 45 min, users are complaining."
2. Measurable goals: not "faster" but "p99 under 200ms."
3. Honest alternative comparison: not "ours is the best" but "A is faster but costs 2x; B is cheaper but more complex."
4. Address dissent: include a FAQ section that anticipates "you might be thinking..."
5. 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

1. Discussion: brainstorm on Rust Internals forum
2. Submit PR: Markdown PR to the rust-lang/rfcs repository
3. Community discussion: weeks to months
4. Final Comment Period (FCP): 10-day final feedback window
5. 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

1. Don''t aim for a perfect one-shot: publish a draft, iterate across versions
2. Motivate fully: "why now, why this approach"
3. Alternatives considered: mandatory
4. Migration path: if it breaks things, show the migration
5. 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:

1. Specific title ("What we learned migrating X to Y")
2. Problem + solution + lessons
3. Explicit audience takeaways
4. 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

6.1 Google''s promo packet

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

6.2 Structure

1. Summary: one-line recommendation
2. Impact: major contributions over 6–12 months
3. Complexity: technical difficulty
4. Scope: team → org → company level
5. Leadership: mentoring, interviewing, external work
6. 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

1. You: write a draft
2. AI: structural feedback
3. You: revise
4. AI: grammar/phrasing polish
5. You: final check, restore your voice
6. 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:

1. Tutorials: learning-oriented (for beginners)
2. How-to guides: complete a specific task
3. Reference: precise technical information
4. 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

• Title: specific, searchable
• First paragraph: clear on why to read
• TOC: required for long posts
• Why → What → How order
• Diagrams: for every complex concept
• Code samples: they actually run
• Alternatives discussed: why you didn''t pick them
• Numbers: measurement, not guessing
• Takeaways: what the reader gained
• References: link the originals
• Proofreading: spelling, links
• SEO metadata: description, OG image

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

• On Writing Well — William Zinsser
• Designing Data-Intensive Applications — Martin Kleppmann
• Writing docs as a developer — Julia Evans zines
• Design Docs at Google — Malte Ubl
• Staff Engineer''s Path — Tanya Reilly
• Storytelling with Data — Cole Knaflic

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.