Musings (I)

I believe that blogs function best when their authors only post when they have something to say.^[1] I also think that out of respect for my readers' time I should avoid posting unsubstantial posts. I want the posts here to be worth reading and for the most part not too topical or current-event heavy.

All that said, I do have occasional thoughts that are not large enough for their own post but that I still want to capture and share, so I expect this post to be the first in a series that I will publish sporadically as I collect enough new things worth sharing.

Font Recommendations

I came across the site Grabby Aliens on Hacker News the other day and was struck by the font combination, enough so that I stole the fonts they used for this website. Actually, that's not quite true. The font pairing they are using is Inter and Hoefler Text. Inter is available on Google Fonts, but Hoefler Text is proprietary and too expensive for a site such as this, so I went with EB Garamond instead, which is similar in spirit but free.

Shakespeare's Advice to the Anti-Natalists

Sonnet 3

Look in thy glass and tell the face thou viewest
Now is the time that face should form another,
Whose fresh repair if now thou not renewest,
Thou dost beguile the world, unbless some mother.
For where is she so fair whose uneared womb
Disdains the tillage of thy husbandry?
Or who is he so fond will be the tomb
Of his self-love, to stop posterity?
Thou art thy mother's glass, and she in thee
Calls back the lovely April of her prime;
So thou through windows of thine age shalt see,
Despite of wrinkles, this thy golden time.
But if thou live remembered not to be,
Die single, and thine image dies with thee.

Why is Programming So Frustrating?

A significant numbers of programmers, possibly a majority, find programming frustrating. Why is this? There are probably many reasons, but a core one is the difference between product and process. Programming is a process, while a program is a product. The trouble is that programmers mistake the process for the product. You want your program to be easy to use, do its job well, and hopefully use resources (memory, cpu, storage, etc.) parsimoniously. If it appears this way to your users then you've done your job well. The literal code you write is not the product, in the same way that the drafts, edits, and scrapped sections of a manuscript are not what matters to readers. The finished book is what matters. Same with the finished program. Almost no act of creation is entirely pleasant, from childbirth to sculpting. It's foolish to assume programming would be any different.

Accidental Complexity Vs. Essential Complexity

This relates to the above section on why programming is frustrating. It's a cliche in creative work in general, but particularly in software, that you want to avoid accidental complexity so that you can better deal with essential complexity. I don't have any criticism of this idea, I think it is correct, however, it is easy to trick yourself into believing that something is essential complexity just because it has never been solved to date. For example, services like Render are a massive improvement over AWS for most SaaS type sites, however, prior to Render's existence, many developers would say you couldn't do much better than AWS, and many will still say this today, or argue that "akshually AWS isn't that bad, you just have to understand it better". These people are, of course, fooling themselves. Creating things is hard. If it wasn't the world would look a lot nicer than it does. If you want to create better than average things you need to approach problems in better than average ways, and one way to do that is to question your assumptions about what is accidental and what is essential complexity.

Physical Products Need Debugging Too

Programmers often think other engineering disciplines get things right the first time. This is not true. Few things work correctly the first time, whether due to tolerance issues, unanticipated failure modes, or just overlooking something in the design stage. I was reminded of this while reading a memoir of George E. Frost's experiences in the ammunition making business. Ammo is an interesting product because it must be manufactured to fairly tight tolerances, but it is basically destroyed after one use. The entire book is fascinating, but the part relevant to this discussion was a section discussing setting up a new plant in Mexico. They had purchased machines from another ammunition maker for the plant. The machines worked but required a significant amount of tuning to get things within tolerance and the integration into the assembly line was non-trivial as well. He even referred to this sort of work as "debugging". So the next time you feel frustrated while trying to connect two libraries together or struggling to track down some tricky bug just know it's not much better in the world of atoms.^[2]