Skip to main content

What, a Blog?

Feb 19, 2026 · 3 min read

I finally started writing publicly to capture real engineering decisions while they are still fresh. Not polished thought leadership. Real decisions, real tradeoffs, and things that actually work in day-to-day software work. Each post connects to the next.

I started this blog for one reason: I am building toward something bigger, and I want to share the path while it is happening.

For years I postponed writing because there was always something else to ship first. The reason I kept coming back to it is simple: I have strong ideas about engineering, delivery, and quality, and I want to contribute those ideas back to the community.

This is the same reason I started public speaking. It scared the living heck out of me in the beginning, and to be honest it is still nerve-wracking most of the time. I started small with company events, then moved to meetups, and eventually to conferences. Writing is the same pattern for me: start small, iterate in public, and improve with every post. I do not expect every post to be perfect. I expect to get better by writing more.

You will not get polished thought leadership fluff here. You will get real decisions, real tradeoffs, and things that actually work in day-to-day software work.

In practice, that means writing about work close to the metal: how I scope tasks, where I put quality gates, how I decide when to refactor, and how I keep delivery speed from destroying maintainability. These are not abstract opinions. They are patterns tested under deadlines, team constraints, and messy real repos.

It also means sharing failures, not just polished wins. Some of the most useful lessons come from bad assumptions, unclear requirements, or tooling choices that looked smart at first and turned out expensive later. If a post cannot survive that level of honesty, it is probably not worth publishing.

Another reason for writing now is compounding. A single idea in one conversation is easy to lose. A written trail of concrete decisions becomes reusable, both for me and for other engineers trying to solve similar problems. I optimize a lot by nature, and that can stay trapped in my own projects if I do not write it down. This blog is my way of making those lessons reusable.

The plan is simple: write when there is something worth saying, keep it practical, and keep it honest. Each post connects to the next, not as a marketing funnel, but as a real engineering trail.

If that sounds useful, stick around.

Share

Read next

I and AI

I use AI as a fast engineering partner with clear scope, fast implementation loops, and structured review. AI removes execution overhead, but technical judgment stays with me. Higher delivery speed without giving up code quality or ownership.