Adam Keys is Thinking

I'm a developer who (formerly) recoiled at math, especially calculus and matrices.

Instead, I thought, I loved the language-y parts of software development. Programming languages, little languages, domain-specific languages. Designing the names, concepts, and relationships in APIs. Domain-driven design, jargon, modeling. I thought of myself as more of a writer-y developer than a math-y developer.

I suspect that I’m not alone amongst programmers in favoring liberal arts over sciences. Further, I suspect that over the past two decades the number of programmers with science-y backgrounds has steadily declined.

But, it turns out I do a lot more math than I thought! SQL is set theory. Layout is math (mostly about centering things 🤷). State machines reduce many kinds of logic problems to simple, but math-y, flowcharts. Almost every bit of programming one does is logic, which is, you guessed it, math.

And that only covers web apps! Computer graphics is a heck of a lot of trigonometry (and whatever is involved in calculating diffusion of light). Machine learning is lots of statistics plus a little calculus. Type checking in compilers is category and/or set theory.

The flip side is also true: developers who think they only enjoy the math-y parts do a lot more language/liberal artsy stuff than they think. They've got opinions about language constructs, whether a method name is good or not, if an API is easy to use correctly or not. All "soft" non-math-y constructs!

When it comes down to it, it's more likely that poor math education let me down than I am fundamentally not a math person. Related: Why Math Class Is Boring—and What to Do About It:

There are two types of people in the world: those who enjoyed mathematics class in school, and the other 98% of the population.

It’s hard to land music, books, etc. recommendations from friends because timing is everything. The best case is a recommendation for a thing I didn’t know of and it’s precisely what I need to read or watch at the exact moment. Beyond that, it’s likely I’m reading some 900-page book (humble-brag) or deep into a peak television series (humble-brag) that I’m trying to finish before my attention wanders.

I’ve come up with a couple of ways to more immediately act on recommendations, so they aren’t for naught:

• Download a Kindle/iBooks sample right away and read the first several pages of whatever they recommended. If I’m into it maybe I’ll stick with it. At least, it’s on my backlog of books until I forgot why it’s there and delete it (i.e., 2-3 times a decade).
• Watch the first several minutes of the thing on Netflix or whatever. See if it’s any good instead of watching random YouTube videos recommended by the algorithm.

For everything else, there’s always the long, scary list of things I’d read/watch/play/listen to if we stopped doing billionaires and gave everyone a living wage. 🤷‍♂️

Craig Mod, Fast, instant client side search for Hugo static site generator:

I believe Fast Software is the Best Software and wanted keyboard-based, super fast search for my homepage / online collection of essays. This method was highly inspired by Sublime Text’s CMD-P/CMD-shift-P method of opening files / using functions.

I love that this is a Gist, an idea floating around. Not to reuse wholesale but to adapt and make your own. More like a recipe, less Professional Software Development 🤵‍♂️. Not packaged software, almost a thought-experiment wrought of relatively-accessible code incantations.

Replicache Detailed Design(https://doc.replicache.dev/design):

Replicache runs alongside your existing application infrastructure. You keep your existing server-side stack and client-side frameworks. Replicache doesn’t take ownership of data, and is not the source of truth. Its job is to provide bidirectional sync between your clients and your servers. This makes it easy to adopt: you can try it for just a small piece of functionality, or a small slice of users, while leaving the rest of your application the same.

Conflicts are a fact of life when syncing, but they don’t have to be painful. Replicache rewinds and replays your transactions during sync, sort of like git rebase.

I haven’t used Replicache, but this design document makes me think it has the qualities that excite me when I discover infrastructural software:

• it solves a tricky problem (distributed application state)
• by compressing the problem down to essential concepts
• those concepts are solved in a way that I can imagine “how would I use this?”
• and writing clearly about that solution

If you’re doing the whole servant leadership thing, you’re gonna hear some people venting frustrations. Yihwan Kim, When a 1:1 turns into a vent session:

As an engineering manager, I’m learning that a big part of my job (perhaps my only job) is to help people solve problems. I happen to enjoy solving problems myself. So it’s only natural that when someone starts venting, I want to rationalize the conversation, correct inaccuracies, and discuss actionable next steps.

I always have to remind myself: don’t.

Relatable. It’s easy to react to someone venting by rationalizing and solving. As Yihwan points out, that’s not the card to play here. The win condition for these is to 1) hear your colleague out and 2) help improve the cause of the vent if your teammate wants you to.

Spoiler alert: it’s all about organizing what they wrote in the past, finding it later, and remixing it into something they need in the moment. 🧠

Austin Kleon, Indexing, filing systems, and the art of finding what you have: writing is meticulously indexing what you may have jotted down in the past. Come for the bit on classic American authors, stay for Phyllis Diller and Joan River’s massive card catalogs of jokes! 🤯

Cory Doctorow, Writing is accumulation: it’s easy when you accumulate a pile of text files from blogging over twenty years. He searches and surfs tags to find material for whatever he wants to write about today. An external brain.

That’s how blogging is complimentary to other forms of more serious work: when you’ve done enough of it, you can get entire essays, speeches, stories, novels, spontaneously appearing in a state of near-completeness, ready to be written.

Shawn Wang, Mise en Place Writing: writing is like cooking. Separate the preparation/creation and the cooking/editing.

By decoupling writing from pre-writing, I can write more, faster, and better.

Nat Eliason, Tactics to Help You Become a Better Writer: writing is rules. The better your rules, the better (and more) your output.

It’s true that I can scale myself, teams, and organizations to walk and chew gum at the same time, but it is surprisingly effective to focus on one thing at a time. This is the essence of “priority” — put all my energy into one outcome until it’s done. Then the next one, the next one, etc. as my efforts start to compound.

I, like many folk, do much of my best work in coffee mode. When that deep, coffee mode work aligns with my priority, everything is operating smoothly and life is good. If my priority (singular) changes and I need to go deep on something else, that’s not ideal but not so bad either. As long as I can still focus, things are good. When I’m asked to go deep on two things or pulled to work on deep but unaligned tasks, that’s when things get gnarly.

A useful activity that looks like (and is often called) prioritizing is sorting (“triaging”) a list of potential work by what’s most impactful or important. This is more of a planning activity than a priority exercise. It acknowledges there’s a lot to do and time is finite. The result sends a clear signal: this thing at the top of the list is more important than all the things below it. In particular, any of the top items are more useful to work on than all the things further down the list.

Get better at finishing projects. That’s working smarter, not harder. Finished projects, axiomatically, don’t need prioritizing against other work. Limiting work in progress is difficult to pull off in the moment but a crucial tactic to apply when things get intense.

Possibly controversial: multiple priorities is about the same as having no priorities. The trick that priorities pull is freeing us of the energy-sapping process of deciding what’s most important and what trade-offs to make. A single priority is a note from your past, well-considered self saying “this is more important than all the other things; work on it before anything else”.

Systems of “one priority”:

• Rocks/pebbles/sand
• One Thing
• Kanban
  

Multiple priorities make it unclear what expectations are for individuals. Choosing what to work on becomes difficult and a burden. A single priority is a mission, a clarity of work. Get this thing done, declare victory, move on.

I’ve got three “virtual” desktops going on my Mac right now. The idea each is its own functional workspace. I don’t have three separate physical workspaces to do my writing/thinking, coding/building, or communicating/collaborating. So a digital approximation is the second closest thing. 🤷‍♂️

Leftmost is where I do the thinking. The background is one of the “scenic” images included in macOS. The idea is, if I had a little writing hut, ala Thoreau in Dickinson for looking off into the distance and plying some kind of writing craft, this is the kind of thing I would see when I look up.

Rightmost is where I communicate with the world and my colleagues. The background is also a built-in macOS dynamic desktop of swoopy, abstract colors. Like John Oliver comes to our living room from a featureless void, so I think of this desktop. Ideas, questions, and data points come to me from the void of the internet, end up in this imagined space, and I respond to them in turn through this medium and back to the void. Heavy, eh?

In the middle is where I do the building and coding. The background here is a flat color. I got it by color picking a photo of the 12-Gauge Garage. I noticed later that it’s close to “go away green” as used in Disney’s theme parks to draw the eye away from backstage areas where the magic may be in-progress or under-repair. The idea is I shouldn’t really see this background. I should focus on whatever I’m coding/testing/making/etc.

Planning is essential. But, not too much. Mostly in the next 90-day window (with apologies to Michael Pollan).

Humans are, with few exceptions, awful at planning. It’s impossible to see the future. We rely on our previous experience over data too often. Or, not enough. Or, in the wrong combination for this scenario. Beyond a few days, the world we operate in is too complex, people too hard to predict, and all of it is interconnected in surprising ways.

Even worse, humans easily deceive themselves with plans. It’s so easy to look at basically any kind of ambition or outcome and say “yeah sure, given 6-18 months this seems totally feasible.” (With apologies to our ambition, it probably is not feasible.)

Yet when we account for those hazards, planning is essential (apologies to Dwight Eisenhower). Most things won’t go to plan, but making one forces us to think things through, ahead of time. Outcomes without a plan are worse than outcomes from a plan that has to change when reality punches us in the face (with apologies to Mike Tyson).

I find that periodically looking 90 days into the future to think about what I want to focus on and outcomes I hope to realize is a pretty dang good way of setting myself up for “luck favors the prepared”.

Planning the work is an essential part of doing the work. An ambitious but uncertain 6-month idea becomes an ambitious but plausible plan in steps. Make a 90-day plan by breaking it into chunks. Organize them into a coherent fraction of the 6-month idea. Make trade-offs to decide what’s most important or risky. Start on the first thing. Rinse and repeat.

Iteration is part of planning. Unknowns, predicted and unpredicted, rear their head. Risk turns into caution turns into incidence. Nothing goes exactly to plan. So, we take another swing at the plan, armed with new information.

We’re always smarter than we were last week or last month when we made the plan. Sticking to the plan is foolish. Updating or overhauling the plan makes much more sense than trying to argue with it.

Planning is like writing. They both focus our thinking. An idea that flops when we take it from our brains to the page probably needs more work, whether it’s writing or planning.

I miss tumblelogs. Especially projectionist. Twitter and Tumblr fit the mold, functionally. But the vibe is not the same. That time right before centralized social media achieved critical mass was a great moment. Let a thousand weird flowers bloom in their own meadow.

Omar Rizwan recollects that one of the original selling points of React was that you could consolidate all the HTML, CSS, and JS for a single component in one file. No navigating across large directory trees to find the one line of code that implements the behavior you want. Far less worrying "if I change this am I unwinding a ball of yarn that I will regret?"

(Side note: one of the most powerful tools programmers have is scope. Most things are easier when you're working in smaller and more local scopes. If your HTML/CSS/JS only applies to the file you’re looking at, many things are easy or possible.)

I'd forgotten about this selling point and wish things had evolved differently to support it. In the large, many programming techniques don't work and this one is no exception. But in the small, how wonderful would it be to express everything about an idea you're trying to build in just one place?

Lately, I'm finding that my prototypes and weekend hacks are most successful when I don't try to get "too serious" about them too early. Adding type checkers, linters, even switching contexts to write automated tests are all "too serious". If I give myself a little freedom to work messy and concentrate on the idea, not the code, things go better.

I suspect there's a connection between working messy, generating ideas, and using a framework that doesn't punish/forbid throwing all your code into one file.

You can do a lot of fancy stuff with your notes these days. Backlinks, graphs, embedding, “transclusion”, knowledge databases, and digital gardens are all tempting sirens. But building up a collection of ideas over time and ease of search is the most important thing.

Matt Webb, Memexes, mountain lakes, and the serendipity of old ideas:

I’ve noticed that smart people keep notes, and in particular use their notes in a certain way, and it made me think of something I read recently about viruses.

…

And it’s interesting, right, this accretive note-taking and the process of taking core samples through the deep time of your own ideas. I’ve built something similar, not as consistently, but for about two decades too, and I keep all my notes in plain text, and all in the same searchable database. I develop nascent ideas in part by typing in keywords, spelunking my own memex for things I’ve previously spotted, connections I’ve made, turns of phrase… most of which I had forgotten, but there they are. And old ideas come back and get recombined and become fresh again. That database of notes is my greatest asset. It’s how I write here, and it’s also how I pretend to be clever when I’m working.

The endgame of having extensive notes accumulated over a long period of time is not to put them in a grand, unified theory. The point is to play the long-game to think in them, search them for new insights, and to develop ideas over weeks and months. An antidote to thinking in Slack messages and tweet-storm hot-takes.

Daveed Diggs mentioned this awesome wallpaper, Bay Area Toile, in a tour of his house. Amongst the Bay Area celebrities whose likenesses it features is Humpty Hump aka Shock G of Digital Underground. Jorma Taccone of the Lonely Island was involved in designing it.

That’s a hell of a thing right there. And, I never thought I’d think of wallpaper as awesome.

“This is a showtime, but the show hasn’t been written for it”

The Case of the Missing Rewards - Luckily, in my many hours playing Destiny 2 I haven’t been bitten by this bug. Seeing behind the curtains of something I interact with so often is pretty neat though!

It’s fascinating to read the tale of a gnarly bug from a domain I have no practical experience working in. In this case, large-scale, long-term game development. The volume and detail of data they work with to find a strange little bug that only manifests in certain kinds of game activities and involves weird decisions made in sizing networking subsystem buffers is amazing.

See also, How I cut GTA Online loading times by 70%

A good email newsletter is like the conversation you may have had over coffee with an interesting pal. A surprising topic, a novel theory, perhaps an amusing tangent or two.

I’m feeling the trough of newsletter overload, like many folks. I’ve put my own on hiatus because it seems more useful to write broadly on the web than narrowly via email.

I suspect that email newsletters have evolved from interesting conversations to (mostly) yet another medium to build eyeballs to sell to someday. Or, newsletters were the mold that blogging reinvented itself from.

But, I still think good newsletters could still exist. But, they have to feel more like a conversation and less like a monologue.

Paul Ford, The Secret, Essential Geography of the Office:

Offices have their own mental maps. “Oh,” they say, “she’s moving to the 17th floor.” And everyone says: the 17th floor! And you know, being a social primate, exactly where you are in the organization relative to that floor. Offices all have their formal and informal maps, whether inside a bank, statehouse, cathedral, museum, school, or open-plan tech firm. I say “West Wing” and you know what I’m talking about.

I once worked at a company where the hypothesis behind customer acquisition was currently in flux. A couple times a quarter, a new concept would come along. With a new concept almost always came a change in the sequencing of handoffs between teams. This month, outside sales hands off to the onboarding team hands off to customer support. The next month, marketing hands off to outside sales hands off to onboarding.

It so happens this company had a large, somewhat raucous open office layout. All of sales, support, and marketing were in one big room. (With three different Sonos systems playing three different songs at any given time. Madness.)

It also so happened that this was a high-energy sales culture. (Are there kinds of sales culture? Someone tell me there are monk-ish sales people, making one call per day, speaking only a few quiet words, ringing a small bell, and going home for the day. 😆)

Thus, when the current concept of how customers were handed off from the top of the funnel downward, a few people would move the desks around so hand-offs happened across aisles of the office and not from one corner of the office to a remote corner sixty feet away.

The upside of all this apparent chaos was that on any given day, you could walk into the office and see the current hypothesis of customer acquisition. As long as you knew who was in sales, marketing, support, etc. or their typical posture (walking around talking on a headset, answering emails as quickly as possible, looking at marketing campaign mockups), you could tell what’s going on. One could literally walk through the funnel, from marketing to sales to onboarding (assuming that was the hypothesis of the day).

Besides the madness of open offices with multiple songs within speaking distance of each other, I think this is not the worst way to arrange a physical workspace.

I saw this BMW at Radwood in Austin last year.

In hindsight, I would kinda like to know the whole story behind this car and the custom plate.