Library Podcasts

Ep. #6, Style Guides at Airbnb

Guests: Harrison Shoff

In the sixth episode of JAMstack Radio, Netlify’s Brian Douglas and Cassandra Salisbury are joined by Airbnb Design Engineer Harrison Shoff for a discussion on linters, what makes for a good style guide and why they are so important for growing engineering teams.

About the Guests

Harrison Shoff has been Design Engineer for Airbnb since 2010 where he helped build developer-based projects including Shoff currently works on the People & Culture team where he uses technology to strengthen employee connections throughout the Airbnb workplace.



Brian Douglas: Welcome to another episode of JAMstack Radio. Today in the room, we've got Cassandra.

Cassandra Salisbury: Hey.

Brian: And we've got Harrison Shoff, software engineer at Airbnb.

Harrison Shoff: That's right.

Brian: Cool. I think I emailed you or maybe hit you on Twitter, I don't remember which one it was. But yeah, I randomly saw that you had a lot of contributions to the Airbnb style guide, for the JavaScript one.

Harrison: Yeah.

Brian: I wanted to have you on to talk about that. But before we jump into that, you've got a pretty interesting story of how you got into actual engineering. Can you briefly share with the audience how you got into engineering?

Harrison: Sure, yeah. Quick story here. I grew up as more of a designer. I spent a lot of time in Photoshop and Illustrator and I ended up going to school, trying to figure out what I wanted to study.

Took about three years or so, much longer than my parents probably wanted me to take, and I hopped into electrical engineering because it's fun to build things. It's kind of like an adult Legos kind of thing. I did zero research into what life was going to be like after graduating with a degree in electrical engineering.

Brian: Like most of us do.

Harrison: I was very confused when I reached my senior year. I was finishing my project and it was time to go interview and check out jobs. It was like, "Oh man, this isn't really what I wanted to do." So after I graduated, I ran out of money pretty quick, moved back in with my parents. They wanted me to find a job, so I started as a valet at a hotel up in Seattle, WA, and that's a quick way to motivate yourself to get a different job, because I thought I would have a career.

It's not a bad job. It was a great job, but I just was looking for something else to do. So I started picking up web design, taking the designs I had, trying to put them on websites. Learned HTML and JavaScript, that kind of thing. I just started picking apart different websites, things that I thought were interesting and cool. I started teaching myself how to do all this stuff.

Slowly, over the course of a couple months, I felt pretty good about it and thought it was time to start interviewing at companies. I was too scared to go and try to apply to a big company. I was like, "There is no way Facebook would have me, or Google would have me, or Amazon." I'm not that kind of person. So I was like, "I should find a startup like a small, little company that would be willing for me to do anything," even though it was just picking up the garbage or something like that.

Brian: You mean like write CSS? Just kidding.

Harrison: And so I picked up a magazine, I think it was Ink Magazine's "Top 30 Under 30." I was like, "What are these people doing that I'm not doing?" And that's where I discovered Airbnb. Two designers and an engineer started this company. I was like, "That's crazy. I didn't know designers could start companies." Reading up on them, learning about what those guys were doing and how they're working. I felt drawn to it I guess and here I am today.

Brian: I use the Airbnb style guide, which is part of the reason why I knew where to look to find you. But every project I've started or used, it always included the plugin, the ESLint plugin for the Airbnb style guide. Can you explain how Airbnb's format for writing JavaScript became so popular with ESLint? How did that connect? And when did it get started?

Harrison: It's kind of like a two-pronged process here. There's really two types of people, engineers, let's call them, that deal with these kind of things. There's a person like me who doesn't really have a preference about how they write code. If you want me to not use semicolons, that's totally fine. I know how to do that. If you want me to match up my brackets, that's cool too. I don't really have a preference. It's like, just tell me what you need and I'll do it.

And then there are people that really prefer and have strong preferences about how they write JavaScript, to the point where they'll spend time changing your code to match the way that they want to do it. And they're generally not too happy rewriting someone else's code to make it the way they want. And so, how you make both those people happy? Well, you make a style guide.

You figure out what your consensus is on what those rules are for everyone, and so those are the rules for the game. And then you bring in a referee, which is the linter. So you have two pieces there.

You need a style guide and then you need someone to enforce the style guide to make it real.

When we first started the project back in 2012, one of the first commits we ended up adding was a SublimeLinter plugin that actually enforced some of these rules. Not everyone had it on, but eventually more and more people started to see the benefits. So it was a very casual, organic method that we started adding it.

Then in the big move to ES6, when we did that, that's when we started looking into ESLint. We had other linters in there as well, but ESLint was taking off really quickly for a number of reasons unrelated to us, but they had this nice plugin feature where you could write your own rules, say which ones to enforce, which ones you didn't want to enforce, and that was exactly what we were looking for. And the rest was history there.

Brian: At the time, I remember JSHint was pretty big with ES5. But I know it wasn't as customizable, so I think that's probably the reason why ESLint, as you mentioned, picked up speed. I come from the same background, where I didn't have a professional upbringing into writing code. I learned as whoever taught me could teach me, and I was pretty impartial to semicolons or having to write my functions either anonymous or with names, and all that kind of stuff.

My start in JavaScript wasn't until last summer and it was during my learning ES6 by converting some CoffeeScript to ES6. One of the things that I actually found very helpful with having a style guide was to get me the bumpers to be able to understand, " I don't know how to write perfect JavaScript, but if this linter is going to force me to write it properly, then it makes my job so much easier to learn how to do JavaScript." If I just completely mess up on syntax or don't reassign a variable or something like that, the linter is going to tell me.

Cassandra, I know you have more experience with the Go community. With Go, they have the format tool. How much experience have you had with coding?

Cassandra: Ooh, not much experience with coding.

Brian: Not much. But the one thing that I really like about Go is that they have one way to do it, and the format tool actually forces you. So there's no discussion in your PRs about, "Hey, you should really not write semicolons here," or, "Hey, you should really not use Oxford commas," or anything like that in your program. There's a big conversation about tabs verses spaces, which I don't even know if there's really a conversation.

Harrison: World war.

Brian: Yeah.

You don't need to get in an actual religious war about whether or not to use tabs or spaces or whether or not to use semicolons.

Because you're going to say, "Hey, linter is king around here, so if you don't like it, send the PR to the linter." Which is awesome.

Harrison: Oh yeah, I mean, that's the whole thing, is that a pull request should be focused on the code and what it's trying to do: What feature are you adding? What are you changing? Let's talk about what's actually happening in the process and not doing this nitpicking stuff that a computer can do for you. That's the big benefit now. Code reviews are better and faster because you're not dealing with other things. And that's the beauty of having a linter around.

Brian: Yeah, and it can really get down to the nitty gritty about actually writing challenging code that actually works properly, because you're not focused around Johnny engineer or whatever, or Samantha engineer, whoever. Equal opportunity. But we don't have to worry about someone complaining about, like you said, something so silly as where you put your commas or how you structure your arrays, which is awesome.

With that being said, why is the Airbnb style guide so popular? Why is their plugin for ESLint so popular out of all the other ones that are out there? Was there a blog post that happened or something?

Harrison: No, I mean, it really just happened organically. The community just picked up on it and started using it. I'm surprised myself, to be honest. We have been very responsive to the community when they open pull requests, when they send requests or want to talk about what different portions of our rules are and how they work. And I think people have just been responsive to the fact that we have been so responsive and supportive and we want to learn together. We want to bring the whole community up and not just ourselves.

Cassandra: Did it fall in line with the actual business growth? Did you notice that, as the business grew, the style guide got more popular?

Harrison: Definitely. I think doing more to promote the engineering brand at Airbnb definitely helped. A lot of people didn't know that we were so serious about JavaScript. I think that was the big thing. Our thinking behind JavaScript helped a lot of people understand some of the problems we're tackling and how we're tackling them.

Brian: There's not just the style guide, there's the JavaScript side, there's also the CSS side, which also is very helpful. Because similar to JavaScript, CSS, I know you didn't start this, but CSS, it's also very hard to get rules around how to write good CSS. And CSS, more than JavaScript, can get really a big ball of mess.

Harrison: It can get out there quick, yeah.

Brian: Yeah, for sure. So just to have all those decisions about, "I don't know if we should use them versus whatever," whatever is out there. To me, honestly, I'm not as advanced in my CSS because I've always just used whatever style guide is already in there. So whatever it tells me to write and how I should structure my code that way, I just do that so I don't have to think about how to organize them.

I can just think about how to make things purple where it needs to be purple.

Harrison: Oh great, I mean, that's the way to do it, right?

Brian: Yeah.

Harrison: Big shout out to Mike Fowler who wrote the original CSS guide and SCSS. We use Sass as well, so we have both in there. Kind of off tangentially on that one, was that he just started it one day, just realized we didn't have one, "Why didn't we have one?" We were doing all this thing for JavaScript for a number of years and then he just opened a pull request for the new CSS guide, and that's how it evolved. That's how it starts.

Cassandra: Is that three style guides that Airbnb has?

Harrison: The JavaScript one is in its own repo, and then CSS and SCSS are in a separate repo as well. But also in the JavaScript one, we combined React and JSX. You can find it in there, how we write React at Airbnb. And then you can also find a Ruby style guide. We're a Ruby on Rails shop, as well as some Java services as well, so we have style guides for those as well.

Cassandra: So you got style guides down. I'm curious from an outsider's perspective, from you writing the actual or starting style guides and you using style guides, what makes a great style guide?

Harrison: That's a good question.

Brian: ESlint has this plugin system where you can have different pre-made plugins or basically these packages have pre-made all the styling rules. So you don't have to, me as an engineer, I don't have to think about every single situation of how we should write our code. I can just import Airbnb's ESLint plugin, and then all the decisions are made for me.

So anyway, I can get a project up and running with little effort and just get down to the code, of writing the code. Me personally, that's what makes a good style guide for me. I don't know, Harrison, if you have something to add on it. I mean, since you started this. We haven't touched on it. But a reason for...

Harrison: Happy to go more into it.

Brian: There were definitely complaints about whether or not certain things should be written.

Harrison: As your team and projects grow, your code base is just getting bigger and bigger and bigger. And at that point, contact switching gets really expensive, depending on how many people are changing projects or moving into a different code base. And for us, the way you make that less expensive to switch contacts so often, is to

make it seem like every piece of code in your code base was written by you.

So make it feel familiar when you open that file. That way, when you jump into a new project, maybe it's been around for four or five years or something like that, and you feel right at home. It's not something that was written very drastically different, jQuery spaghetti style or in an old, deprecated ES5 style that we're not doing anymore. Making it feel very familiar when you jump in. That's the big point there. It makes it easy for all engineers.

Brian: I'm sure you guys have, internally at Airbnb, you don't just have entire mono repo. You apply it to multiple projects.

Harrison: The main site is a mono repo.

Brian: Oh, is it?

Harrison: Yeah, and then it's talking with a bunch of services as well.

Brian: Are the services also JavaScript, or you guys use something else?

Harrison: We do have some JavaScript services, but we have a lot of Java services and then some other Ruby on Rails services.

Brian: I imagine if someone were to go from Ruby on Rails, and then they get a feature maybe, I'm not sure how you guys separate your teams, but if they have to jump in and do a little bit of front end or tease it around, they have that contact switch for going from Ruby on Rails to JavaScript.

I don't know if a lot of people realize, but it actually is a big jump because JavaScript is written differently. So if you keep writing your JavaScript code like Ruby, and you push it to a pull request and then someone has to review that, that's pretty painful to have to keep going back and forth to fix it.

Harrison: Absolutely. That's the easy way I end up with global variables and things changing all the time. You're like, "What's going on?" That's how JavaScript works.

Brian: You also touched on, you guys use a little bit of React as well, and you also do a really good job with style guides there, too. React is really popular about they don't have many conventions.

So, since you guys now are using a React style guide, the way you write React in your project or whatever project or whatever component inside this repo, you don't have to worry about whether if you, Harrison, write it wrong or whether Samantha engineer writes it wrong. It's going to be written the right way based on this fallback, which is your linter and your style guide.

Harrison: Absolutely. I mean, in these frameworks and systems that don't really have conventions or aren't built that way, you want to have them when you're on a big team working together. We fell into that trap with Backbone a long time ago, of not having conventions, and everyone just did it a little differently. So we took those lessons and when we started using React and started moving off of Backbone into React for reviews and all that. We wanted to make sure we have the conventions before we started having everyone writing React right off the bat.

Brian: Yeah, that's awesome.

Harrison: I was also going to add that, when you do have the conventions, it makes it much easier to go and modify those conventions over time. Because you know it's always written the same way from before. Check out a project or a blog post on codemods by Joe Lencioni on the Airbnb blog. He wrote about how we transitioned from ECMAScript 5 to ES6 and the process we went through to do that.

By having it all written one way, in a similar style, made it very easy to go find where that style happened and then convert it using code mods into ES6 style. That's how we did that and upgrading, transitioning an old code base into a more updated one.

Brian: Awesome. So, you've been at Airbnb for five years now?

Harrison: Coming up on six.

Brian: The team's obviously not a startup anymore. It's probably a pretty well-sized team. So you've probably seen engineers come and go in the past almost six years. How is it getting new engineers or specifically JavaScript engineers on the team? Do they find it challenging to learn your way of JavaScript?

Harrison: Oh, we hope not. We think by having it open source already, people will have maybe checked it out before they started working at Airbnb. But if not, that's totally cool as well. What we do is we have a boot camp, so when you're a new hire, you show up, you go through a boot camp, two-week boot camp, where we introduce you to how we write JavaScript, what our stack is and how it all works.

That's how people get onboarded really quick. They graduate from this boot camp, they join their team, and they're ready to go, because they feel confident and understand how it all works and how we do things. It's not new to them.

Cassandra: That's awesome. Where did that idea come from?

Harrison: I believe that started at Facebook. It was the model where it came from, and it's been working to great success for our company.

Cassandra: How long have you guys been doing that?

Harrison: A couple of years now, maybe two years, one and a half years. I think we've probably had 300 engineers go through boot camp, something like that, quite a bit.

Brian: How big is the Airbnb engineering team?

Harrison: It's big now, biggish. I don't know the exact numbers, I'm sorry.

Brian: Airbnb is like what, over 500?

Harrison: Yes, over 500.

Brian: Wow, and are you guys distributed throughout the world, or US?

Harrison: We have, let's see, 22 offices, something like that. We have probably five main offices around the world. Three of them, we're doing engineering work in. So we have the San Francisco office, Portland office and the Seattle office. So we're all on the same time zone right now, and that's just an easier way to do distributed engineering work for now. We'll see what happens later on.

Brian: Honestly, I'm not really sure how far our reach is as far as audience. I mean, we're pretty a new podcast, but I'm pretty sure that someone out there hasn't heard of Airbnb.

Harrison: Oh, yeah.

Brian: If they haven't, I highly recommend it. I used it when I first moved here to the city.

Cassandra: I have used it many times traveling, and it's great and the customer service is phenomenal.

Brian: I haven't had to use the customer service yet.

Cassandra: Unfortunately I did with one particular host, but the response was great.

Brian: Yeah, I've seen some blog posts on Medium and stuff about Airbnb's customer service and how responsive they are, which is awesome. Well, we do have a portion of the podcast where we go into picks. I like to call these "jams" for obvious reasons.

Harrison: That actually reminds me. I was listening to the first podcast and I realized we're bringing gifts.

Cassandra: We've got some jam.

Harrison: Along with the jam, I got maple syrup.

Cassandra: Jam and maple syrup.

Brian: Wow, awesome. We still have the jam from the first podcast in the office. I don't know if you've even noticed that.

Cassandra: I did. I didn't know where it was from, and now that I know, I'm going to be trying a bacon jam from the first episode soon. So maybe I'll report back how that was. It looks like we have fresh strawberry jam from Trader Joe's.

Harrison: That's right, yeah.

Cassandra: I'm liking that.

Brian: And we have maple syrup, which I don't understand.

Harrison: It's delicious.

Cassandra: That's just encouraging us to make waffles in the office.

Brian: Ooh, that sounds good. Chris, if you're listening, we want a waffle maker and we want a waffle maker employee too. Because that way we don't mess up the waffles.

Cassandra: Yeah.

Brian: Very cool. I didn't even ask you, before we jump into that JAMstack, we have in the intro of the show we explain what it is. But what is your opinion of JAMstack? It's a term that we're trying to push as a podcast. Have you heard of the term before?

Harrison: Before this podcast I had not. But it's a familiar concept. I'm glad it has a name now.

Brian: Yeah. We do get a lot of push-back because JAMstack is basically marketing. But what we have trouble in trying to explain all these websites that are focused on the front end, so we did have the term "static." Static was so limited. Now we have websites that can do pretty awesome stuff in JavaScript like React on a front-end React site, is actually JAMstack.

Though you guys use Ruby on Rails, your front-end portion, actually, is technically part of the JAMstack. So anything that has JavaScript, an API, which is your Rails server, and then anything that uses markups, so ERB or if you use JSX or whatever. Me and Cassandra are actually working at Netlify, so we host JAMstack websites. So that's what the term is. We're just trying to spread the jam.

Harrison: Spread the jam.

Brian: Obviously you're helping us by bringing some jams.

Harrison: I love strawberry.

Brian: But I did ask you to think of something that gets you going, something that you're excited about, you're willing to share with the actual community and the listenership. So, you do have any jams, Harrison?

Harrison: I've got a couple jams. I'm going to start with the first jam. Since we're talking about style guides, I'm highly, highly going to recommend this book called "If Hemingway Wrote JavaScript" by Angus Croll. It's a beautiful way to understand that there are many ways to express different ideas, and he does it in a very, very great way, and the illustrations are wonderful. Angus Croll.

Brian: I've never heard of it.

Harrison: Great book. You've got to check it out. He also has a great blog on JavaScript as well. It's where I did a lot of my initial readings on JavaScript, and learning from it, so shout out to Angus Croll for putting together some great work and a beautiful book. On shelves now.

Other jams from me right now, on the music side, it's from Aesop Rock. It's called "The Impossible Kid," which came out a couple months ago. I think it's album of the year, for me personally, but I'm a huge Aesop Rock fan, so that probably sways it a little bit. I can keep going. I got other things.

Brian: If you've got them, spread them.

Harrison: I would highly recommend if you're a startup, if you're a company, if you just work in this field, to go through unconscious bias training. We went through it ourselves at Airbnb. All employees, when you go through boot camp, you go through unconscious bias training as well.

Brian: Sorry, what's unconscious bias?

Harrison: It's these suggestions that you might not know you have that influence, maybe decisions or things that you're doing that you didn't realize you were doing. In our industry, you can see things like in interviewing, hiring, conversation, performance reviews, meetings, all of these things,

unconscious bias can come into it and have an effect on that. The more you're aware of it and talk about it, the better.

So I recommend unconscious bias training to everyone.

Brian: Very cool. I actually have a jam. My first jam is actually going to be Kanye West. I didn't pick him for the first episode, but I did a podcast about Kanye West. I want to pick Kanye West and "The Life of Pablo." I actually got a chance to finally listen to it shortly after the first podcast, and I actually enjoyed it and I liked Kanye West's style. I like his music.

His personality is... I don't know, it's borderline, whether or not I like it or not. But he is a guy who came from a nobody who was making beats for Jay-Z back in the day to becoming an actual rapper that people actually, a common name in most households. So he's got that going for him. And he also has this new album going for him which actually is really good. It's a big transition from what he's done in the past.

He's also collaborated with a lot of different people, so I highly recommend checking it out. It's on Spotify, which is part of the reason why I now can listen to it, because I don't do Tidal or Apple Music. But check it out, "Life of Pablo," Kanye West. I tend to mention him in all my meetup talks. I didn't do it at the SF Rails, but I did to it last night at the Ruby SF.rb, and most of the conference talks, I'll do a Kanye West reference.

I do have another pick, KineticJS is coming up next month in October. Hopefully by that time, the podcast will be out. If not, we will have a recording on YouTube, and I am going to be speaking at it about making designers happy with React. I'm looking forward to that. With it being in the Dirty South, I'm probably going to have some Dirty South references as well as Kanye West references, so be on the lookout.

I also have another jam, which is The Get Down. It's a Netflix Original Series which is about hip hop in the Bronx. I'm familiar with hip hop in Atlanta and hip hop in New York, but specifically in the Bronx, I don't know anything about it. It's like late '70s, early '80s hip hop and how it got up and running and started. So this is like Grandmaster Flash, turntables, break dancing. It's basically watching the phase of disco end and hip hop start in the Bronx, which is pretty awesome. I can't actually make a jam of Jaden Smith's acting, because he's an actor in it, but if you can get past his acting, it's actually a pretty good show.

Harrison: I've got to check that out. I haven't seen that yet.

Brian: Cool. Cassandra, I look to you for finishing up our jams. Again, anything you want to jam about: music, beverages, food.

Cassandra: I do love food. I had some really good pupusas yesterday, but I don't remember the name of the restaurant in the mission.

Harrison: What is a pupusa?

Cassandra: It's like a flour and corn masa, so it's almost like a tortilla but not. Stuffed with beans, cheese and pork, and then you eat it with a cabbage-coleslaw deliciousness and salsa, and it is pretty awesome, if you have not tried pupusas. They even had a t-shirt that said "I love pupusas."

Brian: That would be awkward if I saw that shirt, because I know what a pupusa is now because I moved to SF, in the Bay Area. But outside of living here, I've never heard of it. I've had one in my entire life and yeah, I can attest, they're actually pretty good. But yeah, if I saw a shirt before I moved here that said "I love pupusas," I'd be like, "I don't know..."

Cassandra: The funny thing is, I'm not the biggest pupusa fan. I've grew up with them, just not the biggest fan. However, this particular place, they did this thing with the cheese where it melted out and just burnt on the bottom and I love burnt cheese. It's like that piece on the lasagna that you just want to eat it off. It's my favorite part of lasagna as well, the burnt part. I think that's what sold it for me, was the burnt, crispy cheese.

However, my jams other than the pupusteria which I can't remember the name of, I started reading a book that I think I'm really late to the game on. But I'm in love with it so far. It's Snow Crash by Neal Stephenson, and I don't know if either of you have read that, but I am a huge Ender's Game fan, the entire series by Orson Scott Card, and this book was suggested to me.

I guess it's maybe in the future or set in a different time than we are with a lot of sci-fi and fantasy tendencies, and it starts off with The Deliverator who is this pizza delivery guy, and he has to take his job very seriously. If his pizza is late, he will die.

Yeah I know, that was my face too when someone described it to me, a look of "What?!" But it's been great so far. I'm a few chapters in, and so I'll let you guys know how it goes. Another jam, if you haven't watched Stranger Things on Netflix, it was pretty freaking awesome. I have finished it and I'm really sad that it's over.

Harrison: But it's being renewed for a second season already.

Cassandra: Which, yeah, of course it is because it was amazing. I jumped, I got teary eyed. It was the whole nine yards with my emotions.

Brian: Awesome. Well, that concludes the entire podcast. I'm going to wrap it up there. Harrison, I really appreciate you coming all the way from Airbnb, which is down the street.

Harrison: Just down the street. Thank you so much for having me.

Brian: Awesome. And then if anybody wants to find the style guide or find you on the internet, how can we find both of those things?

Harrison: Of course. So, on the internet, point your machine to That'll take you to the style guide and link you to all of our other style guides. You can check out all of Airbnb's open-source work at And check us out, our blog is on Medium, or @airbnbeng. I think they do it that style. And then you can find me on Twitter, @hshoff. It's spelled hshoff though, H-S-H-O-F-F. It's been happening my entire life.

Brian: Well, Harrison, thanks again and continue to spread the jam.

Harrison: Jam it up.

Want developer focused content in your inbox?

Join our mailing list to receive the latest Library updates. After subscribing, tell us your preferences to receive only the email you want.

Thanks for subscribing, check your inbox to confirm and choose preferences!

You've been here a while...

Are you learning something? Share it with your friends!