 Cool. All right. How's it going? My name's Austin. I'm a software engineer at Facebook. I've been at Facebook for almost three years now, full time, interned twice. So it feels like I've been at Facebook for almost five years, but really three. And today I'm actually going to talk to you guys about a hack that I did over four years ago at Facebook as an intern. I'm going to talk a little bit about the hack itself and that process. But actually, my main point of giving this talk to you guys is talking about some of the lessons that were first ingrained in me during that hack that I didn't really realize at the time were so important. But now, four years later, as a full time software developer at Facebook, these are things that I've seen time and time again on different teams that I've been on that have made me a better engineer, or that I've seen reflected in really good engineers at Facebook. So I just wanted to share the story and then share those learnings, and that's what this talks about. It's called 72 Hours to Launch Celebrate Pride. So the background is on June 26, 2015, the US Supreme Court ruled in favor of same-sex marriage. This was a really big deal in the US. Everyone was kind of holding their breath. It ended up being a 5-4 decision in the Supreme Court. And on that same day, Facebook launched this pride filter overlay. And it's just a simple overlay, but it also showed the world that it kind of supported this movement. It just supported this decision. It was giving people a tool, the power to kind of express that feeling as well. So clearly, this must have been like a very well-planned launch by Facebook to take a stance. But actually, it was a week before, it was an idea that I had as I was deciding whether or not to go to this intern hackathon. And I ended up going to the hackathon, mainly for the food, so it's always good at these events to have food. More people will show up. And yeah, it was the week before Pride Week in San Francisco. So it's a huge thing in San Francisco where they have this Pride Parade. A bunch of people at Facebook get really excited about it. They have flags, rainbow flags hanging all around campus. So I knew I wanted to do something for that. And I had a lot of coworkers that I wanted to build for. I actually wasn't thinking really large here. I was just kind of thinking of how can I do something small so that my coworkers, they're going to celebrate this next week. Hopefully, I can build something that they can use. So yeah, that's where I came up with this idea for the profile picture overlay. Just put a rainbow on your profile picture. And yeah, so I looked in the code. I was an intern, so naturally I just found some code that pretty much did the same thing. Or at least changed, content your profile picture, and I just changed it. I just copy pasted it and made it into a rainbow. And that was it. So I left the hackathon early. And I was like, yeah, I'm done. I didn't even tell anyone about it. I was just like, yeah, I'm done with the weekend, so I went home. So the next week, I shared it with my colleagues, and they told me to post in this internal group. We have this internal group called Facebook Global Social. Basically, all the employees are in this group. You can kind of just post in there. And so I did. I posted this link to this internal tool. I built just a button. And if you pressed it, I'd say with a 60% chance it would work, and actually then go change your profile picture. But over 1,000 employees used it on the first day. And that was really exciting. I felt like mission was accomplished. Like this is something I built, and my coworkers are using it. So yeah, this is the post. And then I was kind of done. I was like, OK, now I can go back to my normal intern project, like a good intern. So the next day, this guy comes by my desk. And he just says, are you the one that built the thing? And I say, yeah. He said, OK, wait right here. I'll be back. And I didn't know who he was at the time. It turns out he's the head of growth at Facebook. So I should have known. I should have been more attentive. But he came back, and he brought an engineering manager. He brought a designer. He brought one or two engineers. And he said, this is the team. You guys are going to stop what you're doing. You're going to go ship this by the end of the week externally. So that was really cool. That was really exciting. We immediately went into a room. And I mean, again, I was an intern. I really didn't know what was going on. I was just very happy they were still including me. And I didn't tell them I copy and pasted everything. And yeah, but it was amazing to see in that first hour in this meeting room, really how efficient these engineers, this designer, this manager could be. And kind of laying out what was going to be done for the next 72 hours. I don't even think for the next 72 hours we really met again. Like that's how well-planned it was. And everything was new to me. I mean, things like, I knew we had to make it external and probably had to fix the fact that didn't work all the time. But besides that, I didn't know that we had to make it work on mobile, on different browsers, get it translated into 50-plus languages, and do a lot of things. So it was a huge learning experience in a very short amount of time. So that's what this next talk is kind of about. Not those next 72 hours, because I think it was kind of like a team grind. Not much to say about that. But some of the lessons I learned along the way, as we were trying to launch, that I still think back on today and I still see reflected in day-to-day life as a software engineer at Facebook. So the first one is readoff. This is something that you definitely come across in school, or in interview questions. You have to make a trade-off between A and B. And this one has a faster runtime. This one has faster space complexity. But in the real world, it's different. It's real. Nothing is perfect. There's no perfect answer. And you're always really making a choice between several options. And even choices, even things that you see that are built today, are not always the best option. It's useful to go look at things that are existing today, existing solutions, and to think if they could be built better. Maybe you can go test it. You can run an A-B test by refactoring something, by changing something. So that was the lesson I learned here. The actual example in this hackathon was in this landing page. So the designer said, OK, it can't just be a button anymore. We have to make it more exciting and actually usable. So the landing page he designed was it'll actually show you your profile picture with the rainbow overlay when you land on it, which makes sense. It'll show you what you're basically about to change your profile picture to. Now, to do that, there's a couple options. There's a few options. And the two main ones here are you can either do this server side. Like the actual changing of the profile picture, when you click submit, it does its server side. It goes to server. It'll fetch your profile picture. It'll go pixel by pixel and try to compute what that pixel's new value should be. And we actually tinkered a lot with that to make it still work with these edge cases. If your photo is really dark or really light, to make it still work well. So that was a lot of computation plus the server call. So you can either do that and get pixel for pixel what it's going to look like. Or you could do this other thing, which was just layer some CSS on top of it to make it basically take a CSS semi-transparent layer, put it on top of your current profile picture, which we've already kind of fetched and cached usually, and give you instantaneously something that looks 90% of the way there. Like probably what it's going to look like on your profile picture, maybe not pixel for pixel. And that's what we ended up going with. And I think at the time that was the right decision. If you, like when we started looking at the data when people started using this, a lot of the time spent, like the waiting time was due to this server operation, because people are using it all over the world with bad connections. And so this ability to make this decision, I think probably, we didn't run it as an A-B test, I don't know for sure, but I think it actually helped more people use this at the end of the day. So that's the takeaway here, which I still use today is that these trade-offs are opportunities. They're opportunities to make a good decision. And even things that you see that are built today, they're not done deals. They were built by a human being at some point in time. So maybe you can find ways to build them better. The next thing I learned is about growth hacking. I didn't really know what this meant at all, but when I got to Facebook, I was on the growth team at Facebook. And the growth team at Facebook is kind of like notorious for just being really good at growing things. Actually, the way it used to work is, it might still work, is it's just this team, they're not working on like any one product. They're just really good at growth. And it's like things that need to grow kind of like come into this team. So it's almost like this organization is a data structure in itself, and it's just really efficient at growing things. So when Instagram first came on board, it's just like they got put into the growth machine. Anyway, I digress. But these people that I was working with as well were from the growth team. And the problem they were trying to solve was like, OK, we're going to launch this, but how do we actually get people to use it? And especially if we're launching it on the day of the SCOTUS decision, how do we get the word out there? So of course, you could run some ads maybe, or you could try to get like Zuck to do it like that, which he ended up doing. But I thought this organic piece, which is kind of the virality, the idea they came up with, is like you just, and probably the best thing we did was put the link to the thing inside the post. So anyone that changed their profile picture, their description by default would be a link to the tool that would use the tool. So basically, if one person uses it, then all of their friends are seeing this link. And so you kind of have this kind of exponential network effect. And as soon as celebrities start using it, then it'll just be present in front of millions of people. So this was a lesson I learned is about kind of this organic growth-hacking. It's super important, actually, I think. Like anytime you guys go build something, getting people to use it, even if it's not user-facing, even if it's like internal-facing, you're building a platform, you're trying to get clients to use your platform, like selling the thing, making it grow organically. Getting people on board is a super important lesson. And this was just kind of like the part of it that I learned during that hackathon. The next major lesson I learned is about how important domain knowledge is. And this is definitely something I've seen a lot more after a few years of full-time work, is basically the people that have spent active time acquiring knowledge, even when it's not related to their direct day-to-day work, something that they need to get done. The people who are spending extra cycles, reading a lot, both internally and external documentation, talking with people, networking, are usually the most effective engineers after some period of time. It's like learning a language where on day one, it's not like a linear thing. It's kind of like the more tools that you have. It's kind of exponential in the amount of problems that you can go tackle. So the one related to this hackathon was we were kind of very tight on this timeline to get it out before Friday when the decision was coming out. And we finished all the code about Thursday night at like 11 p.m. And at this time, we have at least on like Facebook's web tier has daily pushes. So just because you write the code doesn't mean it's like running on your guys' machines or running on the servers that you guys are hitting. It takes some time. And at that point in time, I think it was daily. Like every day we do a cutoff. We'd say like, okay, not accepting more code. We'll test it and then we'll deploy it the next day. So we had missed that cutoff. It was 11 p.m. The cutoff was at like 5 p.m. So basically if we just waited and did nothing and waited for the normal deployment process, it wouldn't have been live until like the weekend or the following Monday. Luckily, one of the engineers on the team had worked a lot. It was one of these people that was just like just knew a ton. You could tell he was someone who networked a lot with other engineers, just kind of knew everything that was going on. And he knew about this new code push. We just started this Tel Aviv office and they had set up just a month before a code push in Tel Aviv, which meant it was actually lining up to be 2 a.m. Our time in California. And it was because of this that we were then able to talk to people he knew in Tel Aviv and get them to put it into their push before our Friday morning. So definitely a part of this was luck for sure. But it was also like, if the other four of us that were working on this, I mean, none of us knew about this Tel Aviv code push. And it's not really something I think we would have found out either. So yeah, this is a very like, I guess contrived example of this domain knowledge coming in use, but this is one of those things where the most senior engineers I see at Facebook aren't really usually, there's kind of like a cap to how like technically advanced you can be. I think there's some unique people that are just kind of like technically beyond everyone else. And I think that's awesome and it's quite rare though. I think like the more common case of really senior engineers at Facebook are people that are just have a large domain knowledge set of tools, people that they know where they can just kind of get to a solution, not a technical solution all the time, right? Just a solution much, much faster than anyone else. Okay, so yeah, so this one, another lesson learned from this is about persistence. So when we actually launched this, we, it had been launched for like an hour when Zuck used it. So Zuck wouldn't use it, which was awesome, except that it wasn't awesome because it didn't work. And not only did it not work, which was like the worst fear. I didn't know it could get worse. It actually deleted his profile picture. So as I said, I had like copy and pasted some code and like we were still using that code. And it was a very weird thing. I don't even really remember what it ended up being. I think it ended up being something like it probably wouldn't have happened that often. Like I think it had something to do maybe with Zuck's specific profile. But nonetheless, like something happens and it was bad and we had to shut the whole thing down. So like our graph just down to zero like after an hour of being launched. After we'd spent so much time, we'd figured out the Tel Aviv code push. And so like this was definitely a moment where we like could have given up or like started crying and, but we were like, we were persistent. We just said, okay, like we all got into a room and like debug the thing and found like exactly what happened and fixed it. I don't even remember how we got the fix out, but we did and we turned it back on maybe an hour later. So yeah, this persistence thing. Yeah, the note I have here is that like a probability of something shipping is a function of you. So I think this happens a lot where I think if you put two different people on the same project, even with a similar skill set, like you'll get different results and someone will get farther. And it's oftentimes because it's a function of the person and like how willing they are to like continue to push the thing forward even when they hit bugs or yeah, something breaks. So that's kind of like a lesson I've definitely seen a lot. I think that's something that separates like junior engineers from senior engineers as well. And it was definitely an example of it here. Okay, it's my last lesson, I promise. The last lesson is similar. It's about following through. And I think this is also like the thing that separates junior and senior engineers a lot where actually launching something or like building something is, after a certain point it's actually not hard sometimes. It depends on of course what you're doing, but like getting it 80% of the way there, which sometimes is like launching something is really only 80% of the work. It's this like last 20% that is like very elusive and kind of like hard to pin down and like hard to get to 100%. And I think that's something that senior engineers do really well. So this again, this kind of like contrived example that I saw in the hackathon that is a parallel for this is once we launched it, right, we're tracking the number of attempts. How many people are effectively clicking this button and the number of successes. So it calls the server and the server is trying to do the thing and then it fails, right? I don't actually think what this gap is. It actually wasn't, I've zoomed in, right? Like the gap is there. It wasn't like my internal tool, which was like 60%. I don't actually know what this gap is, but it's there. But I think it wasn't bad enough such that we needed to shut it down or anything. Like people were, a lot of people, most people were still successfully using it. So we actually could have done nothing, right? Like this thing wasn't gonna be a, it was a very like finite amount of time. Like its peak was during this weekend, so during that weekend. So it's not something that we were trying to build necessarily to stand the test of time. But we, again, even though we had like not slept for a very long time, we like went back into the room and we tried to figure this one out. And we worked really hard and we figured out that it was actually based on the image size was like the main thing, which makes sense. Like if a lot of people's profile pictures they're nice, high rendered 2048 by 2048 photos. It's four million pixels. It's a lot of things to iterate through. And this was taking a lot of time. And so luckily we store, for everyone we store lower rendering pictures of your profile picture because we, you know, if you're gonna use another app or if you're gonna use Facebook Lite or some like other app that can't display high quality photos, so we have those. So we knew we had those photos. And again, this is another domain knowledge thing. I didn't know this as an intern, but someone else, one of the engineers knew that we store lower rendering photos of everyone. Everyone's profile pictures. And we used, hopefully that doesn't scare anyone. And yeah, so we ended up using those, right? Like we sacrificed a little bit of quality here. It's another trade off for potential performance win. And this is what the, this was the result when we fixed it. So this was falling through. I think this is probably my strongest lesson that I take as like a engineer. Because I think like a lot of companies as well are on quarterly cycles, half cycles, right? You're on sprints to get stuff done. And I think a lot of times you like, you leave breadcrumbs of kind of like not great code, but then you go like, go move to a different team and then you're like, well, I don't need to care about it anymore. I already like built the thing, got the impact from, because it was, we launched and it was 80% of the way there. But to build credibility, right? You wanna be someone that people will look at the code like five years later and they'll look and see who wrote it and they're like, how does this still work so well? So it still works better than anything we've built. And this is just like a silly example of this or like a contrived example, but that's actually like the people I respect most at Facebook are those few people who, like I still look at some of their code so long ago and it's like not even using the best practices of like the new things, but it's so good. Like it's not gonna break. And you can tell they just kind of like cared a lot about following through on that. So that was my final lesson. I'll share the results. It's not what this is about, but the results are fun as well. So yeah, 26 million people used this, 5,000 people a minute at the peak watermark, half a billion likes and comments. So it was definitely an impactful thing that happened in a really short amount of time. Reiterate the learnings. So trade-offs are opportunities, right? So just, and nothing is ever perfect and even existing things aren't perfect. So I think some of the like biggest wins can often times come from not new things that you have to make a decision on, but actually existing things that people probably didn't necessarily make the best decision on at the time they built it. Growth hacking. So even like organic growth can be kindled. So again, this is like, think about ways to organically grow your thing. This is definitely, it might apply more to kind of like client facing, user facing things, but not all the time. Be being creative in how you're gonna get people to use your product or platform. And kind of get it to spread organically is powerful. Domain knowledge is a toolkit, right? I think just like constantly spend some cycles learning and reading. Even if you have like a ton of code to write, it's actually probably just better that you just cut off 30 minutes or an hour every day to like be reading what's going on around you. Persistence. So like probability of something shipping is a function of you, right? And this along with following through is kind of like about you building credibility as an engineer and building things that you're proud of, that stand of the test of time, that work really well. And then this last kind of in Facebook blue lesson learning here is to ship to one person before you ship to a billion people. So my kind of like magical final quote. The meaning of this is actually and I reflect on this like intern hackathon and kind of how naive I was and I like wasn't even thinking about for launching this externally. I just wanted to ship it for like people at Facebook. I think that's actually, if I hadn't taken that approach by accident, then I don't know if it actually would have launched externally, right? Like the only reason that this VP came by my desk is because I had like gotten people at the company to use it and get excited about it. And that wouldn't have happened if I like built the thing and then like immediately after I built it, like started telling people like we need to launch this externally. It's gonna be huge. Like I don't know if people would have believed that or it would have felt it as much as getting some small organic usage internally first. So yeah, this is kind of just a plug for building things or if you are doing hackathons, which you should, they're awesome. Built something small and like built something for a smaller group of people and you'll have a higher chance of succeeding. Yeah, so that's it. Yeah, thank you. You're welcome. Thanks.