Many years ago (circa 2001) I wrote a letter to C/C++ User’s Journal (an odd but interesting name: users of C/C++? A user of languages implies an interesting relationship) that argued for automatic type inference in C++. Andrew Koening replied because my letter was in response to one of his articles saying more or less “yes, we want type inference but probably not in the next version of the standard”. It turned out later that he (and everybody else) misjudged how long it would take for the new standard to come out so type inference did end up in the C++11 standard.

Sorry for starting this with a long quote but it’s important: “Centuries ago, if you had wanted to build a large structure such as a bridge or a cathedral you would have engaged a master builder. He would have had some knowledge of what it takes to give a structure strength and stability with the least possible expense and effort. He would not have been able to express much of this knowledge in the language of mathematics and physics, as we can today.

I lovingly call my daily breakfast “the sludge”. The recipe has evolved over the years, even changed substantially, but it has essentially survived for 10+ years, even through the many years of no-breakfast intermittent fasting. It’s essentially protein and fiber bomb. The current iteration is the one I love the most so far as it’s both the healthiest for me and reminds me of the chocolate oatmeal breakfast that I grew up on.

I have decided to no longer deploy a post “when it’s ready” because they are mostly never ready. I am writing other things that are occupying my head space and then posts just linger, unfinished, some for years. So instead I am going to do a quarterly drops of posts. I won’t be changing the dates so past dates will suddenly appear but as far as I know I have a single reader (hey friend) so I don’t think it will matter much :)

A friend writes, talking about a stateless software component (lets call it X) that we both know well (edited for clarity and to remove concrete details): The reason why I call it a monolith is because we still have to deploy the whole thing at once. Ex: We want to enhance the capability <X>. If we had another component in front I could make changes to just that component. When we discussed it today I felt we were very concerned about the global rollout.

I hate the fact that in Postgres I cannot give the query planner any hints about what indexes it should be using. It’s such a… paternalistic view of “we always know better”. Do I think I always know more than the query planner? Not at all and in 99% of the cases I would just leave it alone (and I have - I think I used index hint maybe twice out of hundreds of pure SQL production queries that I have written).

During my onboarding at Levels, I was asked to write a “User’s Manual” for me. Here’s a free-form draft (with some slight edits) that I finally didn’t use directly because the actual User’s Manual was much more structured: I am a “strongly typed” kind of a person: I will take all your utterances at face value, without wiggle room. This is automatic and natural and has been as long as I can remember.

I had a large PR that colleague asked me to split into multiple smaller PRs. I reviewed different tools but those either: split the PRs based on commits or unrolled PRs into a linked list of branches Neither of these seemed like a good choice because both assumed that somehow timeline matters when it comes to splitting. But I think that the right grouping is not time based but file based.

I wrote this out in 2022 but never published it. A colleague from back then had a lot of input into this but he wrote out a different thing, continuous to this, which with his permission I might publish at a later date. I have left my previous position recently and things I have read, viewed and heard throughout my onboarding process (in the new org) made me think of this draft.

I have recently re-listened, after 10 years, the “Lean Startup” by Eric Ries. I think it was and still is an important book and in retrospect, I wish that I had taken it more to heart and re-read it more often. But I have some major qualms with it as well. Qualms I will start with what looks like a minor qualm, like nitpicking, but which I hope to show lies at the heart of my disagreements with this book.