Adam Keys is Thinking

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.

This dinger at the end of Mattt’s WWDC wrap-up is everything:

Taking care of yourself — sleeping enough, eating right, exercising regularly — will do more to improve your productivity than any language or framework out there. Your ability to communicate and collaborate with others will always be a better predictor of success than your choice of technology stack. Your relationships with others are the most significant factors of success and happiness in 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).

I didn’t expect Thea Flowers’ Building a stateless API proxy to end up explaining public-key cryptography and motivating JSON Web Tokens (JWT) from first principles. But it did! Great read.

1. Write about how computer programs are fun to solve and everyone can solve programming problems
2. Run into a computer program that involves multiple black boxes in multiple computer programs you can’t look at the source code for, find good docs, or ask a human about
3. Sometimes you’re the bug, sometimes you’re the windshield

Sam Saffron - Tests that sometimes fail. Fantastic advice on maintaining a test suite over time. A test suite is either an albatross or an asset, depending on the quality of effort your team invests. Via Ben Bailey.