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.


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.

There’s a common pattern where some men seem to have a complete inability to understand women when they speak. As far back as the 1970s, this kind of interaction has been illustrated with humor:

an excellent suggestion, Miss Triggs. Perhaps one of the men here would like to make it

The term mansplaining was coined more recently, sparked by Rebecca Solnit’s 2008 essay Men Explain Things to Me. Solnit’s stories present a different perspective from the prevailing narrative that women lack confidence to speak up: perhaps the lack of confidence is not in ourselves but rather in our audience. One must be an authoritative expert on a subject with footnoted documentation before having the right to an opinion, and even then, we may be inaccurately criticized or simply ignored.

It was a few years ago when I realized that I had accepted the status quo. I was on a conference call with two male colleagues. I was caught up in the discussion and hadn’t noticed that I had initially put forth an idea that was then attributed to my other male colleague. Instead of tacitly accepting credit for my idea, he promptly said “I agree, that was a great idea that Sarah had.” A simple correction, said kindly with an edge of humor, honored my contribution while gently chiding our colleague. Most men have the capacity to listen to the words I say and follow the thread of the idea, and some realize that correct attribution is a simple respect that fosters effective collaboration.

A couple of weeks ago, Jen-Mei Wu, Judy Tuan and I were talking about code and sharing stories of our lives. With dark humor, I noted that for some men, it seems that my voice is unintelligible. I know they hear me, since they typically wait till I finish speaking before repeating themselves verbatim as if I had not spoken or asking a less knowledgeable man to explain in more detail. I joked that I needed a personal translator, a man who would attend meetings with me and repeat what I say for some of my colleagues who can’t seem to understand my words.

We wondered if this behavior might stem from the need to compensate for a cognitive disability where some men can hear female voices, yet struggle to discern meaning from sound. Without self-awareness of their own affliction, when they hear the garbled syllables, they assume the woman is not speaking clearly, and so they feel compelled to repeat their understanding of the words. Tech companies might identify men who are thus impaired and offer mansplaining-as-a-service as a benefit to accommodate this peculiar affliction.

I sought a word to describe this new insight about a potential root cause, perhaps a previously unknown form of aphasia where some men cannot cognitively process words when they are spoken by women. It seems important to separate the community service where a man will amplify a women’s ideas by repeating key points with attribution, as distinct from the bizarre echolalia commonly known as mansplaining which may be a further symptom of this affliction.

In reading further on this subject, I discovered some research indicating that there might be a physiological basis for this syndrome. Further study may be needed. Independent of the neurological processes involved, I suggest the word agynephasia to describe this phenomenon.

agynephasia greek roots: a- not, gune woman, phanai speak

I urge men to support your colleagues who may be unaware of their disability. Until the tech companies start routine testing for this affliction and providing trained assistants, you can help by learning about the expertise of your colleagues and dinner guests, regardless of their race or gender, correctly attributing ideas, and helping to redirect the discussion if needed.

In 2009, when Sarah Mei and I started teaching free coding workshops for women, we didn’t expect to fix the industry, just our little corner of it.

We’re programmers. We solve problems by focusing on something concrete that can be built with the tools at hand. We focused on increasing diversity in the SF Ruby meetup. By teaching workshops, engaging the local tech companies and all of the people who wanted to help, we moved the needle. Later we expanded to include outreach to other demographics who are underrepresented in tech (which turns out to be most people).

Last week I spoke at a Bridge Foundry event where we announced a new industry partner program. In preparing for this announcement, I spoke to Amanda Cooper (@MandaCoop) on our advisory board. She framed what we do as “you make the road by walking it.”

There was no clear path, but we had ideas that we thought could work. We did the work to implement our ideas. We took a data-driven approach to measuring impact. We open-sourced our process and materials. In doing the work, we created a path that others could follow. Or more accurately, inspired others to help create the path by walking it with us.

Over the years, I’ve watched students become senior software developers. I’ve seen how volunteering at the workshops has caused some ex-programmers to decide to become software engineers again. It’s not all about more diverse software developers — we want everyone to be able to learn these tech skills, if they want to. Coding skills are applicable across many disciplines and can be useful to simply understand the technology that people use every day.

Most students and volunteers are working software developers, and we’re seeing some particular problems in the tech industry where we think we can help.

Lack of good tech jobs

The tech industry has a diversity problem that goes well beyond the “pipeline” problem that can be address with skill training. There seem to be few workplaces where there is real opportunity to succeed based on individual skill and potential.

I believe that most companies genuinely want to create workplaces where people with the right skills and capabilities can deliver business impact. This should be very aligned with business goals. Unfortunately systemic bias gets in the way. There are patterns that need to and can be changed. There are bugs in the system that need to be fixed in order to attract and retain diverse talent.

I see some companies where the environment seems to be different. I hear about companies who want to do better. Help create the path by walking it with some folks who have a lot of experience solving these kinds of challenges: join the Bridge Foundry Industry Partner Program.


Traveler, there is no path.
The path is made by walking.

Traveller, the path is your tracks
And nothing more.
Traveller, there is no path
The path is made by walking.
By walking you make a path
And turning, you look back
At a way you will never tread again
Traveller, there is no road
Only wakes in the sea.

― Antonio Machado, Border of a Dream: Selected Poems