Having recently left the Go team at Google, I thought that it might be worthwhile to reflect on and to write about my experience. After asking the community, I would like to to shed some light on what it’s like to be involved in such a group. In this article, I will discuss my prior experience with Go, how I came to join Google and the Go Team itself, my (tl;dr: awesome) experience on the team, and what my future at Google looks like. Twitter users also expressed interest in hearing about the processes that are involved with maintaining and updating the Go language — to the best of my ability, I will discuss this, too.

First, a little bit about myself: I am 23 years old, less than two years out of my undergrad degree at UW-Madison. Thinking I was going to major exclusively in mathematics, I didn’t start programming until I took an Intro to Java class on a whim. Afterwards, I really got into coding and hacking. Sometime during my four years, I became passionate about both web development and compilers, though I did not use Go for either.

At the start of my senior year, and after a rollercoaster of interviews, I decided to join Google’s Engineering Residency program in their New York City office. The Eng Res program is a great way to get acquainted with working at a large company like Google. Participants go through several weeks of training to become productive Google engineers, and then complete two approximately 4-month rotations on different teams. If you are considering entering the software engineering trade from college, I highly recommend this program.

My first team was a small, internal tools team for Maps. A big draw for me was that I was able to use the new and improved Angular (2+) frontend framework. However, as my focus on the team shifted more towards backend and database work, I also gained experience with the team’s Go API and Spanner database. I was delighted by how simple it was to get things done in Go. Most of my previous web work dealt with the frontend, but I have done a significant amount with both Ruby on Rails, Node.js, and PHP backends. Unlike these backend ecosystems, Go had no magic, which made it gentler to navigate around the growing codebase, and of course, to debug all my code! The infrastructure for the team’s backend was also well supported — answers were easy to find, and things “just worked”. Around this time, my Eng Res peer Rebecca Stambler was working on the Go Tools team in New York — the team I would later join. She said many positive things about the team, and ended up converting out of the Eng Res program in the spring of 2017. Rebecca now wrangles Google’s internal Godoc, and contributes much to editor integrations with Go.

When my rotation on the Maps team came to an end, I got the opportunity to join the Go team. As a fan of working in open source, as a dabbler in programming languages, and as a new Go fanboy, I was intrigued to join the team. My project would be to port the example-based refactoring tool, eg, in order for it to operate in Google’s monolithic code repository. I would work under the guidance of Heschi Kreinick, who contributes to dynamic tools for Go, and Alan Donovan, who wrote both the Go Programming Language book and the eg tool. Please allow me to hand wave any questions regarding the difficulty of this port by saying that it was in fact, difficult (there are a lot of confidential “things” and idiosyncrasies related to the monorepo). Also, because the size of the monorepo is confidential (as are its contents), please believe me when I say that it is REALLY BIG. Refactoring is a problem that scales superlinearly with the size of the codebase. If Go is to succeed in being scalable, stable, and useful at Google, we need good refactoring tools.

So, about the Go team: At Google, it is a globally distributed team of software engineers, developer relations, and product and program managers. In my time on the Go team, I met and spoke with the majority of the “Gophers”. The team works on the language itself, as well as various parts of the Go ecosystem such as libraries and Google Cloud integrations. Most engineers on the team contribute to both the internal and external Go ecosystems. One of the team’s overarching goals is to make using Go a great option for both existing and new projects at Google. A lot of work at Google involves sending Protocol Buffers between services, at scale, which is the kind of software engineering for which Go was designed and at which it excels. (The adoption of Go by container and microservice developers illustrates this.) Go’s utility in server programming is also part of the reason why RPC-friendly libraries like Context were introduced.

In the New York office, the team mainly focus on tools, both inside and outside of Google. “Tools” includes everything from static tools, like gorename, to dynamic tools, like pprof and debugger support, to build tools like our internal version of Bazel. In addition, we also have Sameer Ajmani, who manages all of Go engineering, as well as the recent additions of Andrew Bonventre and Steve Francia, who work with the external Go community. Within a few weeks of starting my rotation, I felt accepted by the team. I learned so much just through code reviews, documentation and codebase surfing, and even during casual coffee breaks with the Tools team. I feel that Go is a project that intrigues many experienced Googlers, which made it a perfect place to apprentice with Google engineering practices and infrastructure.

Every week, the entire Go team (including people like Russ Cox and Robert Griesemer) meet to watch a Googler’s demo over video conference. Demos may cover topics like performance changes in the runtime, practice talks for events like GopherCon, or project retrospectives like the one I gave about my work at the end of my rotation. We also occasionally have demos from related teams, like the data pipelines team, who want to integrate or develop for Go. Language features and proposals do come up, and we expect more with the recent announcement of the Go 2 effort.

This speaks much to the philosophy of the team. Given the scale of its contributions and influence, the Go team is one of the most pragmatic teams with which I’ve worked. Simply put, nurturing a language is a difficult thing to do: any “minor change” could end up breaking a user or worsening their performance. The Go team wants to make life not just easier, but provably better for users.

What I am most pleased with working on the Go team, actually, is the Go community. Nowhere was that more apparent than at GopherCon, which I was fortunate to have Google pay for me to attend (and our intern, Suzy Mueller, too). Even though I was relatively new to Go and worked on internal source, I felt welcomed by the community with its camaraderie and intense technicality. That feeling, combined with helping people make their first CLs to the Go project during the Contribution Workshop, made me proud of my teammates’ work in supporting Go. Although my project’s code will never appear or run outside of Google, I’m happy that I was able to provide useful tools for engineers whose Go code will.

At the end of August, I finished my rotation on the Go team and gladly became a full-time, salaried Googler. My new team also deals with developer tools, but on the public-facing, Google Cloud side of things. The details and launch date are secret, but hopefully, eventually, my new team’s tools can make your life easier as an engineer.

I hope I was able to shed some light on what it’s like to be a Googler working on the Go team. It was an absolutely rewarding experience. I met and worked with great people and hacked on interesting problems. For example, I still remember discussing (read: getting schooled in) thread sanitization and channels with the compiler team over a casual lunch. The Go team and the language itself still has a lot of work ahead of it, but I believe that the right philosophies, and more importantly, the right engineers and community are guiding the project’s growth.