Blog

I don’t actually own a convertible, but that’s what this newsletter feels like sometimes. I want so badly to correspond to you but somehow I leave it juuuuuuust long enough to make it difficult to get started again.

Partly it’s the lack of time. I started with a new client a couple of weeks ago. It’s my first gig with a potentially long-term client in a few years, and that’s different. I am the sort of weirdo who gets excited about digging into hairy old Rails codebases. I feel like certain wheels that have been spinning too fast for too long are finally biting into good root-entangled earth.

Hey before I get too deep into ramblings, a quick item plug for a friend’s upcoming event: Eric Evans, author of Domain-Driven Design, is hosting a virtual DDD immersion training in December. This is a rare opportunity; up til now (pre-COVID) these classes were only available at in-person workshops.

In case you’re wondering, I’m not getting any compensation for plugging this class. Eric is a friend and his book is one of my all-time favorites on software design. I think this is a neat opportunity to learn the art of “supple design”. Seats are very limited, so grab one while you can.

I talked to a friend the other day about a company they were watching go through a re-branding makeover. My friend remarked on the new “statement of values” that emerged from this process: “These… are not the values I would have guessed were at top of mind for this organization.”

Maybe I’m cynical, but I think most mission statements and written values are exercises in self-deception. At best they are aspirational; at worst they are a form of gaslighting. “You definitely didn’t see the CEO subtly encouraging an unhealthy work/life balance, because that’s not what we do! It says so right here.”

It’s not that I think organizations do a bad job of putting their values into effect. It’s more a case of misunderstanding the natural direction of cause-and-effect. Complex systems don’t adhere to values; they exhibit them.

This is observable at the individual level. Goaded on by personal development literature, I have tried at various times to nail down my own personal values and mission. But what I’ve realized is, people aren’t what they claim to be; they are who they associate with.

I am J., who optimizes their life for novelty and delight. I am A., who feels the anguish in the world acutely, and constantly interrogates their own actions for injustice. I am C., who seeks ever more profound experience and wider consciousness.

The same goes for organizations. You can sink all the time in the world into committee meetings to hash out a mission statement, but you are ultimately who you are. Show me who a team attracts and retains, and I’ll tell you what they value.

Jess and I went to the St. Louis Zoo yesterday, a nice outdoor socially-distanced activity. I don’t recall ever watching hippos swim before, and it was by far my favorite part of the visit.

Hippos look for all the world as if somewhere back in their evolutionary history they wandered into a river, got comfortable, and just never quite got around to getting out again.

“Look, Hippo! We grew long necks to reach the highest leaves!” said the proto-giraffes.

“Nice effort!” said proto-hippo, from a mud-wallow.

“Don’t you want strong legs to run away from predators?” said proto-antelope.

“I’m tired just watching you. But you do you, man!” said proto-hippo, rolling a joint.

“Silly Hippo, you don’t belong in the water. You don’t even have fins!” said the proto-elephants.

“Yeah man, it’s cool” said proto-hippo, languidly. “I can walk on the bottom.”

The programming literature reads like fitspiration Instagram sometimes: Lean code! Clean code! Slim, lithe and limber code! What makes the world go ’round, though, is muddy code. Cozy code. Chonky code. Hippo code.

What’s good

At GitHub, we have normalized on a set of script names for all of our projects that individual contributors will be familiar with the second after they clone a project. We call them “Scripts to Rule Them All”.

— Jon Maddox

A piece that I’d missed from five years ago. A useful pattern for standardization.

For software to be truly maintainable, it needs to carry as much of the explanation of the why along with it, and where the code itself cannot communicate that, the only place were an explanation doesn’t rot is where it’s completely bound to the implementation at that moment in time. And that’s exactly what the commit message is.

— James Adam, “Two thoughts on maintainable software”

A good read on the importance of storytelling in commit messages.

One of the rules for developing DFD is that all flow must begin with and end at a processing step. This is quite logical because data can’t transform on its own.

— Visual Paradigm

Confession: I’d never really paid attention to Data-Flow Diagrams before. But I kind of want to draw more of them now. There are some useful constraints here, as well as a nicely explicit acknowledgment of the human elements of a system.

There are many hurdles in interfacing with an external system. For example, the infrastructure layer must provide the means to communicate with another system that might be on a different platform or use different protocols. The data types of the other system must be translated into those of your system. But often overlooked is the certainty that the other system does not use the same conceptual domain model.

— Eric Evans, Domain-Driven Design

(Emphasis mine) this is from the section in Domain-Driven Design on the anticorruption layer pattern. When I’d heard the name of that pattern I’d always assumed it had something to do with keeping out “bad” data. But it’s really about firewalling one mental model from another, and explicitly translating between the two. Or quarantining a system that lacks a consistent model at all. It’s about being intentional in preserving and cultivating your team’s shared ubiquitous language and understanding.

What’s new

• On a recent Greater than Code, Jess, Amy Newell, Damien Burke and I chatted with the inimitable Chelsea Troy about software investigation.
• I wrote up a technique I use to share SSH configurations from my Docker host into dev containers.
• There’s a new freebie up from the RubyTapas archives, covering advanced use of the fetch method.
• Speaking of RubyTapas, recent episodes have covered the Output Record Separator, Input Record Separator, and tools for re-running only the tests that failed.