I’ve been building things for years and writing down almost none of it.
Every project taught me something. Most of those lessons are gone. Not forgotten exactly (I could probably recover them if I sat and dug), but they never got sharp enough to keep. They stayed as a vague sense of I think I learned something there, which is worth roughly nothing.
That’s the honest reason I’m starting this. Not to build an audience, not because a portfolio is supposed to have a blog. Because I kept noticing that the things I understood well were the things I’d had to explain to someone.
Writing is a test you can’t cheat
You can build something that works without fully understanding why. It happens constantly. The thing ships, the metrics look fine, and somewhere inside there’s a decision you made on instinct and never examined.
Writing about it doesn’t let you get away with that. The moment you try to explain why you chose Aurora over DynamoDB for that particular thing, or why a chatbot would have made the problem worse instead of better, you find out immediately whether you have a real reason or a habit.
Half the time I find the reason and it’s solid. The other half I find out I was pattern-matching. Both are useful. Only one of them is comfortable.
What’s going to be here
Two kinds of posts, and they won’t look much alike.
Technical ones. AI agents, architecture, the decisions behind systems I’ve built. Not tutorials. There are enough of those, and they’re mostly written by people who read the docs rather than shipped the thing. I’d rather write about the constraint that forced an unusual choice, or the design I rejected and why. The interesting part of engineering is never the syntax.
The other ones. Work, competition, patience, the strange experience of being early to things. I’m nineteen. I don’t have conclusions about any of it. But I’ve noticed that the people worth reading are usually thinking out loud rather than reporting from the finish line, and I’d rather do that honestly than wait until I’ve earned the right to sound certain.
The rule I’m setting for myself
Nothing goes up that I wouldn’t want to read.
That sounds obvious and it’s the hardest part. Most technical writing exists to demonstrate that the author knows something, which is why so much of it is unreadable: it’s performing rather than communicating. I’ll fail at this sometimes. But that’s the bar.
No fixed schedule. When I’ve built something worth explaining, or thought something through far enough that it holds together, it’ll show up here.
That’s it. Thanks for reading this far.