YouTube Deep Summary

## Intro [00:00] This needs to get in and if it breaks the site, I will resign. This is Michael Novati. He joined Facebook preipo and shared a ton of interesting early stories. Like this is so much better than Zuck's code. This is the craziest thing though. The head of HR emailed the five of us and was like at Facebook. He went from an intern to a senior staff engineer in just a few years. Was there anything common among all the IC7 plus engineers? The engineers that most impressed me. I think you'll like the full episode since I asked some tough questions and he was transparent throughout. In spirit of openness, I want to like try to talk about it but carefully. Do you think that LMS will kill the coding machine archetype? Let's get into the interview. And I ## Joining Facebook [00:46] think before we go into, you know, common topics of how you got promoted to IC7 or staff or, you know, how you write so much code, I wanted to go into just you joining Meta. What was the story behind you joining and why did you pick Meta of all companies when it was small at the time? I started as an intern in May 2009 and I was in between undergrad and grad school, which is not like the most common internship to have. Um, I was going to do my PhD at University of Washington in HCI and I was like signed up, ready to go, had my housing and everything. I even had a research assistantship lined up already. I really wanted to work get some more work experience at like a top company that was doing really interesting kind of uh interesting product work. Um, so I was really only looking at at the time Facebook and Google and I had no problem getting interviews there, which I don't know, nowadays it seems a lot harder to even get those interviews, but um, it wasn't that hard to get interviews. I think I just applied online for both. Um, and Meta was just like or Facebook at the time. It was really like the perfect team fit which is also not that common with internships where you actually I like happened to have randomly interviewed with a engineer who was working on um internal collaboration tools which was like Meta's diff review tools and task task tools and discussion tools and I happened to interview with this person and that's exactly what I wanted to work on. I really wanted to work on like the the social network for work and in making people more productive and that side of things. So I was just like almost a perfect fit. I did well on the lead code questions and then uh joined his team as and he was my manager and it started from there. So it was really just kind of like the stars aligning. How big was the company at the time in terms of engineers? Yeah, it was about 220ish. It's a bit there's some debate because at the time production engineers I don't think were like classified as software engineers. So there was like the math may vary a bit but it's about 200 or so. Yeah. And so, you know, I listened I did some research and I saw that you felt like you were one of the most into Meta's culture engineers. What drew you so much to Meta's culture? Like what were the your favorite parts? Yeah, it's it's really interesting. It was both technical and also the social vibe you I would say. So, like when I showed up on day one, I opened up my dev environment following the instructions and it was like I was literally running not the most complicated stack, but it was even simpler at the time. I was running Apache locally and PHP and my dev server and it was just hitting a database, my SQL database, just like I would in a side project, except it was a much larger SQL database um and a federated one. Um, but it just felt like a really good fit. I just like I sat down and it just felt like I was home kind of vibe. Um, and from that point forward, I technically I just felt really like in tune with with how they were building stuff. And then socially, I mean, honestly, Facebook was really cool at the time. It's changed over the years. It's had its ups and downs. Even while I was there, I saw like the peaks and troughs, but it was just like really cool and it was a cool product that was that everyone knew about and was talking about and curious about. I could get lots of feedback from people about like what they liked and didn't like and it was motivating to work on stuff that like people cared about. Um, and I just kind of really wanted to make a good product for all these people who cared. So, um, both those things I think. Yeah. When I joined Facebook and a lot of my peers also joined as well, PHP was something that I don't know want to say it scared. It definitely was something that we were not attracted to. We thought oh we had worked with it a little bit here and there in college was something that was pretty unattractive. Did you feel similarly when you joined Meta? So now Meta um uses primarily hack which is the derivative of PHP. It's kind of I don't know if the language is officially forked or I don't know you can you can probably comment on that but it went through multiple stages though to get to hack. Um and the first step was just having a like a compiler for PHP that turned it into more performant code. Um and those efforts were ongoing at the time. And there was discussion of like should the company change from change rewrite the entire codebase like in Java or Python or all these things and they ended up just kind of optimizing the language and starting to customize it to address some of the deficiencies like I think having loose typing was one of the first things or an early thing that was added. Yeah. So they kind of I feel like it PHP off the shelf definitely had the stigma at the time, but I felt like Facebook's approach was like we're going to make this better than any other language could be because it's going to be customized at a language level for how the company uses it. So it's like easier to use as an engineer, more performant, and has all those traits. So like uh both sides of that. So yes and no is the answer. Yeah. Yeah. No, definitely. I think PHP gets more of a negative rap than it actually deserves and hack is a a much better experience. Not it's not comparable to PHP. So that makes sense. Um on the culture, you know, one of the early things that I really liked about uh Facebook was these move fast and break things culture. I just thought it was such a cool framing of something that mattered a lot to people. Since then, that culture has changed. What are your thoughts on on that? I was definitely the move fast and break things person at the time. I still like the kind of move fast and break things framing. Um, personally, I think that the removing the like break things part um it felt like it was maybe a little bit more like the perception on the outside. There's part of it was like Facebook communicating to the public didn't want to communicate that like people are recklessly like breaking everything. Um, but the spirit of it wasn't it wasn't about like breaking. It wasn't like you're going around like breaking glass all over the place and like stepping on and cutting your feet and like it wasn't that environment. The idea of breaking things was breaking norms. More recently when you hear people talking about first principles thinking and like not following trends for the sake of following them like breaking move fast and break things was about like trying to break established norms and thinking about things a different way and trying things from scratch. And um it h it was a really like I think more in the spirit of first principles thinking than like actually just like causing havoc. Um so I I still think that that's a good good motto if they had it today. But um at the same time like when a company's larger, more mature, um stability like even the smallest bug has millions of dollars, tens of millions of dollars of impact sometimes. and stability can have a real impact so financial impact. So I think it's also I can see also that motivation for including it too. And your throughout your tenure I mean you started when it was so small at 200 engineers. Did you feel the culture changing? I think you were there earlier than I was. So I'm curious like how did that evolve over time? So when when I joined and this was um going back to kind of maybe what was like appealing about Facebook at the time. Um the culture is very engineer uh driven at the time. It still has that today to some extent and it's a great place for engineers to work in one of the top competitive places. But um it was like to the extreme where like engineers were very empowered to make decisions. Um designers and product managers had to kind of like win over the engineers and get their buy in to build something because if the engineer wouldn't build it, it wouldn't get built. Um so there was like a lot of uh like uh engineers were empowered to push back and negotiate with designers and engine and I mean these are still things that happen today but it was just another level. The internal a lot of the almost all the internal tools at the time were written from scratch internally and employees use them. So that actually gave like it really set a tone that like this is a company that is that is engineering first. It builds the things it needs. it cares a lot about like what it's building and what it's using and that part of the culture I like loved. I mean the IPO in 2012 was a turning point where the stock like crashed after the not crashed completely but it tanked after the IPO um because people were like how is Facebook going to make any money and it's like yeah that's a good question. You know I started in 2009 and for three years we didn't really talk that much about like how we're going to make money. Um, and you know, it's like to have a to have a business that can make money, to hire more engineers, to build really cool stuff that hopefully has a positive impact to you have to like in at least capitalist society, you have to make money to keep that going and keep growing it. Um, so I kind of had a more mature view as we grew and understood how changes to optimize ads or to changes that focused on saving money or making more efficient infrastructure became more important. Um, and there was different competing factors. I would say early on engineers would have more like like senior engineers would have more head-to-head discussions about how to build stuff like somewhat independently of management and like towards the end you would have more like VPs of two different teams like negotiating stuff and then it like percolating down. Um so that's just an example of the engineering empowerment um too. I see. What was it like when Meta IPOed? ## Facebook IPO experience [10:26] What was like the feeling among the team? Was it ecstatic or people were scared cuz the the drop in the stock price? People definitely weren't scared. Um I would say that it was like a celebratory moment. It started off not not being one of those things like um I feel like Mark Zuckerberg was really good early on about like keeping things grounded and humble and not getting caught up in like headlines and the press and perception on the outside. Um it was just very much like you know IPOing is a very rational thing to do to raise funding for the company and that's what an IPO is. It's not like a party or anything even and and it was very rational. At the same time though it's like it is kind of like an event that can pull employees together. So the actual IPO they like got the NASDAQ to there's like some button that like opens the stock exchange or whatever. I don't know. They got them to like bring the button to Facebook campus and set up a stage and like someone like rang the bell or posted pushed the button or whatever and like I can't there was some talk about how they actually like hooked that up through some special like networking system so that it actually was the button and not I don't it was like some there's way more to that story that you should dig into. Ask ask internally about that. There's probably something about it. But yeah, but it was really cool. like uh Mark Zuckerberg's parents were standing like right beside me in the crowd and like I even told told Mark about this story because they just happened to be beside me and and it was like the like kind of tear in their eyes like it's a big moment for like you know and you see like kind of that person so like you see kind of like all your friends growing up and doing something and I thought that part was very impactful on my life but it wasn't like um yeah I mean financially all the stock vested like six months after the IPO so none of the employees actually had like any money or anything at the time. They were all the same same as they were before the IPO day. But right when it vested, what was that after it had tanked a bunch? Yeah, it was actually it had tanked down to I remember this day because me and a bunch of it's like 20 of us. We went to go see a movie. We were in the movie theater and like everyone's sitting there and then like the stock hit their accounts. So it's like all the phones like went off and it's like your vested stock has been deposited. Um yeah, and it was kind of I remember that moment. Um but the IPO didn't really like change people's behavior short term. I think like much longer term like financially people could afford houses and have kids having kids in the Bay Area is like super expensive. So having kids is is even like a a thing that you a decision you might make after having some more savings. So like there was some impact there longer term, but like short term it didn't really impact people. Did you hold because you say, "Oh, this is this is going to go off and you know, we've got this." Or were you the type that's diversify, put it in index funds type of, you know, as soon as you get vestings? I held my all my IPO stock and I still have all of it. Um, but the Oh my god, you really believe But I uh sold on vest after at some point in time, I don't remember when, but at some point in time, I sold it vest to diversify. It was very fortunate for the younger people who like came out of school and didn't have a lot of financial literacy to have like the the old guards so to speak who came who went through like Google IPO and Yahoo IPO and like there was like classes and stuff on like how to how to man just they were had nothing to do with like the IPO per se just how to manage finances and how to deal with stock like stockbased compet I grew up in Canada stock-based compensation was like I had no idea what that was like I and I can read the paperwork. I can do the math, but like I didn't really like deeply understand it. And it was not my day job. And I so having these these like lessons and stuff was was infinitely helpful in like understanding how to manage and how to think about the risk and and these different things. I don't know if they still have those classes today, but they were very useful. I mean, Meta Stock went down to like 90 or something like a year or two ago. Were you sweating at that point or you don't? It's just kind of out of sight, out of mind. I mean, I have like diversified enough now that it's not like my uh retirement like collapsed like type thing. It wasn't that like but it was definitely sweating a bit like like oh these numbers are low like Yeah. Yeah. Yeah. I mean because 90 I mean when I started in 2018 it was like 180 or something 150 I forgot exactly. So it went to half of that like two years ago. It's kind of crazy. I do know people that started during that time though who in like now three years like almost 6x their stock which is I mean at form so formation uh where I'm what I'm doing now and we're helping people prepare for interviews, understand offers. It's definitely one of the one of the pieces of advice I give from just seeing these fluctuations over the years when people are like comparing offers and they're trying to compare them in today's dollars headto head and they're sweating over like singledigit percentage differences. Like it's a lot of money. Engineers get paid a lot of money. It's it's reasonable to care about like the thousands of dollars differences, but at the same time though, like they're kind of estimates based off of current situation and things change so much and stocks go up and down and acquisitions happen and scandals happen and like there's so many things beyond your control that like I always advise people to prioritize an offer or a company that you're going to fit really well at and perform really well at because your performance over time is more within your control and you will be financially rewarded for that performance more within your control than trying to guess a stock um type thing. Yeah. Yeah. No, definitely. I mean, especially for early career, I mean, just one promo could be, you know, 40% more compensation and relatively in your ## His internal newsletter [16:30] control. So, I was talking with one of my old managers who's been on Meta for a long time and I mentioned that I was going to talk to you and he said that you had some like internal newsletter or something that was really popular. I'm kind of curious to learn more about that. What What was that and what made you start it? It sounds really immature in retrospect, but I had this like it was called the weekly navati. So, I I wrote like a weekly blog post type thing. So the notes product on Facebook, it's like the blogging platform type product. It was unowned when I joined in 2009. There's no no one product engineering wise like it was just code that existed. So it was something I worked on a lot at hackathons um improving it. I added like it was literally like plain text. It was like you could write plain text notes and post them. So I made I supported rich text and one in a single hackathon. It's uh like on 11,000. You can probably find the PR somewhere, but uh or the diff somewhere, but it was 11,000 lines. I think it's like not how you build code. So, I had to like organize a meeting to review that code where like get engineers in person because no one could actually review 11,000 lines of code. It was anyways um had rich text editing and kind of spruce them up a little bit. Um and it kind of evolved. I kept adding a couple things here and there, tags. Uh, I was kind of using it a little bit like dog fooding, which is a big thing at at Facebook, like using the product yourself and poking holes in it and trying to give feedback and stuff like that. So, yeah, I was using it myself to post a lot of notes in general and then um I had a couple of posts that were just slightly controversial controversial about like product building and yeah, different like kind of hot topics and they got a lot of traction and discussion. So, I started posting more regularly. Some of them were very off-the-cuff like random things. Like there's one that was like, "If I was CEO, what would I do?" Um, Facebook was adamant about only having a Menllo Park campus and not having anything in San Francisco. And I was like, "We need to have stuff in San Francisco. All the new startups like Stripe and Uber, they're all in San Francisco and they're like taking our employees and everyone wants to be there and all the employees are moving to San Francisco." And like Facebook was just like, "No San Francisco office. No San Francisco office." So, I was posting a lot about that and I had like one post about how they should open a South San Francisco office and that actually happened. So, I was happy that that one like came true. When you look back on that writing, um because I know some people do advocate like, you know, you should start some sort of internal, you know, post in some Slack group or workplace group or email newsletter just internally. Would you recommend it? Like were there outcomes from that that looking back you say that was a great idea? Overall I would say that was not a good idea in retrospect. Oh really? Um why is that? So okay there wasn't a strategic reason to do it. It was really like I call it like open and transparent and I think it comes from Facebook values. Facebook's values of being open. Um at the time that was like a a strong value. Um, and I really just believe in like removing like removing like the kind of surface pleasantries and facades and like what are things like more objectively and like what can we do? How can we improve them or like if you build a product and it got like a lot of traction but it was there's always some luck involved. But if it was more like the circumstances that made the product grow and not the substance, we want to be like real about that. Like this is awesome. we got really lucky that this product took off and it's not that great. We need to improve it. Um whereas like I see a lot of startups, a lot of boot camps like if they get a lot of little bit of traction um they kind of like think that that's how that it must be justification that the thing they built was awesome and they kind of like don't hold the like highest bar to keep ruthlessly iterating on it. a bit of a tangent, but my generally my like philosophy is to be just fairly like open and direct and I want people to be that way with me and like create that environment where people are just okay talking about stuff. So, it was really about pushing Facebook's values and trying to have a company where people feel open about talking about things and it had nothing to do with like performance reviews or growing influence or anything like that. It was like there was no other motivation. But in retrospect, I would say I would not do it because actually caused this is like something I didn't deal with well at the time and I still don't know how I would have dealt with it if it caused some like friction and tension sometimes like there was one post where I just openly called out that uh Facebook has software engineer job titles where you can like be a software engineer and move around to different teams and it's a pretty like it's what you think of canonically as like the software engineer but then they had all these other engineers like network engineer data engineer and those engineers like couldn't change teams easily. They were hired to like teams and they weren't quite like the same like privileges as a software engineer. And I just like called this out very openly like out of the blue and I didn't realize that that was like a big tension behind the scenes and it like caused a lot of like friction with different executives who were like Michael I'm working on this problem. I didn't like really did not help us to like call this out like we have to do damage control now like we need to talk about this and it like kind of that off-the-cuff style like does have consequences. So I learned that and I try to try to adopt that still today but I still am very big on on Reddit and on LinkedIn on just trying to be like direct and open and unfiltered a little bit with with thoughts to try to show people that it's okay to do that. Did HR ever reach out to you saying hey you got to take that down? Uh yes. There were not issues with sketchy type things like oh this is like uh you need to take this down like for the comp like I don't know. Um, but I got feedback from HR on certain things. Like I had a post that was about which companies are like hiring Facebook like poaching Facebook engineers and Uber was like giving Facebook engineers like very large stock grants at the time and HR was like not super they gave me feedback that like that kind of post they thought it could incentivize people to like explore other opportunities. Um, and they, it's not like I can't do it, but they just, it was just more like feedback that like, hey, did you realize that you might incentivize people to like consider other opportunities unintentionally with that post? And I was like, no, I didn't realize that. And it's like these were more off-the cuff thoughts and maybe it wasn't worth the the friction. But yeah. Yeah. Even in that case, I like when I got that feedback about the engineers going to competitors, I was like a bit concerned and I messaged Mark Zuckerberg directly and asked him like how he felt about it and he was totally fine with it and encouraged me to keep posting. So I like felt like it was like okay to do that and I I was still motivated to keep keep posting. But yeah, you could directly message Mark Zuckerberg and he would reply. Yeah, I mean when I joined Facebook was quite small. So I like interacted with Bos I think was my direct manager, skit manager for a while and I regularly interacted with him even when I left like I messaged all the executives one-on-one like Chris Cox and Shrep and Jay and Bos and and Zach and like told them I'm leaving and you know they responded thanking me for the contributions and stuff like I feel I had a relationship with all the people all the executives at the time but it was kind of from joining when it was small and from just genuinely interacting with them I'd say of all The people though Mark I like got to know more personally too outside of work a little bit and have like the closest relationship with him of all the executives but I have not talked to many of them for the past couple years as Facebook has really like exploded but ## Working with Zuck [24:26] yeah when you had just joined I guess 200 people probably not but did Zuck still write any code like did you ever see a diff from him I actually worked with him on a hackathon in 2009 Zach had this hackathon idea where he was like I think that anyone should be able to put like any emoji to any post as a reaction. And this was like in 2009 and now this is actually like the norm everywhere. So he was right. I was like a bit skeptical but I thought like it sounded like technically feasible that I could help build that. So I I was like working with him on that during a hackathon and uh with another engineer Tom Whitner. We kind of got it working but uh the code was just so bad we it never got shipped at the time. But he Mop just like did not give up on that idea though. And like I remember when um I think Sammy Krug I think is still at Meta. But I think she was the PM if I remember correctly. She was the PM who like led the reactions initiative and when it launched I was like wow like this it was done like properly and well and like well designed and well implemented like this is so much better than Z code. But uh there's also another there was another time though where he actually merged a PR and this is actually like a Facebook like this is a crazy story but um there was like this lockdown period in 2010 where Facebook was very concerned about plus um potentially making a dent into Facebook's user base and there was a lockdown period where they really wanted to ship like a bunch of features really fast. There was food served on the weekend. It was like pretty pretty intense and I was like again the all in person so I was there like all weekend but during that period I at one of the company uh Friday Q&A companywide Q&As's I basically made a bet with Zuck that he wouldn't like if he was able to commit code by the end of lockdown then I would like stop ripsticking which was a skateboard like thing that was very dangerous that's now banned that I would do around the office and then if he didn't commit the code I I can't remember what the penalty was and I don't remember what it was. Ripstick is that thing that like you go like this, right? Yeah. You have to wield skateboard and you have to like wiggle your hips. I like got got really good at it. But um it was really dangerous. So like a lot of there's rumors that Facebook's health insurance premiums were significantly higher than other tech companies because these ripsticks were like scattered throughout the office and there were so many injuries. Ripsticks were eventually banned I think in like 2012ish. This is the craziest thing though. The week before the formal ban went into place, the head of HR emailed like the five most prominent rip stickers at the company, the head of HR emailed the five of us and was like, "Can you give us feedback on this draft banning ripsticks and at draft email banning ripsticks?" And at the I didn't realize this, but this is like a classic technique to try to get buy in from like opponents is to like try to bring them into the process more. So this was actually like a a buy like hey like hey you know ripsticks are going to get banned but can you give us like feedback on how we communicate this like I want to talk to her about like this part of her job but I just can't imagine being like the head of Facebook HR like tens of thousands of people and like having to ban ripsticks and having to get buy in from like these critical Um or else it could be like a revolt. That was like a big tangent. But yeah, I I just Oh yeah. What about the Zuck thing or he merged the PR and Okay. So basically it was a Yeah, bet in front of the whole company and then he actually like merged the PR. Um so then I think I was banned from riding ripsticks out indoors or outdoors. I think they like qualified it just to there was like a loophole. But yeah, there's these all these stories of like early Facebook where Zach actually wrote a lot of the code. When you first got there, was a lot of it, you know, you look at the git blame or I don't know what what uh source control early was. Would you see like those people's names in there? Yeah. Um occasionally, yeah, there was a bit I think there was a wave of engineers like in the Facebook kind of internal lore. the first engineers at Facebook were not known to be writing the like best quality code per se. Um, but they wrote code fast and like they did a good job of what they were doing. But there there's kind of like this like wave of engineers where mic um where Facebook got like poached a bunch of former Harvard people from Microsoft. I think Bos was in that wave too. Um but there was kind of like a wave of more like mature or slightly more experienced engineers who came in started laying out more more structure and framework and then they also brought in some other people at the time who really started writing like more of the core abstractions and the stuff that was the foundation for the product infrastructure team. Um I don't know if the team still exists today but um it existed for a really really long time. um who builds all those core abstractions and maintains them and um that wave of people their names are like all over the code base like Evan Priestley and Putnham and um these people. So these were my role models when I joined when I wanted to be the coding machine who writes a lot of code and I saw these people's names. I was like those were kind of my role models of who I wanted to be. ## Engs that impressed him [29:50] Yeah. I'm kind of curious, you know, you you grew into such a strong engineer, uh, senior staff, IC7. Who were the other engineers that you looked at that you said those people really impressed me and why? The engineers that most impressed me was the product infrastructure team working on like the React framework uh nowadays, but at the time it was more like the PHP abstractions. Um like Nick Shrock and Ola and um the they were kind of it was like building out the the end framework of today like that was built through my time. So I saw that kind of get constructed brick by brick and those people I kind of saw as like the best engineer kind of thing. Uh Dan Schaefer I think Dan Schaefer might still be I'm not sure but I saw those engineers as people as a different type of engineer. They were that was not like the thing that was not my specialty. So the person who was most like me was this person Evan Priestley who I think was like the number one committer before me. I don't know if he invented clown I don't know if you still have clown town. This idea of clown town was like if you like caused a really bad silly bug or typo or something or like you break Maine or something like that, you would be like added to Clown Town philosophically. Oh, he had a a certain type of humor, I would say. But but he he was very prolific. He single-handedly wrote uh the diff diffol camp at the time which became fabricator and like when he left they forked they kind of open sourced it and like wrote all of that entire product suite from scratch like himself basically if let's say you are you know you're building your own team and you could either have him on your team to build out this new product or you can have four senior engineers just regular other senior engineers, you know, which would you rather take? Uh, Evan Priestley. Wow. Okay. So, how how many senior engineers does it take to you would pick them over Evan? So, it depends on the context of what you're building. And like this is something too that comes up with like came up with me a lot too is like if you have like this branding as like this person who just like writes a lot of code. It's like they're not like it's not like a mysterious process where like the code just magically appears or something like like it comes from just work hard work and it comes from keeping like a bunch of code in my like RAM in my head like my memory like and and paying attention to like the littlest details and really getting absorbed in it. And like if you put me on like a brand new product, like if if you were like Michael's a coding machine, let's put him on like Oculus uh firmware or something, I like would not be productive at first. It would probably take me a really long time to absorb everything and suck everything in. But it's not like just have like this magic power to do that. So I think it depends a lot on the context. Like uh if you're at a company and everyone's already ramped up on the thing and you have that choice, I would probably choose the the coding machine. Um, if you're doing something like really like new, you might actually want like a little bit more diverse backgrounds and diverse experiences so that there's a little bit more like flexibility and creativity in the process. Um, so I would actually qualify that as context dependent, but all things equal in a comfortable codebase, I would want the coding machine. I have like many many examples over the years of things that like just like would not have happened if it wasn't for the single person whether it's me or Evan Priestley or a similar coding machine like there it's like that's kind of what makes you the coding machine at that level is you're like doing something that people did not think was possible and you're making it actually happen. Can you give an example where you know something where you or Evan succeeded where you know a team of seven senior engineers would not have brought that through the finish line. The like canonical example for myself is um there's this framework called preparables. Um it was a framework that in a given component separated the rendering code from the data fetching code. Um so like a given component on the screen um would have a data fetching function and a rendering function so that you could kind of in different p waves fetch all of the data in parallel wait for it all to be fetched and then render everything. Those concepts have matured a lot now in React and all of the like complexities with with suspense and spending and all these like more intricate things. At the time it's fairly simple just like component two functions fetch data render at that framework basically got replaced over time with async await and uh more modern things. But there was thousands of classes throughout the codebase that people would be interacting with on a daily basis that were preparable structured. Um, and I like manually relentlessly remove refactored and removed every single preparable until literally the the parent class was removed from the codebase. Um, and I think there was three like three, five, six thousand of them or something. Um, it did take several months, but like I don't think that would have happened and it was single-handed effort. Um, and I don't think that would have happened otherwise, believe it or not. Now there's like a, you know, there's like a routing framework to route all of the like URL URL requests like to the right like endpoints. It's like abstracted now. I mean, it's been abstracted for many years now, but when I joined, there was still like PHP endpoints that were hit directly on the server like kind of old school web development. Um, and another project I did was to remove every single one of those and only use like the routing framework. Um, and it's again like something that if there wasn't like the drive, the grit, the priority, it wasn't like, you know, it wasn't like the most important thing for the company, but like those things wouldn't have happened. They would have taken a lot more resources that could be working on like new products to do. and one person just single-handedly doing it can make all the engineers lives a little easier to not have to deal with these legacy frameworks and stuff. ## Will LLMs kill coding machines? [36:20] I mean what you just described a large scale refactoring or super coding heavy task I could see an LLM doing that job quite well um in the future or maybe even now to be honest and so my question is do you think that LM will kill the coding machine archetype? So when I was doing all this work at at Facebook, I was using Vim. And the tools I used were like this thing called TBGS, which I don't know if it still exists, but it was just an indexed search of the entire codebase, but it was a proprietary tool outside of any IDE, like a command line tool or a web tool. Um, so I used that to find things and I think I had tab completion in Vim, like a plugin for like class names. That was it. Um and I was very productive. So even if I would have had like VS code with modern tools that we have now, I probably would have been more productive. So the the current wave of AI tools and the LLM based AI tools um are kind of like a next step of going from Vim to VS Code. It's like going to a LLM AI powered mode that lets you be more productive, makes certain things faster, certain refactorings faster and changes faster. The next evolution going into like that, you know, we're seeing some some agentic flows in coding popping up already. Um, some success cases here and there. Um, it's not like mainstream. I think that those flows will probably be even more replacing of like those basic functions right now though like and probably for it's changing so fast. It's never things have never changed this fast. But like for this year, I think that AI and LLM tools like a lot most people most engineers still don't use them. Like you get off YouTube and Reddit and all these places like and you just go to the middle and no middle of somewhere and ask an engineer like they're not using AI tools as much as like the the people who are pushing the leading edge. Um so if like everyone used the tools the way the like leading productive people are using them then we would have a massive industry change already and we would all be more productive including the coding machines. Um, and then the agentic flows that happen after that, like I don't I don't know. I not uh I'm not decided yet on how that's going to impact the coding machine and or the rest of engineers as well because that's going to really change things probably even more than we've ever seen before. What's the biggest difference between, you know, how you used to work? I mean, you mentioned this Vim workflow is basically your hand writing the code and doing everything yourself to using the LMS. like what are the biggest differences you noticed? I'm in a code base that's 500,000 lines give or take, which is not a small codebase, not a tiny codebase, but it's like the size of a popular like open-source big project. It's a reasonably sized codebase, but it's small enough that I like still know most of the code structure in my head and the and and everything. So I'm not using that many uh codewide agentic flows um or multifile flows in general sometimes but not often. Um I'm normally using AI to speed up what I would already do. So I already almost know the code I would want to write and I'm using LLMs to generate that code faster. Um, if I want to write an entire component that I think is going to be like a 100 lines of of markup for the page, um, if I I have to make a real-time judgment call, if I can type those lines faster or if I can explain in the most efficient prompt possible to an LLM in the right spot how to generate those lines for me and have it be successful. Um, and I'm just, you know, prompt by prompt building up that intuition on how to effectively give those prompts to speed up my workflow. Um, and I'm in a spot right now where I'm like very much more productive. Like we have a product, we are adding new features. Like the workflows are kind of pretty similar now that they have been six months ago for our product development process. And I'm producing like five times more code than I was then just through these optimizations. And it's changing so fast. So it's not like there's an endgame here. Um it's not like there's this fixed path. It's like every every time a new model comes out I'm developing different intuitions or a new feature or a new Yeah. Um a new command line tool stuff like that. Yeah. So it's interesting time for sure to be an engineer in general. It's interesting. I mean today and maybe soon also it just uh it seems like LLMs are an extension another thing to delegate to that makes us more productive. You mentioned the agentic stuff if it can kind of uh more independently generate code without the software engineer being involved. I wonder how would you feel if coding was more of a hobby in the future and programming was no longer driven by humans? Uh, I think it's a cool future. We talk about all the cool things that engineers do and and why it's so awesome to be a software engineer, but like if you actually clock your time and look at what you do as an engineer, there's a lot of stuff that's like copy paste, search, copy, paste, change some lines, like sit there and stare at the screen and think for a bit. Like there's a lot of things that are like not as fun. And if you could really just like focus on the fun parts like the creative product pieces or even sometimes just like building I find joy and excitement in like cleaning up code and combining things that didn't seem like they have any overlap and merging them into one like frame one concept like like there's things like that that I just like doing that maybe as a hobby or maybe it's just like Sergey Brin at Google's probably like the perfect example of this where he can just like plop into whatever he wants to work on um and like contribute what he wants to contribute there and like it's more he's doing what he wants to do and there's and not the day-to-day stuff. So I think it's probably it's exciting in some sense in that sense for sure. Um it's definitely like scary to the software engineering profession because it kind of like raises like what does it mean to be a software engineer? Is it actually writing the code? Is it architecting the data models? Is it coming up with the systems level stuff? Is it gluing it all together? Like it and it's kind of a AI is already just making us think about those things. And I think it's going to be redefined many times over in the next few years. Like I think we're in this really weird transition phase though where for the next little while, I don't know how long, but next little while like AI and LLM tools are going to make engineers more productive. specifically engineers with a lot of experience and strong taste are going to be more and more productive. And if you're not an engineer with lots of experience, it's going to be harder and harder to to build that. Um, which is I'm more confident in that. But in the future beyond that, like if AI can write its own code and maintain its own code, I don't think code will be the same as it is today. Like it's if an AI can do its own thing, it's not going to be writing JavaScript. it's going to be managing its own services that have like a an API and it it's gonna do its thing. Like you might not know how it's building it and as long as that API is contractually provided and it is doing its thing and meeting whatever specifications it has to then it doesn't really matter how it's being built and it might be like doing its own thing and no one might know what that code looks like and it might not even be readable. I mean engineers make a lot of mistake like it's like humans make a lot of mistakes with code and cause really bad bugs and AI is probably going to have bugs and it's going to have ways to fix them and it's not like it's going to like we are going to build AI to to do those things. It's going to be like I don't think it's going to be like this dystopian future overnight. It's going to be step by step as we get there. And I think it's not going to feel and I think it's going to happen. So I don't think we should push back on it. we should be thinking about like how do we make this AI world the best that it can be instead of like pushing back that it can possibly work. That's where I stand on that. But yeah, you you mentioned there were some React engineers that you looked up to and their archetype was different from yours. What what impressed you about what they were doing? What how would you describe the archetype? Yeah, I don't I it might fall under the specialist archetype where you're really really really good at one stack. Um, another example is like this engineer who knew email protocols and was like one of the 10 people in the world who deeply understood email protocols to like I know that like you can look up the specs but like the practical side too of like dealing with spam and routing and all this stuff and like you know so there's like I think it falls in a specialization um bucket um like in general I'm like the fan of the sports team analogy so like you want like a professional sports team that where every every every player on a baseball team can play like any position like pretty well. Even like the pitchers who only throw can probably hit the ball better than most typical people or like even amateur baseball players. Like so it's kind of like you want your team to have those different roles and you want to respect each other's place on the field. Um, so I kind of respect those those engineers for what what they do and I have like my thing and I think that the whole team is exceptional if it has these different these different players. I see. So what impressed you about those engineers is that they solve problems that other people couldn't. Yeah. And uh the abstractions they were creating specifically were very impactful because all the engineers are using them on a daily basis. So like a lot of the coding machine work I'm doing that impacted everyone was like cleaning up and making their lives easier. Um and these engineers were writing frameworks that were like that made the like thought process less overhead for an engineer to fetch data and stuff like that. Um so there were some similarities a little bit but that I like respected that work a lot. Um, but it's very hard to come up with such an elegant API that's super performant and is easier to use. Making things simpler is sometimes more work than writing a lot of code or harder work, too. So, I respected them for that. I wanted to talk a bit about ## Operating as an IC7 [47:20] your career growth cuz you grew to, you know, senior staff or IC7 at Facebook. Um, there were less IC7s at that time, so it's even more impressive that you did that and as quickly as you did it. Um, so I'm I'm curious to kind of dig into some of the, you know, behind the scenes in it. I I think you've told the story publicly a few times, so I kind of want to ask some of the the side topics on it. So, um, one thing I'm curious about, you mentioned somewhere that you had spent 30% of your time on your team's work and about 70% of your time on side projects or projects of your own initiative. How how does that work if you know you're getting work from your current team? Can you talk about that? I think the way I framed it is like almost being like a senior engineer on a small team of 10 people and then um spending like more than half my time doing kind of codebase wide initiatives, cleanup, refactorings, a new framework, sometimes some random random oneoff thing a team needs help with or something like that. Um emergency like other work. Um, so like the I would say like the 30% work very much like if you just imagine having an E5 on your team like it's not like time. It wasn't like I'm it wasn't like 30% of my 8 hour day was the team and it's like only contact me then. It was more like 30% of my mental space or my focus I think. So I would still be like on the team all day long. I would be um as like a senior person you're reviewing a lot of code. You're bouncing ideas off more junior people. You're mentoring, helping junior people grow in scope to get promoted from entry level to midlevel. Those kinds of things. Um writing a lot of code on features that the team queued up like the team had um just you know um contributing to them. um going to like product meetings and contributing to like the product direction evaluating feasibility of things like when product managers like we want to do ABC and it's like okay well A and B I think we the team can do C they can't do like you know general things a senior engineer would do but the volume of code produced was more like a senior engineer on the team I would say how did you manage the relationship with your team or you know your manager for instance typical manager knows you have bandwidth kind of positions you in a certain area but it's a little unconventional if that that IC is doing majority of their bandwidth is solving problems all over the place so how did you manage that relationship I would often report not all the time but I often reported to more junior managers and I was almost like a peer like the skip would generally do my performance reviews but I would like report to a or junior manager, I would almost like help them manage the team and then like really report to the skip kind of thing. Um like unofficially report to them like vibe. So it was definitely like interesting relationships like the head of like one of the VPs I would meet with like monthly for the whole org and my skip level I would meet with like every two weeks. So in the org chart, you reported to a a frontline manager, but in practice, you were almost dotted line reporting to some more senior people and you were known as a it's almost like a weapon of the org that you kind of just go wherever. You know, let's say I'm a I'm a senior engineer and I want to go solve problems for the org all over the place and I'm reporting to my frontline manager. I got my tickets or whatever. How how did you transition into that IC7 solving the hardest problems for the org role? Is in my case like I was almost like the coding machine from day one and the thing that improved was my taste and judgment but the like even the raw output was probably honestly the same when I was like a week into Facebook. Um like there was there was two different a fork of the task tool. Um it was called Laltana and Cortana and it was the same like data source for the internal task management tool and there was two different like UIs. One was like streamlined and fast and one was like bloated with features and slow and there was like competition between them. And like I in like a week or less I merged the two code bases into one that was like the speed of the like slim down one with all the features of the bloated one. Um and it was I just like literally just took the initiative entirely on my own. I didn't even like tell anyone. I mean, this is so early on. You could not do this now, but like I didn't tell anyone. I just mer merged them. I posted to the entire company. I'm like, "The tools are merged. Like, it's done. Like, deal with it kind of vi vibe." Not not in a mean way, just like it's done like like surprise. Um, right that So, what what I learned along like the output was really the same. What I learned though was like that's not the best way to like merge tools that are used by hundreds of people to just be like surprise like URLs changed like deal with it. like I didn't deeply understand like the consequences for teams. Everyone like like patted me on the back and thought it was amazing because like no one could have done this. So like all overall it was still positive but like that would not be like like the the things I learned were like judgment calls about like the scope to change things at um the the how to like pay attention to the impact the changes will have on other people. Building up intuition about what spots are more sensitive than others to make changes in. Um, and that like judgment of doing these massive things like over and over and over again and doing some of them too fast and having too many bugs and there's some people who will like forever not like me because I like caused a really bad bug because I went a little like made a bad judgment call and then I learn take the feedback and then keep going at the same speed while like improving my judgment and building that taste. Um, and I think that accumulation of judgment and taste is what crosses the line into the E7, but the raw output, it wasn't like the raw output kept going up. Um, so I don't necessarily have advice on how to build that because I think you have to kind of like it's very dependent on your or your team, but I think like if you want to do that, I would start by talking to your manager and if they can't really help, maybe talk to your skip level manager and if that doesn't really help, try to find a really senior engineer who is maybe that person and ask them how they did it in that same org as you or in their org similar to yours like it's kind of um it's very dependent on the context but yeah if I'm understanding correctly then you were able to work on all this extracurricular you know orgwide projects because you had such high productivity and that was true from day one and you had the initiative too like no one no one's going to stop you like let's say you you have your your project on your team no one's going to stop you from doing extra work that solves some, you know, problem on the side. And so you you took that initiative and you have exceptional productivity. So you just became known as this person that's constantly solving like extra problems. Um yes, but I I really think that the jud the judgment and taste piece though is like so critical. Um and it's more than just the code. It impacts like the push process. So like now there's continuous integration at Facebook. At the time there wasn't. If you broke something and it shipped to production and you needed a fix like the pushing team like would not generally be happy and you have to like negotiate with them in a sense and if you break things too much they don't trust you and they will not accept your changes. They might even push back on your normal changes. So that hurts a coding machine. So, I have to like build a relationship with the pushing team so they really trust me. And more than once I've said like this needs to get in and if it breaks the site I will resign like quote unquote. I've said that because I burned credibility before like the day before shipping something too fast. I had to be very sure, so sure with the fix that I would like you can fire me if it breaks things and like those types of like things to build that that trust and credibility like another engineer who just shows up and writes a lot of code probably would not be able to get away with it because they didn't have the years of building that up. So it's a that that is really important. It's not only the raw it's like much more than the raw output there. Would you have resigned if you if you broke broke it again and you said you would? Yeah, I think I would have. It's like this weird maybe it's a personality trait, but it's like it puts that saying that puts so much pressure on me that I will like make sure that it does not break. You know, like I will like I will like triple check every line. I will think about every weird case that could possibly happen. Yeah. You talked about taste and judgment when it comes to code and software engineering. What does that mean? Like people who cook with like cast iron pans, they talk about building a patina where you have to like build up layers of like history and it gets burned into the pan and it has a a profile. Um that's to me is like taste. There are some people who who naturally have instincts for maybe it comes from this the way they grew up and their past experiences they have and the the context they're in. and they're they have stronger taste faster, but generally it just requires like experience in some way. Like you might have experience outside of code that might build up you might do lots of like dancing and you build up all this like intuition and muscle memory about dancing or sport. Other sports and stuff too are similar. Um, it's kind of like that but in the coding context of you might read a book on how to be the best like uh the fastest speed skater. You read the book and you just got to put the skates on and you just have all the ambition and you just want to be the fastest. You know you can do it. It's like you're you you have to like spend years doing it and really like feel it like building up every aspect of the muscle memory, every like movement on the ice, the feel of the ice under different temperatures and altitudes and pressures and like the sharpness of different skates. You'll be able to feel the difference between like a skate that was used once versus twice. Like it's like every detail you will over time accumulate by putting in the time and gaining that experience. Um, and I see far too many people rushing early on where in their careers where they're trying to like jump ahead. They're they're trying to enter the Olympics as a speed skater and they have not like they haven't built that yet. And that's okay. Like you can't build it overnight. And there's nothing wrong with you. And I advise people to like put in the the practice and the reps. And I mean at formation it's really important to get feedback because if you just do this without feedback then you don't improve. If you kind of set yourself up to do practice, get feedback, iterate, and really have the grit to keep go following through on that, then you can get to that super top tier stage of I think like any any skill. So when you say taste, are you saying uh like your intuition behind how you design software or are you talking about problem taste like which problems are worth solving for the business? Which code matters more? both for different people like a product and a product manager is their taste is probably more in terms of prioritizing what products features to build and they probably buil they build that up through building lots of products failing failing building something doesn't work building something doesn't work all the junior product managers super ambitious they just need to keep shipping things and seeing what doesn't work and they build that up um and then you see the like exceptional product managers like 90% of the stuff they shipped was like not good at or failed for some Um, and that's why they're so good is because they learned all they learned each step of the way and then they made changes and grew from it. So I'm talking about that for an engineer that applies to like or for me at least that applies to code itself and writing code and the strategies to moving really fast and stuff like that. Yeah. you mentioned about uh changing other people's code or the social norms around touching code that other people own and you know you said something about landing a bug in that codebase kind of really could blow up in your face. So did you ever get feedback from other teams because it sounds like you were kind of touching everyone's code and how did you handle that feedback? Like I think there were some times where like you know going into a codebase replacing some old like framework that on like the live version of their tool the team's tool um and they were already building a newer tool and maintaining like carefully maintaining backwards compatibility and they have lots of like diffs and pull requests in play that were like they had like their thing going and by like just showing up refactoring at some some stuff in the old tool and then leaving it like made their it caused a lot of merge conflicts for all their stuff in progress and they like weren't happy about it. um and they wanted to like revert the change from the code because they didn't want to have to deal with like merging that into their complex uh change, right? Um and that's feedback to be careful for that stuff like I would I would didn't pay attention to that. So it's like okay that is one one use case where you got to be careful is if teams are working on complex longer term thing migrations already like be careful in that area of the code. What about the case of ownership? So, you know, software isn't just about creating it, but there's all this management and maintenance burden after it's created. Did any team get upset? I said, "Hey, you add this feature, great, but who's owning this thing now? Who's going to actually maintain it?" That didn't come up for me. And I don't know if it's the philosophy. I don't know if it's still the case, but the philosophy back then was like every line of code you wrote, you're responsible for. Um Kent Beck talked about this recently that yeah he was like it's a really strong sense of ownership. So like if you if you are okay being woken up at 3:00 a.m. and you're going to respond and fix some bug in your code any time of the day anywhere then like do what you want with like you know don't write tests then go ahead as long as you're maintaining it. If you don't want that and you want to work nine to five, then you might want to write more tests to make sure that your code's stable when you're not around. Um, so I think if I like I I didn't just like touch code, didn't refactor code and forget it. I was responsible if there was any bugs and then in the future like sometimes two years later there's like something that I get an automatic bug assigned to me because it's like you touched this code last and I'm like oh man, I don't even remember doing this. Um, but then I would fix the bug because even though I didn't cause the bug, it was just like that is now my code. Um, now I didn't I didn't have any territorial conflicts because I don't I don't know why I I didn't I just didn't really come up. Um, I never I didn't like step on people's product judgment. I mean, this is part of the the judgment calls I guess that you're building up. Like it it's kind of like performing a surgery and you're not really like you got to be really careful about what you're changing. You don't want to impact. Like I said, I learned maybe learned the hard way from making some mistakes early on and being a bit too aggressive in certain areas. Like you start to learn where that line is between um like messing up people's day-to-day and not and still getting the refactoring or the cleanup done. One thing that I'm curious about you, as you become a more senior engineer, it's very common to get pulled into more and more meetings. miscellaneous overhead. How did you manage your your focus as you got promoted to be a coding machine? You must have had a lot of focus time even as IC7. I really try to minimize my meetings. If someone like just added I don't know if this still happens, but people would like just make meetings, add you to the calendar, there's no context. It's just like something something like sync. You're like, I don't know what this is. I like would ask like what is this? Um, which I think people maybe I don't know if it's still like the the norms have changed, but I would push back on a lot of meetings. Um, I generally didn't do like go to standups unless it was like relevant. Like there's a we're working really hard to ship to something in a month. I need to go to the standup every day because it's like important to be on pace. But if there was like a standup that was more like just social chitchat like cuz the team I don't know some standups end up being that way. I don't know if you've seen them, but like it happens and I would not generally go to those. Um, but yeah, so just being pretty pretty strict about time and then also like having the manager support was like pretty important. like I wouldn't I was pretty choosy and I like went on very I made very conscious team changes when I whenever I did change teams and the manager was like very like in tune with like managers at Meta um like their job is to make their reports perform exceptionally well. I think I don't know if that's how you would summarize it in one sentence, but like um like if your if your reports get promoted and have a lot of impact, like that's what makes you a recognized as a high performing manager too. And so my managers are generally trying to pro like protect me and manage me so that I can have the most impact possible, which means not getting pulled into a lot of meetings where unnecessary. But I also I think I was too arrogant sometimes and that's like one of the things I would tell my older self. Um like sometimes I I I definitely remember walking out on a meeting or two where I was just like I don't think this meeting is useful for me anymore. I'm leaving. I'm just leaving. You you said that? Yeah. Like I just remember this happening a couple times and I'm like wow that was like not like good behavior. like I wouldn't like I I I like almost feel really bad because like the person running the meeting probably felt really bad and now I feel like really really Yeah. Yeah. Did HR ever reach out and say, "Hey, you're you're productive, but can you be nicer and stuff like that?" Uh, no. I don't I mean I I don't because I wasn't like mean. It wasn't like a flip the table type thing. It was like very and I would talk to the like I had a good relationship with most like I think all the PMs I worked with I had a pretty good relationship with because I built stuff really fast. I fix bugs really fast. Like not even my own bugs. Just like if they h the PMs like the PMs that a lot of the PMs that I mean Meta is very high performing company. Almost everybody's very strong who works there. And like the PMs are like they want to like get stuff moving fast. They pay attention to every pixel and they're like, "Oh no, this is like broken. This this test wasn't configured right." And there's like things that I was very helpful to PM. So they actually like liked me a lot. Um, and if I like walked out of me, if I like had to leave a meeting, it was like they would almost like give me permission like yeah, like Michael, you don't really you're not needed for this next part of the meeting, you can go. Like it was not as jerkish as it sounds. But I just remember being like that cutthroat where it was just like like I don't want to spend times in meetings that I can't be coding. Like it was like that that uh that vi that that level of like strictness. I would say you mentioned that your productivity over your whole career was was high and it didn't change that much. It just what changed was what you wrote code about and the problems that you solved. How did you like grow that skill of project taste or picking problems that mattered so that the code was more impactful? I I don't think that so first of all I don't think that I'm like great great at it necessarily. I generally picked and I'm still not good at pri prioritizing in general. I pick things that I like know how to do if that makes sense. All right. I pick things where I see the answer in my head and um it's just how fast can I like type or like get this into the code. Um, and which is also why LLMs particularly are helping me be personally so much more efficient because it's like I have what I want to do in my head and I need to get it out fast and LLM can really help with that. Yeah. So, sometimes like it might not be the most impactful thing but it's like a tricky thing and I have the idea in my head on how to do it. I might just do it even though it's not as important as like another thing. Honestly, this is probably one of the things that held me back career-wise. And it was also frustrating for my managers if they did try to communicate like, "Hey, this thing's very important. Can you do that?" And I'm like, I don't see the answer to it. Like, it's not I don't I don't have it. If I don't have it in my head, I can't do that like super fast. I like need to have I need to like see the answer, you know, in a sense. Um, so I'm going to work on B. It's like, can you please work on A? It's like I have to do B C D E F G H. It's like, okay, that's like a lot of work and that's like helpful, but like A would be really good. And I just like I that was like and I think that that's one of the things that probably held me back in general because that limit like if A really really was so important and I and it was not done, you know, it's like you get a passing grade for doing all the other stuff and it's appreciated, but like the company would overall impact would probably be higher by doing a if I was able to do it. But um I'm somewhat limited by like what I can figure out how to do. I frame it as a weakness. But yeah, that's interesting. So you always optimize rather than business value fully. You your rank ordered list of priorities was what can I just crank out instantly. Yeah. And if you crank out enough stuff, it adds up and it can have a huge amount of impact. But it is definitely definitely like a a different way of thinking of work, I think. Yeah. So once ## IC7+ only group [01:10:30] you got promoted to IC7 I think you had shared that you were added to an IC7 plus only group and I'm curious was there anything interesting you learned by being a part of that group or was there anything common among all the IC7 plus engineers? There's a certain there was a certain kind of bar that everyone had regardless of if they were a coding machine, regardless of if they were a specialist or a fixer, these different like uh reasons why they're there. Um, everyone had like certain traits that were common like extremely strong diligence and conscientiousness. Um, and very uh I wouldn't say fast or quick. I don't know the right word, but like very like sharp. Sharp is the word I'm looking for. If uh if this group was even me as someone who I feel like I'm not I was a very strong student in school. I was like straight A student. I think I'm a pretty smart person, but the most of these people are still are like smarter. Like these are exceptionally smart people who I would who I have to like acknowledge might be smarter than me. Um, but we all could be in the same room and talk about something like very and very quickly move through the concepts. So like here's this new proposed protocol and instead of like having an hourong presentation on it and discussing it, everyone would be pretty sharp sharply be like, "Oh, what about ABCD?" And like the qu follow-up questions would happen very quickly. Um, very sharp fast conversations. Um, and very high attention to detail. Some people like were really like earlier in their career accelerated very fast. They had these traits. Maybe their personality traits. Like for me, these are more personality traits. I would say like it's like leveraging like OCD and like a way a productive way to be like obsessed about every detail of the product instead of like things that are not productive. For other people, they had like their 25 years of experience and they kind of built these things through different ways, but like everyone kind of had that. Um whereas when a lot of conversations with junior people there's a lot less cont there's context missing. There's not necess like the follow-up questions are not necessarily as like sharp and on super fast. It takes a little longer to get things out. Usually the projects are smaller in scope as a result and stuff ## Landing code faster [01:12:55] like that. One thing I want to go over is kind of like a set of topics on just how do you how do you land code fast? Like let's say you're I'm a you know new software engineer. I want to absorb your your coding machine's abilities. Is there a you know top 20% of tips that get is going to give me 80% of the benefit to become more productive? The general advice is you have to move move you can say it just in the shortest possible just like do something like write code. A lot of people I I who ask me for advice or questions like they're like thinking too much about what to do and not doing enough. Um so like step one is like do something just do anything. Um and then step two which is critical is getting feedback from uh like respected people or or people who who have that experience and taste and judgment or further down the line and getting feedback from them. and then actioning that um and then repeating. I thought that my manager hated me because I was writing so much code so fast that was like so bad and he was writing he was doing code reviews and his code reviews he was like he was like very frustrated because he was spending like all day reviewing my code because I was writing so much code and it had so many problems and he was just like please follow the style conventions like there were please like like these kind of things right and like it sounds like that's annoying but that's like step one is you got to get like the raw the raw gears turning and then once the gears are turning getting the feedback and then iterating. So if you're if you get feedback like follow the style guidelines, then you actually have to do that next time and then there'll be something else wrong and then you improve it. And that cycle like that compounds exceptionally quickly. If you're writing a lot and you're getting the getting feedback from experienced people and you actually action it, it works really well. The like the biggest mistakes people make are there's uh three mistakes I think. The first one like not turning the gears and not doing anything like I said earlier. The second one is not getting feedback from the right people. So, if you get feedback from like if you're a boot camp grad and you're getting feedback from another boot camp grad who graduated like six months before you who's like the instructor now and they're giving you feedback like as the instructor like that feedback is probably it doesn't you're not you you can't it doesn't encapsulate that experience and taste and that judgment that you want to learn from that you're trying to learn from in this process. it encapsulates the judgment of someone who's like a little tiny bit further ahead of you. Um, so you want to get feedback from people who have that the judgment and taste that you aspire to. And then the third mistake is, and this is a mistake that I made a lot that I would tell myself to not do. Um, but is not actioning the feedback and taking it more like judgment and approval rather than feedback. So if someone gives you feedback and you're taking it as like a judgment or an approval, you want to pass the test and it's like you failed and you want to pass it and you're not actually reflecting on the feedback. You're just taking as approval. You're not going to iterate fast enough. You're not going to make enough changes. You might change the wrong things because you're not accepting the feedback. So if you do all that, I think you can and and you do it fast, you can accelerate your your progress so much. You're saying uh basically shorten the cycle time and then make sure you get good feedback and then internalize it and just that's going to compound. Just shorten that loop and just keep going, keep going, keep going. I see. Let's say I am I'm outputting a ton of code. I'm already a code machine, but I'm uh I want to get better. Do you have any advanced tips on how to take it to that next level? Let's say I'm pretty productive already. I would be ambitious, more ambitious probably if you're like if you have like your coding machine thing going like take on something ambitious that is pushing yourself a little bit outside of your normal scope of wherever you're you are you're in the code or um like this is very specific to Facebook and Meta though in general because your impact is somewhat judged by like breadth and scope and like the wider the umbrella, the bigger the umbrella kind of the more higher level you are and the more recognition you get. So like in that environment like if you're a coding machine on your department like you got to push beyond the department and p push your comfort zone a bit. My advice to my like something like I saying I'm not good at accepting prioritization from leaders but that's actually the advice I would give though if you're stuck is to ask like talk like ask your I don't know I had many many one-on- ones with like the seauite at Facebook where I was just like hey Chris Cox like I need I want to talk to you about this thing and have a 15-minute one-on-one and just if you're a coding machine that has credibility already and you're stuck stuck like reaching out to more senior people in different areas and trying to get some ideas of those wider scoped projects if you're really stuck um can be a step forward. Coming to the end of the ## Why he left Meta [01:18:29] interview just want to do some you know career reflections and stuff like that and you were at Meta for quite a while and you had a lot of success. I'm curious why why did you leave Meta and what was your thinking behind the career planning there? So Meta got like quite big quite fast. Um, and there was like this turning point I six years, threequarters the way time through there where I felt like when I was all in on on Facebook, I felt like it had my back like 100%. I had their back 100%. It was like a little bit like culty maybe like vibes. Um, and then it felt more like a company, like a business, like a business relationship. Um, it was changing. So, that was kind of like the first sign where I was like open to leaving. Um, and then I won't go into all of the details about the vesting cycles, but there were some vesting logistics. Certain years they like had some longer grants for various reasons and the vesting cycles and overlapping and stuff. there was like a very strong point where it was like your compensation your take-home pay is going to drop like 80% in a month like in a certain over a certain period. So I was kind of like okay you know like this is maybe the time to like ramp down. So I think after the previous performance review cycle when that was coming up I basically said like I'm going to be leaving in three months. Um, and then I did a little farewell tour on Messenger for kids to be like my manager was like, "Okay, like do you want one last harrah?" And then they did this project worked on this project. Um, and I kind of like slowly ramped down over that period. Um, and I was like taking home stuff from my desk every day like slowly slow ramp down. Um, but it was definitely it was just kind of that like at formation now. I mean obviously I'm a founder so it's also I have more control over the the that but um it's really like an all in I'm like allin or not allin and that allinness like broke like somewhere threequarters of the time through through meta as it got bigger and bigger and I like needed to put that somewhere else that that dedication somewhere else. Yeah. I mean getting a 80% pay cut is uh coupled with the cultural changes you know makes seems like a good timing to leave. So when it comes to the highest ## IC7+ talent [01:20:52] levels of performance in IC's, what's your take on how much of it is talent and how much of it is hard work and growth? There is talent. Some people have more talent than others. Some of it is maybe your biology. Some of it's just how you grew up and opportunities you had and some of it is you have raw talent that's not discovered yet. there's like all kinds of views on talent, but it is a thing and it does come into play. Um, so there is an aspect of things that are talent in quotes. If you feel like you're like, "Oh, no, I'm not talented." Like you might actually be talented and it hasn't been discovered yet or you might be like talented at something that isn't your day job right now and you should figure out what that is. And that's actually like at formation that's our like big long-term vision is is we want and why I do what I do every day now is like we want people doing the work that is the most impactful work they can do and we want to help them find that work because not everyone grew up the same way with able to explore and find what that thing is and they might have not found it yet. We want like, you know, I feel I feel like everyone has some kind of talent or something that they're better than most other people at. And if you find out what that is, that is a big piece of the high performance. And you might not have that at your day job right now, and it might limit your performance a little bit. It's not it's not the whole thing, but it might limit it. On the other hand, um hard work is within your control. Um my friend Philip Zoo talks about this a lot. Um, but he says like talent is something outside of your control and luck is outside of your control, which is another thing that comes into play sometimes. But, uh, hard work is the one thing that's within your control. And if you maybe aren't you're in a place that you're you're good at your job, it's maybe not your like natural talent, but you're good at it and you like it and you want to keep your job and you want to do better, um, you can outwork people who are similar to you and you will probably be recognized more performance-wise as well. What percent of your career growth would you say is luck of the growth? Um I think it's 5050 in I came from Canada. I when I showed up on my first day of Facebook they gave me I like grabbed my laptop and left the onboarding room and they like called me back because they said that I didn't have my phone and I didn't know what they were talking about. It was like phones like they give you a cell phone and they gave us like all these accessories and like this bundle like it was like they were like red carpet. And I was like, "What is all this stuff?" Like, "I just need a computer." Like, it I came from a place that was a lot more of like the things you hear about tech and the way that engineers are like treated and compensated now is very was very weird. Um, so if I had like stayed in Canada and worked at a company, I would probably be doing quite well, but like I wouldn't have had the same acceleration. Um, the lock was really landing at at Facebook at the time that I did and it being like the perfect fit for my personality at the time and the values were extremely aligned. Code was like aligned with what I could handle and that part is like pure luck. So, I would maybe just say 50/50. I've seen a lot of people who don't have the same like drive and got the luck piece and they're also doing very well. But like either one of those could work out and be okay. But I think I got both of those and that worked out very well for me personally. Yeah. Last question. Um if you could speak to ## Advice for younger self [01:24:28] yourself when you just graduated and give yourself some advice knowing everything that you know now, what would you say? I think going back to what I said earlier, um I was very much and I see this a lot with people preparing for interviews at formation nowadays seeking too much approval for like uh like pats on the back approval. They want to pass the test. They want to submit their leak code and see a green check mark. They want to um I was that person. I wanted to get the highest grades and I didn't really like know what I was learning even. I just wanted to get like an A+ or 100%. And because of that, I was not accepting feedback as feedback to improve. I was accepting feedback as grade to judge myself and put pressure on myself to get 100% next time. But I wasn't putting pressure on myself to actually improve. So my advice to people who are ambitious and who want to get those like perfect scores and check off all the boxes is to really reflect on feedback on how you can improve and try to push your comfort zone there instead of trying to look at it as a a judgment or a a grade. Awesome. Well, thanks so much for your time, Michael. I I was really looking forward to talking to you and, you know, hopefully the audience got something helpful out of this as well. Yeah. And if anyone has any follow-up questions, I'm like very very approachable. You can ping me on LinkedIn or Reddit or whatever and happy to happy to chat. Hey, thanks for ## Outro [01:25:58] watching the show. I don't sell anything or do sponsorships, but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interview. So if anyone comes up who you think you really want to hear their career story, uh, let me know and I'll try to reach out to them and get them on the show. Thanks for listening as always and I'll see you next time.