CJ Eller

Classical Guitar by Training, Cloud Engineer by Accident

Recently I picked up a deck of cards. I'm reminded of how versatile it can be.

Just now I am using a Joker ​from the deck as a bookmark.

A memory resurfaces of a favorite donut shop. They use a deck of cards as a way to keep track of orders at a donut shop — you'd hear “3 of Clubs!” coming from the counter as a box of fresh donuts appeared.

And that's ignoring the swath of possibilities that come from card games. The number of games is endless. I learned one couple weeks ago called Donsol, resembling the random romps of rogue-likes — exhilaration & frustration rolled into one.

That's just one game. I have yet to learn Solitaire, let alone other ones obscure and popular alike to be played with friends or alone. The beautiful thing about a deck of cards is that I don't have to download these games or pay for a subscription to access them. I just need to learn the rules (which might be behind a pay all). Once the rules are internalized, you're set.

A deck of cards as an analog game console.

Through a long history, men have, I believe, explored the transactional possibilities of countless of the things in their environment and sometimes, Pygmalion-like, the things have come alive. Thus many of mankind's most prized technological discoveries, from agriculture to chemistry, may have had their origin [...] in the fortunate misapplication of social intelligence.

This bit is from a paper by Nicholas Humphrey called “The social function of intellect” (source) which I stole from the end of Steven Mithen's wonderful book The Prehistory of the Mind.

Fortunate misapplication of social intelligence — I love that phrase. Reminds me of some of my favorite writing on computers. Pieces like Zach Mandeville's The Map is the Territory make the computer come alive through imbuing those smart rocks on our desks with social autonomy. Here's a particularly lovely part of Zach's introduction to the command line that illustrates this:

To use the terminal is to engage in a dialogue with your computer. You will ask it to do something and it will do it. Most of the time it gives no outward response, just moves quickly and diligently through the task and waits silently for your next ask. If you ask a question of it, it will print its answer. If it doesn’t understand you or encountered an issue, it will print out its problem as best as it can articulate.

Engaging in a dialogue with the materials in our environment transforms those materials into something new. We make personal discoveries of materials more personal and brimming with life than we thought; materials that serve as anchors for our very selves.

Sometimes there's advice that you wish was there when you needed it. Pam Hobart's guest post on Paul Millerd's Boundless newsletter is full of such advice. Here's a passage that resonated with me:

I didn’t know at the time, but I was doing the discovery thing all along – saying that I had a plan while actually spending my time and energy trying things and then seeing what happened. But it’s not cost-free to say you have a plan while actually messing around. Deviating from “the plan” while you theoretically still hold one invites you to feel like a failure and to erode trust in yourself when things go off-script.

You’ll be ahead of me if you realize what you’re actually doing – the bottom-up thing, in large part. Celebrating, or even merely admitting, the lack of a specific plan focuses you on your real objective: learning what you can from each work experience, doubling down when it’s right, moving on in a timely manner when it’s not, and limiting the costliness of each iteration. After you’ve had a job or two, you may have some idea of what industry is (or is NOT) for you, or some idea of what kind of management style you need. These high-level considerations are helpful constraints.

I deviated from my top-down plan of going into classical guitar by goofing off while in grad school. There were so many other things that I focused on other than my studies — organizing music events at an art gallery, volunteering for an education technology startup, playing in experimental bands, being a barista, running a music podcast with a friend. Basically anything to avoid the responsibilities of getting a degree to get an associate professorship at a college.

Those tangential activities planted the seeds for where I am now. If I didn't organize those music events, I wouldn't of been friends with the gallery owner's husband who mentored me in Python and my early tech career. If I didn't volunteer for the education technology startup, I wouldn't of met my wife who influenced me to go down the tech career path in the first place. It turns out that these things are anything but tangential.

It reminds me of what David Epstein describes in Range:

The trouble with using no more than a single analogy, particularly one from a vert similar situation, is that it does not help battle the natural impulse to employ the “inside view,” a term coined by psychologists Daniel Kahneman and Amos Tversky. We take the inside view when we make judgements based narrowly on the details of a particular project that are right in front of us.

But there was still the guilt of turning away from the “inside view,” of going off-script that Pam describes. David Epstein mentions as much when describing Northwestern's Integrated Science Program that advocate for broader studies than a top-down focus:

The trouble with courses of study like Northwestern's Integrated Science Program, which impart a broad mixture of strategies, is that they may require abandoning a head start toward a major or career. That is a tough sell, even if it better serves learners in the long run.

Going off-script is a tough sell because it feels like shit. When I dropped out of my phD program, I felt like I let myself down, my family down, my friends down, my fellow graduate colleagues down, my teacher down. It wasn't after a couple years after that I owned up to it. I needed to go off-script in order to serve myself better in the log run.

Now that I'm in a different place with a new career trajectory, it's tempting to go for the top-down path all over again. Still, I want to hold on to the bottom up planning that Pam illustrates; to realize that going the bottom up route is how I got to where I am in the first place. Who knows where else one can go from the bottom up?

In one study of a savant pianist, the researcher, who had heard the man play hundreds of songs flawlessly, was dumbstruck when the savant could not re-create an atonal piece even after a practice session with it. “What I heard seemed so unlikely that I felt obliged to check that the keyboard had not somehow slipped into transposing mode,” the researcher recorded. “But he really had made a mistake, and the errors continued.” Patterns and familiar structures were critical to the savant's extraordinary recall ability.

This bit from David Epstein's Range hit a personal note. No, I'm not a savant, but it made me recall the most difficult music I had to memorize for performing on classical guitar — two atonal pieces. Their difficulty lies exactly in what the savant pianist in Epstein's telling encountered — they negated the patterns and familiar structures that were at the foundations of how I play guitar. Take those away and memorizing passages & chord progressions becomes trickier. It took longer than anything I ever learned before.

Right now, JavaScript feels like those atonal pieces in relation to the comfortable space of Python. I'm by no means an excellent Python programmer, but I'm much more familiar with the syntax. That helps me remember things like how conditionals work and such. When that's taken away, I feel like a fish out of water. Memorization? I have to look up how conditionals work every time I dive into JavaScript.

But that's the beauty of learning newer things, whether it's music or programming languages. They take you out of what professor Erik Dane calls “cognitive entrenchment.” As David Epstein explains,

[Erik Dane's] suggestions for avoiding it are about the polar opposite of the strict version of the ten-thousand-hours school of thought: vary challenges within a domain drastically, and, as a fellow researcher put it, insist on “having one foot outside your world.”

Guess it's time to pick up some more atonal music and JavaScript.

Lately I've been skimming through a posthumous collection of pieces from Umberto Eco called Chronicles of a Liquid Society. In one piece, “The cell phone and the queen in “Snow White,” he makes a fascinating connection between magic & technology.

What is it that has inclined people for centuries toward magical practices? Impatience. Magic promised the chance of short-circuiting from a cause to an effect, with no intermediate steps: utter a magic formula and transform iron into gold, summon angels and get them to send a message. Faith in magic didn't disappear with the advent of experimental science, since the dream of simultaneity between cause and effect has been transferred to technology. Technology today provides everything immediately; you press a button on your cell phone and talk to Sydney, whereas science moves cautiously and its prudence doesn't satisfy us because we want the universal remedy against cancer now, not tomorrow — which leads us to trust the doctor-guru who instantly promises the miraculous potion.

Eco contrasts this want of immediacy that magic & technology seek to satisfy with the slow steps of scientific practice. While no examples are given by Eco of people who embody this prudential mindset, I can continue Eco's thoughts by opening the page from a volume picking up dust beside me — Lewis Mumford's The Myth of the Machine (volume II) — that discusses similar topics like magic & technology seeking an immediacy that is unmediated by moral thought & action. What Mumford does, though, is give an example of a figure that he believes is the antithesis to the immediacy mindset — Leonardo DaVinci. Mumford explains:

Leonardo's practical failures, so far from being a fault, were rather the price of his achievement as a feeling, thinking, value-weighing, acting human being. In an age when the printing press was open to him, this indefatigable recorder and writer published nothing. He was assembling first in his own mind, with a fullness that no one since Imhotep, that master pyramid-builder, had perhaps ever achieved, the necessary ingredients for a culture that would do justice to every aspect of organic life. Again, this synthesis was nowhere consciously adumbrated, it found expression only in Leonardo's works and days: but that expression — though imperfect — pervaded his whole life.

Because I had to look it up, I thought you should know that “adumbrated” means “report or represent in outline.” Anyways, Mumford further outlines an intriguing what-if scenario that serves as a refreshing tonic to the cult of immediacy Eco expounded upon. I'll leave on this more optimistic tone:

Had Leonardo's example in fact been followed, naturalization, mechanization, organization, and humanization might have proceeded together. Thus one method could have influenced and sustained the other, maintaining continuity with the past, yet alertly absorbing useful or significant novelty, constantly reviewing and correcting past errors, and seeking a wider selection of possibilities; introducing new values, not to destroy but to enrich and fortify those already achieved by other ages and other cultures. Such a practical syncretism of technologies and ideologies would have been an open one, open indeed at both sides, to past and future — constantly absorbing and refining more of the past while projecting and remodeling in a richer design ever larger tracts of the future. Unlike the technocrats of a later day, Leonardo was full of admiration for his predecessors.

Today I'm thinking about the last bit of an oft-quoted line:

The cloud is someone else's computer.

The “computer” part can fall to the wayside. Each cloud provider presents (what they advertise as) unique services that try to sway you over to their side or goad you to keep spending money with them. I've found myself diving into the esoterica of each service from the AWS console far too many times to count. However, beneath the veneer, these services are still computers. They operate under fundamentals that have been in place for a long time.

I learned about this just recently. A web server on AWS wasn't responding as normal. Why could that be? The first thing I did was jump to the AWS console to see if it was anything on AWS' side. Nothing. After actually connecting to the instance via SSH and running a few commands, the problem became clear — nginx had stopped. After starting it back up, the web server could be accessed properly.

The above error had nothing to do with troubleshooting AWS but troubleshooting the services running on the Linux instance that happened to be hosted on AWS. It had more to do with computer fundamentals than the cloud provider.

That's why I appreciate that this self-taught cloud computing guide which emphasizes Linux & Networking fundamentals before digging into a cloud platform.

Taking time off of a problem I'm encountering with Github Actions? Easier said than done.

I find my usual troubleshooting method is to continually run my head into the wall until I solve a problem. This leaves me worse for wear — physically, mentally, emotionally.

Perhaps it's better to step back and observe the wall. Find where the cracks are in the first place, then pursue them. That always seems to do the trick. Yet here I go, running at walls anyway. Why is that? Why keep insisting on running into the wall? A sense of personal pride?

This post is a response to a user on the 100 Days of Cloud Discord server asking about details of my journey to where I am now in my career as a cloud engineer. It's a long story but I hope a helpful one.

First off, there's a reason why I have “Classical guitar by training, cloud engineer by accident” as my blog's byline. I got here with a lot of luck.

I've spent 7 years of my life studying to be a music teacher & performer. Being a classical guitarist was my identity for a good part of my adult life. On the cusp of starting a doctoral program, however, something felt off. Music sustained me spiritually, emotionally, and mentally. To make music sustain me financially felt forced. Being an adjunct professor at a college and performing on the side? I couldn't see myself doing that. Why continue? With that I dropped out of the doctoral program, working as a barista all the while.

At this point the accident happened. There was a family friend who needed an extra hand with their IT Consulting business — no experience required. I had been let go at a role I took after the barista gig. No experience? As a music person, that was me in a nutshell. With nothing to lose I decided to jump in.

This was my entry into the world of technology. I learned how to support Windows work stations, printers, servers on prem, Wordpress sites, VoIP phones. The role taught me troubleshooting, of going into a problem with little context and learning enough to solve it. Having the ability to sit with ambiguity long enough to work through a problem? An invaluable skill I carry with me to this day.

Later into my IT role I picked up Python as a programming language to learn on the side. I'm lucky to have had a mentor along the way of learning Python — my friend/landlord who was a backend/operations engineer at the time. He'd sit down with me to go over web frameworks like Django and Flask along with other Pythonic things.

Around the time I got into Python I started using Write.as, my blogging home. One of its many virtues is a clean, straightforward API. This got me thinking — why not create an API client library for Write.as in Python? That's what I did. I shared it to the Write.as forum and tried to be helpful there. The client library allowed me to help some fellow users in different ways — from creating a custom search app to showing a blog's currently used tags. I was able to meet the founder/CEO of Write.as, Matt Baer, a couple times over coffee as well. Soon enough I saw that Write.as was looking for a community manager. I was doing a lot of the things that they needed already and had experience with the product with passion to boot. Why not? I asked Matt about the role. After a couple of conversations I got the job as community manager.

The community manager role involved a lot of advocacy for the product. One part I focused on was getting developers involved in using our API. To do this at scale I created apps using Glitch that took advantage of the API wrapper I made before. We had fun ideas, from turning a Notion page into a blog post to creating a messaging platform that used anonymous Write.as posts as the backend. Glitch eventually reached out to us and we collaborated on a piece for their blog. Using Glitch is a magical experience. I wondered how they could allow people to create web apps so quickly. The answer? AWS. Little did I know this was my first experience with the cloud.

Along with promoting the API we were also trying to find ways for people to install the open-source version of Write.as called WriteFreely. It was here that I explored containerization with Docker along with Infrastructure as Code with Terraform & CloudFormation templates. This got me further into thinking about cloud technologies.

Though all the while I wasn't sure I wanted to transition into cloud. What I wanted to get into was cybersecurity, so I studied up on Linux fundamentals, networking, exploit tooling, and even went as far as getting the Security + certification.

This is when another accident happened. My cybersecurity mentor at the time suggested that I shouldn't focus on getting into cybersecurity through the front door but by finding another way in. Why not through cloud? Be a cloud engineer first and then you can transition into cybersecurity. So I took his advice and focused on a particular cloud, AWS, brushing up on the AWS CLI along with CloudFormation & other fundamentals. I passed the AWS Solutions Architect Associate exam, threw out a lot of applications, and hoped for the best. After many months I got an interview for my current role as an Associate Cloud Operations Engineer.

If you would have told me that I'd be a cloud engineer back when I studied guitar, I'd have thought you bonkers. I took a programming & music elective and hated the course. Why would I do that as a job? But life works out in mysterious ways, in fits & starts, in stumbling along the way. That's why it's hard to give advice. I feel lucky more than anything else. How can I give advice on how to be lucky?

But isn't that every blog post I write? A placeholder for something better in the future?

I've been getting into golf again, though “stumbling” is a more appropriate. Used to play with my dad and friends intermittently. Then intermittent began to mean years instead of months in between sessions. Now my clubs are out of storage and I hope to keep it that way.

The reason I bring this up is because I've discovered this recreational programming practice called Code golf. The Wikipedia definition is as follows:

Code golf is a type of recreational computer programming competition in which participants strive to achieve the shortest possible source code that implements a certain algorithm.

The main site (if that's even true for such a thing as “code golf”) includes numerous challenges with numerous languages and a leaderboard to egg you on. It's not my kind of golf, but I appreciate the spirit of Code golf — driving towards concision.

I had an instance today at work where we were trying to parse data out of an AWS CLI command. This was the initial go around:

aws rds describe-db-dngine-versions --engine postgres --engine-version 9.6.20 | grep -a 500 "ValidationUpgradeTarget" | grep "EngineVersion" | sed -e 's/"//g' | sed -e 's/EngineVersion: /PostgreSQL /g' | sed -e 's/,//g'

Then we played around with using another “club” instead of grep & sed — jq. With jq, the command turned to this:

aws rds describe-db-dngine-versions --engine postgres --engine-version 9.6.20 | jq -r ".DBEngineVersions[].ValidUpgradeTarget[].Description"

Accomplishing the same thing in fewer lines. Though it's more than that. While the second solution with jq is smaller, it's also more readable. You can easily infer the structure of the response.

Code golf judges your code by the number of characters & byte size. The real world judges your code by clarity.