Adam Keys is The Real Adam

“’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.

Austin Kleon recommends skipping the news/social media/blinky lights in the morning. I’ve found this works great for me, and sometimes not! I’m a morning person, so I’ve got that going for me. If I’m already in a groove, have ideas about what to write or code on, and jump in first thing, this advice works out for me.

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?