TL;DR: Writing offers developers more leverage than code. RFCs (Request for Comment) are your secret weapon to accelerate your career faster than any PR ever could.
Most junior engineers believe their job is writing code.
They’re wrong.
The engineer’s job is to solve problems. Code is just one tool. Writing is another.
We default to coding, because we know it’s scalable. Write it once, run it everywhere, anytime.
But the engineers who shaped the internet weren’t grinding LeetCode. They didn’t obsess over the latest JavaScript framework. They’re write documents that influenced how entire companies build software.
You can join them.
The Trap
Every junior dev falls into the same trap.
They think good code speaks for itself. They measure success by commits and PRs, not business impact.
Reality check: your best code will be seen by 3 people and rewritten in 18 months.
A mediocre doc can be referenced by 30 engineers and influence decisions for 3 years.
This isn’t what they taught you in school. But it’s how things work. And you can either resist it or accept it.
Writing is Engineering at Scale
Every single protocol you use today — HTTP, TCP, DNS, SMTP — started as a written document. Not code. Words.
Tim Berners-Lee didn’t start by building parsers. He started by writing proposals that framed the vision for the web. Those documents—like his 1989 memo at CERN—convinced others to implement his ideas. Later, the IETF codified web standards into RFCs, which spread globally. His writing, not just his code, changed how billions communicate.
When you write for engineers, you’re practicing the same skill that built the internet.
Writing is Permission-Less
Most career growth requires permission:
Want to use a new framework? Need IT’s approval
Want to refactor the DB? Need the DBA’s buy-in
Want to attend that conference? Need manager’s budget approval
But writing? Writing is different.
You can write a proposal for any technical challenge your team faces. You can email your manager a detailed proposal tomorrow morning. You can start a technical discussion that influences the opinions of your entire engineering team.
No permission required.
This is your fastest path from “jr dev who codes features” to “Senior Engineer We Can’t Afford to Lose.”
Most engineers wait obediently for someone to give them a seat at the table.
You can write your way to the table today.
The ROI on Clear Thinking
Here’s how to think about the economics of writing:
The RFC ROI Calculator
Time to write RFC: X hours
People impacted: Y engineers
Cycle time saved per person: Z hours
Meetings prevented: M meetings × P people × H hours
ROI = (Y × Z + (M × P × H)) / X
Real Example:
You spend 10 hours writing an RFC about an improved API design pattern
It saves 20 engineers 2 hours each (no more guessing conventions or messy cleanups later)
It prevents 4 alignment meetings x 6 ppl x 1 hr each
ROI =
(20 x 2 + (4 x 6 x 1)) / 10= 6.4x return
One document. 6X leverage.
This is why Jeff banned PowerPoint in favor of a 6-page narrative memos.
This is why teams like Linear and 37Signals obsess over detailed specs before writing a line of code.
This is why OpenAI is telling you to stop obsessing over code and write a spec.
Forcing people to think clearly in writing prevents millions in execution mistakes.
How AI Changes Things
AI is making implementation easier but requirements harder. As models get better at “build the thing,” humans need to get better at “decide what to build and explain why.”
Think about it:
Bad prompt: “Make this better” → Surface-level changes with little cohesion
Bad requirements for engineer: “Build user dashboard” → Radically variable satisfaction based on the engineer’s assumptions
Good prompt: Specific context + clear success criteria + examples → Changes that are useful after one shot
Good RFC to team: Same structure → Aligned engineering team after one meeting
The skills are identical. Clear thinking → Clear expectations → Better outcomes.
This trend is accelerating. Engineers who master specs will lead teams building AI-augmented systems later.
Case Studies
Let’s see what good technical writing looks like.
React Hooks (PR#68) - Short, simple examples, steel-manned the drawbacks. They later linked a 1.5 hr talk from the authors. Two years after the RFC was accepted, the authors kept engaging in discussions with the 330+ commenters.
Rust async/await (RFC 2394) - Similar to React Hooks in terms of magnitude. But interesting how this is nonetheless just 656 lines long. Rust has an entire repo for RFCs and a detailed, yet lightweight process.
Those first two were top-down RFCs, where the core contributors said, “Here’s basically what is going to happen. Any questions?”
Here are two from smaller projects, where the outcome wasn’t pre-determined:
Posthog Temporal (PR#99) - Informal, quick, clear. It’s rooted in business value - the opening questions are, “Is this a good idea? Is getting this done feasible?” There is a lively, supportive discussion among teammates in the comments.
Slack Python Client (PR#384) - This one is my favorite. It is easy to read, includes diagrams, links, and code snippets, along with acknowledging trade-offs and the larger context. Best part? The author wasn’t even part of the Slack team — just some guy who had explained his thoughts well enough to influence the entire project.
Bitcoin Whitepaper (A Peer-to-Peer Electronic Cash System) - Amazing display of thought here. Satoshi starts high-level with internet commerce, gently introduces the role of cryptography, shares his novel idea, and then gives you the math and code to implement it. Oh, and it’s only 8 pages long.
SMTP (RFC2821) - This is an Internet Society RFC, so it’s an artifact of discussions more than it is a request for more. Regardless, it explains how email works using simple text diagrams like the one below.
The protocol that powers our communication 24 years later started as some words an engineer wrote down.
Notice the patterns:
Clear problem statements
Multiple alternatives considered
Detailed rationale for decisions
Implementation plans
Engaging in the follow-up discussion
Learn from engineers who influence millions of other engineers.
RFC Failures
Here are the common patterns of a failed RFC. Spot these early to avoid lots of pain.
The “Solution in Search of a Problem” RFC
Leads with cool technology
Doesn’t establish a clear problem
Gets rejected for being unnecessary
The “Novel-Length” RFC
47 pages of technical details
No executive summary
Nobody finishes reading it
The “Already Decided” RFC
Written after implementation starts
Rubber stamp process
Team feels excluded from the decision
The “Ivory Tower” RFC
No user research
No stakeholder input
Technically perfect, practically useless
Great RFCs solve real problems, include relevant people, and prioritize outcomes over egos.
How to Make this Easier
Thinking deeply doesn’t mean you have to do it alone. Here are some prompts to 10x your RFC quality:
Basic RFC Template
# RFC: [Clear, Specific Title]
## Summary (2-3 sentences)
What you’re proposing and why it matters.
## Problem Statement
- Current situation
- Why it’s problematic
- Who is affected
- Cost of inaction
## Proposed Solution
- High-level approach
- Key components
- Success criteria
## Alternative Approaches Considered
- Option 1: [description + why rejected]
- Option 2: [description + why rejected]
## Implementation Plan
- Phase 1: [milestone]
- Phase 2: [milestone]
- Phase 3: [milestone]
## Risks and Mitigations
- Risk 1 → Mitigation 1
- Risk 2 → Mitigation 2
## Open Questions
- Question 1
- Question 2
Problem Definition Prompt:
I’m facing [technical challenge]. Help me articulate this as
a clear problem statement:
- Current state: [describe situation]
- Desired state: [describe outcome]
- Gap analysis: [what’s blocking progress]
- Stakeholders affected: [who feels pain]
Format as: Problem, Impact, Constraints, Success Criteria
Solution Brainstorming:
Given this problem: [problem statement]
Generate 5 different approaches:
- 1 simple/minimal solution
- 1 comprehensive solution
- 1 completely different angle
- 2 hybrid approaches
For each: pros, cons, effort, risk level
Devil’s Advocate:
Play devil’s advocate on this proposal: [your RFC]
Find every weakness, edge case, and unintended consequence.
What would a skeptical senior engineer ask?
RFC PR Description:
Subject: RFC Review Request: [Title] - [Expected review time]
Hi [Team],
I’ve written this RFC for [problem] and need your input.
**TL;DR**: [1-2 sentence summary]
**Review requested by**: [date]
**Implementation timeline**: [deliver by X if approved by Y]
**Key reviewers**:
- @[name] - [why their input matters]
- @[name] - [why their input matters]
**Link**: [RFC document]
**Specific feedback requested**:
- Does this solve the right problem?
- What alternatives am I missing?
- Any implementation red flags?
Thanks for your time.
Trade-Offs
Now, I’m not saying you should write RFCs for everything. That’s as foolish as never writing them.
Let me address the three biggest objections I hear from senior engineers:
Critique #1: “Junior devs should code more, not write docs”
This is the most common pushback. “You need 5+ years of battle scars before you can write meaningful specs. Focus on shipping.”
They’re half right. You absolutely need implementation experience to write decent RFCs. But writing and coding aren’t competing activities — they’re complementary.
The best approach? Write about the code you’re already working on.
Don’t invent new projects for the sake of an RFC. Take that API redesign you’re implementing next sprint. Write a mini-RFC first. Document your thinking. Share it with your team.
This isn’t net-new overhead. You were already thinking through these problems. You were already making these decisions. The RFC just turns your cycles into an artifact.
Go slow: Instead of flooding your team with half-baked docs every week, just pick 1-3 meaningful technical decisions per quarter.
Critique #2: “RFCs create analysis paralysis”
I get it. Every senior engineer has seen RFC processes that turned into bureaucratic nightmares. Six months of debating, zero lines of code shipped.
But this is a process problem, not a writing problem.
The solution isn’t to stop writing. It’s to write better and faster:
Time-box RFC creation: 4-8 hours max for most specs
Set decision deadlines: “We’ll decide by Friday, then implement”
Implement while discussing: Write RFC, start experimentally coding, adjust based on feedback
Kill zombie RFCs: If discussion drags past 2 weeks, commit or move on
Good RFCs actually accelerate shipping by preventing the real velocity killer: building the wrong thing and having to rewrite it.
Critique #3: “Most RFCs are just inexperienced engineers over-engineering simple problems”
This one stings because it’s often true. Junior engineers love to turn “add a button” into “comprehensive component architecture overhaul.”
The antidote is ruthless honesty.
Before writing any RFC, ask:
Is this problem actually complex, or am I making it complex?
Will solving this wrong create more work than solving it right?
Am I the right person to be thinking about this?
Write the RFC first when there is:
High uncertainty (multiple valid approaches)
Long-term impact (decision lives for years)
Cross-team dependencies (alignment critical)
Implement first when:
Clear problem + obvious solution
Single developer impact
Tight deadline + low risk
Throwaway/experimental code
Remember: Your goal isn’t to write RFCs. Your goal is to make better technical decisions. Sometimes that requires writing. Sometimes it doesn’t.
Your Action Plan (Slow + Steady)
Here’s how to build this skill without triggering the “overeager junior engineer” alarm:
Week 1-2: Foundation
Read 5 RFCs
Don’t write anything yet - just observe patterns
Weeks 3-4: Skill Building Through Helping Others
Volunteer to review others’ RFCs (this is how you learn fastest)
Ask questions, don’t give answers - “What about edge case X?” not “You should do Y”
Build trust through thoughtful and timely feedback
Month 2: Your First RFC
Start small: Pick something you’re already implementing
Write it for yourself first: Clarify your own thinking before sharing
Get informal feedback: Chat with 1-2 people before formal review
Track the outcome: Did it prevent confusion? Change the approach?
Month 3+: More, Bigger
Increase scope: After getting traction on a few smaller RFCs, take on more difficult and larger problems
The internet is created by engineers who write their ideas down and convince others to help them build it.
Why can’t you be one of them?
You said/
-----------------------------------------------
The skills are identical. Clear thinking → Clear expectations → Better outcomes.
This trend is accelerating. Engineers who master specs will lead teams building AI-augmented systems later.
-------------------------------------------
RIGHT ON!!! That's something to highlight!!!!
When you have clear thinking expectations the outcomes are more ideal. BINGO!!!