The advice to "learn in public" has been repeated enough that it sounds like a commandment. Write blog posts. Tweet what you are studying. Share your progress. Build an audience. The problem is nobody tells you how to do this without broadcasting that you do not know what you are doing, and the default approach — posting summaries of things you just learned — does exactly that.
The fear is legitimate. If you publish a post titled "What I learned about React hooks today" and the content is a surface-level summary of the official docs, you have told every reader two things: you just learned hooks, and you do not yet understand them well enough to say anything original about them. That is not a reputation asset. It is an inexperience beacon.
The fix is not to stay quiet. It is to change what you publish and how you frame it. A junior who writes well about their learning process is doing something rarer and more valuable than a senior who writes yet another React tutorial.
The difference between a learning log and a beginner blog
A learning log says: "Here is what I learned today." It summarizes a concept at the level of a documentation paraphrase, and it benefits nobody except the person who wrote it. A beginner blog is a blog by a beginner. Both are fine as personal practice. Neither belongs in public if your goal is to build credibility.
A public learning artifact that works says: "Here is a problem I encountered, here is what I tried, here is what actually worked, and here is what I still do not understand." The format is the difference. You are not summarizing a concept you just learned. You are documenting an investigation you conducted. The reader learns something because you did the work of connecting the concept to a real situation, and you were honest about the edges of your understanding. That honesty does not make you look like a beginner. It makes you look like someone who knows that every engineer has edges.
The specific shift is from "I learned X" to "I needed to do Y, and X was the tool that solved it." The first frame is about you. The second is about the problem, and you happen to be the narrator. A problem-driven post is useful to anyone facing the same problem, regardless of whether they already know the tool. A summary-driven post is only useful to someone who does not already know the tool, and that audience shrinks as you get more senior.
Before you publish anything, ask yourself: would this be useful to someone who already knows the thing I am writing about? If the answer is no, you are summarizing, not teaching. Add the problem, the dead ends, and the why. Those are the parts that make a post worth reading for anyone beyond raw beginners.
Formats that signal growth, not gaps
The safest format for a junior writing publicly is the technical postmortem. Something broke. You fixed it. You wrote down what happened. This format has several advantages over a tutorial. It is inherently specific: the bug was real, the stack was real, the fix was tested. Nobody reads a bug postmortem and thinks "this person does not know what they are doing," because the fact that you fixed it is the premise. And bug postmortems are universally useful, because specific failures are searchable in a way that generic tutorials are not.
The second format is the comparison: two approaches to the same problem, with measured tradeoffs. You tried X and it was fast but broke on edge case Y. You tried Z and it handled Y but was harder to set up. You do not need ten years of experience to write a useful comparison. You need to have actually tried both things and recorded what happened. The value is in the empirical data, not the authority of the author.
The third format is the question-documentation: you had a question, you could not find a clear answer, so you found the answer yourself and wrote it down. This is the format behind a surprising number of high-traffic technical blog posts. The writer was not an expert when they wrote it. They were just the first person to write the answer down clearly. A question-documentation post on "how to configure Webpack to handle SVG imports in a TypeScript project" will outrank a generic "Introduction to Webpack" post indefinitely, because the former solves a specific problem someone is typing into a search bar right now and the latter solves nobody's problem.
The format to avoid is the recap. "What I learned this week" posts aggregate shallow summaries into a single shallow summary. They signal that you are learning, which is the one thing you already know and the one thing readers do not need to be told. A single deep post about one problem you solved is worth more than a year of weekly recaps.
Do not publish AI-generated summaries of topics you just learned and pass them off as original writing. Readers and hiring managers can spot this instantly because the output is fluent but generic — it sounds like documentation, not like a person who struggled with something real. If you used AI to help write, the post still needs to contain your specific problem, your specific dead ends, and your specific fix. The generic parts are filler. The specific parts are the post.
When to publish and when to keep it private
Not everything belongs in public. A rough draft of your understanding, written the same day you first encountered a concept, belongs in a private notebook. Let it sit for at least a few days, ideally until you have applied the concept to something real, before you decide whether to publish.
The test for publishability: can you add something to the existing body of writing on this topic? If the answer is no — if a Google search already returns 20 posts that say the same thing better than you can — do not publish. Your time is better spent building the experience that will let you write something original later. A public learning practice is not a content quota. One good post a quarter beats twelve forgettable ones a year.
The platforms matter less than the format, but the practical advice is to put your writing on a site you control. A personal blog is a permanent, searchable asset that a hiring manager can find six months from now. A tweet thread is an ephemeral asset that decays within 48 hours. Both have their place, but if you are choosing where to invest the two hours it takes to write a solid technical postmortem, put it on a domain you own and link to it from social media. The blog is the asset. The social post is the distribution.
When you do publish, include a date and be transparent about your experience level. "I'm a junior engineer and this is what I learned debugging a memory leak in a Node app" is honest and frames the post correctly for readers. Pretending to be more experienced than you are gets caught, and getting caught on a public artifact is worse than never publishing it.
Public learning done well is the highest-ROI career habit a junior can build. It costs nothing but time, it compounds across years, and it produces a body of evidence that no resume bullet can match. Done poorly, it signals the exact thing you are trying to overcome. The difference is not in how smart you are or how well you write. It is in whether you publish summaries of what you learned or investigations into what you solved. Pick investigations. The rest takes care of itself.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)