Learning in public as a system

Why write while learning

Learning in public is not only a branding strategy. For me, it is a way to make learning harder to fake.

Private notes can become vague. A public note has to survive another person's reading. It needs a clear claim, enough context, and a reason to exist.

That pressure is useful.

It also changes how I study. If I know a concept might become public writing later, I pay more attention to the parts I cannot explain yet.

When I write about a project or concept, I have to ask:

• What did I actually build or understand?
• What problem was I solving?
• What tradeoff did I make?
• What would I do differently now?
• What can someone else learn from this?

Those questions make the learning sharper.

The difference between notes and essays

Not every note should become an essay.

Some notes are temporary. They help me remember commands, bugs, links, or fragments of thinking. An essay needs a stronger shape. It should carry one idea from beginning to end.

I like to think of the pipeline like this:

1. capture messy notes while working
2. extract the durable lesson
3. connect the lesson to a project or concept
4. write a short public version
5. revise when the work changes

This website is meant to be the public end of that pipeline.

My current rule

My current rule is that a public note should do at least one of three things:

1. explain a concept I want to remember
2. document a project decision I might be asked about later
3. capture a lesson that could help someone else avoid a mistake

If a note does none of those, it can stay private.

Why project notes matter

A portfolio page can show what exists. A project note can show how I think.

For example, listing a tech stack is useful, but it does not explain why those tools were chosen. A good project note can explain the product constraint, the architecture, the tradeoff, and the lesson.

That is why I want this site to be writing-first. The projects still matter, but the writing gives them context.

The portfolio says what I built. The writing says how I think while building.

The risk

The risk of learning in public is performing certainty.

It is tempting to write like every decision was obvious after the fact. Real work is messier. Sometimes the first approach was wrong. Sometimes the constraint was unclear. Sometimes the lesson is still provisional.

I want the writing here to keep some of that honesty.

A useful note can say:

• I chose this because...
• This worked for now, but...
• The weakness is...
• The next version should...

That kind of writing is more durable than pretending every project was perfectly planned.

A useful tone

The tone I want is direct and careful. Not too polished, not too casual, and not trying to sound older than I am.

For technical posts, that means explaining the hard part plainly. For project notes, it means saying what the system does, what tradeoff shaped it, and what I would improve next.

What I want this site to become

I want this site to be a public notebook for technical growth.

Some posts will be computer science explanations. Some will be project case notes. Some will be reflections on learning, building, and working with AI tools.

The point is not to publish every thought. The point is to leave behind enough evidence that someone can see both the output and the reasoning behind it.

That is the standard I want to keep improving toward.