Adam Keys is Thinking

Sometimes I ask myself: why did past Adam think this text/link/picture/etc. was important. Increasingly the answer is: put it in a bucket that makes the answer self-explanatory. For example: I have tags in Bear for music, recommendations, notes on The System of the World, Technology, software, Disney, and even for random tweets that I will sometime want to share with someone as proof that I’m not just making this up.

twitter.com/rands/sta…

95% endorsed! The exception: I am extremely picky about the size and aspect ratio of windows in relation to how the particular application is designed. I can neither walk into Mordor or simply resize an application to use exactly 50% of my screen.

Prolific is better than perfect, Jared Dees:

“Perfect” is a mirage that no one knows how to reach.

I’m fond of restating this in terms of the quantity/quality trade-off. It’s easy for me to fall into the temptation of creating one essay/pull request/turn-of-phrase that exhibits all of the quality that should exemplify my work. But it’s better for me to create a bunch of things that exhibit some of that quality so I can better learn what is essential to the quality and what is illusory.

To borrow Dees’ model: if I write fifty-two blog posts in a year, several of them will be Not That Great. But after the first dozen or so, I’ll start to figure out what’s important in a story and what I thought was important but doesn’t really matter much. This is quantity creating quality; not a tradeoff!

The flip side is Chidi’s dilemma: spending your whole life trying to write every single thing about your area of expertise, with nuance, and producing something so impenetrable that not even a demigod can make sense of it.

In short: quantity doesn’t reduce quality. Quantity is the feedback loop that creates Quality.

Yesterday I was handed a fresh, nifty new laptop. This is, for me, mildly terrifying. Last time I did a clean operating system install was seven years ago. I’ve carried an idiomatic mixtape of dotfiles, macOS preferences, files, and cruft with me on my personal laptop ever since.

A brand-new, stock laptop is a shock to my highly acclimated and particular system.

I started contemplating how exactly I could get setup relatively quickly. At the same time, I want to pay down a little bit of automation debt. By the next time I’m faced with this situation (when I buy my own computer, if a disk is struck by lightning, etc.) I shouldn’t feel so much like a deer in headlights.

At first I thought I’d attempt to transmogrify my current lightsaber into something like Gina Tripani’s dotfiles. I like how this is structured, and that the initial setup of apps and Unix-y things is bootstrapped by Homebrew. But, then I remembered Thoughtbot’s laptop and dotfiles and convinced myself this was the way to go.

Indeed, laptop helped me cut the Gordian knot of setting up my new machine so I can write code and feel at home on it. I highly recommend it if you have the means.

New dotfile repo forthcoming!

The first few years of my career, I edited the wrong file all the time. I could spend hours making changes, wondering why nothing was happening, until I realized I’d been tinkering in the wrong place because I was misreading a file path or not paying close enough attention to control flow.

Fast forward to now, and I’m pretty quick to drop a raise “BLORP” in code I’m tinkering with if things aren’t working like I think they should. All hail puts debuggerering.

However, it turns out I found a new class of this operator error today. I was diligently re-running a test case, expecting new results when the test fixture file I thought was changed was the wrong file. Once I deleted the right file, I was back on my way.

Joyful and grumpy are we who can find new ways to screw up time ever day!

A few folks suggested I try lazy enumerables to make my extremely chained style practical. I was curious about the actual costs of my style, so it’s time for lies and microbenchmarks! Turns out naively chaining a bunch of maps together isn’t very costly, so go with that to start.

Lazy came in much slower than consolidating the logic in one loop or chaining them without lazy. I thought, I must not have used lazy properly. Turns out, I’m probably showing that laziness isn’t well suited to iterating over collections without an early termination clause (e.g. a take, first, or find) and that for small collections (like an 87-line /etc/passwd), the cost of the lazy plumbing can noticeably outweigh the work done inside the loops. Thanks to Rein Heinrich for talking me to the bottom line!

Programming is easier when you know how to stop solving 100 problems with 1 fancy thing and solve 100 problems with 20 plain things.

Ember is probably leading the JavaScript framework pack by supporting releases with security patches for slight more than a year. By comparison, there’s a cottage industry of garages restoring and updating old Porsche sports cars then selling them for ridiculous prices. The USAF (the same one, curiously, that is spending $1.5 trillion on a useless jet, somehow) is going to use their largest strategic bomber, the B-52, for one hundred years.

I’m always thinking about Greg Borenstein’s words when it comes to technology churn:

The constant churn of web technologies hobbles the creation of timeless learning materials and continuity of knowledge across generations.

We should try harder on this.