Adam Keys is Thinking

A thing I’ve learned from weightlifting (also from Destiny, but that’s a whole other thing), is the value of showing up several times a week and putting in the right kind of work.

Learning is training, and the quality of your reps is important. David Perell makes the connection better than I could:

Athletes train. Musicians train. Performers train. But knowledge workers don’t.

Knowledge workers should train like LeBron, and implement strict “learning plans.” To be sure, intellectual life is different from basketball. Success is harder to measure and the metrics for improvement aren’t quite as clear. Even then, there’s a lot to learn from the way top athletes train. They are clear in their objectives and deliberate in their pursuit of improvement.

Knowledge workers should imitate them.

Learn like an athlete

In short:

• Train intentionally: choose one learning project per quarter.
• Do the reps: learn every day.
• Train in public/on Instagram: write/blog/etc. about your journey.

Economist Tyler Cowen also commented and shared his routine.

My personal routine this month is: read fiction and non-fiction every day. Write or revise every day with an eye towards building up my muscle for publishing articles on this blog.

Also: floss every night. 🤷‍♂️

Related: applying a fitness training mindset to software development is a great way to reach “I know this”!

How William Gibson Keeps His Science Fiction Real - I gotta read more Gibson; just as soon as I finish all the Stephenson. 🤦‍♂️

One of them showed him an episode of “Cops,” the pioneering reality series in which camera crews sprinted alongside police officers as they apprehended suspects. Policing, as performance, could be monetized. He could feel the world’s [fuckedness quotient] drifting upward.

Futurists he knew had begun talking about “the Singularity”—the moment when humanity is transformed completely by technology. Gibson didn’t buy it; he aimed to represent a “half-assed Singularity”—a world transforming dramatically but haphazardly. “It doesn’t feel to me that it’s in our nature to do anything perfectly,” he said.

He spent time on eBay—the first Web site that felt to him like a real place, perhaps because it was full of other people and their junk. Through eBay, he discovered an online watch forum, and, through the forum, he developed some expertise in military watches. He learned of a warehouse in Egypt from which it was possible to procure extinct Omega components; he sourced, for the forum membership, a particular kind of watch strap, the G10, which had originally been manufactured in the nineteen-seventies and had since become obscure. (A version of it, known as the NATO strap, is now wildly popular in menswear circles.) Gibson noticed that people with access to unlimited information could develop illusions of omniscience. He got into a few political debates on the forum. He felt the F.Q. creeping upward.

Did Gibson popularize the NATO watch strap or was he just ahead of the horological time?🥁

Setting roadmaps and key results feel like truthful, strategic work. But the flip side is, if you approach them at face value or don’t focus on the outcome, they reduce the ability for teams to creatively pursue different solutions in service of the desired outcome. That increases your risk of exceeding calendar/complexity budgets!

I’ve come to hate the damage the “product roadmap” metaphor does to the brains of everyone involved in developing a product. When I use an actual map of actual roads, I assume that I know where I’m going and how I’m going to get there. This is never the case when developing a product.

Kent Beck, Decisions, Decisions or Why Baskets of Options Dominate

Instead: choose shorter iterations that let you try an idea, spend a limited amount of time on it, and decide if it’s worth further pursuit. Optionality! The downside is, now you have to decide on each idea that got you closer to building the product or achieving the key result. Decision fatigue: It’s a better problem than no options! 🤷‍♂️

Consumers, on the other hand, love options. Buying a car, instead of e.g. a bike or using scooters and buses, is buying a bundle of options:

That’s why ditching car ownership is going to be really unattractive for a lot of people - no matter how attractive you make the alternatives. Unless you can replace all of the important jobs that a car does for you, all at once, then competing against the car means competing against free. Actually, it’s worse than that - it means competing against free and nice. Bundle economics (and also ego issues) are powerful enough that it’s pretty rare to see people downgrade their cars, even if their car requirements have gone way down (like they had kids go off to college). Once you go SUV, you don’t go back.

Alex Danco, The Car Bundle

When we’re buying cars, we are making trade-offs on money, signaling, time, practicality, wanderlust, recreation, and whatever hoops the car salesperson is putting us through. Again, decisions are fatiguing!

I'm having a moment where I feel like I've got a winning wakeup/morning formula 🎊. Wake up early, around 6:30am. Feed the cats so they don't barf in protest later. Skim the tweets and feeds for a few minutes while the brain boots up. Write for five, fifteen minutes or so. Organize and think about notes/files/projects/research (I'm trying PARA) and the structure of my work. Meditate. Work out, get to work (around 9:30am, lately).

Drink coffee. Focus before lunch. Teamwork after lunch, focused if possible. But probably meetings or 1:1s. Land ideas/tasks/projects/articles into Things as I work so I can avoid distractions.

Backfill things I finished into my todo so I don't have days where I accomplish a lot but check off little. Finish work by 6ish. Read in the evenings. Restrict gaming to weeks my wife travels for competitions. (Narrator: he used restrict in a loose sense, here). Watch the Peak Television, or just Bob's Burgers re-runs in the evening. Read a bit before bed, but probably also end up watching car videos on YouTube.

I fall to sleep easily, which is my superpower. Rinse, repeat.

“’tis better to have known a software bug than to have never had a software at all”

Lord Alfred Tennyson, except not

Software that never ships never has issues. Draw the line, get it out there. Celebrate a little and recharge your batteries. Now fix the important stuff; it may not even be the bug that almost held up your release.

Dave Rupert, Everything I Know About Remote Work. Me, everything I know about working with remote workers when you're co-located:

1. Every single meeting has a video link.
2. If one person is remote on a meeting, it's optimal to have everyone on the video call. Meeting rooms with video equipment are good, but don't put everyone on equal footing. Mind the dynamic! One person with their laptop open vaguely facing most participants is not even acceptable.
3. People naturally discuss and even decide things face-to-face/offline when colocated. That's fine! Make sure one person summarizes the shape of the conversation and important take-aways in email/Slack/whatever you're using.
4. You now work async. On the downside, that means anyone on your team could now be heads-down, in the zone, not responding to your emails/Slacks while they get stuff done. On the upside, you can turn off all your distractions and get some stuff done too!

The end.

Narrator: there was probably more...

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. 🤷‍♂️

You can Graphviz on the web now. Roughly-drawn sketch style, slightly Swiss modernism, or even in the design tool Figma. Mostly enabled by a port of Graphviz to Web Assembly via emscripten. This is one of the futures I was promised.

The thing which makes blogging difficult is not engagement, analytics, finding just the right theme, curating to a newsletter, managing comments, finding reach after the demise of Google reader, etc.

The hardest part is showing up, every day, writing. The hardest part is writing! The second hardest thing is hitting the publish button on a regular basis, not necessarily every day.

Deciding what to write about is pretty tricky too. And not falling prey to "hmm this idea really deserves a nine-part, 15 thousand word treatment, probably in eBook form". And hitting Publish even when you're not sure.

So I'm trying to blog (most/many) days in November. Which is easier than writing a whole book! The roadblocks look pretty similar, though.

I'm currently intrigued by, and not entirely sure what to do with, the ideas of Toby Shorin. Particularly, Jobs To Be Done and The Desire for Full Automation. The thread of design thinking, the "needs" of technology, capitalism, and social systems runs throughout. Milkshakes are perfect for commutes, jobs are as varied as chores, biological functions, and societal norms. Existing in the system of the world, the system and our job within it defining us. What capitalism desires of people and society, the need for automation therein. Whether automation of tedium liberates or restricts us. Has the agency of capital (the excess money in the emergent system we live in) already turned us into automatons for its purposes? How does automation and purpose square with religion? 🤔🤔🤔

The hardest part for me is knowing when to use this. It creates a lot of friction for a small application, but all applications start small. Moving to an event-sourced architecture when your application (and team) is no longer small feels like a big undertaking that could be hard to justify.

Dave Copeland, Event Sourcing in the Small

Once an application is big enough to need it, it's already hard to introduce it. But, it's too much trouble to start an application with this architecture. Maybe this is corollary to "most things are easy/workable on small teams/applications"?

A few problems that Dave ran into building a small event-sourced data model were in deriving the domain models (he called them projections) from the event data model. It's possible that there's a sweet balance point between rolling this kind of data flow behavior by hand and building an entire framework around capturing events that are transformed for various consumers to their specific domain model needs. I haven't seen it yet.

I haven't kept up with Datomic, but the interesting about it a few years ago was that it was sort of event sourcing as a database. Data producers store events to it (in a format that strongly resembled RDF triples). Consumers used data flow queries to define how to transform and scope that data to their needs. It also had a pretty sweet time-travel story. (I'm always a sucker for a good time-travel story.)

If well-considered boundaries and excellent operational tooling are the enabling factors of a services architecture, what are the enabling factors of an event-modeled architecture?

There was a time when the hacker mindset was about something nice.

They’ve adopted a hacking mindset. They translate this clever, ethical, enjoyable, excellence-seeking behaviour to their everyday lives. See? Hacking is a mindset, not a skillset. When you seek, in your everyday life, to deliberately find opportunities to be clever, ethical, to enjoy what you are doing, to seek excellence, then you’re hacking.

Not enriching a few people. Not replacing everyone else's bad things with differently-bad treadmills. Not crushing 20-hour days, the latest programming hype, or whatever Paul Graham/Peter Thiel are saying. The orange website ethos, as one might say.

Enjoyable. Ethical. Seeking excellence to reshape the world into something better for everyone's everyday life.

My favorite thing about software development is the breadth and depth of the profession. On the one hand, there’s a ton to learn about computer science, programming languages, operating systems, databases, user interface, networking, and so on. On the other hand, there’s even more to learn about math, payments, sociology, team dynamics, finance, commerce, linguistics, business, design, etc. Pretty much the whole world around us!

Some folks tell you topics are off-limits. “Front-end developers don’t need to know databases”. “Back-end developers don’t need to know design”. “You only need to know Linux if you’re doing dev-ops”. “The humanities are a waste of your time.”

Those folks are wrong. 😡

You can pick up whatever ideas you want. You can study a topic at any depth. Choose your own specialization. Learn whatever you want, however you want.

Maybe you want to know just enough Fourier math to understand how imaging and audio systems work. Maybe you’re so hungry for clever math you work the problem sets from a college course. Either way is fine!

Several years ago I wanted to understand the jargon and mechanics of economics and finance. So, I listened to a bunch of podcasts, read a few books, and consistently read a magazine. I can throw around words like “negative externalities” or “financial instrument” now, but I’m no expert. I’m cool with that. I’m just here to understand the shape of things, not to become a professional.

Point is, all of these ideas could come in handy under the very large tent that is software development. Go learn economics, databases, design, or whatever. The more you know, the more likely you are to create a connection between adjacent ideas.

Beyond the languages, the libraries, and all the hype cycles, the ability to understand domains of knowledge is what sets great developers aside from good ones. And none of that knowledge, whether technical or otherwise, is off limits!

We could be problem-solving technologists. We could avoid getting wrapped up in programmer elitism and tribal competition.

We might solve more problems that way!

We can still find joy in certain technologies. We can still ply our trade in solving meta-problems with those technologies while solving increasingly interesting problems with the technology.

We might have more fun and worry less about the hype treadmill!

We’d have more mental space to consider how we’re solving problems. We could communicate better with our teammates and customers.

We might consider whether the thing we’re building is right for the world we live in!

Greater Los Angeles - Geoff Manaugh. Remember when an iPhone had trouble with cellular reception if you put your fingers in the wrong place and a response that was overblown and taken out of context was “you’re holding it wrong”? Los Angeles is a city which you cannot hold wrong. It is so vast and varied that everyone belongs in some way and yet everyone can be alone in some way. It’s not about where you came from or what you did, but what you’re making of it right now. The idea of moving to LA is daunting, but at least it's a bit romantic.

Corporate Background Music Is Taking Over Every Part of Our Lives - Sophie Haigney. Apparently there’s a whole post-job/career industry of making and (royalty-free) licensing of music to play in the commercial spaces where we do our consumer society thing. Previously we would have called this Muzak, which was also the name of a company, which is also still a thing.

What Kurt Vonnegut’s “Slaughterhouse-Five” Tells Us Now - Salman Rushdie. My favorite phrase, “So it goes” is a bit more gallows than I remembered:

I had not remembered, until I reread “Slaughterhouse-Five,” that that famous phrase “So it goes” is used only and always as a comment on death. Sometimes a phrase from a novel or a play or a film can catch the imagination so powerfully—even when misquoted—that it lifts off from the page and acquires an independent life of its own. “Come up and see me sometime” and “Play it again, Sam” are misquotations of this type. Something of this sort has also happened to the phrase “So it goes.” The trouble is that when this kind of liftoff happens to a phrase its original context is lost. I suspect that many people who have not read Vonnegut are familiar with the phrase, but they, and also, I suspect, many people who have read Vonnegut, think of it as a kind of resigned commentary on life. Life rarely turns out in the way the living hope for, and “So it goes” has become one of the ways in which we verbally shrug our shoulders and accept what life gives us. But that is not its purpose in “Slaughterhouse-Five.” “So it goes” is not a way of accepting life but, rather, of facing death. It occurs in the text almost every single time someone dies, and only when death is evoked.

It may be impossible to stop wars, just as it’s impossible to stop glaciers, but it’s still worth finding the form and the language that reminds us what they are and calls them by their true names. That is what realism is.

Slaugherhouse Five is not my favorite Vonnegut novel (Cat’s Cradle is, lets hear it for Bokonism), but it’s certainly the most consequential and the one I get the most out of re-reading (or have ever re-read?). I had no idea Hitchhiker’s Guide to the Galaxy is so intertwined with it (which I also could stand to re-read).