Building in public is uncomfortable. You ship something half-baked and people see it. You write down a thought before it’s fully formed and it’s there, forever, attached to your name. That friction is the point.
The default is to hide # Most people — myself included, for a long time — treat their work like a draft. Always one more iteration before it’s ready to show. Always one more feature before the product is good enough. Always one more revision before the post is worth publishing.
Every year a new framework launches with the promise of solving the fundamental problems of software development. Every year engineers adopt it with enthusiasm. Every year the same problems resurface, just in a new form.
The appeal of new # New technology is exciting because it represents possibility. Before you’ve built anything real with a new tool, you can project onto it all the things you wish your current stack could do. The ergonomics feel better because you haven’t hit the edges yet.
There’s a genre of content online that frames learning as an optimization problem. Learn React in 30 days. Master system design in a weekend. The implicit premise is that faster is always better.
I’ve been thinking about whether this is true.
Speed is sometimes the wrong variable # When I’ve tried to learn something fast — really compress it into a short window — I tend to end up with a shallow model that breaks under pressure. I can answer the interview question but I can’t debug the production incident.