As Developer Advocate on Google’s Flutter team, Filip Hracek created The Boring Show to show that all developers share similar frustrations and moments of confusion. In this talk from DevRelCon San Francisco 2019, Filip explores how creating authentic resources can benefit the developer community.
So I’m going to give you a talk about honest dev rel and candid dev rel. Are you ready?
I’m extremely passionate about whatever I’m talking about right now. You wouldn’t believe how excited I am about the tech product that I’m covering. And it is amazing, it is probably the best thing that has ever happened to me in my life. And I think the engineering team did everything well. I will not be covering any problems because there aren’t any problems.
And now, I am live coding, look how easy it is. Engineering is easy. And also, if anything happens during the live coding, that’s the demo gods, because normally, nothing goes wrong with technology ever, right? And lastly, I made an app, that’s a sample app, and I had no engineering, or I’m sorry, no management oversight. The app has no business model, no ads, no legacy code integration, but I will still talk about it as if it’s on the same level as whatever you’re doing in your day-to-day work. Right?
So I think we get the idea. Now, why do we do this? And make no mistake, we are all doing this. Right? If you think you’re not doing it, you’re doing it. If you’re like, “Okay, I’m doing it a little bit,” you’re doing it a lot. We’re all doing it.
So why are we doing it? So I think an overarching thing is dev rel is becoming an industry. Right? So we have all these best practices, we have all this institutional knowledge, we have all these things that we’re like, “Of course you do it like this.”
But on a deeper level, there are I think three reasons. One of them is we just want our technologies to succeed. Right? This is our job, by the way, so we want that. We also don’t want to look stupid in front of the audience because no one wants. Right? And third, we are actually excited about things. We’re not insane excited, as in like talking to random people about, “How excited I am about something,” but we are excited about the things.
So we do this. We’re like, “We make technologies look better than they actually are.” We talk about all the cool features, we never talk about the bugs, we talk about how you like build a CMS system in five lines of code but we don’t talk about how you maintain like 1 million lines of code. We don’t talk about migration, we don’t talk about legacy code, we don’t talk about the bad stuff. Right?
We also like never show ourself, if we can help it, we never show ourself being dumbstruck or just like not knowing something about our technologies. Right? And that creates a lot of, you know, the imposter syndrome that we see in the community because people are like, “Oh, they’re great at this and I’m not, so something’s wrong with me.”
Okay. So we do this, we know why we do this, but I’m here to tell you that it is a bad idea in the long term. And this is because whatever you say, whatever you write, it’s always interpreted. Right? It’s not like, when I talk to you right now, it’s not that you take the stream of my words directly into your like value system. No, you’re talking through it, you’re comparing it whatever you know from your life, and it’s just interpreted.
And the thing is developers, and people that are smart in general, are interpreting the hell out of everything, and we need to recognize that. Right? So if you say something and you’re thinking like, “Oh, the way and the thing that I said is exactly what the people I talk to now think,” that’s not the case, people are taking, you know, as I said, they’re comparing to what they know, they’re also thinking about the things that you didn’t say and should have.
So developer relations is built on trust as any other kind of relation. And if the developers can trust you to tell them the truth and the whole truth, then you are kind of moving yourself from dev rel into a spokesperson. And I don’t think many people are, maybe you are excited, you were like, but I’m not excited about being a spokesperson.
Anyway. So I come from this part of the world, the central Europe, and this is like a bunch of countries that you’ve never been to and the thing that kind of ties them together, in my mind, is skepticism. If you’ve been to Central Europe, you know what I mean.
And if I go to Prague and I start a talk with something like, “I’m extremely excited about this product,” that’s the end of my talk. Like people are cringing, and groaning, and just like they are not listening to me anymore and they don’t tap me seriously. Take me seriously, sorry.
So I firmly believe that this is the case everywhere else. Maybe like if you talk to North American engineers, they’re not like cringing and you can’t like see it visually on them that they are not really believing you, but they smell bullshit as much as anyone else. So please stop do that.
So this is my call to do candid dev rel. And I have a case study. So the case study is The Boring Show. So okay, so we have a developer SDK called Flutter, which is an SDK for, you don’t care. And we have several shows on YouTube, one of them is The Boring Show. Right?
So it’s like a developer tutorial video show let’s say. Right? So let’s take a step back and see what are the like best practices about doing videos for developers on YouTube. Right?
So I think there are three main ones. It’s going to be short, it should be below 5 minutes or even 3 minutes, because otherwise, you know, people won’t watch it.
It should be super edited, so like it’s this kind of ADHD way of editing that I dislike. It’s like, whenever something stops, immediately after that you have like an explosion or like color or an animation or something like this. Just like so that the developer can’t have time to think about anything else, and God forbid, actually goes to watch another video.
And third, I like fun but “Fun.” That’s the kind of like when all the videos are like, “Oh, I have a pirate hat and I will be talking like a pirate,” the whole thing, I mean, you know. So I looked at this and I was like, “How about no?”
And the cool thing was I was talking to Andrew Gerrand from the Go language team, 3 years previously, and we talked about videos as well, and he was like, “You know what’s interesting? The most successful video that we’ve ever had is this.”
So this is a video that is one hour long and it is basically just two people, and probably unedited, two people in front of a webcam, a shitty webcam at that, and all they’re doing is they’re just programming, right, they’re pair programming.
And I was like, “I want this.” So I went to the Google team that does like video production and I was like, “Can we do this with Flutter?” And they looked at it and they were like, “No, no.” They’re were like, “This is 2018 and we have actual like quality standards so we’re not doing this.”
But we talked a little bit more, and they were actually really good, and they said, “Okay, let us produce this so it doesn’t look bad but you can do whatever.”
Right? And so, February, 2018, we started the first Boring Flutter Development Show, which was a one hour long. This is us. Look how young I look there. So that’s Andrew and me and you can see that probably, maybe, I don’t know, but it is an hour long and we were just like pair programming an app.
Right? And we hit some bugs, we had like a lot of like red codes, we were dumbfounded by what we were doing and we were like looking stupid. And then, we continued going. So this is Emily and Andrew doing another Boring Show.
We have 25 Boring Shows now, and each of them is one hour. So this is Emily and Andrew being dumbfounded, this is Andrew and Matt being dumbfounded, this is Emily and Lara laughing about a red screen of death. And this is me and Ian, Ian is the co-founder of Flutter, he like who invented the whole thing. Being dumbfounded. Right? And I don’t know about you, but to me, that makes me respect him more for like, you know, doing that. And he’s like that, so it’s awesome.
So anyway, results. Right? In terms of views, like if you look at only views, this is obviously bad. Right? Like it is like one third or one half of the other video series that we have. But the other video series that we have are two minutes, five minutes. This is one hour. So, in terms of time span, this is huge.
I didn’t do the math but I think, I’m pretty sure, that if you watched at least some Flutter Boring Show videos in the past year, you saw more of my face than Jon Snow. Let that sink in. It’s terrible, I know but…
So that’s one, but more importantly, it’s really influential. People are talking about it, people are doing their own versions, you know, people are like watching it in different ways.
One of the coolest things I’ve learned is I met this person, Filipe Barroso, at Google I/O, and he talked to me, and I didn’t know him before, and he said, “I love The Boring Show, and in our community, in Portugal, it actually changed the developer community around because people are more likely to share things, more likely to not like feel, sorry, impostor syndrome,” and so on.
He wrote this, “The Boring Show helped create a welcoming community, free of judgment. Everyone is learning.” This is, to me, like I can have this on my tombstone and I’ll be happy. This is impact, right?
So I talked about candid videos but it doesn’t need to be only videos. It can be articles, talks, demos. APIs can be candid. I actually have a Medium article, from about 2 years ago, called the Hello World Fallacy, so if you want, you can search for it. Not now.
And in general, everything in dev rel could be made more candid I think. In fact, if you allow me to like dream a little bit, I think there are other fields of human endeavor that could be made more candid. Right?
I’m not going to say like exactly what, but I think you can imagine like there are some things where people are kind of tired of like bullshit and, you know, not hearing everything that they think is happening. And then, it can create frustration and not good things.
So, but back to Earth. Candid dev rel. I have five commandments of candid dev rel because I like, “Commandments,” more than, “best practices,” but it’s best practices.
So first, fight. Fight for your right to be candid because this is not going to happen by itself. There’s a lot of pressure on you to not be candid. You will be fighting with the PM, you will be fighting with your managers, you will be fighting with yourself to like be able to say some bad things about the product that you’re talking about. Right?
Second, show warts, show the things that are not working. And not just to meet them, like after the fact, “Oh yeah, sorry,” no, show them. Like in The Boring Show, like we really show these things, we don’t edit it out, and that makes things more candid.
Three, be boring, pick boring topics. Like don’t just do the, “I’m going to write a blog system in five lines of code,” do refactoring, do unit testing, do CI/CD, do whatever other things that people are doing in their everyday life. The thing is most developers, most of the time, don’t write todo MVC or Hello, World! apps, they are actually maintaining bigger projects and you want to see how your product is, or how your SDK is working with that.
Four, empathize. So there are people, like, for example, here we talk a lot about like impostor syndrome of us as dev rels. But we have it kind of like, I don’t want to put down that, that’s a valid point, but we are in power. Right? We are those that stand right here and talk to other people. And then, imagine like, if you do like, “Oh, this is so easy,” to someone who’s beginning and they see that it’s not so easy for them, what kind of impostor syndrome it creates for them? So emphathize.
And five, don’t be afraid. Don’t be afraid to look stupid. Don’t be afraid to show the warts and the bugs and all these things. Don’t be afraid to fight with the PM and all that stuff. Right? Again, it’s not very easy to be like there. And trust me, like I’ve done many Boring Shows now, it’s always really bad, I sweat, it’s like, “Oh my god,” and we’re not editing this out. And it is not pleasant but, compared to the fact that someone out there is not going to be like, “Oh my god, how did they do this? I’m a terrible programmer because, if I do it myself, it never runs that well,” that’s I think it’s worth it.
Okay. So, to summarize, fight, show warts, be boring, empathize, and don’t be afraid.
Do we still have time? I have one video to show. One hour-long video to show. Yeah? Four minutes? Okay. So the video team, at Google, they actually created like a tutorial, I’m sorry, tutorial, what do you call it? Trailer? For Boring Show. Which is amazing, it’s like meta because like you’re trying to do this flashy thing for Boring Show. And so, I think they did a pretty good job there.
So I’m playing.
“Hello. I’m Filip, speaking to you on this trailer for The Boring Show. The Boring Show is a place where two engineers sit down and build apps in Flutter from scratch. Oh, look at that. Wait, can we just focus for a minute here? So where was I?
Right? The Boring Show is an entirely necessary look into the development process of an app that… Bees? Bees? All right, The Boring Show. The Boring Show is important because it’s an opportunity to show Flutter being used in more complicated ways. We also take viewer suggestions on what features and apps to build next.
Ultima Thule, an asteroid 6 billion kilometers away. Look at that. I love outer space. Stars, nebulae, black holes, weird bean-shaped galaxies. Wait, hold on a minute. Why does everything on the internet have to be so red and bite-sized? There should be room for long-form deep dives into topics like estate management, or caching, or typography.
And on The Boring Show, we buck the trend of oversimplifying complex subjects because we want to be fair to our users. We want to show you how we work, even if that means showing how we’re stuck. Please join us at The Boring Show, now publishing twice monthly on the Flutter YouTube channel. Give it time and maybe you’ll find it surprisingly exciting. Open and closed brackets.
Okay, thank you.
Do you need to have a fully formed dev rel metrics framework right from the off? Or can you take a more gradual approach?
Understanding the journey a developer takes through our products is essential if we want them to be successful.