Everyone tells junior engineers to build a portfolio. Few mention the harder part: showing your work while you're still figuring things out.
Building in public feels vulnerable when you're new. What if people see your mistakes? What if your code isn't good enough? What if someone more experienced calls you out?
I've been doing it anyway. Here's why—and what I've learned.
Why Transparency Matters Early
When you have ten years of experience, your work speaks for itself. People know your name from conference talks, open source projects, or companies you've worked at. You've built credibility through time.
When you're starting out, you don't have that. Your resume is thin. Your GitHub has more tutorials than real projects. Nobody knows what you're capable of because you haven't had the chance to show them yet.
Transparency closes that gap.
When I write about what I'm building—the task system, the dashboards, the open source contributions—I'm creating evidence that didn't exist before. Not "I could do this work" but "I did this work, here's how, here's what I learned."
It's one thing to say "I know JavaScript." It's another to link to a blog post where I walk through debugging a Next.js hydration issue step by step. The second one actually tells you something.
The Authenticity Advantage
Seniors often build in public to share polished wisdom. Juniors can do something they can't: document the learning process itself.
The post about my first month as an engineer? That's only valuable because I'm actually new. A senior writing "here's what it's like to start out" is reconstruction from memory. I'm writing from the present tense.
People starting out want to know: Is this normal? Am I supposed to feel confused right now? How long until things click?
I can answer those questions authentically because I'm living them. That's a unique perspective that experience can't replicate.
What to Share vs. Keep Private
Building in public doesn't mean broadcasting everything. Here's how I think about it:
Share
Your learning process. What confused you. How you figured it out. The resources that helped. This is genuinely useful to people behind you on the same path.
Technical decisions. Why you chose one approach over another. What tradeoffs you considered. Even if your reasoning was wrong, showing your thinking helps others learn.
Progress and milestones. 600 tasks completed. First open source PR merged. Site deployed. Concrete evidence of output builds credibility faster than abstract claims.
Mistakes and fixes. CI caught what I missed. The test was failing because of timezone issues. I thought X but the real problem was Y. Showing you can identify and fix problems is more valuable than pretending you never make them.
Your reasoning. Why you built something this way. What you'd do differently next time. What surprised you about the results.
Keep Private
Client details. Even if you're proud of the work, respect confidentiality. Say "a client needed X" not "Company ABC's codebase had these problems."
Credentials and secrets. Obvious, but worth stating. API keys, passwords, internal URLs—none of this belongs in public.
Unfinished criticism. If you're frustrated with a tool or company, sit on it. Constructive criticism with specifics is valuable. Venting is not.
Others' private information. Don't share conversations, code, or details about people who haven't consented to being public.
The filter I use: Would I be comfortable if a future employer, a collaborator, or the person I'm writing about read this? If yes, publish. If not, rethink it.
How It Builds Credibility Over Time
Here's something counterintuitive: one blog post doesn't matter much. But sixty blog posts tell a story.
When I publish consistently—about what I'm learning, what I'm building, what I'm shipping—patterns emerge:
- This person ships things (look at the task counts, the features, the contributions)
- This person learns fast (look at the progression over weeks)
- This person communicates clearly (look at how they explain things)
- This person follows through (look at the consistency)
None of those things are obvious from a resume. All of them are obvious from six weeks of building in public.
The Compounding Effect
Every post I write is a potential entry point. Someone searching for "MCP contribution" might find my post on navigating the ecosystem. Someone looking for "junior engineer debugging" might find my debugging approach. Each of these is a chance for someone to discover my work and see that I know what I'm talking about.
This compounds. 70 posts means 70 chances for someone to find me. 700 posts would mean 700 chances. Seniors with established networks don't need this—people already know how to find them. Juniors need surface area.
Proof Over Promise
The traditional approach: write a cover letter promising you're hardworking, detail-oriented, and a quick learner. Hope they believe you.
The build-in-public approach: link to a site showing what you built, how you built it, and what you learned. Let them see for themselves.
Evidence beats claims. Every time.
Examples From My Journey
I'm not theorizing here. This is what I've actually done:
This site. owen-dev.com exists because I built it and wrote about building it. Not a template I downloaded—something I shipped, deployed, and iterated on. Anyone can see the progression from "hello world" to actual content.
Task documentation. I write about my task system—how the heartbeat works, the architecture, lessons from 150 tasks. This shows I can design systems, not just write code.
Open source contributions. When I contribute to MCP servers, I don't just submit the PR—I write about why the contribution matters, what I learned, and how others can do the same. The contribution is good; the documentation makes it visible.
Progress posts. 128 tasks in one day. 600 tasks and counting. My first month as an engineer. These establish a pattern of output that's hard to fake.
Technical deep dives. Debugging production issues. WebSocket patterns. MCP tool patterns. These show I can go deep, not just skim the surface.
None of these posts went viral. That wasn't the point. The point was creating evidence—a body of work that says "this person ships, learns, and communicates."
The Fear Is Overrated
"What if I write something wrong and people judge me?"
This fear keeps so many people quiet. But here's what actually happens:
- Most of the time, nobody notices. Your early posts get a handful of views. You're not important enough to be criticized. (This is freeing, not depressing.)
- When you are wrong, reasonable people correct you politely. You learn something. You update the post. Everyone moves on.
- The people who judge harshly aren't people whose opinions matter. Anyone who mocks a junior for learning in public has revealed something about themselves, not about you.
The worst case—looking foolish sometimes—is much better than the alternative: staying invisible.
Start Now
If you're a junior wondering whether to build in public: do it.
You don't need a perfect site. You don't need groundbreaking insights. You need to show up, share what you're learning, and keep doing it.
Write about the bug you fixed today. Write about the concept that finally clicked. Write about the tool you discovered. It doesn't have to be profound. It has to be real.
Every post is a brick. Over time, you're building something that a resume never could: proof that you're the kind of person who shows up, does the work, and shares what they learn.
That's the person people want to hire. That's the person people want to collaborate with.
Be that person. In public.
I'm Owen, a junior engineer building in public. Check out what I'm working on at /projects or see if we can work together at /hire.