Adam Keys is Thinking

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).

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.

Will we ever come to agree on writing code?

Ruby folks like short methods. One-liners even; maybe for their concision, maybe to show off their language and code golfing skill.

JavaScript folk like often like a bit more heft in their functions. No matter how good a function name is, logic is easier to understand if it's all in one place.

Despite the mechanical similarities of this sample size of two languages, programming communities have chosen very different styles. This has been happening for decades, since the beginning. It will probably always happen.

As sure as Keith Richards sounds different than George Harrison or Pete Townsend, developers will disagree on the structure and little details of code. Like music, like code.

Luckily, now we have pretty printers and code formatters like prettier, gofmt, rustfmt, or RuboCop. This is a welcome advance from even ten years ago, when some code reviews could bog down in "there's an extra whitespace here" or "this function seems too short, can we merge it with its callers?"

We don't have to agree, we just have to act like professionals when it comes to the little things.

A stranger walks into an elevator. I say “how about this weather?!” They smirk, or let out a small laugh. It’s easy to think, “I am funny guy!” But: that’s not a joke, it’s not funny. It’s just small talk and politeness in action. I am not, actually, the funny guy in this scenario.

When I was fourteen, I was really into standup comedy. I managed to find a club above a bowling alley that let me do a 2 minute set. The only constraint was that I couldn’t work blue. So I wrote two minutes of jokes, performed it a couple times, got a few laughs, and that was that. I figured out that I could get in front of people and tell some jokes, and I didn’t need to rely on slapstick cursing to do it.

Also, I was fourteen and surrounded by teenagers. Teenagers make a lot of jokes at each other’s expense, because they’re cruel, don’t know better, and aren’t practiced humorists. I had experienced my share of being the subject of those jokes and decided I didn’t want to be that kind of funny. Eventually, I came to the formulation that the best jokes aren’t at someone else’s expense.

As random things in one’s youth go, these two were pretty formative. I decided that if you can’t get a laugh without cursing or making a joke at someone’s expense by punching down, you weren’t actually funny.

Turns out these principles are pretty handy for the world we live in (and have always lived in, but some the future is not evenly distributed, etc.)

twitter.com/AndyRicht…

You can work blue, you can demean other people, you can say what’s really on your mind, and you can punch down. You may get laughs, but they’re because people are sympathetic to your anger or cruelty. Or, maybe you’ve been bombing so long they’re just relieved you said something almost decent and the laugh to diffuse the situation. But, that’s not funny.

When a joke misses, when a standup flops, it doesn’t mean we’ve become a humorless or prduce society. None of this means the end of humor or satire. It means we’re going to separate the really excellent humorists from those who are merely humor-adjacent.

As a long time Rands fan, I highly recommend you partake of the Rands Information Practices and Rands Slack Protocol. Allow me to add some of my favorite tactics.

Get your browser tab situation under control; I get itchy when I have more than several tabs open! (But if you’re the sort who never has less than a few dozen tabs open, I still like you.) Move your most important and favorite blogs and websites into a feedreader. I like Newsblur plus Reeder macOS/Reeder iOS. You can even put Twitters and email subscriptions into Newsblur, which is some next level distraction management.

Learn the keyboard shortcuts. All of them. Dazzle people with your ability to dance across the keyboard and make computers do things. Bonus tip: picking up a mechanical keyboard will make you sound extra amazing but slightly annoy the people who sit close to you.

Customize your system to remove distractions, allow you to focus, reduce drag, and move faster. If other people sit down at your computer and can’t operate it, that’s okay. But, don’t customize it too much. I want to get stuff done, not produce the ultimate hot rod computer for hot rodding computers.

Speaking of hot rodding, do not go too deep on productivity systems. I need a notebook-like app to think in and write stuff down. I need some kind of souped up todo list. Not much else. They are outboard brains, augmenting my ability to function as an adult and as someone thinking about and/or making things. Its tempting to read about everyone else’s Extremely Awesome Productivity Setup, but they’re doing different stuff and have different responsibilities; it’s entertainment, not education.

I cannot read the entire internet. Get really good at guessing whether something that comes across your desk is going to better your understanding of the world. Skip all the clickbait and tribal rage stuff. I look for stuff that provides insight into how we got here or what the future might look like.

That said, don’t accidentally filter your dear friends out in the process of managing the information onslaught. Put them in a special list or feed folder and look at it daily. Engage with them like its 2008 and the internet is still a promising thing that connects us to our friends.

Finally, I highly recommend you follow Rands’ best bit of advice, which is curiously tucked into the last footnote: replace screens by your bed (as many as possible, at least) with a book.

Over the years, I’ve heard a few times about something like Decision Tables (Hillel Wayne):

A decision table is a means of concisely representing branching and conditional computations. In the most basic form, you have some columns that represent the “inputs” as booleans and some columns that represent outputs and effects.

It was usually some variation of teams using something like a truth table to define the logic of their application without using a mess of conditionals. It also turned out that there was a compiler optimization where these tables could be laid out such that figuring out which behavior was appropriate to all the inputs was faster than conditionals would have been.

Wayne doesn’t mention anything like this. But, there is mention of using decision tables with an RSpec macro to verify code behavior with less boilerplate assertion logic. So that’s neat!

If I had to sum up my style of coding, I’d say probably a third of it is about reducing the time I spend reading or writing conditional code. That’s where most of the bugs and frustration are. Pushing them down into the compiler, runtime, or database is a fun exercise too.

At some point in elementary or junior high school, we were taught all our essays should answer one of five questions: who, what, where, why, or how. These were, at the time, “the five W’s” of writing.

Why is my favorite because it provides context. Asking why usually gets me to the bottom of the situation. It often encapsulates the who/what/where/how/when. It’s the most open ended, which is probably the best part. Asking why almost always makes the next most important question obvious.

I still like the other ones too. When often yields interesting histories or chronologies. Who can lead to a nice bit of biographical or character background. How is great when I care most about progress over deep context. Where can give me a little bit of backstory about why a certain location or geography is important.

Asking why wraps up all of those. Why are shipping containers a standard size? Who decided it should be that way. How did that drastically change global shipping? When did this occur and what changes can we observe from it?

One word, one question. So much to learn!