An encouraging thing happened to me last year. I was faced with a mystery involving how a bit of application code was interacting with ActiveRecord. It seemed like we were calling ActiveRecord properly, but the query wasn’t coming out quite right. In years past, this would have likely stymied me; productivity lost! But this time, I had the gumption to dive into the mystery and the tooling to help me navigate the murky waters of an object-relational mapper’s internals. Armed with a little bit of confidence, the ability to click on a method call to jump into its definition, and a little bit of experimenting in a Rails console, I figured out the problem. Success!

Now, when I’m faced with a weird situation, I tell myself “these are computers, I know this!”¹ and dive in.

This feeling is due to a few ways I leveled up my skills over the past few years. A little improvement in my tooling helped me acquire the “quickly jump to the definition of this function/method/etc.” skill. The big level up was the confidence that I could figure this mystery out, that there was likely an easy explanation lurking just behind the curtain, and that if I had the gumption to pursue it, I could figure all this out.

I feel like any developer of any background and experience can level up these skills!

I. Finding courage in cartoon foxes and stick figures

Over the past few years, I have been able to dive into more curious bugs, behaviors, and domain logic because I was encouraged by off-the-wall, esoteric forms of technical discourse. It probably started off years ago with the silly carton foxes of Why’s Poignant Guide to Ruby. Check it out if you haven’t!

Fifteen years ago (yikes!), when Ruby was gaining momentum and Rails was, to most people, a demo screencast, this approach to teaching a language was controversial. “Programming is serious!”, some would say. They claim there’s no room for flippant catchphrases like “chunky bacon,” sketchy cartoons, or programs not meant for “production-fortified commercial codebases”. Turns out, they are wrong — some folks find playful texts are a much easier way to learn deep topics like Haskell, Erlang, or even economics.

Fast forward to now, and folks like Julia Evans, the Base CS podcast, and illustrated.dev are once again chipping away at the notion that computers are all serious business that require a stiff lip and stereotypically masculine dedication to mathematical rigidity. I have learned more about datacenter networking and containerized deployment from Evans’ stick figures than any manual page, reference doc, or even the classic textbooks of W. Richard Stevens.

In other words: These are computers. I know this. And from there, I can figure out almost anything.

II. Knowing I’ve solved bigger mysteries than this

Allow me to get self-involved for a moment.

I recharge my batteries not with side hustles or open source projects² but by tinkering with side projects and learning new technologies. I’ve long had a growth mindset. I’ve benefitted a lot by turning that energy and curiosity into something I could apply when I get stuck on less esoteric work mysteries like legacy-to-me code and framework code.

I was fortunate to study computer science in university, and a little lucky that the program at my university was very average. My courses pushed me to figure out topics I would have otherwise skipped or found too intimidating like discrete math, computer architecture, or compiler construction. I came out with the ability to self-teach myself the topics I found interesting and immediately practical like Linux, programming languages, and how to actually build software.

In my twenties, when I was still full of energy and some margin time to pursue interesting ideas, I took more time to self-learn things which challenged or intrigued me. I learned how Ruby works, the basics of Haskell, and went deeper into databases and distributed systems than many developers outside of mega corporations have the necessity to do.

By my early thirties, I could look at a wide spectrum of technologies and feel confident (perhaps unearned) I could “figure it out” if necessary in a professional context. Out of order computer architectures, database index and query strategies, distributed consensus, managed runtime trade offs, or implementing binary addition from first principles all felt like a big challenge, but something I could participate in a discussion of, if not attempt to implement of on my own. A growth mindset in my twenties, learning tricky talks on my own, and a few of the courses I didn’t think I’d use in college paid off!

Having these topics “under my belt” makes tackling many (but not all) challenges feel achievable. I feel like this is down to the curiosity to learn a bunch of topics on my own and the optimism that I’ve learned plenty of tricky topics and can learn more. Of all the things I would encourage a younger-me to continue doing, challenging myself to figure out big, audacious mysteries is amongst the most important.

III. Believing there are no evil spirits

In code, there are no boogeymen or little demons conspiring to confuse me. The vast majority of the logic and behavior of any computer, program, or system thereof is explainable. While it’s tempting and enjoyable to ascribe personalities, stories, motivations, and drama to inanimate systems, they do not actually exist.

Most systems are linear, predictable, and some kind of deterministic. Things don’t happen magically, they only happen for reasons I don’t yet understand. There are no evil demons or spirits, only processes or circumstances which my mental model does not yet accommodate.

The corollary to this is that there are very few mysteries I can’t solve with sufficient time and determination. The solution might be weird, completely different from what I first thought, not what I’d hoped to learn, or involve inputs outside what I considered the domain of the problem. But the answer exists!

It’s tempting to say “this job just dies overnight and we restart it” as though that were nature and we have no agency over the process. But, I totally do have control over the process and can look into why it’s dying overnight! The only thing stopping me is me, and finding some time to learn. Given necessity and a time box³, I can figure it out or eliminate variables that aren’t the answer.

It’s also tempting to think “well I call this method and then the framework does some magic? and I get the value I want back, most of the time”. Like I said before: there is no magic, only things I don’t yet know about. When I find myself uttering this, I know it’s time to roll up some courage, gumption, and sleeves then dive into the framework to figure out how it makes the magic happen.

Some unpredictable or surprising behavior is very deep. Not every mystery is worth my time to resolve. That’s what time boxes are for! When this happens, my goal is to remove as many “suspicious spirit” stories as possible. The more logic and facts I bring to explaining this behavior, the better equipped I am to actually figuring it out next time I look into it.

These are computers and software; I know this.

IV. Enhancing my thinking with tools

I eschewed integrated development environments for a long time; they were slower and less capable than more focused text editors with smaller, Unix-style language integrations. But, computers are faster, designers of IDEs are more tasteful, and we now live in a world where language runtimes are just as influential as linters, test runners, and build tools. Perhaps now is the time for a smarter, integrated development environment.

It’s essential, to me, that whatever I’m using to write and edit the code is fast enough to keep up with my thinking. Beyond my own ability to type and make up names, the important criteria are all about enhancing my ability to think. TextMate first did this with vastly improved file navigation and language-specific snippets and expansions that helped me hold less syntax and boilerplate in my head. Vim, then Atom, helped me lay source files out side-by-side, like I would with sheets of paper, so I could think about related things in a limited-but-helpful spatial ordering.

Now, the tool that is enhancing my thinking is RubyMine. Its ability to “take me to the definition of the method/variable/class/etc.” under my cursor is now much easier to use than setting up equivalent tools that integration with Emacs, Vim, etc. So in the moment of perplexing code, I’m able to jump into the code at the center of the mystery and figure out what was going on.

In this case: these are computers, they know me. ;)

V. Mystery. Learn. Repeat.

Pulling it all together: I’m often faced with mysteries in the course of development work. It often takes courage and the confidence I’ve tackled deep topics before to go down the rabbit hole. Once I’m down the rabbit hole, it’s important to remind myself that most systems are linear and have logical inputs and outputs; no philosophical daemons mischievously manipulating results to confuse me. Automated tools for navigating source code are a huge boon throughout the process. All together, I stand a pretty good chance of tackling mysteries.

The common link between Ms. Evans and Mr. Stiff, makers of cartoon-y programming literature, is broad curiosity about the craft of programming and optimism that no topic is “off limits”, “too deep”, or “requires credentials” for us to learn. That’s a great mindset we can all benefit from!

Thanks to Marie Chatfield, Kelsey Huse, and Brian Ray for giving me tremendous feedback on this draft.

1. There’s a scene in the original Jurassic Park where a young heroine saves the day by doing some computer stuff. In a crucial moment with dinosaurs about to eat the whole cast, she sits down in front of the computer system which can save them, recognizes it, utters “This is Unix, I know this!”, and proceeds to save the day. ↩
2. Though I wish I could do that too! ↩
3. Time boxing is working on a task for a fixed time, e.g. 30 minutes. Either you finish it, decide not to keep going, or have a better idea of how to break it down so you can finish it. ↩

Best albums, singles of the years. Who is better, the Beatles or the Rolling Stones. Top 100 smooth jazz to fall asleep to. We love to put music into boxes and then rank the items in those boxes. So without further ado, ladies and gentlemen, I present to you: the string section of the orchestra, as rated by the string section.

There’s a bit of a tie for first place. The violins and cellos feel equally strongly that they are the best. The cellos and basses are equal mixes of ambivalence to these status games and envy that they are not in the violin or cello sections.

Here’s a sampling of the sentiment data our polling gathered, aggregated by section.

Violins: I’m better than everyone else or I’m better than that violinist over there.

Violas: I wish I played cello. Or, that I’d gone to that writing workshop.

Cellos: I am underrated, more composers should write good solo work for cello. I am going to use every minute of this melody to shine. I am overflowing with emotion, which you will hear through my extremely wide vibrato.

Basses: I wish I played cello. Or jazz. Or that this instrument was as loud as the brass section. Or that I was out at the loading dock, smoking.

I spent some time this weekend attempting to make front-end code with Tailwind CSS. Tailwind is a utility-first approach to CSS wherein styles are organized into classes by how they function, not what they style. Instead of avatar-image as a class name on a user’s photo, you would probably have m-4, roughly meaning “margin four”. It’s a bit cryptic at first!

Reading through all the documentation before getting started is a good idea! Once I read through it and tinkered with it (or any other utility-first CSS approach) for a bit, it was pretty easy to use. The point where it clicked for me was when I thought “hmm, this needs a little room on the top” and then “that means I want mt-2, perfect!” Having a good autocomplete for class names helps a lot too.

I started off trying to use Tailwind in a Code Sandbox, but it seems like the community hasn’t quite figured that one out yet. That said, once I cloned a not-quite-working sandbox locally and ran it, I was off to the races.

I’ll probably read more through the component gallery next. If I can get closer to being to thinking/sketching up a UI component and then coding it up in just HTML and utility CSS, that will be a huge step forward for my craft.

Onward and upward! 📈

I’m refreshing my understanding of mainstay Rails libraries lately¹. This week, it’s OmniAuth.

When you sign-in (authenticate) to website A (say dev.to) via website B (say GitHub), that’s delegated authentication and the protocol underneath it is OAuth2. OAuth2 is a bit tricky because there is a lot of back-and-forth between the service that the user signs into (GitHub) and the service that you’re signing into with that authentication (dev.to).

Once you’ve set it up set it up, OmniAuth encapsulates much of the back-and-forth with a Strategy class. A bunch of folks out on the internet have bravely contributed literally hundreds of strategies for various services that provide OAuth2 sign-in, e.g. omniauth-twitter or omniauth-github.

A nice thing about the Strategy implementation is that each phase of the OAuth2 callback scheme² is a method; you can overwrite each one to handle the particularities of the provider you’re integrating with. For example, the “callback phase” is the most common extension point since every app is likely to want to store user information and access tokens differently.

In the wild, OmniAuth is often used in combination with Devise for user models which in turn uses Warden for authentication.

Also nifty to note: the Rakefile for OmniAuth has developer tasks for benchmarking performance and measuring memory overhead. It’s pretty awesome that an essential gem like this has that level of detail in its maintenance.

The time required to do a simplistic OAuth verification is negligible; about as fast as a call to Redis:

% rake perf:ips
Warming up --------------------------------------
                 ips     1.210k i/100ms
Calculating -------------------------------------
                 ips     12.329k (± 5.1%) i/s -     61.710k in   5.019465s

I have no baseline to compare this with, but memory usage looks like this:

% rake perf:mem|head
Total allocated: 147317 bytes (831 objects)
Total retained:  60863 bytes (152 objects)

allocated memory by gem
-----------------------------------
     74492  lib
     52894  rubygems
     12659  omniauth/lib
      4200  rack-2.0.7
      2832  hashie-3.6.0

So that’s OmniAuth. If your Rails app is more than a few years old and integrates with other services, you’re probably already using it. Thanks, OmniAuth community!

Gorillaz, Demon Days – this one holds up, still a solid album.

News to me, Moby has been making extended ambient tracks in some manner of partnership with the Calm app. They make good “I need to focus and get stuff done” music, but aren’t particularly high energy, if that’s your thing. Says Moby, “my suggestion is to not approach this as music, but to approach it as a sleep aid or tool“. Okay!

I would like to some day learn enough piano to play and sing the songs of the original Van Halen line-up, e.g. “Panama”, “Hot for Teacher”, “Beautiful Girls”, and “Unchained”. My theory here is, the original Van Halen is very Vaudeville, except louder and more late-seventies. Corollary: played literally and with a little bit of a vaudevillian spin, they’d work perfectly. Case in point: “Ice Cream Man”.

Somehow, I’ve never mentioned Soulection Radio. It’s equal parts new R&B/hip-hop, classic soul, and a lot of sample culture. It’s one of the best things going on Apple Music, Spotify, and Soundcloud.

They’re on our phones, in our voicemails. Computers or sometimes even humans calling in massive volumes, funneling people into bad purchases. Questionable insurance at best, outright fraud at worst. Sometimes, depending on the state you live in, politics!

There’s no reason to pick up on an unknown number in 2019, or even 2009. For many of us, Dunbar’s number for phone calls is in the low single digits. Outside those few numbers, why answer an even remotely questionable number, ever?

If you squint right, robocalls appear they were  designed for the technological landscape of 1995, of _Friends_ and cordless, landline phones. Robocalls,  could have made sense in 1995. You get a call, it’s Friday, there are no repeats of your favorite show on, you’re a bit bored. Sure, maybe you’ll pick up. Or in 1992, when receiving a phone call was not only a big, exciting deal!, but also a social imperative. You can’t just let the answering machine pick up? It could be…someone. Probably a human!

Sadly, the technological landscape I just described is exactly folks who aren’t “technology natives”. I suspect that’s largely who Robocalls prey on: the bored and lonely, those who grew up before the pace of technological evolution surged and haven’t developed a layered defense to those who would prey on them.

Space isn’t a dead-end, it’s just taking us longer to figure out than our earliest trajectory. The New Yorker has a great look at The Race to Develop the Moon for industrial purposes:

Lunar construction projects now look feasible. “Down the hall, we have a telerobotics lab,” Burns said. “You could print components of habitats, of telescopes. You use the lunar regolith”—the dust of the moon—“as your printing material. You could print the wrench you need to fix something.” Fifteen years ago, the moon was believed to be a dry rock; now we know that there’s water there. Both private industry and national agencies regard the mining of water and precious materials as something that’s not too far off.

Only twelve people have walked on the moon, all of them between the summer of 1969 and Christmas, 1972. All the moonwalkers were men, all were American, all but one were Boy Scouts, and almost all listened to country-and-Western music on their way to the moon; they earned eight dollars a day, minus a fee for a bed on the spacecraft.

Buzz Aldrin had hoped, and briefly expected, that it would be he, and not Neil Armstrong, who would take the first human step on the moon. The astronaut Michael Collins, who manned the control module that orbited the moon while Armstrong and Aldrin walked below, has said of Aldrin that he “resents not being first on the moon more than he appreciates being second.” On the moon, Armstrong took photos of Aldrin posing, but Aldrin took none of Armstrong doing the same. One of the few photos that shows Neil Armstrong on the moon was taken by Armstrong himself—of his reflection in Aldrin’s helmet, as Aldrin salutes the flag. We are petty and misbehave on Earth; we will be petty and misbehave in space.

​Futurism isn’t dead, it’s just not all around us like Tomorrowland promised.

Into the Great Wide Open strikes me as a singular album. Perhaps it’s not even the best Tom Petty album, but it stands out from the rest in some kind of way.

Maybe it’s nostalgia? It’s the first Petty album I bought.

Maybe it’s humble? None of the songs are flashy, sitting right on the fence between songwriting and rock ‘n roll.

Maybe it’s the lyrics? I’ve listened to this album a lot, so I’ve actually heard the lyrics and they’re the right balance between clever and storytelling, for me.

Maybe it’s Jeff Lynne? Love that guy’s production work. Great touch.

It’s not too long, it’s not too short. All the moving parts do their job without getting showy. Perhaps, it’s just more than the sum of its parts.

At some point in what feels like the very distant past, I bought The Shape of Design by Frank Chimero. For six years, apparently, I’ve flipped past it on the way to reading other things. For some of that time, I was convinced I’d already read it. I was wrong, I just started reading it, and I’m super glad I did.

It opens with this bit of foreword, which struck me right in the “these are my people” feels:

Frank Chimero and I came together over a shared commitment to jazz. But not only exchanges of music. We emulated the form. He would write a blog post. I would respond. I would improvise one of his hunches. He would iterate one of my posts. A call-and-response approach to a developing friendship.

From there, it’s continued to impress. The illustrations before each chapter are delightful, the chapters are short and punchy, and the ideas are as useful to doing computer programs as they are to doing design.

The first idea in the book has taken up residence in my brain and I don’t want to let it go. It is, simple enough, that we should ask “how and why?” are we building this thing.

The “how” is often easy enough and the proverbial cart before the horse. We’re building a design system, we’re using Rails or React or whatever’s hot right now, or we’re doing XP with a little bit of Kanban and a dab of Lean methodology. The thing is, in the end, few of us will say “Oh, they built this with a design system, React, and lean methodology. Phew! I wasn’t going to use it otherwise.”

The answer to “why” is more likely to generate a satisfying response. We build things to learn, because they don’t exist and we want it to exist, because what exists doesn’t satisfy us, because people need it, because it brings joy to those who would use it, etc. Answering why motivates our craft.

Working backwards from “why” something should exist to “how” it should come to exist makes the difference between boring blandness and purposeful clarity.