Why I keep a technical notebook

Most side projects start with a very clear idea and end with twelve browser tabs, three discarded approaches and one oddly specific lesson you cannot find in the documentation.

This blog is where I want to keep those lessons.

I am less interested in writing broad tutorials that pretend every project follows the same path. I would rather document the useful middle: why I chose a boring solution, what broke under real use, and which small detail made a system noticeably better.

What will show up here

My work often sits between cloud software and the hardware people already own. That means Rust and TypeScript, local models, device communication, privacy boundaries and the occasional deep dive into performance.

Some posts will be technical. Others may just be a short record of a decision I want to remember. If a solution only worked in one very specific situation, I will say so.

Why publish it?

Writing forces me to separate what I know from what merely happened to work once. Publishing adds one more useful constraint: the explanation should make sense to someone who was not in the room.

That is the whole plan. Build things, pay attention, and leave better notes than last time.