Podcast: Break Things on Purpose | Steve Francia, Product and Strategy Lead at Google

Break Things on Purpose is a podcast for all-things Chaos Engineering. Check out our latest episode below.

‍

In this episode of the Break Things on Purpose podcast, we speak with Steve Francia, a Product and Strategy Lead at Google.

Episode Highlights

Transcript

Jason Yee: Hey, everyone. Welcome to Build Things On Purpose. Our slight deviation from the Break Things On Purpose podcast, where we talk with people that have made really cool things and we learn some tips from them about how we can make cool things as well, things that are reliable and that scale well. So joining us today we have Steve Francia.

Steve Francia: Hi.

Jason Yee: So Steve, tell us a little bit more about yourself. What do you do? Where do you work?

Steve Francia: So I work for Google as the product lead for the Go programming language. Previously, I worked at Docker and MongoDB in executive roles and have been involved in open source for 25 plus years. And I also was on the board of directors for the Drupal Association.

Origins of Hugo

Jason Yee: Nice. So just some background for our listeners. That's actually how I met Steve, through Drupal. He was my boss at MongoDB. But aside from Drupal, one day, Steve came up to me and said, "Hey, check out this thing that I built." And it turned out to be a thing that I think a lot of you might be using, a thing called Hugo. So Steve, tell us a little bit more about Hugo and why you built that.

Steve Francia: So back when I was at MongoDB, working with Jason, I was running developer experience, which was product engineering, DevRel, documentation, websites, and more; so anything that really our users interacted with. And part of that was creating and guiding our different language and integrations. I'm now working on Go, but back then I was a polyglot and we worked with about a dozen different languages. And interestingly, the need to integrate was what brought me to Drupal. We added some good support there. And as we look to extend our language base, we adopted Scala and Go as our last two when I was there. And I spent a few months learning Scala and then pivoted to Go and needed a project to work on there. And at the same time I was retooling my website, I realized I was spending more time doing WordPress security updates than I was blogging, and that maintenance cost was killing me.

So I thought I'm going to switch to a static site generator and tried Jekyll and a few of the others that existed at the time and really struggled with how much time it was taking to render my blog of a few hundred articles. And I thought there must be a faster way to do this. I was just beginning to play with Go. I'd spent maybe a couple of weeks with it and I thought, I bet Go is faster than Ruby. I bet I could write a static site generator a little faster. And I said to myself I don't want to write a markdown parser, so if they have one Go, I'll write the rest. And luckily here, I did a quick search and found a really good markdown parser and just started tinkering around with it and within a couple of weeks, I had something that was maybe, I don't know, 50 times faster than Jekyll.

And I thought, wow, Go is awesome. It's easy to write. You can get great performance out of it. And the birth of Hugo came out of that. And it's an interesting project. Speed was obviously a goal, but I also wanted to make it really easy to use and really flexible. I took a lot of things I'd learned from Drupal, put them into it, things I'd learned from WordPress, put it into it, things I'd learned from running documentation at Mongo DB, particularly with multi-lingual support, and put that into it. And then the open source community embraced it. And we got lots of contributions from all over the world and they were able to extend and polish and improve and really take Hugo further. And today it's much faster than it was then in the early days, which is amazing because we kept adding more features and usually you add features at the cost of speed or other costs. And in this case, so we were able to continue to keep it fast and even improve the speed. And partly, that was also aided from Go, which over its 15 releases, it just gets faster and faster and a lot of benefits to Go applications is a result of that.

Tips for learning Go

Jason Yee: Yeah. So I'm curious, as things have progressed, I'm sure a lot of that speed has come about too from just learning the way to do things. You started Hugo as a project to learn Go and obviously, when you do that, you do things in the way that you know of at the time, but then you learn better and you're like, oh, I should have done it in a certain way. I'm curious if you've got some tips on what are some of those things that new Go learners should think about?

Steve Francia: Yeah, it's a bit humbling to have your first project when you're learning language become the most popular, a very popular project, because all of your words and learning bumps are out there. That said, I'm not shy. I was learning the whole time. I made plenty of mistakes as I went. I would say there's a few things that I really benefited from and now from the purview of being on the core Go team and having a lot of experience from working with the creators of Go now for almost five years, my first advice is Go is simpler than you're used to. Don't fight that simplicity. Embrace it.

And then the second one, which it stems from that, which is everyone comes to go, most people, not everyone, now we have some first programmers using Go, but most people come from another language and they want to come in with their Java way of doing things, or the Python way of doing things, or the C++, or whatever it is way of doing things because that's what's in their mind, and Go as a pretty different language. It's not object oriented, it doesn't have exceptions, it has concurrency baked in. So there's some pretty fundamental shifts in Go. And the advice I give is try and learn the idiomatic way of doing things. And the best way to do that is look at the Go standard library. And the standard library is comprehensive and it's of excellent quality. It's very usable and it really shows you the Go way of doing things. And I think that's a great starting point.

In other places, look at other popular packages from well-known maintainers and authors. Between that, you should be able to figure out really the Go standard way of doing things. And of course, I didn't have the benefit of this, but now, we actually launched a website just about a year ago called learn.go.dev, and there's a ton of great learning resources from online courses to tutorials, interactive to books. So it's a great starting point for people new to Go.

Patrick Higgins: I'm curious, Steve, did your perception or thoughts about the language shift much when you started working very closely with the people who wrote it?

Steve Francia: It's a good question. Did they shift much? Honestly, it was an interesting evolution. To go from a community member to a core team member is just a really interesting shift, and I can't say that they changed all that much. I already was very impressed with Go and the things they did. Working with them more closely deepened that. So I wouldn't say it shifted it, but I do find myself just incredibly lucky to be working with the Go team. I'm a bit older. I remember the '92 dream team for the Olympic basketball team and it was all the best players. And there was this one time in history where this blip came where you just had this magical moment. And I kind of think of that as the Go team. I knew if I didn't join it, I would have regretted it the rest of my life, to be able to rub shoulders with the luminaries that created so much of what we consider is modern computing. So if anything, I was already in awe of them, and then sitting next to them and seeing it in person, actually doesn't happen often, but that impressed me even more. I felt even more humbled to be working with them.

Open source and contributors

Jason Yee: I'm curious similarly. Has going from being a community member and participating in open source to now being a core member and really running the language and the program and the evolution of it, has that changed your perspective on open source and how people get involved?

Steve Francia: I think we're all learning what open source is more and more over time. And I don't know that that transition happened, but certainly being in the role I'm in has opened my eyes a lot. I'd say the biggest thing I learned is, I started my career actually in mostly web based open source things. And there's a unique property about web based things is that they can change regularly. Sometimes in our general broad developer community, we joke about, oh did you know JavaScript framework four months ago? Don't worry, there's a brand new one, because it's kind of constantly evolving. And when you're close to the surface, you can do that without much pain. But with the language, that's as low as you can really get. It's amazing how much more thought you have to take into what you're doing.

And so I remember as part of Drupal and other communities, it was about getting a big contributor base and more engagement and energy and excitement around it. And with Go, it helped me understand the maintenance taxes that come from that and that our maintainers have refined their skills over decades. And not that we don't want contributions, we very much do, but we also know that there's a cost of reviewing, there's a cost of interacting, and that distracts them from being able to do these things. So with Go, the approach is we don't want to change much. We actually want to change as little as possible and in a way that keeps stability and a good experience for our users.

And for me, that was kind of a new way of thinking. And it was a new way to think about open source and how do you create a good contributor community when the default answer is no? And it's no a high, high percentage of the time. And I kind of struggled with that a bit and I know a lot of our contributors do because it's such a shift. And one thing that helped me with it was to recognize, as a Go team member, the bar was even higher. We actually get told no even more than the community. And so many of our good ideas that we think are good end up on the cutting room floor, so to speak. So I think that was an interesting challenge of how do you figure out how to do that? And we tried a variety of things and some stuck and now Go is actually more contributions from outside than inside the core team. But that was a slow process that evolved over a decade to get there.

Jason Yee: I think that's fantastic insight. I mean, thinking of this podcast and talking to builders and talking about building reliable systems and applications, that idea of having that default to no and just ensuring that your core is of high quality and is reliable. And that oftentimes does mean you say no to a lot of things, but also balancing that with that contributor experience and ensuring that people have the right guidance and the right experience and are still part of that community despite being told no.

Cool. Well, thanks for being on the show with us. It's been a pleasure to chat with you. Usually before we go, we give people a chance to do any sort of plugs if you've got any pluggables, things that you want people to check out.

Steve Francia: I could give some just general things. It's not like I'm in a movie or anything exciting coming up. For those of you interested in Go, check out go.dev. We've got some great learning resources. We've also got some great case studies from major companies like American Express and PayPal and Google who've adopted Go and how it's been transformative to them. And then you can always check me out at spf13.com. We're on GitHub/spf13. And on Twitter, I'm everywhere at spf13, so just check me out. I'm excited to talk to you.

Jason Yee: Cool. Well, thanks again.

No items found.