Why I build
There is a particular kind of satisfaction in making a thing work. Not the loud satisfaction of finishing a release or shipping a feature — the quieter one, of watching a process exit cleanly, a test pass, a function return what you expected on the first try. It is small, and it is most of the work.
I came to computer science later than some of my peers. I wrote my first useful program — a script that renamed my music library — when I was sixteen, and I remember being slightly embarrassed that I had not started earlier. In hindsight, the lateness was a gift. By the time I started, I had already failed at enough other things to know that difficulty is not a signal to stop.
What I am looking for
When I think about the kind of engineer I want to become, three things matter to me:
- Working at the right level of abstraction. Most software pain comes from being one level too high or too low. The skill is in noticing the mismatch and being willing to step.
- Finishing things. A half-built system teaches you less than a finished, ugly one. The last 20% is where the lessons live.
- Caring about the reader. Code is read more than it is written. So is everything else — docs, commit messages, pull requests, postmortems.
The best engineers I have worked with treat the next reader as a guest in their codebase. The worst treat them as an intruder.
None of this is original. It is the conventional wisdom of every engineering blog written in the last fifteen years. But conventional wisdom has to be earned, and the only way to earn it is to write the bad version first.
What this blog is for
I want a place to think out loud — about distributed systems, about the modules I am taking, about the small projects I run in parallel, about the things I read. I do not promise expertise. I promise honesty about what I do and do not understand.
If that sounds useful, welcome.