Learn In Public Without Pretending You Already Know The Answer

Learning in public doesn’t mean teaching a finished lesson. It means posting what you tried and the specific question you can’t answer yet, before you have any expertise to show off. The smallest version is two lines: what you attempted, and what you’re still stuck on.

What does learning in public mean?

Learning in public means sharing your process while you’re still figuring something out, not after you’ve mastered it. The phrase was popularized by engineer and writer Shawn Wang, known as swyx, in his essay ‘Learn In Public’, which argues that documenting your own learning in public creates a trail other people searching for the same answer can later find. This is different from ‘building a personal brand,’ which implies you already have authority to lend. Learning in public carries no authority requirement. A first-year analyst posting ‘here’s how I finally understood this pivot table formula’ counts as much as a ten-year engineer explaining a database migration. The only rule is honesty about where you are in the process, not where you wish you were.

Why do most people avoid it?

Most people avoid learning in public because they confuse it with having to be right. They wait until they’ve solved the problem completely and polished the explanation before posting anything, which usually means they never post at all. John Stepper’s Working Out Loud method, which he developed while working inside Deutsche Bank before it spread to other companies, was built around exactly this fear: people assume visibility requires competence, so they stay invisible until they feel ready, and most never feel ready. The fix is lowering the bar for what counts as a post. A half-finished thought or a wrong guess you later corrected is a valid post. Waiting for certainty is the single biggest reason good learners never post anything.

What’s the smallest version that works?

The smallest version that works is two lines: what you tried, and what you’re still stuck on. You don’t need a conclusion, a lesson, or a polished takeaway at the end. Community site dev.to built an entire content format around something this small, called ‘TIL’ (today I learned) posts, often two or three sentences long, and they still get read and answered. The format works because it asks nothing of the reader except recognition: ‘I had that exact problem too.’ You’re not teaching. You’re narrating. Austin Kleon describes the same habit in his book Show Your Work, where he argues that sharing your process in small pieces, as you go, helps other people more than any finished product you eventually publish.

Where should you post it?

Post it wherever the people who would ask your exact question already gather, not wherever feels most comfortable to you. Developers use dev.to and Stack Overflow for short technical notes. Founders and indie builders use Indie Hackers to post weekly build logs, often a few sentences about what shipped and what broke. Professionals post learning notes directly on LinkedIn, where a short, specific post about a mistake usually gets more engagement than a polished tip. Students and career-changers use subreddits like r/learnprogramming to ask the exact question they’re stuck on. Pick the one place your future reader is most likely to search, and post there consistently, rather than spreading the same post across five platforms you’ll abandon within a month.

What should you post this week?

Post one specific thing you tried this week, using this template: ‘I tried [specific action] to solve [specific problem]. Still stuck on [specific question].’ For example: ‘I tried asking Claude to summarize a 40-page vendor contract into three risk flags. Still stuck on how to phrase the word risk so it doesn’t flag everything.’ That one sentence is more useful to a future reader than a polished guide, because it shows the failed attempt next to the fix, not just a clean result. If you want the exact prompt structure that fixes vague AI answers like this one, this is the version I train people to use.

Five formats, ranked by difficulty

Here are five ways to learn in public, ranked from least expertise required to most, so you can start at the bottom no matter how new you are to the topic.

1. The question post. You ask the exact thing you don’t understand, in public, instead of only in a private chat. Requires zero expertise.
2. The today-I-learned post. One fact or fix you just picked up, written in two sentences, similar to the short build logs developers keep on GitHub. Requires one small win.
3. The failed-attempt post. What you tried and why it didn’t work. Requires one honest attempt, no success needed.
4. The comparison post. You test two tools or methods on the same task and report the difference, a format Hacker News’s Show HN threads are full of. Requires running both, not mastering either.
5. The explainer post. You teach a concept clearly enough that a beginner gets it. Requires enough repetition that you’ve already explained it to yourself several times first.

Start at formats one through three. Format five is the only one that needs anything close to expertise, and it’s the last place to start, not the first.

What if nobody responds?

Nobody responding is the normal outcome, and it doesn’t mean the post failed. Most learning-in-public posts get found by search, not by an audience scrolling at the moment you publish. Someone searching the exact error message or the exact phrase you used will find your post months later, the same way freeCodeCamp’s community forum fills up with years-old posts that still get new replies today. Treat the post as a message to a future stranger, not a performance for today’s audience. If you post and wait for likes before deciding whether it was worth it, you’ll stop within a week. If you post because the next person with your exact question deserves an honest answer, you’ll keep going.

Does this help your career later?

A public record of what you tried and learned becomes evidence in a hiring conversation, where vague claims about skills usually fall apart under a follow-up question. When an interviewer asks how you use AI tools, pointing to one specific post with one specific failure and fix is a stronger answer than a general claim of comfort with the technology, something I cover in what to say when an interviewer asks how you use AI. It also gives you language for explaining AI-assisted work to a boss who doesn’t trust it, because you already have a written history of what you tried and verified, instead of a story you’re constructing on the spot. Career subreddits like r/cscareerquestions are full of people asking how to prove skills they haven’t had a chance to use on a job yet, and a public learning record answers exactly that problem. None of this guarantees a job or a promotion. It’s simply evidence that exists when you need it, instead of a claim you have to invent under pressure.

You are a writing coach helping me turn a work session into a short, honest learning-in-public post. Here is what I tried today: [paste your attempt]. Here is what happened: [paste the result, including what failed or confused you]. Write a two-to-four sentence post that states what I tried, what happened, and the one specific question I'm still stuck on. Do not add a conclusion or a lesson I haven't reached yet. Keep the tone plain and specific, not polished or promotional. If you need more detail from me to make it specific instead of generic, ask me one clarifying question before writing the post.

I'm stuck on something but can't tell what my specific question is yet. Here's what I've been doing and where I got confused: [describe the situation in plain language, including anything you tried]. Ask me three short follow-up questions, one at a time, to help me narrow this down to one specific, answerable question I could post publicly and have someone else answer. Do not answer the question yourself yet. Just help me find it.

Review this short learning-in-public post I'm about to publish: [paste your draft]. Check for three things only: one, does it state a specific attempt and a specific result instead of a vague summary; two, does it avoid pretending to a conclusion I haven't reached yet; and three, is the one open question at the end clear enough that a stranger could answer it. Point out exactly which sentence fails any of these checks, and suggest the smallest edit, not a rewrite. Ask me first if you're unsure what I tried versus what I'm guessing happened.

Act as a blunt hiring manager who has read ten thousand resumes, not a career coach. I will paste my full resume and the job description I want. Rewrite the whole resume for that role, section by section, in this order: summary, experience, skills, education. Rules: every experience line leads with impact, not duty. Use bracketed placeholders like [8 percent] for any number I did not give you, and list at the end every placeholder I need to replace with a real figure. Keep it to one page of text. Plain formatting only, no tables or columns, so screening software can parse it. After the rewrite, tell me the three weakest claims that need evidence before I send this anywhere. My resume: [paste resume]. The role: [paste job description].