What to Write About When You're a Junior Engineer

TL;DR - Project writeups, debugging stories, and "I was confused by X" posts are reliable formats that do not require expert-level knowledge. - "Document, don't create" means writing down what you already learned, not producing original research. - The most useful posts are written for the version of you that existed before you understood something. - Your job search provides constant raw material: problems you solved, tools you compared, concepts you learned. - Tutorials on things you just learned are legitimate content, not recycled beginner material.

The hardest part of writing online as a junior developer is not the writing. It is deciding what to write about. Most developers believe their material is too basic, too derivative, or too obvious. They think the internet already has enough tutorials on React hooks or how to set up a Django project.

This is both true and irrelevant.

Yes, those topics have been covered. But your explanation has not been written. Your specific confusion about useEffect dependencies has not been documented. Your debugging story about the CORS error that turned out to be a misconfigured environment variable has not been told. The specific angle you bring, as someone who just learned the thing, is genuinely different from an explanation written by someone who has known it for five years.

The frame that makes this easier is simple: document, don't create. You are not trying to produce original research or publish a definitive guide. You are writing down what you already learned so that other people who are where you were recently can benefit from it.

Here are the five categories that consistently work.

1. Project writeups

After finishing any project, whether it is a portfolio piece, a coding challenge, or a side experiment, write about it. Not a tutorial that teaches readers how to build the same thing. A narrative about the decisions you made and what happened.

The structure is straightforward:

What you were building and why
The key technical decisions you made and what drove them
Something that went wrong and how you resolved it
What you would do differently if you started again

This kind of post signals more to a hiring manager than a GitHub repository alone. The repo shows what you built. The writeup shows how you think. Two candidates with similar projects are not the same candidate if one of them has written a thoughtful narrative about the choices they made.

A project writeup also pairs naturally with a case study in your portfolio. If you have already written up the project for your portfolio, the blog post is 60% done. Expand the decision-making section, add some context about what you learned, and you have something publishable.

2. "I was confused by X, here's how I finally understood it"

This is the most reliable format in technical writing for anyone who is actively learning. Pick a concept that genuinely confused you. It could be something you spent an hour on or something that took three weeks to click. Write the explanation you wish you had found when you were struggling with it.

The specific phrasing in the title matters. "How async/await works in JavaScript" will compete with hundreds of posts. "I kept thinking async/await was doing something it wasn't. Here's what actually happens" is narrower, more honest, and more likely to match how a confused person is searching.

The content should be written for the version of you that existed before you understood this. What was the mental model you had that was wrong? What was the one thing that made it click? What example, analogy, or code snippet finally made it make sense?

These posts are valuable because they are honest about difficulty. They acknowledge that understanding something took time and effort, which is both relatable and more useful than explanations that assume the reader is just one clean definition away from understanding.

3. Debugging stories

A debugging story is one of the most underused formats in developer writing, and it is one of the best at demonstrating how you think.

The format is a narrative:

What the bug was (or appeared to be)
What you thought was causing it and why
How you investigated
What you found
What the fix was

The most useful debugging posts are specific. Not "I had a weird async bug" but "my API calls were returning stale data even after a state update, and here's exactly how I traced it to the component lifecycle."

Specificity is what makes these posts searchable. Real error messages, real library names, real symptoms. Someone with the same bug will search for the same terms you would have searched for when you were stuck.

These posts also show something resumes cannot. The ability to investigate systematically, form hypotheses, test them, and revise your thinking is a core engineering skill. A well-written debugging story is a direct demonstration of that skill.

4. Comparisons

Comparison posts are easy to write, easy to read, and easy to search for. The format is: "I needed to accomplish X. I tried approach A and approach B. Here is the difference."

Some examples of this that work:

Two libraries that do similar things (e.g., two state management solutions, two ORMs, two testing frameworks)
Two approaches to the same problem (e.g., polling versus webhooks, server-side rendering versus client-side)
Two ways to structure the same code and why you ended up with one over the other

The post does not need a definitive winner. It can end with "it depends on your situation, and here are the factors that would tip me toward each one." That kind of nuance is often more useful to a reader than a forced recommendation, and it is more honest about how engineering decisions actually work.

Comparison posts also show that you are evaluating your tools rather than just using whatever you encounter first. That is a signal of developing technical maturity.

5. Short tutorials on things you just learned

The objection to writing a tutorial as a junior developer is usually: "Someone else already wrote this. A better version. Why should I write another one?"

The answer is that a tutorial you wrote while the concept is still fresh in your memory will be structured around the confusions a beginner actually has. An expert writing a tutorial will often skip the steps that seem obvious to them but are opaque to someone encountering the concept for the first time. You do not have that problem right now, because you just encountered it.

Keep these short. A tutorial on one specific, narrow thing is more useful than an all-in-one guide. "How to connect a Django app to a PostgreSQL database on Railway" is a more useful post than "a complete guide to Django deployment." The narrow version answers one clear question. The sprawling version tries to answer everything and usually does none of it well.

The tutorial format also benefits from code that actually runs. If you copy the example code from your tutorial and run it, does it work? If yes, your tutorial is already better than many of the ones online.

How to keep finding topics

The raw material for blog posts is your day-to-day work as a developer. Here is a practical system for capturing it.

Keep a running list somewhere. A notes app, a text file, a Notion page, it does not matter. When you solve a problem, add a one-line description. When a concept finally clicks, add a note. When you spend more than an hour on something that turned out to have a simple solution, write down what it was.

That list is your content backlog. When you sit down to write, you are not starting from nothing. You are choosing from a list of things you already experienced.

The posts that perform best in search and generate the most useful engagement are usually the ones where the writer was genuinely confused and then genuinely figured it out. That experience is not rare for a junior developer. It happens constantly. The only thing standing between that experience and a published post is the decision to write it down.

The "document, don't create" frame

This phrase has been used in various forms by developers who write publicly, and it is worth taking seriously. The resistance to writing usually comes from the belief that you need to produce something original. An insight no one has had. A technique no one has published.

You do not. You are documenting your learning. Writing it down in your own words, with the confusions and false starts you actually had, produces something that is both useful to other learners and genuinely represents your own thinking.

Starting a technical blog is the bigger picture question of setup and platforms. But once you are past the setup, topic generation is the recurring challenge. The categories above are not a finite list. They are generative patterns. Almost every technical experience you have fits one of them: a project with decisions, a concept you finally understood, a bug you traced and fixed, two approaches you compared, or a thing you just learned.

A note on post-mortems

There is a related format worth mentioning even though it applies more to projects with problems than to general learning: the technical post-mortem. If something went wrong with a project, writing a structured account of what happened, what you did, and what you learned is both good practice and compelling reading.

Technical post-mortems are common in professional engineering culture. Writing one as a junior developer shows that you understand the value of reflection and that you can be honest about failure in a productive way. That is a signal that stands out.

Getting started

The most useful thing to do with this list is to pick one category and one topic right now. Not later, not after more planning.

If you finished a project this month, write the project writeup. If you got stuck on a concept this week and finally got it, write the "I was confused by X" post. If you squashed a bug yesterday, write the debugging story.

The best time to write these posts is immediately after the experience, when the details are fresh and the confusion you had is still recent enough to inform your explanation. Waiting tends to mean not writing.

Related reading: how to start a technical blog covers the platform and setup questions so you have somewhere to publish once you have something to say. For how writing fits into your job search more broadly, writing online as a developer explains the mechanisms that make it useful for getting hired.