Airbnb Engineering http://nerds.airbnb.com Nerds Thu, 18 Dec 2014 20:03:10 +0000 en-US hourly 1 http://wordpress.org/?v=3.8.5 Payments at Airbnb http://nerds.airbnb.com/payments-airbnb/ http://nerds.airbnb.com/payments-airbnb/#comments Wed, 17 Dec 2014 20:29:18 +0000 http://nerds.airbnb.com/?p=176594675 Talk Abstract Payments at Airbnb is challenging because it operates at the core of a global marketplace to create trust. No single solution exists to meet our needs. Going global involves supporting multiple currencies and payment methods but it also involves nuanced complexities that are unique to local markets. It’s very common for our problems […]

The post Payments at Airbnb appeared first on Airbnb Engineering.

]]>
Talk Abstract

Payments at Airbnb is challenging because it operates at the core of a global marketplace to create trust. No single solution exists to meet our needs. Going global involves supporting multiple currencies and payment methods but it also involves nuanced complexities that are unique to local markets. It’s very common for our problems to cross different domains such as product, compliance, growth, finance, and engineering infrastructure. Airbnb’s two-sided marketplace includes guests and hosts who introduce two different payment problems: collecting and distributing money. Our payments platform also supports other activities in the marketplace such as photographers, translators, trip services, and more in the future.

We’ll talk about building end-to-end systems (upstream and downstream) that process billions of dollars in a reliable and scalable way. Want to know how to change tires while driving in a production environment that has significant money flow? Want to know how to confidently sprint instead of walk with code on a frequent basis? As a result of Airbnb’s rapid growth, its Payments platform has evolved quite a bit and we’d like to talk about it while also providing concrete tips based on our experience.

Speaker Bio

Ian Logan is an Engineering Manager at Airbnb. He joined Airbnb over 3 and a half years ago as the first payments engineer, bringing his experience working in investment banking at BlackRock, Barclays Global Investors, and Morgan Stanley to a new problem of payments in the sharing economy. During his time at Airbnb, Ian worked on all aspects of core payments technology and built its original foundation. Currently, Ian leads the engineering teams responsible for Payments, Trust & Safety, and Internal Products at Airbnb.

The post Payments at Airbnb appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/payments-airbnb/feed/ 0
Meet the Nerds: Eric Levine http://nerds.airbnb.com/meet-nerds-eric-levine/ http://nerds.airbnb.com/meet-nerds-eric-levine/#comments Wed, 17 Dec 2014 15:32:28 +0000 http://nerds.airbnb.com/?p=176594660 Howdy, Eric Levine! Eric is an engineering manager on our Trust and Safety team. Eric tells us about keeping bad guys at bay and going for swims in a Turkish bay (okay, just a pool, but sounded better to say bay). How did you get started in Computer Science? My path toward computer science started […]

The post Meet the Nerds: Eric Levine appeared first on Airbnb Engineering.

]]>

Howdy, Eric Levine! Eric is an engineering manager on our Trust and Safety team. Eric tells us about keeping bad guys at bay and going for swims in a Turkish bay (okay, just a pool, but sounded better to say bay).

How did you get started in Computer Science?

My path toward computer science started when my brother and mentor Matthew came home from university and decided that he wanted to teach his kid brother how to write some code. He taught me the basics and helped me pick out a book to continue my development. I just ran with it from there, and by the time I finished high school I was running an online game with about a dozen regular users.

What was your path to Airbnb?

My path to Airbnb was a long one, starting in 2008. I received an email from a recruiter who worked at YouTube at the time who asked if I was interested in an internship. That internship definitely changed the course of my professional career in a very positive way. Fast forward four years, and that same recruiter from my YouTube days, reached out to me about a position at Airbnb. Due to the previous encounter, I knew I could trust her, and Airbnb seemed pretty amazing from the outside. I was working at Google at the time and decided that I didn’t think the skills I was accruing were as portable as I was hoping they’d be. You don’t take a lot of Google’s infrastructure with you when you leave and I wanted to be more versatile in my skill set. Airbnb was the perfect fit and it has been one of the best decisions I’ve made.

What’s the most interesting technical challenge you’ve worked on since joining?

The most interesting technical challenge that I’ve worked on since joining has definitely been our machine learning-based risk detection systems. My colleagues Naseem Hakim and Aaron Keys wrote up a great blog post describing some of the systems that I’ve worked on, and the next iterations are definitely taking it to the next level.

What do you want to work on next?

We’re hoping to start thinking more about Verified ID and how we can do even more with that. While it’s been a great start, we can start to apply our learnings from other areas and try to apply it to identity to better understand the users of the platform. Further, we have a ton of awesome work planned to improve our systems to further help protect the community.

What is your favorite core value, and how do you live it?

My favorite core value is Embrace the Adventure. The way I interpret this core value is a recognition that perfection is an impossible ideal and that one should try to “roll with the punches” when faced with undefined situations. We try to apply that in our engineering culture by encouraging people to fix things that are broken and to really take ownership of our product. It’s this core value and the way we apply it that makes Airbnb so unique.

What’s your favorite Airbnb experience?

My favorite Airbnb experience was with a couple in a Kirazli, a small village in Turkey. The space itself was absolutely stunning, beautifully designed and the perfect fit for our stay. Every morning I’d wake up to the village’s morning call to prayer. After lazily awakening, I’d go for a quick swim before the hosts would treat me to a traditional Turkish breakfast. The hosts would then take me for a walk through the hills to pick fresh figs off the trees. The whole experience was just extraordinarily pleasant and inspiring.

 

The post Meet the Nerds: Eric Levine appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/meet-nerds-eric-levine/feed/ 0
Decentralized Payments with Bitcoin http://nerds.airbnb.com/decentralized-payments-bitcoin/ http://nerds.airbnb.com/decentralized-payments-bitcoin/#comments Wed, 10 Dec 2014 18:54:33 +0000 http://nerds.airbnb.com/?p=176594641 Talk Abstract So you’ve heard of Bitcoin, a global digital currency with an avid following, and a wildly fluctuating price. But the real power of Bitcoin stems from its underlying decentralized ledger, the blockchain. In this talk, Adrian will take a deep dive into the blockchain, and look at how transactions are generated and broadcast […]

The post Decentralized Payments with Bitcoin appeared first on Airbnb Engineering.

]]>
Talk Abstract

So you’ve heard of Bitcoin, a global digital currency with an avid following, and a wildly fluctuating price. But the real power of Bitcoin stems from its underlying decentralized ledger, the blockchain.

In this talk, Adrian will take a deep dive into the blockchain, and look at how transactions are generated and broadcast in a completely trustless peer-to-peer network. He will discuss what role miners play in this network, and whether the blockchain network could exist independent of the Bitcoin currency. Finally, he will look at some of the potential future applications of Bitcoin and the blockchain, including sidechains and decentralized asset tracking.

Speaker Bio

Adrian Macneil is Director of Engineering at Coinbase, the largest bitcoin company in the world. Originally from New Zealand, Adrian has previously been involved with several e-commerce and payments startups, and has seen first hand the difficulties faced by companies looking to innovate using the current financial networks. Adrian moved to the US in early 2014, and has since helped Coinbase grow from 5 to 20 engineers, and launch in 19 countries and 22 languages. In his spare time, Adrian can be found traveling, snowboarding, and spreading the word of bitcoin.

The post Decentralized Payments with Bitcoin appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/decentralized-payments-bitcoin/feed/ 0
Randomness and Fraud http://nerds.airbnb.com/randomness-fraud-2/ http://nerds.airbnb.com/randomness-fraud-2/#comments Wed, 03 Dec 2014 23:25:49 +0000 http://nerds.airbnb.com/?p=176594604 Talk Abstract Over the course of three years, we’ve built Stripe from scratch and scaled it to process billions of dollars a year in transaction volume by making it easy for merchants to get set up and start accepting payments. While the vast majority of the transactions we process are legitimate, Stripe does need to […]

The post Randomness and Fraud appeared first on Airbnb Engineering.

]]>
Talk Abstract

Over the course of three years, we’ve built Stripe from scratch and scaled it to process billions of dollars a year in transaction volume by making it easy for merchants to get set up and start accepting payments. While the vast majority of the transactions we process are legitimate, Stripe does need to protect its merchants and itself from rogue individuals and groups seeking to “test” or “cash” stolen credit cards. In this talk, I’ll discuss the two types of fraud Stripe faces—merchant fraud and transaction fraud—and how our approach to both has evolved over time. I’ll then demonstrate how “randomness” helps us combat fraud in the three stages of the model-building process. Specifically, I’ll focus on how fraud often appears less random than legitimate behavior (feature generation), how our in-house, distributed random forest learner allows us to build models on huge data sets with more control over how the random splits are made (model training), and how the introduction of randomness in the production scoring environment allows us to reason about counterfactuals (“what would have happened if we hadn’t intervened?”) and evaluate candidate models without production experiments (model evaluation).

Speaker Bio

Michael Manapat is a Software Engineer on Stripe’s Machine Learning team. He was previously a Software Engineer at Google, a Postdoctoral Fellow in and Lecturer on Applied Mathematics at Harvard, and a graduate student in mathematics at MIT.

The post Randomness and Fraud appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/randomness-fraud-2/feed/ 1
SDK Mindset http://nerds.airbnb.com/sdk-mindset/ http://nerds.airbnb.com/sdk-mindset/#comments Wed, 03 Dec 2014 23:25:30 +0000 http://nerds.airbnb.com/?p=176594599 Talk Abstract Writing software is difficult. Bugs happen. Users find weakness and hit them with their mallets repeatedly. Complexity hides and exponentiates with every new feature. When developing SDKs—that is, code we write to run in others’ systems—these problems are critical and acute. We will talk about a number of scenarios we’ve encountered to highlight […]

The post SDK Mindset appeared first on Airbnb Engineering.

]]>
Talk Abstract

Writing software is difficult. Bugs happen. Users find weakness and hit them with their mallets repeatedly. Complexity hides and exponentiates with every new feature. When developing SDKs—that is, code we write to run in others’ systems—these problems are critical and acute. We will talk about a number of scenarios we’ve encountered to highlight the difficulties of building and shipping SDKs: backwards compatibility, flexibility, abstraction, understandability, shippability, adoption, beta partners, communication, etc.

Speaker Bios

Ben Mills is a software developer who works on the Braintree SDKs primarialy on the back-end.

Mickey Reiss is an iOS developer who works on Braintree’s iOS SDK. Braintree is a payments company who’s goal is to provide developers with a foundation to build applications on.

The post SDK Mindset appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/sdk-mindset/feed/ 0
The Future of App Deployment http://nerds.airbnb.com/future-app-deployment/ http://nerds.airbnb.com/future-app-deployment/#comments Wed, 03 Dec 2014 23:25:07 +0000 http://nerds.airbnb.com/?p=176594596 Talk Abstract Writing an app is one thing, deploying it to a production ready environment and keeping it online in the face of countless potential scenarios of adversity is an entirely different beast. Not only does it currently still involve a fair bit of expertise when it comes to unix-fu, it also involves keeping an […]

The post The Future of App Deployment appeared first on Airbnb Engineering.

]]>
Talk Abstract

Writing an app is one thing, deploying it to a production ready environment and keeping it online in the face of countless potential scenarios of adversity is an entirely different beast. Not only does it currently still involve a fair bit of expertise when it comes to unix-fu, it also involves keeping an eye out on the latest software and configure them properly to combat things like security breaches. This is all generally considered tedious and cumbersome work, and often outside the domain of knowledge of developers. Wouldn’t it be great if we didn’t need to go through as many hoops as we need to do today and make it more developer friendly?

This talk will go over the most important steps currently involved in setting up a production environment for your a web app and will propose alternative approaches as well in the form of new software solutions developed by Phusion. This talk will focus on app deployment, monitoring and server provisioning, but will also touch upon topics such as UI design and UX as the latter plays an important part in making things more accessible. More specifically, we’ll discuss Docker, Polymer, Node, Rails, Phusion Passenger, Union Station and much more.

Speaker Bios

Hongli Lai is the co-founder and CTO of Phusion. His work involves all layers of an application stack. Be it from Phusion Passenger for deployment, to tinkering on Docker baseimage, his work has helped deploy hundreds of thousands of sites.

Tinco Andringa is a full stack software engineer at Phusion. During his time at Phusion he has built Ruby on Rails applications for clients and he is now leading development work on Phusion’s new monitoring solution Union Station. When he is not building Ruby web apps he works on open source software and tinkers on video games.

Goffert van Gool is a Full-Stack Engineer at Phusion, where he works on modern web applications, and high-availability services. He is often experimenting with new technology and how it can be used to improve application architecture.

The post The Future of App Deployment appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/future-app-deployment/feed/ 0
Feature Engineering for Real-Time Fraud Detection http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/ http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/#comments Wed, 03 Dec 2014 23:24:44 +0000 http://nerds.airbnb.com/?p=176594588 Talk Abstract This talk will explore some of the joys and pitfalls of applying machine learning to Internet activity. It’ll focus on the process that Sift Science uses to develop features for its realtime fraud detection service, covering some of the specific evaluation and modeling problems that are unique to this kind of data. Speaker […]

The post Feature Engineering for Real-Time Fraud Detection appeared first on Airbnb Engineering.

]]>
Talk Abstract

This talk will explore some of the joys and pitfalls of applying machine learning to Internet activity. It’ll focus on the process that Sift Science uses to develop features for its realtime fraud detection service, covering some of the specific evaluation and modeling problems that are unique to this kind of data.

Speaker Bio

Doug Beeferman is a software engineer at Sift Science, formerly at Google and Lycos. His focus throughout his career has been applications that analyze logs of user activity such as search and web logs. He is also interested in text and speech processing.

View the slides here.

The post Feature Engineering for Real-Time Fraud Detection appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/feed/ 0
Meet the Nerds: Carol Leung http://nerds.airbnb.com/meet-the-nerds-carol-leung/ http://nerds.airbnb.com/meet-the-nerds-carol-leung/#comments Mon, 24 Nov 2014 06:03:25 +0000 http://nerds.airbnb.com/?p=176594578 Welcome to our second installment in our series that peeks behind the curtain of Airbnb’s engineering team. Today, say hello to Carol Leung, an Engineer on our mobile team working on our Android app. Carol shares with us her experiences from founding her own photography start-up in Hong Kong to making the Airbnb mobile app […]

The post Meet the Nerds: Carol Leung appeared first on Airbnb Engineering.

]]>
Welcome to our second installment in our series that peeks behind the curtain of Airbnb’s engineering team. Today, say hello to Carol Leung, an Engineer on our mobile team working on our Android app. Carol shares with us her experiences from founding her own photography start-up in Hong Kong to making the Airbnb mobile app seamless to use.

How did you get started in Computer Science?

My high school started offering a computer science class in my sophomore year. I was curious and took the intro and follow-up CS classes. I was fascinated by how applicable CS is to so many things in our daily life. I was inspired to build a program that simplified the process of matching students with their interests for our annual “Diversity Day.” The experience of being able to build a solution to a real problem set me on the path to become a software engineer.

What was your path to Airbnb?

I love travel and immersing myself in different cultures. I have lived and worked as an engineer in different parts of the world: building algorithmic trading systems at Goldman Sachs Tokyo, co-founding my own digital photography software startup in Hong Kong, leading a mobile development team at XtremeLabs (now Pivotal) in Toronto, and building an iOS and Android app from the ground up for a small social network startup after I moved back to San Francisco. My love of travel (and software development) lead me to Airbnb. I love that I can use my passion for traveling to help shape a product that enriches other people’s journeys.

What’s the most interesting technical challenge you’ve worked on since joining?

Guests have traditionally felt more comfortable browsing and searching for listings on the web than on mobile. It’s my mission to change that perception by creating an outstanding guest experience on mobile. The challenge is creating a seamless, cohesive user experience across a variety of complex features in the app: Wish Lists, optimized search and filtering, embedded maps in the listing feed, listing navigation flows in map search. My teammates and I strive to hide that complexity from users and make the experience intuitive and “just work.”

What do you want to work on next?

I think we can go beyond helping guests find their ideal place. We can empower them to plan, build and experience the trips of their dreams. I want to build a mobile experience that would allow guests to enjoy a delightful journey from when they first start thinking about their trip. Searching, planning, and booking should be frictionless, delightful, and personalizable. We want users to be able to easily collect and compare listings they browse across different devices, make collaboration with friends and families on group trips fun, and surface recommendations based on users’ previous searches and location to inspire more meaningful trips.

141118_CarolLeung_NerdBlog0059

What is your favorite core value, and how do you live it?

“Every frame matters!” As a mobile engineer, I look at every UI element on every screen with a critical lens. I constantly ask myself: is this iconography clear? Does this animation feel natural? Are the widgets user-friendly? Does this navigation and transition make sense? Does this screen provide enough context while being pleasant to use? These questions often lead to great discussions with my teammates: engineers, designers, and product managers. “Every frame matters,” is also a starting point when we create technical designs and review code. This detailed-oriented attitude allows us to constantly improve code quality and structure of the app. It also yields world class products.

What’s your favorite Airbnb experience?

While I’ve enjoyed Airbnb in large cities like New York, Barcelona and Tokyo, my favorite was a lovely, cozy listing in Sonoma with my boyfriend and his family. The host thoughtfully wrote down great recommendations of local restaurants and vineyards on their cute, colorful kitchen chalkboard, and left us a fruit basket and a complimentary bottle of wine as welcome gift. I still remember the delicious smell from their spacious, beautiful garden growing fresh tomatoes and herbs. We had a blast relaxing and playing croquet and horseshoes in their backyard at night, a perfect way to end our wine country trip.

The post Meet the Nerds: Carol Leung appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/meet-the-nerds-carol-leung/feed/ 2
Maintaining Quality at Scale http://nerds.airbnb.com/maintaining-quality-scale/ http://nerds.airbnb.com/maintaining-quality-scale/#comments Tue, 18 Nov 2014 17:04:43 +0000 http://nerds.airbnb.com/?p=176594528 When I joined Airbnb in the fall of 2012 things were a little chaotic to say the least. At some point in the preceding year the growth of the company had kicked into high gear, or hyper-growth, as some call it. Along with the increase in site traffic and transaction volume, the engineering team also […]

The post Maintaining Quality at Scale appeared first on Airbnb Engineering.

]]>
When I joined Airbnb in the fall of 2012 things were a little chaotic to say the least. At some point in the preceding year the growth of the company had kicked into high gear, or hyper-growth, as some call it. Along with the increase in site traffic and transaction volume, the engineering team also expanded very rapidly. When I arrived we were a team of about 40, compared to 16 one year before (and over 130 today). Looking back now, I think we were in the midst of a make-or-break period in Airbnb’s history.

Growing a website and engineering team as quickly as Airbnb presents both technical and cultural challenges, and in many cases those challenges are intertwined. In the old days, we were struggling with many issues, but broadly those issues were related to scaling a monolithic Ruby on Rails application (which wasn’t built with scaling in mind) and scaling the engineering team in a way that facilitated the former.

Today, I think it’s fair to say that we’ve overcome the existential challenges we faced back then. This is not to say we don’t have numerous new challenges and hard work ahead of us, but we survived the kick into hyper-growth without tearing apart. There are a lot of different things we can look back on, but in this post I’d like to focus on how we have transitioned to writing code in a more maintainable (and thus scalable way).

I work on the Payments Team at Airbnb. For us, code quality, robustness, and maintainability are of the utmost importance. With the amount of transactions flowing through our system these days, we literally can’t afford even small mistakes. Over the past year, we’ve put a lot of work into figuring out how our team can continue to iterate quickly while still producing quality code and avoiding technical debt. The three things that I think have been most helpful at this level are forming and adhering to specific code style and conventions, practicing a comprehensive and collaborative peer review process, and testing.

Code Conformity

Code conformity relates both to syntactic/textual style and to applying conventions and best practices when writing code. It has been said many times before, but if you have a codebase where you can open up a file and tell which person on your team wrote it, that’s a very bad sign. Formulating a standard way of writing code and getting everyone on board has been highly beneficial for us.

Computer code is generally consumed by two classes of entities, machines and humans. Machines generally don’t care about what your code looks like (assuming it compiles), but humans on your team probably do. Having a wide variety of styles and approaches to similar problems in your codebase will create unnecessary cognitive load for everyone, and eat up a lot of time as people attempt to grok new terrain. On the other hand, if everyone on the team is writing code in a more-or-less identical manner, everyone on the team should be able to grok, debug, and/or maintain one another’s code with close to the same level of effort (once they get through the initial ramp-up). Put another way, it’s important to favor the human reader, not the machine, when crafting your code, and it’s even more important to be consistent. This is not to say you should chose an O(N) solution over an O(1) solution for readability or simplicity’s sake, but there are many steps you can take to facilitate your fellow humans through code conformity.

We’ve achieved better code conformity in two ways. The first is the use of style guides (of which we’ve created several of note). Our most detailed guides cover JavaScript and Ruby, however we also have internal guides for RSpec, API design, service design, etc. Although these guides grew from our specific experience, some of them are now public and utilized by other individuals and organizations (who then often contribute back). Depending on the type of application you’re working on, they may or may not be useful for you, but if you work with JavaScript or Ruby, I’d encourage you to check them out, if for no other reason than inspiration.

Some style rules we’ve settled on are completely arbitrary. Take for example indentation characters (tabs vs. spaces), or which line the opening brace goes on. It’s hard to argue for one over the other in cases like these. The important thing is settling on something and then having everyone stick to it. On the other hand, some seemingly simple rules can have vast ramifications.

Consider line length. We like to keep lines short and sweet. Shorter lines are not only more friendly to other engineers’ eyes (and editors), but they also tend to result in cleaner, simpler statements (especially when paired with descriptive variable names). Methods that consist of a series of short, simple statements are easier for other team members to comprehend and modify. Diffs (in version control tools such as Git) also end up showing more clearly what behavior was changed between commits. And, since we’re also writing testable code (see “Testing” below) which promotes small, concise methods, you start to develop a very clean, modular, and easy to understand codebase.

Consider this example:

usernames = Users.where(:status => 1, :deleted => false).map{ |u| u.first_name.downcase }.reject{ |n| n == ‘john’ }.map{ |n| n.titleize }

Imagine we wanted to tweak the behavior of this line but switching from downcase to upcase. The diff would end up looking something like this:

- usernames = Users.where(:status => 1, :deleted => false).map{ |u| u.first_name.downcase }.reject{ |n| n == ‘john’ }.map{ |n| n.titleize }
+ usernames = Users.where(:status => 1, :deleted => false).map{ |u| u.first_name.upcase }.reject{ |n| n == ‘JOHN’ }.map{ |n| n.titleize }

It’s hard to tell which part changed without parsing the line in your head. Had the code been written more like this:

users = Users.where(:status => 1, :deleted => false)
usernames = users.
map{ |user| user.first_name.downcase }.
reject{ |name| name == ‘john’ }.
map{ |name| name.titleize }

The diff would also be much cleaner, showing exactly what behavior changed:

users = Users.where(:status => 1, :deleted => false)
usernames = users.
- map{ |user| user.first_name.downcase }.
- reject{ |name| name == ‘john’ }.
+ map{ |user| user.first_name.upcase }.
+ reject{ |name| name == ‘JOHN’ }.
map{ |name| name.titleize }

The funny thing is that those of us who started promoting this faced a good deal of pushback in the beginning. Like testing, however, we were persistent and we’ve gotten to a place where this has become second nature. To see some extreme examples of this mentality, I suggest checking out the Joint Strike Fighter C++ coding guide or the JPL C Coding guide. Obviously these standards are overkill for most consumer web applications, but always keep in mind what type of application and goals you have when settling on rules. It’s about picking the right balance.

As mentioned before, we’ve also begun to create style guides for higher-level concepts such as API and service design. Although prescribing how to build things like this can be a bit more of a gray area, it’s been incredibly useful to consolidate the collective knowledge of the team into single resources that are easy to digest. When coupled with a peer review process and a collective insistence on conforming, we’ve eliminated a lot of pain points and needlessly repeating conversations.

Peer Review

Another way we have been able to achieve more consistent code is by having a comprehensive and collaborative code review process. Code reviews come with many benefits. The obvious case that comes to mind is a colleague catching a horrible bug before it goes out and brings the site down. But there are many more subtle benefits. Over the past year or so, we’ve instituted code reviews for every change and we like to see at least one other person to sign off on each diff before it goes out.

Having just one other person sign off, however, is the bare minimum. We encourage everyone who has context to get involved, and most non-trivial pull requests have at least one or two substantive conversations pop up. Sometimes these can get pretty deep and some of us end up learning something we didn’t know about (credit card processing, database internals, and cryptography come to mind). If there are big insights we are also sure to record those in the relevant guide/documentation. Most importantly, there is no authority in code reviews based on seniority or title. Everyone’s input is valid and yet best practices always tend to prevail and new team members tend to learn quickly.

It’s important to remember that just because a style guide exists doesn’t mean that it will always be followed (or even read) or that it addresses every case. Peer reviews are what really help people get on the same page. They are also an effective way to learn and teach the art of programming itself, which can’t be as easily captured in pre-written material. In addition, having an environment where people learn a lot on the job helps keep them engaged and boosts the quality of their work.

As an illustration of something that might not belong in a style guide because it falls more into the wisdom category, take this example.

us_users = User.active.select{ |u| ‘US’ == u.country }
puts “There are #{us_users.length} US users today”

vs.

us_users = User.active.where(:country => ‘US’)
puts “There are #{us_users.count} US users today”

We used to run into a lot of examples like the first one in our codebase. While they both output the same thing, the first example is far more expensive, and at scale could actually cause a catastrophe. Adding select to the User.active proxy object means that Rails will go to MySQL, fetch every active user, instantiate them, put them into an array, then iterate through that array and select the users with country equals ‘US’. All this just to get the count.

In the second example, we start with the same proxy object, Users.active, but then we use where to filter on that object. The first line does not trigger any DB queries! On the next line, when we ask for the count instead, Rails knows to just do a SELECT COUNT(*) query, and not bother fetching any rows or instantiating any models.

Knowing the language and framework well is very important, along with spreading that knowledge to everyone involved. We have been diligent at Airbnb about fixing these types of common mistakes and promoting the best practice of pushing work to the DB when it makes sense. Take another example. How much did we pay out today?

Bad:

amount = Payout.
where(:successful => true).
where(‘DATE(timestamp) = ?’, Date.today).
inject(0) { |sum, p| sum += p.amount }

Good:

amount = Payout.
where(:successful => true).
where(‘DATE(timestamp) = ?’, Date.today).
sum(:amount)

The first example could be worse, we do at least narrow the scope to a single day, but it still causes a large number of payout objects to get fetched and instantiated, just to sum a numeric field. In the second example, we have MySQL do the summing during the lookup and just return the number we care about. This comes at essentially no extra cost to MySQL yet we avoid both unnecessary network traffic and a potentially vast amount of processing in Ruby.

So one benefit to having a healthy review process is to formulate and teach conventions and best practices that will benefit everyone. These seemingly trivial examples make our site more responsive (and can even prevent it from going down). Things like this also might have the side effect of striking up conversations about database internals or financial reporting. The thing about this kind of knowledge is that it’s shared and it would be hard to consolidate it into a single resource (and expect everyone to read that resource). It gets introduced by new team members, or veterans who have been bitten, and then passed down through the generations. It can only live on, however, if there is an active, healthy dialog surrounding the production of code. Personally, I feel as though the rate at which I’m learning in this environment is much greater than in previous positions I’ve held where code reviews and quality weren’t taken as seriously.

Testing

I’m not going to go too deep into testing in this post because my colleague Lou recently published an excellent post of his own on this blog. What I will say though, and I don’t think I’m saying anything new, is that I believe testing is extremely important to writing quality, maintainable code. However, it’s not just about raw coverage. It’s about creating culture in which testing becomes second nature to everyone on the team. When writing tests becomes second nature, writing testable code becomes second nature. At this point you really start to see dividends.

Conclusion

So concluding this little overview, I’ll summarize the three main topics again. Code conformity. On a professional team of any size, it’s important for everyone to write code the same way. This helps spread good practices and makes maintaining other peoples’ code much easier. Style guides are a great starting point. Even seemingly simple style choices can impact code quality, robustness, and ease of refactoring. Active, healthy review process. Above maybe all else, it’s important to foster an active and healthy review process. At least one person besides the author should look at each diff, and suggestions should be gladly given and welcomed by team members of any level. This helps spread wisdom. It helps newer team members learn and develop good habits. It helps more senior members teach and stay honest. Ultimately it can keep your application from failing spectacularly. Testing. It’s important to have a strong testing ethic, and not to compromise or take shortcuts. The more we test, the more second nature it becomes, and we might eventually even learn to love it. It doesn’t have to start by decree, but can grow organically in a few spots until it begins sprouting up everywhere.

The post Maintaining Quality at Scale appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/maintaining-quality-scale/feed/ 2
Meet the Nerds: Scott Raymond http://nerds.airbnb.com/meet-nerds-scott-raymond/ http://nerds.airbnb.com/meet-nerds-scott-raymond/#comments Wed, 12 Nov 2014 00:26:15 +0000 http://nerds.airbnb.com/?p=176594518 We’re starting up (or restarting depending on how you look at it) a series that looks at life inside the Airbnb engineering team and introduces you to some of our engineers. In this first installment, Engineering Manager, Scott Raymond talks about his early days in computer science, transitioning from founding Gowalla to working on the […]

The post Meet the Nerds: Scott Raymond appeared first on Airbnb Engineering.

]]>

We’re starting up (or restarting depending on how you look at it) a series that looks at life inside the Airbnb engineering team and introduces you to some of our engineers. In this first installment, Engineering Manager, Scott Raymond talks about his early days in computer science, transitioning from founding Gowalla to working on the mobile apps at Airbnb, and of course his favorite Airbnb experience.

How did you get started in Computer Science?

My first rudimentary childhood programming was in BASIC, on a Commodore VIC-20, a hand-me-down from my uncle. The only storage was on cassette tape. A little later, I got access to a Mac SE/30 with HyperCard, and things really got rolling, making games and graphics programs. Eventually we got a modem, which allowed me to connect with the wider world of programming. In college, I actually studied Linguistics instead of comp sci — and every once in a while, I get the chance to apply that training in my work.

What was your path to Airbnb?

In 2007, I co-founded a company called Gowalla, whose mission was to to get people out exploring the world. The app was like a digital passport that you could fill with stamps — unique illustrations from thousands of places around the world. We were acquired by Facebook. After some time, I got to know a few folks here at Airbnb, and became enchanted by the product. It’s been really cool to pick up on some of the themes from Gowalla, especially connecting people with unique places.

What’s the most interesting technical challenge you’ve worked on since joining?

We are constantly looking for ways to improve the core experience (like performance and stability), running experiments to make the marketplace efficient, and building new features to make travel better. The hard part is doing all three at once. We spent a lot of time this year working on tools and processes that allow us to iterate really quickly, without letting quality slip. For one example, see my co-worker Zane’s recent post about our project to redesign Airbnb for iOS.

What do you want to work on next?

Right now, we’re thinking a lot about how people move between devices. They might use their tablet to browse listings, and their computer to book, and their phone to communicate with their host. I think we can make the seams in that experience much smoother. If we’re successful, the logistics of travel fade into the background, so that people can focus on the joy of travelling.

What is your favorite core value, and how do you live it?

Easy: “Be a Host”. I actually think about this all the time, even when planning how to code a feature in our app. There are all kinds of things that can go wrong with technology, especially when you’re travelling — you might be on a flaky network, run out of space on your phone, whatever. Like a great Airbnb host, our app can try to anticipate needs and deal with snafus graciously.

What’s your favorite Airbnb experience?

I recently took a great trip with my wife and 3-year-old daughter to Paris and Amsterdam. Our listing in Amsterdam was this delightful place on a canal, with the steepest staircase I’ve ever seen. We woke up in the morning and the street outside had transformed into a massive bustling Saturday market.

 

 

The post Meet the Nerds: Scott Raymond appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/meet-nerds-scott-raymond/feed/ 2