Adam Keys is Thinking

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.

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!

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?

Tyler Cowen: go down self-directed rabbit holes rather than reading the “definitive tomes” on broad-ish topics you’re curious about:

Let’s say you want to read some books on Venice, maybe because you are traveling there, or you are just curious about the Renaissance, or about the history of the visual arts.

…

I instead suggest a “rabbit holes” strategy, a term coined in this context by Devon Zuegel. Come up with a bunch of questions about Venice you want answered, and then simply do whatever you must to pursue them. 

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.