The Boring Show

This is an opinion piece, and the views expressed in this post are my own, not my employer (Google)

Interesting times

I started at Google in DevRel just a short time before the pandemic ramped up to its early terror. I ended up doing my Noogler (you can probably guess, but it’s one of the many -oogler nicknames, in this case for new hires) orientation at the New York office. You might have heard stories about our offices — living walls, arcade games, scooters in the hallways, many cafes with free food. Well, in reality… it’s exactly like that, yeah. :) The left half of the banner image above is a picture I took from the terrace outside one of the NYC-9TH cafeterias. It’s a really phenomenal place.

There’s a truism about Google that Nooglers almost universally come in with “imposter syndrome”. The short version explanation of that term is… take it away, Wayne and Garth.

Google has a kind of glass tower reputation (and a monolithic facade) that I think makes it feel inaccessible to other developers. One of the functions of developer relations, at least in my mind, is to dispel some of this aura, to be in both your corner and ours. I do honestly believe that this is a special place (one of the best I’ve worked at), but at the end of the day, we are also just trying to make stuff that works, and more importantly, make stuff that works for you.

The Boring Show

Getting back to the title of my post, I’d like to bring up something really cool that the Flutter/Dart developer relations folks are doing: The Flutter Boring Show. The idea behind this effort is to drop the contrived examples / marketing / what-have-you, and focus on really hard, real world problems that are baffling both outside developers and our own. This is what we offer to people applying to work at Google (solve real world, really hard problems!) and I believe that we should offer it to all of you, as well. Our goal, then, is to take care of some of that complexity for you, so that you can focus on the hard problems that make your own work unique and interesting.

As part of DevRel engineering, my primary task is to make the libraries that interface with our services work well for you. That includes adding new features, looking at bug reports, and helping out with customer cases. My other primary task :) is to bi-directionally advocate:

• Helping users understand why things are the way we’ve designed them
• Helping us understand why things should be designed differently
• Trying to broker compromises between those positions

To that end, some focus has recently been placed on making full, end-to-end examples. A quick snippet of sample code and good documentation go a long way toward getting you started, which is really important; but in the end, you also need to know how to connect the pieces together, and where to go next.

These are all really important to us as Googlers. I can only speak for myself, but my impression is that it’s a shared aspiration — we really want to help you succeed, and nothing is more delightful than hearing that you have.

Buffering…

I’ll close out by talking about the right half of that banner image at the top. When the rubber hits the road, as they say, things get messy. Nothing in my lifetime has been as messy as trying to persevere and thrive through a global pandemic. I experienced a few scant months of that fabulous Google office life before we all started working from home. Network issues, cats taking over the camera frame, suddenly having to run to help the kids who are stuck at home.

As I say at the top, I can’t speak for my employer, only my own views and perceptions. But everyone I work with is dedicated to continuing to improve your experiences on our platform, as well as your own! We don’t always hit the mark (again, my opinion). It’s a given, and humility toward improving and doing better without drama is an internal virtue we try to export. We try, but, well… we are people too. :)