CJ Eller

Classical Guitar by Training, Software by Accident

There's a great passage from Maria Popova's Figuring about Emily Dickinson's prolific output and relating it to the place where she wrote them — her bedroom. Popova sets the scene, standing in Dickinson's bedroom in her historic home in Amherst, Massachussetts:

I am struck by the contrast between the bellowing darkness of her poems and the fount of sunlight flooding in through the two fully windowed walls. I am struck, too, by the scale of it: Her mahogany sleigh bed is practically child-sized, her cherrywood writing desk almost a miniature at seventeen and a half inches square. I am reminded of recent findings in embodied cognition — the study of how external physical parameters influence our interior states — indicating that large open spaces and rooms with high ceilings enhance creativity, and I find myself wondering whether there might be an embodied-cognition analogue to Kierkegaard's assertion that “the more a person limits himself, the more resourceful he becomes.” Deliberate constraints, after all, are a mighty catalyst of creative breakthrough

[...]

Seventeen inches square. More than seventeen hundred poems

Amazing. It brings to mind something I hadn't heard of much before but now want to learn more about — embodied cognition. How does it relate to our own day-to-day analog/digital lives?

What's cool about Github is that it has built-in Continuous Integration & Deployment (CI/CD) with this feature called Github Actions. On an event like a commit to your Github repo, it'll run the CI/CD jobs that you write out on a...runner. These runners convert your job into a container that executes the code you've set up on there. Practical benefits galore — run scans on your code, deploy a project to Github pages, the possibilities are endless.

What I wanted to try was to see whether I could create a Github Action that would publish to my blog. This blog post is a that. I am using this repo to do it — a Python script that takes the content of a Markdown file and updates a Write.as post that gets published to my blog via a scheduled publishing program. When I make a commit to the Markdown file, the code in the Python script will execute on the runner, updating the post. You get the added granularity of version control for a piece of writing with the automated publishing via CI/CD. Plus you don't have to open a web browser to publish on the web this way — just edit a Markdown file, perform some git incantations, and you're off to the races!

This is merely a test though, a bit of a Rube Goldberg machine, but isn't that part of the fun? To tinker around because you can? Take hobbyist software kludging with a sense of pride. At least I try to (on a good day).

I've gone off-roading with git at work. On production. It's a pretzel of merge requests and commits that I have to untangle to get to something that resembles a reliable source of truth. Thankfully no production resources broke because of the changes — only my ego.

I thought I knew more about Git not to get (ha) into this pretzel. But here's the thing — I thought a rudimentary knowledge of git commands would get me by. It doesn't. The problem is my lack of knowledge of using version control within context —when there's more than one person working on more than one branch. That blindspot is now apparent.

Look, knowing how to say certain words doesn't mean you know how to hold a conversation. More than a series of commands, I am learning that git is actually the conversational space for people who run a codebase. It's great if you know how to check in a branch and push changes, but there's more going on behind the scenes. Do you create branches for each feature? How do merge requests get taken care of? These were things that flew over my head and landed me in the spot where I am on — untangling a pretzel because I didn't fully know what the standards for doing version control were.

But moments of learning can come from moments of failure. Blogging about this gives me perspective. Now I just need to act on that.

Thanks to Tom Critchlow for sharing this passage from Sara Azout's newsletter:

The more my career takes me in the direction of creative projects that require peace and quiet, alone time, and imagination, the more I realize that being productive has very little to do with high-stakes, high intensity conferences, back to back meetings, can't-catch-a-breath to-do lists, or endless projects I’ll half-ass due to exhaustion. What makes work good is time to read, think, slow down, and create a rich inner life. In other words, good work comes from slowing the fuck down and trusting that good ideas will come through if we give ourselves enough time and space to see them.

Cultivating richness of mind to create richness of work reminds me of a piece of advice I read from sculptor John Gibson, giving advice to Harriet Hosmer at the start of her Zenobia sculpture:

There are many obstacles in the path to fame, but to surmount them, to produce fine works, we must have tranquility of mind. Those who are envious cannot be happy, nor can the vicious. We must have internal peace, to give birth to beautiful ideas.

Tranquility of mind from slowing down and taking time. Hard to do with the insanity Azout describes as workin within a productivity paradigm, but we have to find ways of microdosing tranquility into our days. For me I've been trying to think of ways to build in tranquility breaks in the day. One strategy has been to have a couple books that sit beside me on my desk, ready to open if I need reprieve from staring at code for too long. That above Gibson passage actually came from such a book, Maria Popova's Figuring, on such a tranquility break.

Go figure.

But still I wonder about how to cultivate a sense of continuous partial wonder such that it is more likely that something in the everyday will catch you, just every so often. Perhaps that is one of the functions of keeping an observational diary, or of prayer.

Perhaps it could be a pill. Microdosing cathedrals.

This bit from a blog post by Matt Webb gets me thinking about how a blog acts as a way to cultivate a sense of continuous partial wonder.

Personally, I've found this heightened with a Monday through Friday publishing routine. That schedule makes me extend my field of view rather than retract. What does that mean? Before, I thought that my blog needed to be centered around software and “tools for thought.” That led to sitting on work, not publishing much if anything at all. Now it's anything but.

That change, however, has made me more aware of my every day. It could be what I read or what I experience at work or conversations I have or pieces I play on my guitar or code I cobble together. All of these can provoke the partial wonder Matt Webb is referring to. That partial wonder can then be distilled into a blog post.

Perhaps it could be a blog. Microdosing posts.

Here's a curious entry from Bryson's The Body: A Guide for Occupants that might glean a neurological basis:

Each neuron connects with thousands of other neurons, giving trillions and trillions of connections — as many connections “in a single cubic centimeter of brain tissue as there are starts in the Milky Way,” to quote neuroscientist David Eagleman. It is in all that complex synaptic entanglement that our intelligence lies, not in the number of neurons as was once thought.

While this connects back to our anatomical connection to the cosmic, mentioned in the previous post, I think it also relates to the widespread idea of connecting dots as being a hallmark of intelligence. Interesting to think of it as a neurological basis for our fascination with hyperlinks. Is it why we are so fascinated by the hyperlink in the first place? Our brains are built on connections and we seek more connections.

There's historic precedence for that too. I can think of is another book I'm reading that oddly compliments this passage — Maria Popova's Figuring. Therein Popova mentions how the origin of the word “scientist”, coined by William Whewell, was actually in reference to Mary Somerville and her ability to prodigiously connect fields of study into something difficult to define by one field alone:

The commonly used term up to that point — “man of science” — clearly couldn't apply to a woman, nor to what Whewell considered “the peculiar illumination” of the female mind: the ability to synthesize ideas and connect seemingly disparate disciplines into a clear lens on reality. Because he couldn't call her a physicist, a geologist, or a chemist — she had written with deep knowledge of all these disciplines and more — Whewell unified them all into “scientist.”

All I can think of is now is how the trillions of connections our neurons make in our brain strive to make connections in our world turn synthesis into a clear lens of reality.

Here's a mind boggling passage from the beginning of Bill Bryson's The Body: A Guide for Occupants:

Unpacked, you are positively enormous. Your lungs, smoothed out, would cover a tennis court, and the airways within them would nearly from coast to coast. The length of all your blood vessels would take you two and a half times around Earth. the most remarkable part of all is your DNA (or deoxyribonucleic acid). You have a meter of it packed into every cell, and so many cells that if you formed all the DNA in your body into a single strand, it would stretch ten billion miles, to beyond Pluto. Think of it: there is enough of you to leave the solar system. You are in the most literal sense cosmic.

There is enough of you to leave the solar system — that puts things into perspective!

There's a great video educational series called “Head in the Clouds” that's led by Kenneth G. Hartman in collaboration with the SANS Institute. In Episode 5, “Tips for Success with Command Line Interfaces Using BASH” (source), I learned about a command that I've taken to using immediately in my day to day: the history command. What particularly stunned me was how I could not only get a list of past commands but also run any of those commands with the !# format. In recent memory, I've never taken to using a command so quickly as I did with history. Why is that?

I wonder if part of it is the beauty of shorthand when faced with short-term memory. It's at the heart of why we use contacts in my phone instead of memorizing numbers, memorable domains instead of IP addresses. Remembering every command you run in the terminal is tough, but having a command that does with easy numerical shorthand? That eases the mnemonic burden.

That reminds me — a fork of a tool that I've turned to for work called ssha provides a similar service to humanity. When working with dozens of EC2 instances, it's hard to keep up with what keys associate with which instance, let alone the exact IP address of every instance. It becomes a quixotic quest of scrolling through the AWS console to find an IP address. The beauty of ssha is that it allows you to use shorthand to find you need to connect to — ssha takes your AWS credentials and runs some API calls to find the instance, know what key pair it uses, and then run the appropriate SSH command to connect you to the instance. No remembering the key, no remembering the IP address.

The mnemonic services that programs and commands like history and ssha provide is something I've never thought about much consciously. It's been a sort of an unconscious appreciation — “Oh great, I can use less keystrokes”, “Now I don't have to remember a complicated command.” But now that it is in the forefront of my mind, I can't stop thinking about it.

Something I've learned a lot more about in these past couple months is granularity within development/engineering. In a recent case, this on takes the context of wanting to create a specific IAM group in AWS so that a user has exactly what she needs for a particular task — the principle of least privilege really. She would be the only user in that group until others would be added. But what if nobody else would be added to that granular group?

The seemingly innocuous question stuck with me. What if that was the case and we kept creating IAM groups for each user who needed granular roles for every granular task? Chaos. Okay, a bit hyperbolic, but we'd be left with a hell of a time trying to manage the IAM groups that we're constantly creating. Instead, after taking my team's advice, I decided to put this user in a group we already had that still gave her the ability to complete her task, even if it meant allowing additional privileges that, mind you, actually had no bearing on our principle of least privilege.

Granularity is important, but there's a difference from granularity like sand castles and granularity like quicksand. You want granularity to be elegant like a sand castle. You don't want it to weigh you down like quicksand. I'm slowly learning that knowing the difference is a crucial skill that takes time to intuitively understand. For now I'll cautiously wade through the quicksand in order to reach creating those sand castles.

While visiting some friends, I found the majority of my time spent playing games with their three year-old daughter. It amazed me how she wanted me to repeat the same game over and over and over again. Each repetition brought about more joy to her than the previous. Where does that thrill in repetition come from? Is it something that adulthood quietly erodes from our youthful selves? Or does it exist within smaller pockets of our lives, quietly evading jaded outlooks?

I noticed such a pocket in my life recently where this rejuvenated joy in repetition existed — taking tasks that I normally do at my cloud engineer gig and doing them within my personal AWS account. These tasks, like adding additional IAM users & roles along with MFA, didn't feel like drudgery. Rather, it felt like I was taking skills I learned at work and bringing them into my personal life, to better work on projects I care about.

Repetition happened across contexts — a couple times in work and then off the clock. That context shift allowed the repetition to take on new meaning. I'm sure it could happen the other way around as well — repeating something from a personal project in a work project. Perhaps that context shift is but one of many places where that thrill in repetition comes from. I'm hungry to find more.