Technical writing and public proof

There’s a quiet feedback loop that runs in the careers of the engineers you most admire on the internet, and it isn’t talent. It’s that they wrote about their work in public, repeatedly, for years, with nobody reading the early ones. Simon Willison, Julia Evans, Dan Luu, Lilian Weng, Eugene Yan, Charity Majors — every one of them was nobody, writing into the void, until they weren’t. The compounding is brutal and unfair: the first 20 posts feel like nothing, the 30th lands a job offer, the 50th a conference invite, the 100th a recognisable byline.

Most CS students refuse to do this. The reasons are predictable: “I don’t have anything new to say,” “everything’s been written,” “what if I’m wrong,” “I’m not a writer.” All four are wrong. Engineers who write get hired faster, get paid more, and learn faster than engineers who don’t. This module is the on-ramp.

Fair warning: this is the module most students skip and then regret in two years. Don’t be that student.

Set up — pick where you’ll publish

Before you write anything, decide where it will live. Pick one and don’t switch:

Option	Pick if	Pain point
Astro / Hugo / Jekyll on GitHub Pages	You want full control, no platform risk, custom domain	A weekend of setup before first post
Substack	You want zero setup, built-in email subscribers	Bad for code blocks, search-unfriendly URLs
Dev.to / Hashnode	Built-in audience, decent code rendering	Algorithmic feed, not really “yours”
Personal Notion / Tana	Truly zero friction	Looks unprofessional, no real ownership

The right answer for most engineers is “static site on a custom domain you bought for fifteen dollars”. your-name.com/blog. It’s the lowest long-term friction and the strongest signal. But — and this is important — don’t let the setup eat the writing. Pick whatever gets you to first post in under 2 hours. You can migrate later.

Read these first

Three sources, in this order, then write:

1. Patrick McKenzie — Don’t Call Yourself a Programmer. post · 25 min · scroll to the section on writing publicly. Patio11’s explanation of why this is the highest-ROI activity for most engineers is still the cleanest there is.
2. Julia Evans — Some blogging myths. post · 8 min · the antidote to “I have nothing new to say.” Read it before every post you doubt.
3. Paul Graham — Write Simply. post · 5 min · pretend you’re explaining the concept to a smart friend who isn’t in your field. Stay there.
4. Tom MacWright — How to blog. post · 10 min · the “stop overthinking it” version, with concrete tactics.

Stop. Don’t read “10 tips for tech bloggers.” None of it will make your writing better.

Why public writing compounds

Three reasons, all of them mechanical:

• Recruiter signal. A blog with three real technical posts is something a recruiter can read in 15 minutes. It’s the highest-density signal of “this person can think clearly” that exists for someone with no published papers and limited industry experience.
• Network effect. Every person who reads your post and learns something owes you, faintly, for the rest of their career. Some of them will be hiring managers in three years. This is not exploitative; it’s how knowledge work has always operated.
• Your own clarity of thought. Writing forces you to discover the holes in your understanding that reading and conversation hide. Most students don’t realise how much they don’t know until they try to explain it on the page. This, more than any of the above, is why the engineers who write are the engineers who get good fastest.

The third reason is sufficient on its own. Even if nobody read your blog, you’d still write it.

The four post types that work for students

You don’t need to invent a genre. Pick one of these four for every post until you’ve shipped 10:

1. The “I built X” debrief

You finished a project. You write a post explaining what you built, why, what surprised you, what you’d do differently. The structure is:

Premise (what and why) → process (the interesting decisions) → result (with screenshots or numbers) → what I’d change.

Concrete is everything. Real numbers. Real screenshots. Real code. Vague debrief posts (“learned a lot about teamwork”) are worthless. Specific ones (“the SQLite write throughput halved when I switched journaling modes — here’s the chart”) are gold.

2. The “this confused me, here’s the answer” explainer

You hit a thing you didn’t understand. You worked through it. You write the explanation you wish you’d had. This is most of Julia Evans’ career. It works because there are always students one semester behind you who are stuck on what you just unstuck.

“I never understood why JOINs in SQL are slow when you’d expect indexes to fix it. Here’s the answer in 800 words.”

3. The comparison / benchmark / data piece

Pick two tools, two approaches, two libraries. Run them. Publish the numbers. This is criminally under-supplied because students assume “everyone’s already done this.” They haven’t. Even if they have, your version with your data and your hardware is new.

“I ran 8 SQLite drivers from Python on the same workload. Here’s the latency distribution and how I tuned it.”

4. The “what I’d do differently” reflection

After a meaningful project (a hackathon, an internship, a class), you write what you’d do differently. Not “what I learned.” That’s a LinkedIn post. Specifics. The technical decisions, the time-management decisions, the team decisions. Why each one was wrong.

The first three of these are the workhorses. The fourth is an occasional change of pace.

A structure that works

Almost every good technical post on the internet shares the same structure. Memorize it.

1. Title — a promise. (more on this below)
2. Hook — 2-3 sentences. Why does this matter? Why now?
3. The problem — one paragraph, concrete.
4. The approach / explanation — sub-headers, code, real numbers.
5. The surprising bit — something you didn't expect, or a counter-intuitive
   result. Without this, the post is forgettable.
6. The takeaway — 2 sentences. What should the reader do differently?
7. Sources — links to anything you reference. Always.

The post should be roughly 800–2000 words for a first piece. Longer than 2000 and most readers bounce. Shorter than 600 and you haven’t said anything yet.

Headlines that get clicked without being clickbait

The title is half the work. Two rules:

1. The title is a promise. It tells the reader exactly what they get if they read the post. “Why my Postgres queries got 10x faster after switching one config” is a promise. “Postgres performance” is not.
2. Use a number, a contrarian claim, or a specific name. Numbers (“4 things that broke when…”), contrarian claims (“You probably don’t need a vector database”), specific tool names (“Notes from one week with uv”) all outperform abstract titles by 3-5x on click-through.

Bad titles, real examples:

• “Thoughts on system design” (vague, no promise)
• “My first machine learning project” (nobody cares, and it sounds beginner)
• “Why DevOps matters” (no, it doesn’t, and the title doesn’t promise anything)

Better versions of the same posts:

• “How I designed the rate limiter for 50k req/sec on a single Postgres instance”
• “I trained a 2M-parameter transformer on my MacBook over 4 hours. Here’s the loss curve.”
• “The five DevOps mistakes that cost my last team three production outages”

You can be opinionated without being clickbait. The line is whether the post delivers what the title promised.

What NOT to write about as a student

Please don’t:

• Think pieces about industry trends. “Where AI is going in 2027.” You don’t have the standing yet, and recruiters can tell.
• Hot takes. “X framework is dead.” You’ll be wrong, and screenshots last forever.
• Motivational / career posts. “5 lessons from my coding journey.” There are 500,000 of these. None of them help anyone.
• Restating tutorials. “How to install Postgres.” Already exists, better written, by people closer to the source.

Write about specific technical things you actually did. Stay there for two years. Then, maybe, write your think piece.

A minimum SEO pass

You’re not optimizing for a viral hit. You are making sure that two years from now, when someone googles a thing you actually solved, your post shows up. That requires almost nothing:

• The post’s title is a question or claim that someone might Google.
• The URL slug matches the title (/blog/postgres-rate-limiter, not /blog/post-12).
• One H1 (the title), then H2/H3 for sections.
• Internal links to your other posts when relevant.
• A 150-character meta description that summarizes the promise.

That’s it. Forget keyword density, schema markup, link-building. They don’t matter at your traffic scale.

How to share without being annoying

Once published:

Channel	Tactic	Frequency
X / Twitter	One post: title + 1 sentence + link. No thread, no emoji storm.	Once per piece.
Hacker News	Submit yourself, with original title, no editorialising. Don’t ask for upvotes.	Selectively — only the best 1 in 4 posts is HN-worthy.
Lobsters	Same as HN, smaller, more technical audience.	Same selectivity.
Reddit (relevant subs)	Submit only where the topic fits the sub’s culture. r/programming is hostile; r/learnprogramming is friendly.	Carefully.
Dev.to	Cross-post if the post is tutorial-shaped. Skip for opinion pieces.	Most posts.
Your school / company Slack	Post in #random or the relevant channel. People who already know you are your most reliable early readers.	Always.

Don’t DM your blog post to people who didn’t ask. It’s worse than not sharing at all.

The assignment

This week, do this:

1. Pick the post type from the four above. Most students should pick #1 (debrief of a recent project) or #2 (explainer of something you recently understood).
2. Write the title — a real promise, with specifics.
3. Write the hook — 2-3 sentences. Why now, why this.
4. Write the rest. Aim for 800–1500 words. Don’t polish in draft 1.
5. Sleep on it. Edit once.
6. Publish. Share once on X, once on HN if it’s HN-shaped, once in your school Slack.
7. The next morning, write down what you’d do differently. That’s the seed of post #2.

Do this every 2-4 weeks. After 6 months, your blog has 6-12 posts, two of which got real traffic, and your interview process changes.

Going deeper

When you have specific questions, in this order:

1. Julia Evans’ blog archive — read 5 posts. Notice how short they are, how specific, how unafraid she is to write about basics.
2. Dan Luu — How to write good documentation · 30 min · same skill, applied to internal docs and READMEs.
3. Eugene Yan’s blog — the model of an ML engineer who writes consistently. Read his “writing” tag.
4. William Zinsser — On Writing Well. book · skim the early chapters · the canonical book on prose. Most engineers benefit from reading it once.

Skip the “how to grow your blog to 100k subscribers” content. You don’t need 100k subscribers — you need 100, and them being the right 100.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. Why does writing in public compound, mechanically? Name all three reasons.
2. List the four post types that work for students. Which suits the project you’re currently working on?
3. What’s the structure every good technical post follows? You should be able to name the seven sections from memory.
4. What are the rules for a title that gets clicked without being clickbait?
5. List four things you should not write about as a student, and explain why for each.

If you can answer all five from memory, you’ve earned 06.3. The real test is whether you publish your first piece this week. Then move to 06.4, communities.