Optimizing for developer happiness

Well, I'm talking about happiness, thank you, which is a very good setting. So Ohayou gozaimasu.

Just want to get that out of the way. I'm very pleased to be in your country. This is my first time in Japan. I've been to the APAC region, but first time specifically for Tokyo and Japan. And, it's very beautiful city. Like, this is an amazing space that we can sort of view all the places I haven't seen yet. So hopefully, I got one more day left, so I can see the rest of the city in half a day, before I get on the flight.

But I want to share my personal experiences of being here in Tokyo, specifically last night. So last night, we had the speaker dinner, just across the street. We had some drinks and some light eats. And I like to eat a lot. So, on my way there, I picked up food.

And I ate while walking, which I don't know if that's a thing here. It kind of felt weird walking and eating when everybody is just, like, very busy. Also, interesting that you guys put the coffee in the bag with the rest of the stuff, like, I'm very confused when I grab coffee, and it's in a bag. We don't do that in the States. And, as I was walking to the event, I finished my food.

As I was walking, I was looking for a trash can. And I noticed there are no trash cans on the street. Very interesting. So I approached this problem in the same way I do code, which is basically just Google it. So, I Googled, like, why is Japan so clean? Like, what some conversations we had last night is about a difference between the subways here and the subways in the States.

Drastically different. They're actually cleaner here. Who's been to the States? Okay, a good amount of us, I guess about a third of us. So, hopefully, maybe I'm teaching you about American culture, hopefully. Yeah. So I figured out that I went to this, this is the first article, which was on Japan Today.

So I assume it's a news publication like, just here, Googling, copying and pasting, and throwing it in the slides, very similar to the way I write code, just copy and paste, throw it in there, and see if it works. And I found out that it's part of your culture of cleaning up after yourself and tidying up. And I'm actually coming from San Francisco. So, I live here. I work full time for GitHub.

We're based in San Francisco. I work from home, but I'm still within the Bay Area. And we have the opposite problem where we have trash everywhere. So, if you haven't been to San Francisco, and some people are nodding because they're literally have been there before. Trash, it's a big issue, especially in San Francisco. It's a systematic problem, like, hopefully we'll solve it someday. But until then, it's a big problem.

Yeah. We have trash and other things on the streets too as well, by the way. So, I'm just, like, curious of like, why part of the culture is this Japan have this non-issue of trash on the streets. And I looked at Japan to solve my issues because there's hope. And that hope comes in the form of this Netflix show. So, this is a perfect export to the States, like, hopefully, Marie Kondo, she lives in LA now, and she's doing the show.

And she wrote this book here about sparking joy and decluttering your house. And as Americans, we love collecting stuff. We love keeping lots of stuff in our house, almost too much stuff. I literally just moved last week, and I have a garage full of stuff. My garage is actually my office too, that's why I work from home. And I just had a bunch of random stuff.

I was collecting from conferences, all this beautiful swag. It lives in my garage. I just had not been able to distribute it properly into my lifestyle. But that is my lifestyle. That's me as American. So I found in that article that I was mentioning before, there's, like, this little line here that the reason that this is not an issue is because it's part of the culture. And the culture for Japan, excuse me for… and I learned, so if I'm wrong, please come and talk to me in the room and tell me this is not right.

But this is me, Googling, and finding out the culture is that essentially take care of your own mess. So, clean up your own space. And this is I thought was pretty relevant to some of the stuff we've done at GitHub for me and my DevRel team, and what we've done so far at GitHub. So, we'll get into more of that. Who's familiar with Marie Kondo? Okay, a good amount of us.

Okay. So, the Googling I did was whether or not it was actually valid because it's part of your culture. So, whether or not, like, some people in Japan, what I was reading, were, kind of like, why is that a thing in the States. It's a big thing in the States because we don't do cleaning up after ourselves. It's just not part of our lifestyle. And so, there's this whole thing in the beginning of every episode on the Netflix show, where you gather up all your stuff.

Let's start with clothes. And you pile all your clothes onto one pile and then you see exactly what you have. So you take inventory, exactly all the stuff that you have waste and that you don't need. And then you take each piece of clothing, and you address it, and say hello to it, and you thank it for its time. And if it doesn't spark joy, then you get rid of it. If it sparks joy, you keep it.

So, GitHub, we're been around for a lot of… 11 years. And we have a lot of users. We have a lot of stuff that's been around for a very long time. So me and my team, which I'll get into, we got to kind of go through and see what actually is working and what's not. But as developer relations and developer experience, and I know we have some product people, we have some engineers here, like, we should always be thinking about, like, "Is this necessary? Is this actually solving a problem?"

And are developers going to be potentially be happy using this feature or product? So, I keep saying GitHub, but I didn't introduce GitHub as well. So, just a show of hands, who knows what GitHub is? Okay, a good amount of us. So, I can sort of skip the marketing speech and you guys have already done my job for me.

But if you are familiar with GitHub, we're a small incubator inside of Microsoft. So yeah, we're just a, like, small company. We operate as a separate company and a small company. We're just really getting stuff started now, so I'm very excited to see our growth. Yeah. So, we have actually have an office pretty close to that tower. And I was at the office this week working on my slides.

And we have all these GitHub… So, all these computer-science books that reference Git and GitHub. And this was one of them that I saw, and was like, "Wow, I need to read this." Unfortunately, I don't speak Japanese or read Japanese. So, a lot of hovering my phone over there and translating. But if you're familiar with Git and GitHub, maybe you're coming here from a different background.

Git is a way for us to collaborate. Like, the developer tools, collaborate through remote async work. So, my closest teammate is in Amsterdam. Very rarely do we get on a meeting together. We do async conversations through PRs, and issues, and Git really helps and solves that for us because, we actually are working on a project together where we have to write code for it.

But there's no reason for me to be up early in the morning to match the Amsterdam time. Another thing we're known for also is stickers. So if you guys are interested, I've been placing stickers around. I'm trying to get rid of them because when you come in through customs in the States, they look like the Saran, actually it looks like glycerin. Like, depending on what airport you're in, it kind of looks like a bomb.

It's a concern, ship your stickers, don't put them in your luggage, especially Atlanta. If you go through Atlanta, Georgia, don't put your stickers in your check-in bag. Yeah. So let me introduce myself as well. I went through all that. I am self-proclaimed Beyoncé advocate. I'm a developer advocate, but I assume you guys know what that is.

So I tend to speak about the Bey. And I didn't know that the first talk was actually going to be all about bees because I always talk about Queen Bey. And if you aren't familiar with Beyoncé, she has the beehive. So, it's a formation. It's a super group of fans. And I joke and say that I'm queen bee of GitHub because GitHub has 31 million developers.

Now, whether other developers or product people or design, like, we have a lot of users. So I get to go to places like this, I go to events and community events in the region, and get to hear first hand of how people are using our product, and how people don't like our product or love our product. And I can kind of bring that back. So, my daily job is to say, "What would Bey do?" So if there's an issue, figure out what Beyoncé would do.

And it's pretty clear, Beyoncé would actually go to bat for the hive. So, if you guys aren't familiar with that, you see this music video, it's amazing. The entire album's amazing, so check out Lemonade. And what I mean by that is that I'm trying to get people onboarded to our developer platform.

So GitHub, we do take users. We sign up. We have 31 million of those, like, it would be great to have as many users as possible. But, there's some other features that we really want to focus on. So, we're trying to drive growth in certain areas, which are developer platform. And always keep this in mind, developers found your site for a reason. They came here to solve a problem.

So they're here to solve that problem with your stuff. So when you get on to GitHub's developer docs or developer guides, you should have a clear instance of what I'm supposed to be doing. So Cristiano, actually, he wrote this blog post. I told him last night, this comes up a lot, internally, at GitHub. So, thank you for doing our work for us for-free consulting. is what we got from him.

But all these problems in here, we've solved most of them. But like, it's a work in progress. So, this talk will actually follow this sort of pattern as far as, like, I'm going to go through messaging first touch. So, what happens when you first see or arrive to your product or your feature. Also going to talk to how fast to success people can get onto your platform or your tool.

And then finally, reference documentation as well. I also want to talk a little bit about Direct and Channel. This is like a sales thing, but I felt like it was a good, sort of, lens to talk through. So, when I talk about Direct stuff that GitHub is doing, we're going to talk about Channel, it's like our open source, and community, and what they're doing. So, moving along. And I'm going to skip the phone because it's a little laggy. Cool.

So, talking about messaging. So let's go over the Direct stuff. This is our front door. This is github.com. This is exactly what you would see. Some things that we want to, like, solve, as soon as you show up here is like, what is GitHub? Our issue is that we have a lot of experienced users.

A lot of people have been using Git for years. And then we have a lot of users that never heard of Git. So, we have to find that balance in between explaining Git but also explaining GitHub. So, we've had to choose to separate ourselves, not separate ourselves from Git, but go forward thinking and what our next 31 million users are going to be looking for.

So, off the bat you can find out it's here to host code, Ruby code, and work with a broad range of users around the world. Another thing that you probably want to solve is, like, what's it going to cost you? I'm a big fan of getting all the information up front. I did this workshop with freeCodeCamp, where I would go to boot camps and teach people how to build restaurant websites, because my biggest gripe against restaurant sites in the U.S., is that it's very hard to find the menu, it's very hard to find the phone number, and it's very hard to find just general information of that restaurant.

So very similar to your sites, you should also have that information ready and available for your users. So very clearly, GitHub, we put up this nice little box set. I'm on the fence as to whether you can actually see it. It's like on a light background and whether or not it's a button. You'll figure it out. Anyway, I'm not here to gripe about GitHub. I'll gripe about our API soon, but essentially, there's a call to action.

It's very clear. So talking about our channel, when I first learned how to code six years ago, my first interaction, with GitHub was not github.com. It was actually another site called trygithub.io. Managed, and owned, and operated by another company. And this was a training site that was out in the open that taught me how to use Git and GitHub, and that was my first exposure. So, there's always a lens that you have to kind of figure out how much do you want to do?

And how much do you want your community to do? And then on top of that, I know Matz was here talking about Ruby. My first intro was Ruby on Rails as well. So, my intro to GitHub was literally learning how to do Rails. And then eventually, you'll learn the Ruby. And it got me to the point where I got to the point to shipping stuff on Heroku. And Heroku is also interesting too as well because I remember, I had an older version of this. This was a talk I've done before. I rewrote a lot of slides this morning. But I had an older version of Heroku.

But it's funny because Heroku, I never actually saw the homepage for the longest time. My first interaction to Heroku was the COI command. So, I installed, I did some magic terminal stuff, and then my app was launched, and I had a URL associated to it, and I was happy. So just quick rundown of Channel. These are, like, stuff like frameworks, open source, etc., partnerships through other companies, tutorials, like, this is all stuff that we could sort of activate through our relationships at events like this.

And I'm a big fan of talking to people. I love talking. And I love seeing ways that we can get the product that I'm eventually talking about, out in the wild. So just want to mention that if you're working on a developer tool, or you have a developer portal, you'll need a channel to sort of get that out there because there's going to be a certain point where you can't be the only voice of that exact product so…So, in summary for that section is use the scripted copy, leverage your channel, and encourage users to return as well.

So, GitHub is more than just octocats. And I know we have a very strong brand as far as these nice characters. We have an entire team that makes these, that's their only job. And I think that's amazing. But we also have some other issues where we were very focused on our brand and focused on our community and solving our issues.

And a lot of open source developers actually created this Dear GitHub letter to create an organization on GitHub of all places, and could play on exactly what was wrong with GitHub. And as GitHub, as we would do, we asked what Bey would do. But the real question is, like, does this spark joy? And it didn't, because there was a bunch of issues that we couldn't get to, a lot of features that we couldn't just shift right away.

And I think a lot of, like, requests for features in my DMs and on GitHub as well. And it's very hard to address every single one of them. But I am a sounding board, I can point those into a new issue. I do create issues on GitHub for new features. So, let me know if there's a problem. But again, we can't solve every problem. So, when life gives you lemons, listen to Beyoncé's Lemonade.So, my focus is GitHub API.

And GitHub API, it's an interesting beast. It's been around for 11 years. GitHub has been around for 11 years. And it's been around so long that we have other people who have integrated their whole platform. So Heroku, Travis, and Circle, they all integrate directly onto our API. And we make that available to them. The only problem with this is that the majority of stuff that I learned from the API and a lot of these people, they learned from the person sitting next to them.

So, all that information has been transferred from other people on the team that they're working at. And then this is actually a screenshot of our developer docs. These developer docs are purely reference documentation. If you have a need and if you have something you're looking to get done, you just go Ctrl+Find and find exactly the information you're looking for. But that's a huge barrier of entry, especially if you're a new developer within GitHub. So, you can't always assume that your developers will just know exactly what they're doing. I gripe a lot on the blockchain space as well. That's a really horrible… Sorry, I don't want to be so harsh, but it's a hard program or platform to start developing code on, because it's so broad, there's a lot of back and forth, and it takes hours to actually get your entire environment set up.

So if you're in the blockchain space, there's a lot of opportunity to improve that developer experience. So, when you look at the GitHub API, it's like, "Why would you want to use the GitHub API? Does this spark joy?" And the question is, yes, it does. And the way we sort of pitched this in the last year since I've been there is, we had to give a reason for you to actually use this API.

We want more users to use the API. We handed everybody that we talked to had a reason. And our reason that we've sort of went out the gates with, as far as the DevRel team, is automating workflow. So everybody has got a GitHub workflow whether you open up a PR, and then you go into Slack, and you send that link to other people, and let them know, "Hey, my PR's ready." Like, that's a workflow, and that's something that you could solve and automate in the future.

And there's a lot of tools out there that have solved that problem. We're just helping build that awareness of you building that for you. And as I mentioned, identifying these repeated tasks, and then packaging it up into, essentially, a product or a story. And, I mentioned this before, things that you need to support API integration in GitHub is essentially one, the person next to you.

If they know more than you ask them. But in reality, this is all the stuff you need. So, you need to know about JWTs, authentication, know how to get a server up and running, if you need to talk to a webhook. Like, all this stuff, it's all stuff you'll find eventually if you dig deep enough into our documentation. But we found issues in that, because that was pretty messy. And we wanted to package this up into a way where we could say, "Hey, developer, here's an easy way to integrate with our API.Go ahead and run with it."

So, we had to solve that problem. We did that with our DevRel team. So Direct.. I'll mention Netlify really briefly. It's a company I used to work for. One thing I'm really proud about is that we got our deploy cycle. So when you first learn about Netlify it's seconds by the time you have a new app up and running.

And we did a lot of clever things with that. One of them being the restaurant template I did with freeCodeCamp. Excuse me. I'm just going to roll through. I know we're running through time. But this is, like, me go ahead and clicking through the signup process of Netlify. Netlify itself is a GitHub app.

So, they use the GitHub API. You go ahead and authenticate there. And then you go ahead and pick a repo. This is me, so I know exactly where to click. Making assumptions that you know what you're doing or why you're there. And hopefully, when you go to netlify.com, you figure out you need to pick a repo, ship the app, and then this looped over, but it's 25 seconds.

Twenty-five seconds to deploy a Netlify app. Now, imagine you took 90 seconds to read and understand exactly what that's like. We're talking minutes of shipping something, like, from the first instance of learning it. Now, with the GitHub API, that was not possible. You have all this reference material, but you want to ship something, but you don't really know where to start or where to begin.

So, we had to take inventory of all the stuff we had to do. So all that whole list that I was talking about with the authentication and all that stuff. And we essentially took it out and categorized it, and organized it in a way where we could bundle this up into, okay, if you want an automated workflow, we've got the one-click solution for you. And I'll show you how we got there. So, we sort of kind of segmented it out to, like, API, webhooks, and then authentication.

All those were the hardest problems trying to get up and running, and solving integrations with GitHub API's. And we call these GitHub Apps. So it's very similar to Slack apps, we just wanted to package this to make this a very easy solution for you. And part of our team, what we did, and this is, like, sort of outside of the range.

And, you'll find in DevRel that you tend to always step out of bounds of when you need to get stuff to ship. So we have an entire docs team, but we had a docs team to do reference API. And then we have engineers to automate the docs to sort of get it almost there, and the doc team sort of puts it over the goal line. We didn't have a lot of guides. Actually, we had zero guides on the developer docs for GitHub. So my colleague actually spent some time and wrote the first getting started GitHub Apps for GitHub on to our developer guides.

But the problem with that is that once he did that he, sort of, found out right off the bat that it was 15 steps from zero to actually shipping a GitHub app. So that's pretty much a no-go. Like, if you have to learn about JWTs and learn about all this other stuff, we had to go ahead and package this up.

So last summer, we actually created this workshop called the Craftwork. And the Craftwork basically takes that idea. And that's where we got most of our learning from, was in-person regional workshops, figuring out how that works. And the goal was eventually modeling all these other GitHub apps like Travis and Circle. We have these on GitHub marketplace. And, we wanted to solve that because GitHub Apps took too long.

So then, part of our channel is that we have an open-source project called Probot. And Probot itself, it essentially gives you that one COI. So, similar to Heroku, is to create Probot app. And you could actually have a Probot app and a GitHub app working right off the bat within your first finding this out. The problem is, is that we made a lot of assumptions that people knew JavaScript and Node.

So, we had to solve this in a little bit different kind of way. So, GitHub has the idea of cloning repos. If you're not familiar, definitely check out our guides or come find me later. So, we made a one-click installation for GitHub apps using Probot. And we built that using Glitch. So, with Glitch, it abstracts all the stuff that you need to know about code, and you do things called remixes.

And in our workshops, we actually remix a Glitch app. And all the stuff that you need to know about setting up servers and authentication and JWTs is all solved for you. And then we can focus on exactly what you can actually solve with APIs. Then we got to the good stuff really quickly. So, it would take seconds once you start the workshop to then have something to do. So we're currently working to make this content on the guides as well.

So it's a very recent change since the end of last year. And sort of like a summary here. And I'll, sort of, land this plane really soonly, or sorry, really quickly, that's English. We ended up getting to the point where we actually ship zero to 60 really quick. And it was almost an impossible lift for GitHub, because we had a lot of legacy craft.

And we had to sort of identify, "Okay. Well, we always did it this way.But we have all these new users that don't know anything about this, or that, or that. So, let's just package this up, and then talk about the good stuff.And then if they want to go back and figure out how the sausage is made, they can do that by actually digging deep into the code." But all of our code's open source, and our reference materials are out there, and available. So, I'm going to go ahead leave it at that because I think I'm actually out of time.

So I'll skip through. I do want to mention that there is a lab.github.com. There is an intro to building a GitHub app. And this is like, sort of, the first steps of getting that content out there. Simultaneously, our training team was building this as we were building our workshops, and we, kind of sort of, paired together very well. So, this was a great thing to have. And now, hopefully, we can pair this into our developer documentation as well.

Just to mention, my slides, I'll tweet them out. This is all just reference and, sort of like, "Hey, go find these links." I did also want to mention about the channel too as well. I just Googled when I'm on Japanese WiFi, I tend to always get Japanese content. So, it's cool to see that we have GraphQL, which is our next step is actually integrating GraphQL into this project.

But, we've already had that solved with local developers here. So, in summary, take care of your own mess. And sayonara. ♪ [music] ♪