Adam Keys is Thinking

Left to my own devices, I write in the second person. With apologies to my high school English teachers, I have a justification for this: I’m writing to myself from one, five, ten, twenty years ago.

I’m writing a thing on the skill of reading framework code. I try to keep in mind that I should write to you the reader from me the first person, so as not to project upon you. But I keep writing to you the past version of myself, like I’m Scrooged‘ing myself, sending back little bits of wisdom about things that worked out for future me and things that future me wishes past me tried differently.

So sometimes you, the reader, will see me hastily publish something written in the second person. Sometimes I’m diligent and search&replace for “you”. Tools like Grammarly could probably help me here. But sometimes, I like to leave in the notes to my past or future self. 🤷‍♂️

Michael Feathers on locality in software design:

You have locality when you don’t have to look beyond your gaze to understand how you are affected or how you affect.

I find languages with a strong module system (Rust, Clojure, sometimes ES6-by-the-books) make each source file more coherent and easier to read than languages where methods or state have more sophisticated/powerful lookup schemes (Ruby, React-flavored ES6).

Plus, strong module systems seem to come with the side benefit of encouraging us to make up names for the functions and state we import, again improving coherence and readability.

A strong sense of locality, module systems, and coherence aren’t in a causal relationship, but they sure do taste great together.

The deep-black, serene face on this watch is a real winner. The numbering and proportions are also ace.

Who sang lead the most on each Beach Boys album? - Brian Wilson is way more active after Pet Sounds than I would have imagined.

On team composition and the distribution of higher/lower experience team members:

Even though pretty much any team can deliver results, suboptimal team composition is still a problem.  It’s a problem when teams working on very straightforward projects take longer than necessary.  It’s a problem when teams stacked with senior engineers are neither mentoring junior engineers nor taking moonshots.  Most importantly, these problems are hard to notice because, again, everyone’s delivering results.

• Richard Crowley

I often say that learning test-driven development is comparable to learning a whole other programming language. The practice of TDD is a mirror world of depth and trade-offs. Kent Beck underscores that depth in listing all [the desirable qualities of good tests], some of which are at tension with each other. Tests aren’t the easiest thing to get right, but there’s no better way to improve your design skills than to wrestle with the feedback loop of writing tests for the code you’re currently working on.

I’ve been reorganizing some notes and considering moving specific topics/tags out of Bear. Turns out I can search across Bear, OmniOutliner, Ulysses, and random text files on my Mac w/ Spotlight pretty well now. Just type in a few words I vaguely recall and boom I’m there. That’s a promising development, the future we were promised!