When Leah Silber reached out about my speaking at EmberConf, I was reluctant. I’m not doing much front end work these days, and the last time I looked at Ember was long ago when Yehudah Katz and Tom Dale held a feedback session for a very early version of their work. I changed my mind after an asynchronous text conversation with Leah, and listening to Yehudah talk about their work.

Attention to detail

Making software feel effortless isn’t effortless. I was impressed by the EmberJS team focus on backwards compatibility and agility, as well as the impressive performance of glimmer components. They were doing the kind of important, detailed work that doesn’t easily fit into a sound bite.

I told Leah that it reminded me of the work we do at Bridge Foundry, where significant positive change is composed of so many small actions. Leah echoed back all my feelings in her concise reply: “Reality is boring and full of hard work”

As I prepared for this talk, I realized that I don’t actually believe that reality is boring. Reality is messy and difficult. I thought about the hardship of when my kid was a toddler, of crumbs and sticky i-dont-even-know-what-that-was, being so bone tired all the time and also the wildflower in the kitchen and that moment of sun shining through the window casting a shadow on the wall that was so beautiful and I might not have noticed if not for a three year old that noticed everything.

So when I listened to the 2016 talk where Yehudah said that “instability is a drag on innovation” (Stability without stagnation, slide 5), I realized that we need to talk more about the people who are slowly and steadily fixing the broken things in this world. I was reminded of my colleagues in the government, both the techies who served a limited term, and the folks who dedicate their lives to service.

Small fixes to big problems

In the closing keynote for EmberConf 2019, I spoke about the parallels between the work of building (and fixing) software systems and the people systems that seem to rule our lives.

This talk was very much in the context of the Ember community, in honor of their hard work making good software that works well. I hope my words will inspire new voices to tell their own stories about what works well, of their own moments of mundane heroism or those they witness.

Notes

Below are some notes that I prepared in advance, that aren’t exactly what I said, and some things that I cut from the talk, since I always have more stories I’d like to tell.

Intro

At EmberConf 2019, Yehudah Katz in the opening keynote talked about the decisions we make, about how they encode our values and communicate to the world what we truly believe. Later in the day, Melanie Sumner talked about the things we choose to put in our software that no one asks for because we’re professionals.

We write tests and structure our websites for accessibility because we want our software to work and we choose frameworks that make our work easier. We choose to use the tools that give us power to move fast and make great things.

We live in a world where hype eclipses reality. You know how it goes… that new shiny thing that was invented yesterday makes headlines. Often when we put in the effort to make software that works well that doesn’t sound so exciting.

Maybe you have experienced that time when some heroic team worked weekends and nights to deliver in time and save the company, maybe you were even on one of those teams, I know I was, and at the time, sometimes I didn’t notice another other team that delivered solid code on time with no fuss. These days I think a lot about what we consider to be heroic.

Heroes are born through the stories we tell. We have the opportunity to define what we consider to be legendary. We each can decide what we value, the stories of success that we choose to tell.

Reality is messy. Designing and building things that are easy to use and work well is hard. It seems like people don’t want to hear about all the boring details. I’ll tell you a secret. The details aren’t boring. It’s just sometimes we need to work inside a broken system, or one that isn’t finished yet…. Reality is awesome, but things are little broken right now, things we see on the news, on twitter, things I can’t find in the Ember docs…

I joke, but sometimes it’s hard to know what to do.

Sometimes I just feel like reality is broken. This isn’t what I signed up for. This isn’t how they told me it was going to be… but I’m all grown up now, and I’ve picked up some techniques I’d like to share, about how we can change the rules

Today I’m going to share a few stories, a few details that I consider epic. And with these tales, I will share a very basic story of software engineers doing the thing we know how to do. Solving problems, shaping reality into something usable and practical. Because the world needs our skills.

Additional Notes, things I didn’t say

Abstractions make something more easily consumable — what are the essential things, or in a different context, the essential things?

What is success? have I adopted the mannerisms of the patriarchy? “Step forward, step back”

Do your homework! “This entire black history month has been like a terrible sociology 101 class where no one did the reading.” — Clint Smith

Alternate Conclusion

You’ve heard a lot of people here on stage say things. I’d like each of you to think about the stage upon which you live your own life. Each one of us has the power to change the world. In fact, we have no other option. With every word and action, we make change.

The world is pretty strange right now. People are divided. People are frustrated. No matter what side you are on, living in the world today, I think we can all agree that reality is broken. However, small actions can build on each other. Our presence has ripple effects that we rarely consider.

Who has the power to create this reality we live in? As it turns out, we all cooperate in making it so.

In a recent article, Peter Franklin draws a parallel between capitalism and Tolkien’s Lord of the Rings mythology, likening Facebook, and social media in general, to the rings of middle earth — powerful rings gifted by Sauron, Lord of Mordor, to the leaders of middle earth, secretly influencing them, binding them to darkness, and increasing the power of the dark lord.

There’s a larger concept in this mythology about power, which does not necessarily imply evil. The artifacts and tools that we create have power and purpose. In our modern world, open data and open source software can be powerful forces that create positive impact. With open source software, freely distributed libraries and applications influence behavior, affecting properties of the systems that rule our lives. By making certain things easy for other software developers, one small piece of code can have outsize effects on unrelated commercial software. Open and easily accessible datasets can create positive economic impact that can be more evenly distributed than investments of capital.

If you don’t know the story, or if it has been a while, you can catch up on the lore, reading Tolkien Gateway’s background on the Ring Verse or listen to Tolkien reading the Ring Verse on YouTube.

Tolkien’s reflection on power

Tolkien’s ring mythology aptly illustrates that to exercise power, one must give it away (and risk losing it), which he explains in one of his letters. Dr. Rhona Beare’s correspondence led Tolkien to elaborate on the rings of power as a mythical representation of power or, in his words, potency:

The Ring of Sauron is only one of the various mythical treatments of the placing of one’s life, or power, in some external object, which is thus exposed to capture or destruction with disastrous results to oneself…

a mythical way of representing the truth that potency (or
perhaps rather potentiality) if it is to be exercised, and produce results, has to be externalised and so as it were passed, to a greater or less degree, out of one’s direct control. A man who wishes to exert
‘power’ must have subjects, who are not himself. But he then depends on them.
— 14 October 1958 [1]

Whether it is capital investment, the intellectual property of source code, knowledge that you have collected as data or a small golden ring, you can amplify your power by giving it away, but then you must rely on others. Like Frodo, we can all exercise free will in deciding what to do with the power we are given. Destroy the ring, keep the elven chain mail shirt, go adventuring or enjoy our home in the shire. We decide.


[1] originally published in a booklet, later in The Letters of J.R.R. Tolkien, pdf)

In learning a new programming language, it’s helpful to understand it’s philosophy. I seek to learn patterns that are idiomatic, and more importantly: why the syntax is the way it is. This allows me to write original code more quickly, gaining an intuition for simple things like when to look for a library and when to just write code.

I rarely find good resources for learning a new language that are targeted at experienced programmers. So I’ve developed a habit of looking for language koans. Inspired by Ruby Koans, these are unit tests which guide a programmer through basic language constructs by presenting a failing test and let you write simple code to learn the syntax of a language. These tests typically include a bit of text that helps newcomers reflect on what is special and interesting about this particular programming language.

In learning Go, I found cdarwin/go-koans, which helped me to reflect on the philosophy of golang, the Go programming language.

The koans caused me to meditate on the basics, leading me to read more and reflect. While about_basics.go is quick to solve technically, it sparked my curiosity on two points.

1. The uninitialized variable

I really wanted the comments in the go-koans to be a bit more like Zen koans (or Ruby koans), so I wrote these:

// listen to the darkness of an unset variable
// what is the code that is not written?
// consider the emptiness of a string

// create meaning from emptiness
// undefined structure isn't

“Make the zero value useful” —Go Proverbs

It reminds me of the Zen teacup parable. An empty cup has utility, even before it is filled.

2. The implications of a string

One of the most deceptively simple types in modern programming languages is the string. In Go, there is a built-in string type with short, unsatisfying descriptive text.

Strings, bytes, runes and characters in Go explains that strings are a read-only slice of bytes (at runtime). Go source code is UTF-8, so string literals always contain UTF-8 text (except for byte-level escapes.

Strings always cause me to reflect on how memory management works in a language. In my search for basic answers about how and when memory happens in string operations, I read about allocation efficiency in high-performance Go services which includes a nice explanation of heap vs stack memory allocation in Go.

Reflections

At this point, I don’t know what I need to know about this new programming language. I just like to know what the code I’m typing actually does. Learning syntax is boring, so I need to occupy my mind with something more interesting while I practice typing unfamiliar sequences of text. To write good code, I need to know so much more than the syntax, but I need to be careful not get get too attached to certain details. For example, future compiler versions change the patterns of how code is transformed into machine operations. However, if I attach just a little deeper meaning to these syntax constructs and get a feel for what my code ends up doing under-the-hood, I can more quickly understand the implications of the code I write.

When I emerge from these learning meditations and I can finally construct this new syntax without thinking and start to solve actual problems that matter to humans, then I will have created these little trails in my mind that lead to empty spaces, which have shape and meaning, like the Go zero value and the Zen teacup.