Recognizing Value
A transcript of my talk at GothamGo 2017
--
Before I was a member of the Go team, I was living and working in San Francisco working on the new Gerrit Code Review UI. I was there on an extended visit from New York — about 8 months — so that I could be closer to the team and try something new as I’ve lived here for more than ten years now.
When it came time for me to plan my return, however, I was informed that I wouldn’t be able to continue in my role if I changed locations, so I had two choices: stay in San Francisco and keep my current role, or move back to New York and find a new team.
New York and San Francisco both have many qualities that make them wonderful places to live, but for me the proximity to family and seasonal variation were the tie breakers in favor of the east coast, so I informed my manager, who was extremely supportive, and started looking for new roles out of our NYC office.
At Google there’s an internal job board called Grow where teams can put up job requisitions as headcount becomes available and you “apply” for the position. The application process doesn’t have any whiteboard interviews (thank god) but it can be tough for a few reasons. You want to make sure that you gel with the manager/team and the work you would be doing is challenging and in line with your career goals. All while potentially competing with other colleagues for the position.
After a somewhat long and grueling process of finding a new role, I was down to the wire when suddenly an opening became available on the Go team. I’m a huge fan of Go (you’d hope so, right?), having written some APIs for the standard library and forcing, er, convincing everyone at the last startup I was at to use it for everything. I immediately emailed Russ and Sameer, we had our internal hiring dance, and I landed a position on the Go team in New York.
I was so elated and relieved not to have to worry about securing my next role amongst the other stresses of moving across the country, but then I thought about it a bit more. I, a product engineer who builds user interfaces (for the most part), was joining a team building a programming language.
While I had done a few related things in college, I hadn’t done any professional work on compilers, runtimes, garbage collectors, or anything else I viewed would be useful comparatively to my colleagues. Suddenly this was all seeming like I (and the Go team) had made this huge, terrible mistake. Right on cue, my mind dutifully placed the soul-crushing weight of imposter syndrome upon my shoulders.
I started out with some relatively basic infrastructure work like moving services from App Engine to GKE and standardizing some deployment steps for our growing number of apps. Soon after, I was tasked with building a dashboard for our contributor day at GopherCon. We wanted to have a scoreboard and activity stream that updated in real-time when someone registered their account or created, updated, and landed a change. The idea was to have it projected during the workshop so that people felt engaged by the community effort.
I was excited to work on this because it went back to my most recently-practiced competencies and was an example of where I could contribute on the same level as my other colleagues on the Go team. I spent most of GopherCon coding this so I apologize if I missed anyone’s talks or didn’t have time to chat. I was at my cousin’s wedding when the contribution workshop kicked off, but I heard the dashboard worked and that everyone cheered when they hit 1000 points. After this experience, I started to feel less uncertain about the value I could bring to the team.
As I’ve sampled the various challenges the Go team faces—extreme growth, improving the contribution and review experience, engaging with the community for initiatives like Go2—I’ve discovered facets of the project where my own expertise in human-computer interaction, user experience, and product could provide a lot of value. More importantly, this experience led me to reframe and expand the perceived set of skills required to contribute to Go, which I want to share with you today.
Compilers, garbage collectors, profilers, etc. are a very important but limited part of what contributes to the success of a project like Go and not enough people truly grasp the value that a person with a diverse set of experiences can bring. Judging by the low number of external UX designers, copywriters, and frontend engineers who are fully engaged in the project, I would say we’re not doing a good enough job of welcoming these types of people to contribute.
Now, specialization is absolutely critical for a project like Go. We need experts on garbage collection, compilers, and API design so that we can provide, at the base level, a product the community will actually use. What tends to be undervalued in highly-specialized communities, however, is the process of acquiring input from people with a wide-ranging set of skills outside of our bubble of expertise.
But why do we even want this? What good does it do to have people who don’t know anything about programming languages to contribute to a programming language?
Because they see our blind spots, enlighten us with novel solutions, and push us to see things from different perspectives. I’ll give you a couple examples from the analog world…
In the early 1920s, Dick Drew sold sandpaper at the Minnesota Mining and Manufacturing company. Since he spent a lot of time in auto shops, he noticed that there were issues managing the border between the colors on the two-tone paint jobs that were popular at the time. The painters taped butcher paper to the cars but when they removed it, some of the paint would come off along with it. He realized that if the painters had sandpaper (which had a much lighter adhesive) only without the sand, they wouldn’t have to worry about stripping the paint. After two years of toiling he ended up with what is now known as masking tape.
One time when Drew was testing his masking tape, one of the auto workers exclaimed with frustration “Take this tape back to those Scotch bosses of yours and tell them to put more adhesive on it!” (the term “Scotch” was synonymous with “stingy” at the time). Later, when Drew found a similar use case for his company’s cellophane wrapping paper he named it Scotch Tape. By now you can likely surmise that the Minnesota Mining and Manufacturing company is now known as 3M, and they’ve had a lot of success with innovation via cross-pollinating ideas like this.
In 1968, Spencer Silver invented an adhesive with a novel molecular structure that allowed it to stick to things but not permanently. The problem was that he couldn’t find a commercial use for it. Years later in 1974, Art Fry was annoyed that his bookmarks kept falling out of his bible during church choir, so he came up with a use for Spencer’s adhesive, creating Post-Its. Art saw the blind spot that Spencer didn’t, but it wasn’t for lack of intelligence or specialization on Spencer’s part. The product wouldn’t exist without the solution and the use case.
With these examples in mind, I want you to think about developer products that you believe required a lot of cross-pollination between disciplines. For me the first one that comes to mind is Apple’s Instruments product. It has nothing to do with music, rather it’s a suite of tools used by app developers to examine the performance characteristics of their code — to instrument it.
Many of the Instruments you can choose from use commonly-known tools like DTrace in their implementations, but a better and more approachable product was created by bringing in UX and visual designers to collaborate closely with the engineers, resulting in a better experience than what you would get by only using the command line.
I want you to imagine the level of communication required to build Instruments. These are immensely complex tools providing technical insights in ways that allow newcomers and experts to examine and troubleshoot performance issues with their applications. When building a product like this, the specialization required from each collaborator is extremely high, but they were able to find a way to make it work. I don’t have any insight into how the Instruments team collaborates, but I do have suggestions for how we can all encourage better communication in cases like this (and generally).
By nature of being open source, there is an intrinsic call for contributions from the community familiar with our problem domain, but we should do better by reaching out to and encouraging those with differing expertise to feel welcome to contribute. This requires laying out a clear path for these people to follow, but the most important staple to any contributor’s continued success is communication.
For example, if a patch comes in claiming a performance improvement then it likely will require a set of benchmark numbers attached to it. This sort of justification is required by nearly all changes, but as specialties start to diverge, the effort required to communicate benefits, trade-offs, and negative effects gets exponentially more difficult. The overhead of bridging the gap in expertise is very high and too often we’re not used to this kind of overhead so we may dismiss it. As stewards of the project, we need to be cognizant and patient in these cases.
Maintainers should be clear on what is required in this cases by setting clear guidelines for proposals that fall out of the team’s intellectual comfort zone. Importantly, we should communicate what we don’t know so that the potential contributor can approach the issue with a clear idea of what they need to communicate. If a frontend engineer proposes a change to Go’s homepage with that reduces page load times, then they should explain how they did it to an audience that may not be familiar with frontend development. This requires patience and awareness from both the contributor and maintainer.
We all have value and recognizing it can require a lot more work than we’re used to. Be open to different perspectives, welcoming of very different backgrounds, unafraid to offer your unique take on things, and more importantly, patient with each other during this messy process. Thank you.
