the evolving ultrasaurus Sarah Allen's reflections on internet software and other topics Sat, 20 May 2017 18:38:28 +0000 en-US hourly 1 serverless patterns at google i/o 2017 Sat, 20 May 2017 17:01:27 +0000 Continue reading ]]> At Google I/O last week, we presented how to build robust mobile applications for the distributed cloud about building mobile apps in this new world of “serverless development.” When people hear “serverless” sometimes they think we can write code on the server that is just like client-side code, but that’s not really the point.

We have many of the same concerns in developing the code that we always have when we write client-server sofware — we just don’t need to manage servers directly, which drastically reduces operational challenges. In this talk we dive into some specific software development patterns that help us write robust code that scales well.


  • Sarah Allen (me!) I lead the engineering team that works at the intersection of Firebase and Google Cloud on the server side.
  • Judy Tuan introduced me to Firebase over 5 years ago, when she led our team at AngelHack SF (on May 3, 2012) to build an iPhone app that would paint 3D shapes by waving your phone around using the accelerometer. That event happened to be Firebase’s first public launch, and she met Andrew Lee who convinced her to use Firebase in our app. She’s an independent software developer, and also working with Tech Workers Coalition.
  • Jen-Mei Wu is a software architect at Indiegogo, and also volunteers at Liberating Ourselves Locally, a people-of-color-led, gender-diverse, queer and trans inclusive hacker/maker space in East Oakland.

Jen-Mei kicked off the talk by introducing a use case for serverless development based on her work at the maker space, which often works to help non-profits. They are limited in their ability to deploy custom software because they work with small organizations who are staffed by non-technical folk. It doesn’t make sense to set them up with a need to devote resources to updating to the underlying software and operating systems needed to run a web application. With Firebase, the server software is automatically kept up to date with all the needed security patches for all of the required dependencies, it scales up when needed, and scales down to zero cost when not in active use.

The primary use case that motivated the talk from my perspective is for businesses that need to get started quickly, then scale up as usage grows. I found it inspiring to hear about how Firebase supports very small organizations with the same products and infrastructure that auto-scale to a global, distributed network supporting businesses with billions of users.

The concept for this talk was for some real-world developers (Judy and Jen-Mei) to envision an application that would illustrate common patterns in mobile application development, then I recruited a few Firebase engineers to join their open source team and we built the app together.

Severless Patterns

We identified some key needs that are common to mobile applications:

  • People use the app
  • The app stores data
  • The app show the data to people
  • There is some core business logic (“secret sauce”)
  • People interact with each other in some way

The talk details some of the core development patterns:

  • Server-side “special sauce”
  • Authentication & access control
  • Databinding to simplify UI development

The App: Hubbub

Ever go to a conference and feel like you haven’t connected to the people you would have liked to meet? This app seeks to solve that! Using your public GitHub data, we might be able to connect you with other people who share your technical interests. Maybe not, but at least you’ll have lunch with somebody.

You authenticate with GitHub, then the app creates a profile for you by pulling a lot of data from the GitHub API. Your profile might include languages you code in, a list of connections based on your pull request history or the other committers on projects that you have contributed to. Then there’s a list of events, which have a time and place, which people can sign up for. Before the event, people will be placed in groups with a topic they might be interested in. They show up at the appointed time and place, and then to find their assigned group, they open a beacon screen in the app which shows an image that is unique to their group (a pattern of one or more hubbubs with their topic name) and they find each other by holding up their phones.

We built most of the app, enough to really work through the key development patterns, but didn’t have time to hook up the profile generation data collection and implement a good matching algorithm. We ended up using a simple random grouping and were able to test the app at Google I/O for lunch on Friday. Some people showed up and it worked!

You can see the code at:

Many thanks to all the people who joined our open source team to develop the app:

and who helped with the presentation:

  • Virginia Poltrack, graphics
  • Yael Kazaz, public speaking, story-telling coach
  • Puf and Megan, rehearsal feedback
  • Todd Kerpelman our Google I/O mentor
  • Laura Nozay and all of the wonderful Google I/O staff who made the event possible
]]> 0
the making of a fireplace Tue, 11 Apr 2017 03:59:20 +0000 Continue reading ]]> I built a fake fireplace in celebration of our team shipping Cloud Functions for Firebase. The codename was “hearth” — the product was almost ready for public beta by the time I joined the team, yet I know it was an epic journey to create a long-awaited feature and I felt the milestone deserved dramatic punctuation.

Red brick surrounds a monitor with video of log fire, wooden top has rows of whiskey bottles and a card

If you would like to build your very own fake fireplace, here’s how…

Initial Research

I reached out to our helpful facilities staff to make sure that I understood the constraints of the space. (I didn’t want to buy or create something that would be immediately taken down!) James Miller from facilities investigated some options:

“Since a hearth is technically the flat stone floor or the part outside of the fireplace, putting up just a fireplace and mantel leaves out the most important part, but including it presents a tripping hazard.” He suggested a quick and easy solution would be to temporarily change the display play a 8hr yule log video or on extra computer monitor with some fake foam bricks. He noted that some prop fireplaces which look pretty good in the photos, but are just cardboard. There are more expensive electronic fireplaces, but we can’t have anything that includes heating features similar to a space heater, and he reported “most that I’ve seen online are also missing the most important part… the actual hearth.”

Initially I felt that a literal interpretation of the “hearth” code name was not a critical element. We explored buying a real fake fireplace, but the ones we found were very small and we felt they were very expensive relative to the potential impact. However, his thoughts on the meaning of “hearth” later led to some important design elements. I love being involved in a collaborative creative process!

James suggested that something in a stage prop style would have dramatic effect, perhaps using styrofoam so that it would be light and easy to move, if we needed to shift it in the future around team moves. In brainstorming location, he helped me remember to pick out a spot with an electrical outlet.

Measure Twice, Cut Once

an aisle with people at desks on either side, at the end is a small bookshelf with bottles of alcohol and above that a large monitor on the wallI surreptitiously took a photo of the area, and arrived early one morning with a tape measure to determine its maximum dimension.I then measured the computer monitor I planned to use to determine the minimum internal dimension.

There was actually a third, very important measurement: the internal size of my car, which later became a critical optimization. I designed the fireplace in three pieces, so it could fit into the car, which also made it much lighter and easier to transport. Styrofoam is rather fragile, and the smaller pieces fit easily through doors.

Tools & Supplies

Tools: tape measure, hammer, screw driver, propane torch, safety googles, mask, electric drill, electric sander, garden shears, mat knife, level, steel square

Supplies: small nails, wood, styrofoam panels, gorilla glue, sandpaper, acrylic paint (red, yellow, white, black), gloss latex paint (off-white), sharpie, cardboard

I had never worked with styrofoam before and read that it could be carved with a sharp knife, acetone or a hot knife. If it were a small project, a regular soldering iron would likely have been fine, but I wanted something that would be fast and really liked that the propane torch I found had two different tips as well as an open flame option. The small hand-held propane filled torch is also easier to work with than my electric soldering iron which requires an extension cord.

Construction Details

I tested carving and painting the styrofoam very early, including figuring out how long the paint took to dry. I found that painting the white cracks before painting the red bricks made it come out a bit better. It was also good to test carving to create an effect that looks like mortar.

See key steps in photos

  1. Wooden frame: I uses 1″ thick boards for the frame. Discount Builders in San Francisco has a friendly staff and cut long 12′ or 8′ boards into the lengths I needed. The hearth is a separate component, which is like a hollow box with one side missing, where the missing side is actually attached to the larger frame, so the top can rest on it for stability and is not actually physically attached. I used a level and steel square for an even frame and wood screws.
  2. Top: I used a single 1″ thick board and drilled small holes for pegs to attach the top to the frame in a way that could be easily removed, yet fit snugly. I used garden shears to cut a long wooden dowel into 1″ lengths to create the pegs. I used an electric sander for rounded edges on three sides, and finished with fine sandpaper. I then coated with a few coats of gloss paint (which would have been easier if I had remembered primer!).
  3. Styrofoam: for the large panels I found that using small nails to hold the styrofoam in place made it easier to keep everything steady while gluing it all together. I attached all of the styrofoam panels before carving bricks with the torch. Large cuts were most effective with a mat knife.
  4. Carving the bricks: I found a few inspirational Fireplace images via Google Image Search and drew bricks with a Sharpie, then traced the lines with the torch using the soldering gun tip. Then I went back and made the brick edges a bit irregular and created a few cracks in random bricks. I also used an open flame in areas to create more texture.
  5. Painting the bricks: I mixed acrylic paint with a little dish soap and water, which makes it easier to coat the styrofoam. I noticed that most fireplaces have irregular brick colors, so I varied the colors a bit with yellow and brown highlights, as well as black “sooty” areas.
  6. The inside is painted black with a piece of cardboard as backing.

Additional Resources

I studied sculpture in college, so I had practical experience with wood construction, and learned a bit more from the amazing people who publish about their experience on the web. Here are some links to resources that I found particularly helpful.



]]> 0
the vision thing Mon, 20 Feb 2017 04:12:35 +0000 Continue reading ]]> Someone recently observed that I was motivated by a big vision and that some engineers are not, and that’s ok. In my experience, it’s not okay. I wish it was. It’s fun to sink into the code and get into the zone and not worry about the complicated real world. However, it’s not fun to work hard and create something over months or years and have it fail in the marketplace or, worse, never ship at all. I’m not talking about research projects where the primary outcome is learning something or publishing a paper. I’m talking about the kind of software I work on, which is intended to be used by other humans, whether they be developers or regular folks.

There are a few common problems I’ve seen happen when a team writes software without a clear and focused vision.

  1. Lots of bugs are discovered late. When engineers are focused on their own specific component or library, it often happens that another engineer will use that library in a slightly different way than was intended. This is especially true for internal libraries where there is little need for documentation since we can see each other’s source code; however, we don’t typically review all off the code our systems depend on. So each part of the code does what it is supposed to do on its own, but when we put them all together, slight miscommunications add up to things not working quite right, typically discovered late in the development cycle.
  2. The system doesn’t work well. When you are building software as a team, engineers work on different parts of the software. If one engineer is making a gaming engine, and another engineer is making presentation software, it rarely comes together to work well at the end. The gaming engine needs a high framerate and quick response to user input. The marketing presentation software need to display text at large font sizes. It’s likely one or the other will suffer, or more typically the software won’t actually work well for either use case.
  3. You delivered the features your manager asked for, but the product isn’t successful. Customers aren’t happy… or they aren’t buying in the first place. New users and people already using your product have different needs and slightly different use cases. It can be a delicate balance to walk. When developing a “feature” it can be easy to miss a step in between what you are working on and something that seems unrelated from the inside, but which people need to use together or in sequence. I call these features in between the features, which are very hard for engineers to see if they don’t have a complete picture of how people will use the product.
  4. Customers are happy and the product is cancelled. Companies have internal metrics by which they evaluate success. Someone on the business side has determined if we expect immediate revenue, or if this is going to be a long bet and expect slow revenue growth while we focus on strategic customer adoption, or if we need a large base of free users before we expect significant revenue. Sometimes it’s a product that supports larger business goals and drives adoption of a different product. If the engineers don’t know what those goals are, they may not get the important details right to make those goals happen.

So, you need to tell engineers the internal metrics, but that’s not enough. No one writes code that by itself increases 28-day active users. Somewhere in the product plans (or the minds of the executives) is a hypothesis that there are some new or improved use cases that will cause people to use the app more (or to sign up in the first place). A lot of teams do document use cases or user journeys and share them with the engineers, which is important, but not sufficient.

Engineers need to know the use cases that everyone believes will be required to make the product successful; however, usually software engineers have to make all sorts of decisions outside of the required use cases for the next release. The software will work better if all of these little decisions are aligned somehow, and the easiest way to do this (in fact the only way that I’ve found to do this), is for the developers to have a shared vision of what this software wants to be — not just in its next release, but in the future. This vision can be somewhat arbitrary for it to work (which means it is totally fine if it changes), the key point is that it needs to be shared, and when it changes, the change and reasons for the change need to be communicated effectively. A shared vision not only aligns all of the little decisions that developers make independently, but also makes all of the design discussions more efficient. We can focus on how we are building a thing, because we already know what we are building and why.

To create a shared vision, we need to answer: who is the target customer? what are the key problems we are solving? what will our customers be able to do with the initial release and what do we hope they will be able to do in the future? Who are the customers who might not be satisfied with our product and that would be ok?

Good engineers will build something that works for a wider audience. Often the software will enable those people to do many more things than the minimum requirements, but focus is key to creating robust software that works well.

I’ve been talking about engineers, since that’s my focus these days and because there remains a persistent myth that engineers don’t need to be distracted with all this business stuff. All of these questions and answers are even more important for designers, technical writers, support, developer relations, support, sales, business development and everyone involved in the making of and communication about the product.

I’m not motivated by a big vision. I’m motivated by impact — not potential impact, real impact. I need to believe that my day to day work is going to add up to something that solves real problems for real people in the real world. I’ve discovered that to reduce risk in software projects, every member of my team must be able to see a through-line from their day-to-day work to shipping software that causes a large number of humans to be empowered to do something new or better, enabling them to solve real-world problems. To do that, I need to convey a vision that lets the individual team members innovate, coming up with creative solutions in their domain that add up to a system that actually works.

]]> 5
remaining awake through a revolution Tue, 17 Jan 2017 01:23:12 +0000 Continue reading ]]> This day we honor Martin Luther King, Jr. who eloquently described the change that was, and is still, happening in our society. He often referred to the dramatic changes in technology, alongside other changes which require actions from each of us to make happen.

This morning I listened to “Remaining Awake Through a Great Revolution,” a speech delivered by Dr. Martin Luther King, Jr. on March 31 1968. He spoke of a triple revolution with advances in technology, weapons, and human rights. He talks about how we as individuals must accept responsibility and create change, not just in our own behavior, but changing the institutions we are part of.

one of the great liabilities of life is that all too many people find themselves living amid a great period of social change, and yet they fail to develop the new attitudes, the new mental responses, that the new situation demands.

His introduction refers to the story of Rip Van Winkle. We all remember how he slept for 20 years, but I had forgotten exactly what he slept through. He went to sleep under the reign of King George and woke up when George Washington was President — he slept through the American revolution. This story is a apt metaphor for today’s political and social climate. If we don’t talk together about what is happening in our world and work together to make change, we are sleeping. In King’s words: “anyone who feels that he can live alone is sleeping through a revolution.”

Here are some highlights of this speech that are still true today, and inspire me to work towards kind of world where I want to live, that I believe is still possible:

Through our scientific and technological genius, we have made of this world a neighborhood and yet we have not had the ethical commitment to make of it a brotherhood. But somehow, and in some way, we have got to do this. We must all learn to live together as brothers or we will all perish together as fools. We are tied together in the single garment of destiny, caught in an inescapable network of mutuality. And whatever affects one directly affects all indirectly. For some strange reason I can never be what I ought to be until you are what you ought to be. And you can never be what you ought to be until I am what I ought to be. This is the way God’s universe is made; this is the way it is structured…

We need all of the talents and potential of the people in the world to solve the challenges that face us. Let’s look out for the individuals in our daily lives who aren’t getting the opportunities to rise to their potential.

It is an unhappy truth that racism is a way of life for the vast majority of white Americans, spoken and unspoken, acknowledged and denied, subtle and sometimes not so subtle—the disease of racism permeates and poisons a whole body politic. And I can see nothing more urgent than for America to work passionately and unrelentingly—to get rid of the disease of racism.

The opportunity to speak out against racism rises up without warning. I have found myself often unprepared to speak in the moment, and so have worked on practices which cause me to be mindful and take small, quiet actions in my daily life. I volunteer for Bridge Foundry, learning how to work with diverse teams, teaching what I’ve learned to make our tech culture more inclusive and welcoming to people who have traditionally been excluded. I’ve learned about history, so I can tell lesser-known stories, and try to pay attention to present-day voices that deserve to be amplified. Often when I’m about to share an article, I take a little extra time to look up the person who wrote it. I think about how this person’s experience and culture intersect with mine. I do a little more digging and read a few more articles and sometimes choose to share a different one. I enjoy finding new voices. I seek to be intentional about the people who influence me.

we have difficult days ahead in the struggle for justice and peace, but I will not yield to a politic of despair. I’m going to maintain hope… This time we will really confront a Goliath. God grant that we will be that David of truth set out against the Goliath of injustice, the Goliath of neglect, the Goliath of refusing to deal with the problems, and go on with the determination to make America the truly great America that it is called to be.

The world is changing, always. We need to work together, and I’m not just referring to a mass movement to curb injustice and stand up for what’s right (though I hope to be part of that). I believe we need to look for ways to work together as individuals, to speak up in the moment, to address the small injustices that we witness (and participate in) every day.

I don’t intend to appropriate the words of Dr. Martin Luther King. This speech was as much about peace, as it was about racial injustice. It is my hope that with this small blog post I might highlight how his teachings are still very applicable today. I hope someone will be inspired to read or listen to the whole original speech, and that everyone will be inspired to and feel obliged to create positive change in the world.

With this faith we will be able to hew out of the mountain of despair the stone of hope. With this faith we will be able to transform the jangling discords of our nation into a beautiful symphony of brotherhood.

]]> 1
the danger of a single story Mon, 09 Jan 2017 00:06:27 +0000 Continue reading ]]> Chimamanda Ngozi Adichie’s the danger of a single story illustrates how we are influenced by the stories we read and the stories we tell.

Chimamanda Ngozi Adichie speaking

She introduces the talk telling about how reading British and American children’s books influenced her own childish writings that featured foreign landscapes and experiences, rather than drawing from her own life. I remembered how my mom pointed out to me years later the drawings I had made when we lived in Saint Lucia. All my houses had chimneys, even though we lived in this very hot, tropical climate with no fireplaces.

She tells about her experience of negative bias where well-meaning people made assumptions about Africa. She also shares how she inadvertently made assumptions about others based on a single narrative that excluded the possibility of other attributes and experience.

It is impossible to talk about the single story without talking about power. There is a word, an Igbo word, that I think about whenever I think about the power structures of the world, and it is “nkali.” It’s a noun that loosely translates to “to be greater than another.” Like our economic and political worlds, stories too are defined by the principle of nkali: How they are told, who tells them, when they’re told, how many stories are told, are really dependent on power… Power is the ability not just to tell the story of another person, but to make it the definitive story of that person.”

It resonates with me how the negative stories flatten her experience. The creation of stereotypes by such storytelling is problematic not because they are entirely false, but because they are incomplete. “They make one story become the only story.”

“The consequence of the single story is this: It robs people of dignity. It makes our recognition of our equal humanity difficult. It emphasizes how we are different rather than how we are similar… when we reject the single story, when we realize that there is never a single story about any place, we regain a kind of paradise.”

]]> 1
what i’ve learned in the past year Sat, 07 Jan 2017 18:31:26 +0000 Continue reading ]]> At first I thought I hadn’t learned anything new, just the same lessons I keep learning every year. Then I realized that I’ve learned new techniques that let me apply what I’ve previously understood in ways that work better.

Lessons I need to keep learning:

  1. Everything is about the people. My relationships with other humans are more important to me than anything else. Since much of my life is spent making software, I think a lot about how this applies to my work. Software is really made of people: people’s ideas, conflicts, errors, understanding or misunderstanding the needs of others or the limits of machines. We need to work well with other people in order to do everything, or at least to do the things that really matter. The so-called soft skills are hard.
  2. Why is more important than what. If we agree on doing something, but we’re doing it for different reasons, it typically doesn’t have happy outcomes for anyone. For that same reason, working with people who share your values is incredibly powerful. Our values influence our decision-making, sometimes so fundamentally that we don’t realize that we are making a decision at all.

This year I combined these lessons into a very different approach to finding my way in the world. Part of the reason I can do this is because I know a lot of people and have grown comfortable outside of my comfort zone. Or rather, I have discovered that what I used to think of as boundaries create a false comfort, and have gained experience in creating boundaries in my interactions which create safety in new experiences.

Find your people.

When I started doing business development for my own consulting company, I realized that there are different ways of doing business that co-exist in our capitalist economy. There are business people who are competing with each other to win, where in order to win, someone else has to lose. Success is gained at someone else’s expense. There are a lot of successful people who work that way, but its not how I work.

In my very first startup, I came up with a very simple formula for understanding this business of making software: if you make something that people need, especially if it’s something they need to do their work, they will be happy to give you some of their money.

My idea of a successful business transaction is when I am happy to do the work because I get paid to create something wonderful in collaboration with smart, interesting people. Then what I get paid feels like a lot of money, plus I’m gaining experience that I value. If we negotiate well and set expectations effectively, then the customer feels like it wasn’t that much money relative to the value of this awesome thing we created together. Of course, every business deal didn’t work out that way even with the best of intentions, but I learned to notice which people weren’t even trying to create that situation.

I applied this idea earlier this year when looking for my new job. I talked to people who I had really enjoyed working with, who I felt were doing interesting things. Those people introduced me to other people. I didn’t have time to talk to everyone I wanted to meet or reconnect with, so I followed my heart and met with people who I most wanted to talk with. It felt a little random at times, yet it was quite intentional. I prioritized the companies with the people who told stories about their work that inspired me, or made me laugh, where it seem like some things would be easy and most of the difficult things would be fun.

I spent more time talking with people who were honest, whose truths reflected my own, who caused me think and reflect. I also prioritized people who also wanted to work with me. That sounds kind of obvious in a job search, but I mean something very specific. Of all the people who would like a person with my skills on their team, there is a smaller group who actually want to work with me, with all my quirks and diverse interests, where seemingly unrelated talents and skills are valued as part of the team.

I ended up taking a job at Google, inside this huge company where there are lots of different kinds of people, I found a community of like-minded folk. Most of those people don’t even know each other, but they help me stay connected to my own values and help me navigate a strange new world. I stay connected with other industry colleagues through Bridge Foundry, a wide network of civic hackers, and small gatherings of friends. Every week I try to have lunch or coffee with someone awesome who I don’t work with day-to-day. Allowing myself to care about the kinds of people I work and staying connected with a wider group of wonderful people with has created a profound, enriching effect on my day-to-day life.

Be nice to the other humans.

I used to feel like I had to figure out who the good and the bad people were, or the good people and the other people who needed to be enlightened, but just didn’t know it yet. I had to try really hard not to be judgmental, and it was really hard to be nice to people who didn’t meet my standards, except, more often than not, I didn’t actually meet my own standards. Despite my best efforts, I kept screwing up.

I got excited about agile development and lean startup where you are supposed to fail fast and learn, but we can’t A/B test relationships. I realized that sometimes talking about a thing is a whole message unto itself. You are saying “I think our spending time on this is the most important thing we each could be doing right now.” Of course, sometimes it is, but often not at all.

If something might be a misunderstanding, it might be not that important for either of us. If I’m not going to be working with you or might not even see you again this year or ever, and you aren’t actually hurting anyone, maybe I should just be nice. Maybe I should give you the benefit of the doubt, think of the best possible reason you might have said that or focus on something else you said that was much more interesting. Then when we meet again, if its important and still relevant, we can figure it out. More likely, things will have changed, and we will have changed.

We invent ourselves in each moment. These shared experiences are precious moments of ourlives. It may seem obvious or inconsequential, but being nice, genuinely nice, makes the day just a little bit brighter and leaves the way open for new opportunities.

]]> 1
personal online security Sun, 20 Nov 2016 00:04:59 +0000 Continue reading ]]> This morning a few of us gathered for brunch, lured by pancakes and the promise of learning about security, by Aaron VonderHaar (@avh4). People shared experiences, as well as fears of what might happen in the future. EFF’s Danny O’Brien and others shared tips and perspectives on security and online safety.

A important thing to consider is that we need to take different precautions depending on what kinds of threats we expect. Generally Internet security has focused on malicious hackers and thieves. However, the threat model has changed. We also need to fear that our government might demand our information from 3rd parties which is less well protected than information that we hold personally. We need to be thoughtful of what companies we trust.

In addition to hackers and legal action, people who make political statements now have reason to fear false news stories as well as personal attacks that the Internet makes easier with doxxing and swatting.

Solidarity from social and community groups can help serve as protection, as well as developing a relationship (if possible) with local police and your representations. Undocumented residents and targeted groups have increased reason to fear our government, despite that our supreme court has historically upheld that US law extends even to those who are not citizens. Even if someone entered the country illegally, they still have the right to protection from discrimination and abuse. Even before this election, we have not not seen justice and police protection applied fairly and equally in the United States. Those of us with privilege have an opportunity and obligation to support those who ought to be protected by law.

Some useful links for more information:
* Feminist Frequency Online Safety Guide
* EFF Surveillance Self-Defense
* Signal Private Messaging by Whisper Systems, a mobile app with fully encrypted end-to-end communication.
* How to encrypt your entire life in less than an hour

]]> 2
self-evident truths Tue, 15 Nov 2016 16:08:33 +0000 Continue reading ]]> “We hold these truths to be self evident…” are inspiring words. Encoding them into a legal framework has been a process. The Declaration of Independence included values of equality and the unalienable rights of life, liberty, and the pursuit of happiness.

Unalienable, adj. impossible to take away or give up
— Merriam-Webster

The authors of that declaration knew full well the dangers we face of those rights being taken away, and yet the first draft of the Constitution did not protect these rights. The first ten amendments were a good start, becoming known as the Bill of Rights. Over 200 years later, we still need to work to define and protect those rights which we believe should be extended to all people.

First they came for the Socialists, and I did not speak out— Because I was not a Socialist.  Then they came for the Trade Unionists, and I did not speak out— Because I was not a Trade Unionist.  Then they came for the Jews, and I did not speak out— Because I was not a Jew.  Then they came for me—and there was no one left to speak for me.

Many people are saying “it will be okay.” We need to step up and work to make that true. Things were not ok before the election.

It is hard to know what to do, but change is not a result of a single action. We need to think through what we may face, so we are prepared when we witness injustice. And we must put ourselves in situations and in company where we will learn and see and have the opportunity to act.

]]> 1
communication is a technical skill Wed, 05 Oct 2016 03:57:54 +0000 Continue reading ]]> (11/16 update: full video now online)

For Rocky Mountain Ruby last week, I opened my talk with inspiration from Jim Weirich, a legendary developer, inspiring teacher and a great communicator. The short video clip was from a prior Rocky Mountain Ruby, where Jim Weirich shared a song he had composed for _why day:

Here are my notes from the talk which aren’t exactly what I said, but provide a bit of the story…

The ruby community has a lovely culture of openness where people share their work publicly with permissive open source licenses, providing the opportunity for serendipitous collaboration. We actively invite people to use our gems with easy installation steps, documented on clean easy-to-read home pages. We showcase whimsical code snippets hoping to inspire developers, peak the curiosity of someone new or just share our joy in our new creation. As with Jim’s song, we love sharing our code, and we like to read and learn from code written by other developers.

Just in case you think this kind of effort only makes sense for mature projects like Bundler and Sinatra, I picked a random repo from one of my favorite developers, Sarah Mei: a small app embloggen with 33 commits, developed over just a few days. The application took shape in the first day with 14 commits, and we can see that she wrote a README on that same day.

And this isn’t a unique process. I took a look at Jekyll, a popular static website generator, written in Ruby that now powers github pages. It has over 8000 commits and 625 contributors. I went back in time to 2008. There was no README that first day, but a couple of weeks later, we see a description of AutoBlog. It is still something that is only used for this developer’s own use. I’m not sure what “blog like a developer” is supposed to mean, but its a start, and there are install instructions and a license. That starting point must have made it easier to iterate a month later, with a better explanation of what it is and how it works. The README is starting to be friendlier, and more clear, but still geared mostly for a developer audience, which communicates something about the state of the project as well.

We usually think of software as being made of code, but it is really made of people. We imagine what the software should do, and through our code, we turn ideas into reality.

I chose three example of what I think of as good communication — some that I have participated in or that I merely witnessed. I believe the best communication has three parts:

  1. Big Vision
  2. Concrete Step
  3. The Path

Don’t be afraid to communicate your big vision. How will the future change because what you are creating exists? What will it feel like when you get there? Then… what are the small concrete parts that people can experience now which make them believe, and cause them to understand that it is possible. Finally, connect the dots. Describe the path where all the small parts, the ones that exist now and the ones yet to come add up to changing the world!

Bridge Foundry

Bridge Foundry has a vision of the future where the makers of technology are reflective of our society, where all people have equal access. This is not only the right thing to do from a fairness perspective; we also believe that the only way we will solve the very real and critical problems of our time is to leverage all of the talent and potential available on this planet.

One of the key activities of this organization are workshops where we outreach to women and underrepresented minorities and teach coding, with a specific language or framework.

It seems simple, but it is a carefully designed experience that was co-created by our early volunteers and students. We always seek to involve a diverse teaching and organizing team. We offer childcare, and make sure there is plenty of good food. If installation is needed, we get that out of the way the night before.

Then students can focus on learning to code in a full day, where every need is met, and they feel supported. Students and volunteers alike often think this is about learning the process of coding, the syntax and the patterns, and it is, but the primary thing we are doing is sharing this culture: our joy of coding and working together collaboratively. This is the culture that most of us live every day at our jobs, but it is invisible to those outside the industry, and is sometimes surprising to those who only know tech culture from headlines or TV.

Through the workshops and participation in our local meetup, we demonstrated results at a small scale, we iterated, and measured impact. We found that individuals taking the small step of teaching weekend workshops could see it happen. They were inspired by making an impact on just a few people, and we shared the information about how the effects were adding up. In just 6 months, our local SF Ruby meetup went from 2% to 18% women. We illustrated the path from the simple step of volunteering, teaching what you know in a fun weekend experience, to changing the industry.


Next I will share an example from the business of building a software product. In my new job, I work on the Firebase team.

The Firebase Product Manager, James Tamplin, gets up every other week in front of the whole team to give us product and customer updates. He starts every meeting by saying that we are working to “help developers build better apps and grow successful businesses.” And that’s great, it keeps us aligned internally, but I wondered… now that we’re inside Google can we communicate that mission as effectively? So I googled “Firebase mission” and could only find pre-acquisition statements… and then… I noticed on our home page… there it is:

App success made simple The tools and infrastructure you need to build better apps and grow successful businesses”

For an outsider, it looks like marketing fluff, but it’s not. This is our mission. It is not enough to just say this words. We need small things we can do to align the team in building toward this vision. You can’t see it from the outside, but I think it adds up to a difference you can feel. We have these practices, which I believe are key to making this vision a reality.

Our whole team has this relentless focus on the first fifteen minutes of the developer experience. Throughout the development process, in meetings or spontaneous conversations, someone will ask “how does this affect the initial experience?”

One of my colleagues, Joey Yang, told me a bit more detail about this developer experience that is so important to the Firebase team. He described the user experience as the “sum total of every interaction the user has about the product.”

It’s not just our code and documentation, it’s social media and stack overflow. It’s not jut your blog, it’s other people’s blog posts. Someone’s first fifteen minutes might be interacting with another person in the community who is not you! Or it might be through your github repo, conference talks, meetups or hackathons.

“Your product is not just your code — if it takes you more than five minutes to get up and running, then you will spend your time elsewhere” — Joey Yang

I first met Firebase team in May 2012 at a hackathon. I had no idea at the time that I was experiencing a company philosophy! I later learned that they had a policy that “even if you weren’t using Firebase, we would help you out… even if you were using a competing product. Generating good will from the interaction was important to us.”

So my team was at AngelHack back in 2012 making an app that let people sketch 3D shapes in the air. Firebase helped us send paths to the server instantly, to be rendered on a webpage with WebGL. This was just a hobby app, something delightful and fun, a way to stretch our developer skills and our imagination. Firebase treated us with as much reverence and excitement as they did people who were building a business on their product. They invited us to their launch. They showcased our success. Of course, we knew that this was their success as well, but we were center stage.


I started learning Ruby on Rails in December 2008. Rails 2.2 had just been released. I witnessed the adoption of Rack by Rails and by all of the Ruby frameworks. As a developer in the community, it felt like one day, everyone decided that Rack was a good idea, and then everything just got easier. I don’t know the actual history, but I did a little research and was intrigued by what I found.

In February 2007, Chris Neukirchen wrote a blog post introducing rack.

I noticed that there is a lot of code duplication among frameworks since they essentially all do the same things. And still, every Ruby web framework developer is writing his own handlers for every webserver he wants to use.

He observed that HTTP is actually quite simple and expressed it as a simple API:

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]

This is actually a very simple Rack application. Chris presented something which could be adopted rather easily, and when adopted by a single web server was not that revolutionary, but with each server and framework that adopted it, it became easier for everyone. It didn’t need to be adopted all at once to save time and effort. It was a good idea. It was really only an idea. He did write some helper libraries, but no one had to use them.

Rack was just an idea, a thought, that simplified the approach to connecting different pieces of web software.

Communication is What We Do

I find it confusing that anyone could even suggest that communication is a different skill that is optional for programmers. This is what we do. We write our code in programming languages. We define things and then they exist. We make real things using language.

When I was a kid, I wanted to be a wizard, with magic where you could know the name of a thing, sketch it in the air and make it real. We do that with software. When we write code, we simply define a thing and run the code, to make it real.

“Wizards channel arcane forces through extensive study, hidden knowledge, and intricate preparation. To a wizard, magic is an art form, an expressive and powerful method by which he or she seeks to control the world around them” —

New Languages

There seems to be an explosion of new languages or old ones that people are suddenly using more often. This seems driven by combination of fast processors and new problems of building distributed systems that require better handling of concurrency, and new user experience patterns with mobile and all sorts of connected devices.

To understand what these new languages are for, it helps me to think of them in context of history and language design trends. This invention is a conversation between the past and the future we’re creating. Software developers exchange ideas through experimentation.

Closing Thoughts

Learn a new language. Make a new language. Code is communication. Figure out what you want to say: make things that communicate your intention. Experiment! Maybe you can make the thing that will give us all new magical powers.


]]> 3
five dysfunctions of a team Fri, 09 Sep 2016 13:10:09 +0000 Continue reading ]]> The Five Dysfunctions of a Team by Patrick Lencioni tells the story of a fictional team leading a believable tech company. It illustrates how we bring our humanity and our flaws to work, even as good leaders who contribute exceptionally well, we can still fail if we can’t collaborate effectively on a shared goal.

The storytelling was particularly good at showing how it can be so hard to facilitate change. Everyone won’t be in the same place in the same moment. Someone gets it, while others are struggling. The best teams have a culture of helping each other, and we need to create that culture intentionally.

I tend to prefer non-fiction that conveys research when I read books about work, but decided to read it after it was recommended twice in one week (thx Luna Comerford and Adria Richards). I found this corporate fable to be compelling and thought-provoking. The audio book was particularly entertaining and was surprised to finish it in just a day mostly during dog walking, muni rides, and evening errands.

I enjoyed the book and agree with the five dysfunctions presented as a pyramid that illustrates how each weakness leads to the next. In thinking through my reflections on the book, I found it helpful to review Abi Noda’s book notes. I liked his re-creation of the pyramid of dysfunctions, along with annotations, which inspired me to create my own alternate annotated pyramid:

Absence of Trust "politics", Fear of Conflict with artificial harmony, Lack of Commitment, ambiguity, unresolved conflict, Avoidance of Accountability, avoidance of interpersonal discomfort and Inattention to Results (Status & Ego)

At the top of the pyramid, the book talks about “inattention to results,” though the discussion is really about focusing on the right results, which are based on shared priorities and shared decisions. Individuals on the executive team might inadvertently jeopardize the company’s success because of their own status and ego. No one wants the company to fail because of their own functional area, and thus, well-meaning people can become defensive and fail to deliver on shared goals because they are too focused on their specific deliverable. Certainly we all need to deliver great results within our area of expertise, but that must be in support of a primary shared goal.

At the base of the pyramid is absence of trust. The book had an interesting anecdote on how “politics” is common on teams when people don’t trust each other. People use that word to describe different behaviors, but the CEOs definition works well in this setting: “Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.” When we work in an environment where we can just say what we think, trusting that people will believe we have good intentions and are working toward our shared goals, makes everything go faster and leads to better solutions.

Psychological Safety and Vulnerability, Healthy Conflict and Speaking Up, Shared Decisions with Buy In, Accountability supported by collaboration, Alignment of key results, shared goal and a shared understanding of reality

I felt like I wanted to remember the functioning team and the positive state we’re striving for when we work well together. As the story progressed, I imagined the opposite pyramid. At its base is psychological safety, which allows people to be vulnerable; this creates an environment where people can speak up, allowing for and supporting healthy conflict. If people can have productive discussions and have respectful arguments, the team can make decisions that the each individual buys into. People hold each other accountable, but also support each other and collaborate, consistently seeking alignment on delivering on shared priorities. Working as a team requires repeated course corrections. We need to make time to help each other and if we’re all focused on different things, we just won’t have time to do it all. If we’re all focused on the same goal, supporting parts of the same deliverable, then collaboration helps each team member deliver on their individual work and the shared goal.

One key element to making good teams work well is what I call a shared understanding of reality. In the book, the new CEO starts each day of their executive offsite by saying: “We have more money, better technology, more talented and experienced executives, and yet we’re behind our competitors.” She was creating a shared understanding of reality. She was making it clear to the team that she believed in them and in the business opportunity. A lot of what we do when we create alignment on a team is to build that shared reality. Shared goals are built on shared information and shared conclusions, which are based on shared values.

There are lots of ways to think about how to create a healthy team. I like how Abi Noda reflects on the pyramid of dysfunctions presented in this book: “Teamwork deteriorates if even a single dysfunction is allowed to flourish, like a chain with just one link broken.”

]]> 1