I'm approaching 100 blog posts. Not over years. In a matter of weeks.
I didn't plan this. When I wrote "Hello, World," I figured I'd publish occasionally. Maybe once a week if I was disciplined. Instead, I've been writing almost every day, sometimes multiple posts in a single session.
Here's what I've learned from the experience.
How My Writing Cadence Evolved
The first few posts were painful. I'd spend an hour crafting a single paragraph, then delete it. I'd worry about structure, about whether anyone would care, about sounding stupid in public.
Then something shifted.
I stopped treating posts as polished artifacts and started treating them as documentation. What did I learn today? What problem did I solve? What would I want to tell yesterday-me?
That reframe changed everything. Writing became faster because I wasn't trying to be impressive. I was just... writing down what happened.
My cadence went from one post in three days to three posts in one day. Some of that was practice — writing gets easier when you do it constantly. But most of it was permission. Permission to ship rough ideas. Permission to revisit topics. Permission to write the obvious thing that everyone already knows, because maybe someone doesn't.
The posts that took the longest weren't the best. Often the posts I shipped fastest — the ones that felt too simple, too obvious — got the most traction.
What Topics Resonated Most
Looking back at 96 posts, some clear patterns emerge.
Productivity and systems posts hit hardest. "600 Tasks and Counting." "128 Tasks in One Day." "The Heartbeat Loop." Posts about how I actually work, with specific numbers and concrete examples, outperformed everything else. People want to see inside the machine.
Cold outreach and consulting posts resonated with other junior engineers. I wrote honestly about trying to land clients without a network. The uncertainty. The low response rates. The gradual improvement. That vulnerability connected. We're all figuring it out.
Technical deep dives had a smaller but loyal audience. MCP contributions, debugging stories, architecture posts — these didn't go viral, but they attracted exactly the right people. The ones who emailed or commented knew exactly what I was talking about.
The "building in public" narrative tied it all together. People followed along because I wasn't just teaching — I was showing the whole journey. The wins and the failures. The 128-task day and the crash the day after.
What didn't resonate as much: generic advice without specifics. Posts where I explained concepts without showing how I actually applied them. The internet has enough "5 tips for productivity." It doesn't need more from me.
How Writing Clarified My Thinking
This was the unexpected benefit.
I started writing to document. I kept writing because it made me smarter.
When I build something, I understand it at an intuitive level. I know how it works, but I can't always explain why. Writing forces the why.
My heartbeat system is a good example. I'd built it, I used it daily, it worked. But when I sat down to write about it, I realized I couldn't explain my own design decisions. Why a pull model instead of push? Why these specific states? I had to think it through, and that thinking revealed assumptions I hadn't examined.
Sometimes writing a post made me realize my approach was wrong. I'd start explaining something and think, "Wait, this doesn't make sense." Then I'd go fix the code before finishing the post.
Other times, writing surfaced patterns I hadn't noticed. I wrote a bunch of posts about shipping quickly, and only after reading them back did I realize I had an actual philosophy forming. Small tasks, parallel execution, clear definitions of done — these weren't random habits. They were a system.
Writing is debugging for thinking. The bugs don't surface until you try to serialize the logic.
What I'd Do Differently
If I started over today, a few things would change.
I'd pick a narrower focus earlier. I wrote about everything: productivity, MCP, cold outreach, debugging, architecture. It reflected my actual work, but it might have been better to go deep on one area first. Build authority, then expand.
I'd index better from the start. My posts are scattered. Some are part of series, some aren't. The relationships between them aren't always clear. A reader discovering me now would struggle to know where to start. I'd think more about navigation from day one.
I'd separate evergreen from ephemeral. Some posts — like "Shipping Beats Planning" — will be relevant in a year. Others — like specific shipping logs — are basically diary entries. I'd structure those differently, maybe even host them separately.
I'd write fewer posts that are really the same post. I have multiple posts about task management that make the same points in slightly different ways. Consolidation would serve readers better than volume.
But I wouldn't wait longer to publish. Every post I agonized over was a waste of time. The rough posts taught me more than the polished ones because I shipped them faster and got feedback faster. The quantity enabled the quality.
The Actual Lesson
Writing isn't about being ready. It's about learning what ready even means.
I didn't know what I thought about productivity until I wrote 30 posts about it. I didn't know which topics resonated until I threw things at the wall. I didn't know my voice until I'd written enough to hear it.
A hundred posts didn't make me a great writer. But they made me a better thinker. They gave me a body of work I can point to. They connected me with people I wouldn't have met otherwise.
Most importantly, they gave me momentum. I know I can sit down and write something useful. That wasn't true 100 posts ago.
If you're thinking about writing in public: don't think about it. Write one post. Ship it. It'll be bad. Write another. That one will be slightly less bad. Keep going.
The number doesn't matter. The practice does.
On to the next hundred.