Jomar Estrella
Why I write
I build small things. Scripts that turned into tools, tools that turned into habits. I am not building large systems and I am not trying to. My instinct is always toward the smallest version that makes the problem go away.
What keeps me at it is one specific feeling and I have never found a better one. Something is opaque, you push at it for a while, and then it opens. It stops being magic and becomes a mechanism, and the moment that happens you can predict it, repair it, and build on top of it. Most people get told they are not technical long before anybody shows them that door is there at all. That bothers me more than it probably should.
Writing is how I find out whether I understood something or only recognised it. You can carry a fuzzy version of an idea around in your head forever and never notice it is fuzzy. You cannot write it down. The page is unforgiving in a way I have come to genuinely enjoy, and a good half of what I know now, I know because I sat down to explain it and found out I could not.
So that is most of what I write here. Where AI models go wrong and why, how to get text out of files that will not hand it over, and how to build the small version instead of buying the large one.
What I do the rest of the week
I build things. Small tools mostly, the kind that solve one problem for one person and never need a roadmap. That includes some of what is on this site, which is the honest reason I write about how they work: I have already been inside them.
Most of my week is the unspectacular middle of that. Reading somebody else's code, working out why a thing behaves differently in the one environment that matters, and rewriting the part I got wrong the first time.
Why I am worth reading on this
Because I will not explain a mechanism I have not seen run. If I describe how something works, I built the small version first, and where I could not get it working I say that rather than describing the version in the documentation.
The code in my articles executes. It comes out of something real rather than being written for the article, which is why it is usually shorter and less tidy than example code tends to be. Tidy example code is often a sign nobody ran it.
What I get wrong
I explain the mechanism when somebody wanted the answer. Not everyone needs to know why it works, and I am slow to notice when the explanation has stopped being useful and started being for me.
What I will not write about
Benchmarks I did not run. There is a whole category of article built from numbers lifted out of somebody else's post, and by the third repetition nobody can say what was measured or on what. If I have not measured it myself, I either leave it out or name the source and say I have not verified it.
I also avoid writing the tutorial for a tool I have used twice. The gaps show, usually exactly where the reader needs it most, which is the point where the documented path stops working.
Back to the blog