Building in Public: Why Sharing Your Work Compounds Over Time
There’s a particular kind of developer who consistently gets inbound job offers, consulting work, and interesting opportunities without actively looking for them. They’re not always the best coder in the room. They’re not necessarily prolific open source contributors. What they have in common is a body of public work — posts, projects, talks, documentation — that represents their thinking and their skills over time.
Building in public is the practice of sharing what you’re working on, learning, and figuring out as you go. Not polished retrospectives or thought leadership. The in-progress stuff: the half-finished project, the thing you learned by debugging for three hours, the architecture decision you’re second-guessing.
It feels uncomfortable. It works anyway. Here’s why — and how to make it a habit.
The Compounding Mechanism
The reason building in public works isn’t networking (though that happens). It’s compounding.
A blog post you wrote two years ago about debugging a weird Kubernetes networking issue is still being found by people searching that exact problem right now. A GitHub repo you built over a weekend and pushed is accumulating stars from people who needed exactly that tool. A Twitter/X thread explaining how you approached a system design problem is being saved and shared in developer Slack groups you’ve never heard of.
You do the work once. The work keeps working.
This is qualitatively different from private work. Private work is consumed once — by the person who commissioned it or the team you built it for. Public work has an unbounded audience over an unbounded time horizon. The asymmetry is dramatic.
A developer who has been building in public for three years has thousands of artifacts — posts, commits, comments, answers — that represent them when they’re not in the room. A developer who has been doing equivalent private work for three years has a resume, a LinkedIn profile, and references who need to be called.
The Compounding Returns Are Not Linear
Most people stop building in public before the compounding kicks in. The first three months of writing blog posts or sharing projects produce almost no visible results. This feels like evidence that it’s not working. It’s not — it’s the curve before the inflection point.
A rough model:
- Months 1–3: Near-zero audience, lots of learning about what to say and how to say it
- Months 4–12: Small but growing audience, first instances of serendipitous connections
- Years 1–2: Meaningful audience, regular inbound, work finding you instead of you finding it
- Years 3+: Body of work that speaks for itself, opportunities you couldn’t have predicted
Nobody talks about months 1–3 because there’s nothing interesting to report. The gap between “starting” and “seeing results” filters out most people. That’s why the people who persist have an enormous advantage.
What “In Public” Actually Means
Building in public doesn’t mean sharing everything. It means sharing more than the finished artifact.
What to Share
Work-in-progress: The project at 40% done. The architecture diagram you’re iterating on. The thing that’s working but the code is embarrassing. People are more interested in the process than most developers believe.
What you learned: That debugging session where you finally figured out why your Postgres queries were slow. The moment you understood what a semaphore actually does. The realization that your entire approach was wrong and here’s what you switched to. These posts are gold because they hit search results for exactly the frustrated developer who’s in the same situation.
Decisions and trade-offs: Why you chose sqlite over postgres for this project. Why you switched from Docker Compose to K3s. Why you decided not to build the thing at all. Explaining decisions is more interesting than announcing them.
Failures and dead ends: The project you abandoned and why. The approach that didn’t work. The tool you evaluated and rejected. The honest account of a failed launch. These get more engagement than success stories because they’re rare and useful.
Questions: “I’m trying to figure out how to approach X — here’s my current thinking, what am I missing?” Opening your thinking to feedback generates engagement, often gets you the answer faster, and signals intellectual honesty.
What Not to Share
- Genuinely confidential work: Client code, proprietary systems, unreleased products. The bar is real confidentiality, not vague discomfort.
- Other people’s work without permission: If you collaborated on something, get agreement before writing about it.
- Personal information about colleagues: You can write about technical challenges without naming individuals.
- Anything you’d regret if your employer read it: Apply this test before posting, not after.
The Platforms
You don’t need to be on every platform. Start with one. Add others only after the first is habitual.
Personal Blog (The Foundation)
A personal blog is the only public work channel you fully own. Twitter accounts get banned. GitHub changes its policies. LinkedIn throttles reach. Your blog is yours.
The bar to start is intentionally low. A static site with a handful of posts is enough:
|
|
Host it for free on Cloudflare Pages, Netlify, or GitHub Pages. Use a custom domain ($10–15/year) — it signals commitment and is worth it.
Write about things you had to figure out. The target reader is yourself from six months ago. Write to help that person.
Post length: 500–2,000 words per post is the sweet spot for technical content. Short enough to write in an evening, long enough to be substantive.
Posting frequency: Once per week is sustainable for most people. Once per month is fine. Once whenever you have something to say is the reality for most and also fine. Consistency matters less than people think; what matters is not stopping.
GitHub (The Portfolio)
Every project you ship should be public unless there’s a specific reason it can’t be. A GitHub profile with a history of small, finished, documented projects is a portfolio. It shows:
- That you actually build things
- That you can make decisions and ship
- What you know (the technology stack across your repos)
- How you think (your commit messages, README quality, code organization)
Things that make a public repo a good artifact:
- A clear README (what it does, who it’s for, how to run it)
- Working code (it runs without extensive configuration)
- Consistent, descriptive commit messages
- An appropriate license
Things that don’t matter much: stars, forks, perfect code. A repo with 3 stars and a working example is more valuable than a repo with 200 stars of abandoned, broken code.
Twitter/X (The Distribution)
Love or hate it, Twitter/X remains the platform where developers congregate, share, and discover. The value isn’t the platform — it’s the audience. A post that would get 50 readers on a new blog can get 5,000 views if you share it well on Twitter.
For developers, threads work well: a series of linked observations, the step-by-step of solving a problem, an explanation that unfolds. Single tweets work for links, quick observations, and questions.
The follow-worthy developer on Twitter shares:
- Links to their work (blog posts, repos) with a one-sentence hook
- Observations about problems they’re solving
- Reactions and responses to others’ work
- Occasional non-technical personality
The formula that works for building an audience on any social platform is boringly consistent: post interesting things regularly, engage genuinely with others’ posts, be patient.
LinkedIn (The Professional Layer)
LinkedIn has dramatically improved for technical content in recent years. Posts about engineering decisions, career lessons, and project work get significant reach to a professional audience — often people with hiring authority.
The LinkedIn audience is different from Twitter: more junior developers looking for guidance, more engineering managers, more recruiters. Content that performs: career observations, “what I learned from X” posts, and honest accounts of professional challenges.
The posts that don’t work: resume-speak (“excited to announce”), corporate-speak, pure self-promotion without substance.
Dev.to / Hashnode (The Discovery Layer)
Platforms like Dev.to and Hashnode aggregate developer content and distribute it to their own audiences. Cross-posting your blog content (with a canonical URL pointing to your blog) gets it in front of developers who would never find your standalone blog.
The canonical URL is important: it tells search engines that your blog is the original source, preserving your SEO benefit.
|
|
YouTube / Video (Optional)
Video is the highest-effort, highest-reach medium. A technical walkthrough or tutorial can reach audiences that never read long-form text. The barrier is real: you need reasonable audio quality, willingness to be on camera (or at minimum screenshare), and editing patience.
If you’re already comfortable with video, it’s worth adding. If it adds friction that makes you stop building in public entirely, skip it.
Finding Your Voice
The most common reason developers don’t write more is uncertainty about what they have to say that’s worth saying. The answer is almost always: more than you think.
The Expert Gap
When you learn something well enough to use it, you’re past the uncomfortable confusion phase. That phase is the most valuable thing to write about — when you’re going through it. The expert who wrote the official documentation has forgotten what it feels like to not understand their thing. You haven’t.
Write at the edge of your understanding, slightly behind you. “Here’s how I finally understood X” posts are some of the most-read technical writing on the internet because the reader is usually in the “finally understanding” phase themselves.
The Curse of “It’s Been Written Before”
Nothing you write will be original in the sense of containing ideas nobody has ever had. But your specific angle, your specific debugging session, your specific trade-off decision — those are yours. The person searching for “why is my Kubernetes pod in CrashLoopBackOff after upgrading to 1.29” doesn’t care if five other people have written about CrashLoopBackOff. They want the explanation that clicks for them, in words that make sense to their mental model.
Write anyway. Your version will reach the people your version is suited for.
What to Write When You Don’t Know What to Write
- The last thing that confused you — and how you resolved it
- A decision you made this week — and why
- Something you read that you disagree with — and why
- A tool you just started using — first impressions, honest
- Something you thought was true for a long time that turned out to be wrong
- The README for a project you’ve been meaning to make public
The single most reliable source of content is your own work. Write the post that would have helped past-you. That post is also most likely to help present-someone-else.
Making It a Habit
The developers who sustain building in public long-term have systems, not willpower.
Capture Notes, Not Just Finished Posts
Keep a running list of potential topics as you work. When you hit something confusing, write a one-line note: “look into why postgres VACUUM was blocking my queries for 40 seconds.” When you make an interesting decision, note it: “chose sqlite over postgres for this — reasons.” These notes are future posts.
A simple text file works:
## Post ideas
- 2026-03-15: Figured out why k8s pod was OOMKilled when memory limit looked fine (swap)
- 2026-03-17: Why I stopped using Makefile and switched to just.sh for project commands
- 2026-03-20: Terraform state locking with S3 + DynamoDB — actually easier than I thought
- 2026-03-22: Why the "distroless" Docker image tutorial is missing something important
A week of actual work produces 3–5 legitimate post ideas. Most developers don’t notice them because they’re not looking.
Batch Writing, Not Daily Writing
Writing every day is unsustainable for most developers who also have jobs and lives. What works better: a dedicated writing session once a week or once every two weeks, working from your captured notes.
A 90-minute writing session produces a decent 1,000-word post. Two 90-minute sessions produce a polished 1,500-word post. That’s roughly one post per week at a pace that doesn’t require daily effort.
Lower Your Publishing Bar
The biggest enemy of consistent publishing is perfectionism. Posts don’t need to be comprehensive. They don’t need to cover every edge case. They don’t need to be your best work.
“Publish before you’re ready” is often repeated because it’s true and almost nobody follows it. The post that ships imperfectly is infinitely more valuable than the post you’re still refining.
A rough heuristic: if you’ve written it and it says something true and useful, publish it. Edit for clarity and obvious errors, not for comprehensiveness.
Engage Back
Building in public works faster when it’s genuinely public — which means responding to comments, engaging with people who share your work, asking questions back. This isn’t networking in the transactional sense; it’s participating in communities that are interested in the same things you are.
The developers who build audiences fastest are usually responsive. Not because responsiveness is a growth hack, but because responsiveness attracts more engagement which attracts more visibility which attracts more people who care about the same things.
The Non-Obvious Benefits
The obvious benefit of building in public is career opportunity — inbound leads, job offers, consulting work. These are real and they compound over years.
The non-obvious benefits are worth naming:
Clarity of thought: Writing about what you’re building forces you to understand it better. The post you write explaining an architectural decision often reveals problems with the decision. The README you write clarifies what the project actually is. Writing is thinking.
Stronger memory: You will remember what you wrote about better than what you didn’t. The blog post forces a level of articulation that cements understanding. Six months later, when you need to solve a similar problem, you have the post.
Better documentation habits: Developers who write publicly tend to write better internal documentation, better commit messages, and better PR descriptions. The habit of explaining for an external audience transfers.
Community before you need it: The people who engage with your public work become your professional community. When you need to ask a hard question, hire someone, or look for a new role, you have real relationships with people who know your work — not cold connections on LinkedIn.
A record of growth: Looking back at posts from two years ago and cringing slightly is a good sign. It means you’ve grown. The public record of your thinking over time is something you can’t reconstruct and can’t fake.
Starting Today
If you’ve never built in public, the bar to start is: post one thing.
One short post about something you figured out this week. Not polished. Not comprehensive. Just true and useful. Link it somewhere — a Slack channel, a HackerNews comment thread if it’s relevant, Twitter.
Then do it again next week.
The developers who have been building in public for five years didn’t have a strategy. They started with one post and didn’t stop. The compounding did the rest.
Comments