Meta Senior Staff Eng (IC7) On Zuck Stories, Rapid Career Growth, Code Machine Archetype

Michael Novati got promoted to Senior Staff (IC7) Eng at Facebook by the age of 27. He did it while the company was still called Facebook so he had a bunch of interesting pre-IPO stories. In our conversation, we discussed: • Growth to Senior Staff (IC7) by 27 • Being the #1 code committer at Meta • Volunteering to resign if his code broke prod • Stories of working with Zuck pre-IPO • What was common among IC7+ engineers • How LLMs will affect the code machine archetype Timestamps: (00:00) Intro (00:46) Joining Facebook (10:26) Facebook IPO experience (16:30) His internal newsletter (24:26) Working with Zuck (29:50) Engs that impressed him (36:20) Will LLMs kill coding machines? (47:20) Operating as an IC7 (1:10:30) IC7+ only group (1:12:55) Landing code faster (1:18:29) Why he left Meta (1:20:52) IC7+ talent (1:24:28) Advice for younger self (1:25:58) Outro Where to find Michael: • LinkedIn: https://www.linkedin.com/in/michaelnovati/ Where to find Ryan: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  This needs to get in, and if it breaks the site, I will resign.

• 0:04Ryan Peterman?

  This is Michael Novati. He joined Facebook pre-IPO and shared a ton of interesting early stories.

• 0:10Speaker 00

  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...

• 0:17Ryan Peterman?

  At Facebook, he went from an intern to a senior staff engineer in just a few years.

• 0:22Ryan Peterman?

  Was there anything common among all the IC7-plus engineers?

• 0:26Speaker 00

  The engineers that most impressed me.

• 0:28Ryan Peterman?

  I think you'll like the full episode, since I asked some tough questions and he was transparent throughout.

• 0:32Speaker 00

  In spirit of openness, I want to try to talk about it, but carefully.

• 0:36Ryan Peterman?

  Do you think that LLMs will kill the coding machine archetype?

• 0:45Ryan Peterman?

  Let's get into the interview, and I 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?

• 1:04Speaker 00

  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. I was gonna 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, interesting product work. 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 it wasn't that hard to get interviews. I think I just applied online for both.

• 1:47Speaker 00

  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 internal collaboration tools, which was like Meta's diff review tools and 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... 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.

• 2:31Ryan Peterman?

  How big was the company at the time in terms of engineers?

• 2:35Speaker 00

  Yeah, it was about 220 ish. 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 was about 200 or so, yeah.

• 2:49Ryan Peterman?

  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?

• 3:01Speaker 00

  Yeah, it's, it's really interesting. It was both technical and also the social vibe, 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 in my dev server. And it was just hitting a database, MySQL database, just like I would in a side project, except it was a much larger SQL database and a federated one. 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.

• 3:41Speaker 00

  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. And I just kind of really wanted to make a good product for all these people who cared. So both those things, I think, yeah.

• 4:22Ryan Peterman?

  When I joined Facebook and a lot of my peers also joined as well, PHP was something that...

• 4:30Ryan Peterman?

  I don't know, I want to say 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. It was something that was pretty unattractive. Did you feel similarly when you joined Meta?

• 4:43Speaker 00

  So now Meta uses primarily Hack, which is the derivative of PHP. That'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. And the first step was just having a, like a compiler for PHP that turned it into more performant code. And those efforts were ongoing at the time. There was discussion of like, should the company change from, 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.

• 5:27Speaker 00

  Yeah, so they kind of, I feel like 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, both sides of that. So yes and no is the answer.

• 5:51Ryan Peterman?

  Yeah, yeah, no, definitely. I think PHP gets more of a negative wrath than it actually deserves. And Hack is a much better experience. It's not comparable to PHP, so that makes sense. On the culture, you know, one of the early things that I really liked about Facebook was this move fast and break things culture. I just thought it was such a cool framing, or something that mattered a lot to people. Since then, that culture's changed. What are your thoughts on, on that?

• 6:22Speaker 00

  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 personally. I think that the removing the like break things part. 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. 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 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.

• 7:06Speaker 00

  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 it was a really like, I think more in the spirit of first principles thinking than like actually just like. Causing havoc. So I still think that that's a good, good motto if they had it today, but. At the same time, like when a company is larger, more mature. 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 and so financial impact. So I think it's also, I can see also that motivation for including it too.

• 7:50Ryan Peterman?

  And you're throughout your tenure, you started when it was so small, 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?

• 8:01Speaker 00

  So when I joined, and this was going back to kind of maybe what was like appealing about Facebook at the time. The culture is very engineer driven at the time.

• 8:13Speaker 00

  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 it was like to the extreme, where engineers were very empowered to make decisions. 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. So there was like a lot of like, engineers were empowered to push back and negotiate with designers. 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 used them.

• 8:58Speaker 00

  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, not crashed completely, but it tanked after the IPO. 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. 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.

• 9:41Speaker 00

  To, you have to like, in at least capitalist society, you have to make money to keep that going and keep growing it. 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. 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. So this is an example of the engineering empowerment, too.

• 10:25Ryan Peterman?

  I see. What was it like when Meta IPO'd? What was like the feeling among the team? Was it ecstatic? Or people were scared because the drop in the stock price?

• 10:35Speaker 00

  People definitely weren't scared. I would say that it was like a celebratory moment. It started off not, not being one of those things like. 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. It was just very much like, you know, IPO-ing 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 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.

• 11:18Speaker 00

  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 just 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 know. It was like some, there's way more to that story that you should dig into. Ask internally about that. There's probably something about it. But yeah, it was really cool. Like, 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.

• 11:58Speaker 00

  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.

• 12:22Ryan Peterman?

  Right. When it vested, was that after it had tanked a bunch?

• 12:27Speaker 00

  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.

• 12:35Ryan Peterman?

  Okay.

• 12:35Speaker 00

  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.

• 12:45Ryan Peterman?

  Yeah.

• 12:46Speaker 00

  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, it was 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.

• 13:12Ryan Peterman?

  Did you hold because you say, oh, this is, this is gonna go up and you know, we've got this? Or were you the type that's diversified, put it in index funds type of, you know, as soon as you get vestings?

• 13:25Speaker 00

  I held all my IPO stock and I still have all of it.

• 13:30Ryan Peterman?

  Oh my God, you really believe?

• 13:32Speaker 00

  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 best 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 guard, 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 manage. Just had, they were, had nothing to do with like the IPO per se, but just how to manage finances and how to deal with stock, like stock based compensate. I grew up in Canada, stock based compensation was like, I had no idea what that was. Like I didn't, I, I could read the paperwork, I can do the math, but like I didn't really like deeply understand it.

• 14:15Speaker 00

  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.

• 14:32Ryan Peterman?

  I mean Meta's 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?

• 14:41Speaker 00

  I mean, I have like diversified enough now that it's not like my retirement like collapsed like type thing. It wasn't that, but it was definitely sweating a bit like, like, oh, these numbers are low. Like, yeah.

• 14:55Ryan Peterman?

  Yeah, yeah, 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.

• 15:08Speaker 00

  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, so formation 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 head to head. And they're sweating over like single digit percentage differences. Like it's a lot of money. Engineers get paid a lot of money. They're, 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.

• 15:51Speaker 00

  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 type thing. Yeah.

• 16:20Ryan Peterman?

  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 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?

• 16:46Speaker 00

  It sounds really immature in retrospect, but I had this like, it was called the Weekly Navadi. So 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, 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 in a single hackathon, it's a like an 11,000, you can probably find the PR somewhere, but, or the diff somewhere. But it was 11,000 lines, I think.

• 17:30Speaker 00

  It's like not how you build code. So I had to like organize a meeting to review that code where it's like get engineers in person because no one could actually review 11,000 lines of code. It was anyways, I had rich text editing and kind of spruced them up a little bit. And it kind of evolved. I kept adding a couple of things here and there, tags. 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 I had a couple of posts that were just slightly controversial, controversial about like product building.

• 18:10Speaker 00

  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? Facebook was adamant about only having a Menlo 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 went like came true.

• 18:56Ryan Peterman?

  When you look back on that writing, 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?

• 19:16Speaker 00

  Overall, I would say that was not a good idea in retrospect.

• 19:20Ryan Peterman?

  Oh, really? Why is that?

• 19:22Speaker 00

  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. At the time, that was like a strong value. 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

• 20:06Speaker 00

  to improve it. Whereas like I see a lot of startups, a lot of bootcamps, like if they get a lot of, little bit of traction, 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. Bit of a tangent, but 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

• 20:50Speaker 00

  motivation. In retrospect, I would say I would not do it because it 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. It caused some like friction and tension sometimes. Like, there was one post where I just openly called out that 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.

• 21:34Speaker 00

  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 are 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 the 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. I'm 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.

• 22:16Speaker 00

  Did HR ever reach out to you saying, hey, you gotta 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 company. Like, I don't know. Uh, 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, 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,

• 22:59Speaker 00

  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 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 was still motivated to keep, keep posting, but yeah.

• 23:34Ryan Peterman?

  You could directly message Mark Zuckerberg and he would reply?

• 23:38Speaker 00

  Yeah, I mean, when I joined, Facebook was quite small. So I like, interacted with Foz, I think was my direct manager, skip 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 Foz and, and Zuck and like told them I'm leaving and, you know, they responded thanking me for the contribution 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 of years.

• 24:23Speaker 00

  Has, Facebook has really like exploded, but yeah.

• 24:26Ryan Peterman?

  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?

• 24:34Speaker 00

  Actually, I worked with him on a hackathon in 2009. Zuck 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 with another engineer, Tom Witna. We kind of got it working, but the code was just so bad, we, it never got shipped at the time. But he, Zuck just like, did not give up on that idea though. And like, I remember when, I think Sammy Krug, I think is still at Meta.

• 25:15Speaker 00

  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 Zuck's code.

• 25:32Speaker 00

  Well, there was another time, though, where he actually merged to PR. And this is actually like a Facebook, like, this is a crazy story, but there was like this lockdown period in 2010 where Facebook was very concerned about Google+ potentially making it 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 Friday Q and As, company-wide Q and As,

• 26:10Speaker 00

  I basically made that 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 and it's now banned, that I would do around the office. And then if he didn't commit the code, I can't remember what the penalty was. Man, I don't remember what it was.

• 26:33Ryan Peterman?

  Well, ripstick is that thing that like, you go like this, right?

• 26:36Speaker 00

  Yeah, it's a two-wheeled skateboard and you have to like wiggle your hips. I like, got, got really good at it, but 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 2012-ish. 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 ripstickers 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, a draft email banning ripsticks. And at that, I didn't realize

• 27:21Speaker 00

  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, you know, ripsticks are gonna get banned, but can you give us like feedback on how we communicate this? Like, I wanna 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...

• 27:50Speaker 00

  Or else it could be like a revolt. That was like a big tangent, but yeah.

• 27:54Ryan Peterman?

  Oh, yeah. What about the Zuck thing? He merged the PR and...

• 27:57Speaker 00

  Basically, it was a bet in front of the whole company. And then he actually like merged the PR. So then I think I was banned from writing ripsticks.

• 28:08Speaker 00

  Indoors or outdoors? I think they like qualified it. Just to... There was like a loophole, but yeah.

• 28:13Ryan Peterman?

  There's all these stories of like early Facebook where Zuck 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 source control early was. Would you see like those people's names in there?

• 28:30Speaker 00

  Yeah, 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. But they wrote code fast and like they did a good job of what they were doing. But there's kind of like this like wave of engineers where Facebook poached a bunch of former Harvard people from Microsoft. I think Boz was in that wave too. But there's 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

• 29:15Speaker 00

  who really started writing like more of the core abstractions and the stuff that was the foundation for the product infrastructure team. I don't know if the team still exists today, but existed for a really, really long time. Who builds all those core abstractions and maintains them. And

• 29:33Speaker 00

  that wave of people, their names are like all over the codebase, like Evan Priestley and Putnam and 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.

• 29:50Ryan Peterman?

  Yeah, I'm kind of curious. You know, you, you grew into such a strong engineer, senior staff, IC7. Who were the other engineers that you looked at? You said, "Those people really impressed me and why?"

• 30:03Speaker 00

  The engineers that most impressed me was the product infrastructure team working on like the React framework nowadays. But at the time, it was more like the PHP abstractions.

• 30:15Speaker 00

  Like Nick Schrock and Ola and... They were kind of, it was like building out the end framework of today. Like, that was built through my time. So I saw that gonna get constructed brick by brick. And those people I kind of saw as like the best engineer kind of thing. Dan Schaefer, I think Dan Schaefer might still be up, 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 Presley, who I think was like the number one committer before me. I don't know if he invented Clown, I don't know if he still have Clown Town. This idea of Clown Town was like if you like caused a really bad silly bug

• 30:58Speaker 00

  or typo or something, or like you break main or something like that, you would be like added to Clown Town philosophically.

• 31:05Ryan Peterman?

  Oh.

• 31:05Speaker 00

  He had a certain type of humor, I would say. But, but he was very prolific. He single-handedly wrote the diff, diff review tool, diff camp at the time, which became Fabricator. And like when he left, they forked, they kind of open sourced it. And he like wrote all of that entire product suite from scratch, like himself, basically.

• 31:26Ryan Peterman?

  Let's say you are, 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 senior engineers. You know, which would you rather take?

• 31:45Speaker 00

  Evan Presley.

• 31:46Ryan Peterman?

  Wow, okay. So how, how many senior engineers does it take till you would pick them over Evan?

• 31:55Speaker 00

  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 the coding machine, let's put him on like Oculus. Firmware or something. I would not be productive at first.

• 32:40Speaker 00

  It would probably take me a really long time to absorb everything and suck everything in. But it's not like, it's have like this magic power to do that. So I think it depends a lot on the context. Like, if you're at a company and everyone's already ramped up on this thing and you have that choice, I would probably choose the coding machine. 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. 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

• 33:25Speaker 00

  not have happened if it wasn't for the single person, whether it's me or Evan Priestley or a similar coding machine. Like, 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.

• 33:41Ryan Peterman?

  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?

• 33:53Speaker 00

  The canonical example for myself is, there's this framework called Preparables. It was a framework that, in a given component, separated the rendering code from the data fetching code. So like a given component on the screen would have a data fetching function and a rendering function so that you could kind of, in different pathways, 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 complexities with suspense

• 34:36Speaker 00

  and spending and all these like more intricate things. At the time, it's fairly simple, just like component, two functions, fetch data, render. That framework basically got replaced over time with async await and 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. And I like- Manually relentlessly refactored and removed every single preparable until literally the the parent class was removed from the codebase. And I think there was three, like, three, five, six thousand of them or something.

• 35:17Speaker 00

  It did take several months, but like, I don't think that would have happened. And it was a single-handed effort. 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. And another project I did was to remove every single one of those and only use like the routing framework. And it's again, like, something that if there wasn't like the drive, the grit, the priority,

• 36:00Speaker 00

  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.

• 36:20Ryan Peterman?

  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 in the future, or maybe even now, to be honest. And so, my question is, do you think that LLMs will kill the coding machine archetype?

• 36:39Speaker 00

  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. 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. 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.

• 37:18Speaker 00

  So the, the current wave of AI tools, LLM-based AI tools 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 refactoring faster and changes faster. The next evolution going into that, you know, we're seeing some, some agentic flows in coding popping up already, some success cases here and there. It's not like mainstream. I think that those flows will probably be even more replacing of like those basic functions.

• 38:03Speaker 00

  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, the 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. 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.

• 38:44Speaker 00

  And then the agentic flows that happen after that, like, I don't, I don't know, I'm not, 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.

• 39:00Ryan Peterman?

  What's the biggest difference between, you know, how you used to work? I mean, you mentioned this Vim workflow is basically your handwriting the code and doing everything yourself to using the LLMs. Like, what are the biggest differences you noticed?

• 39:14Speaker 00

  I'm in a codebase 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 code-wide agentic flows or multi-file flows in general sometimes, but not often. 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.

• 40:01Speaker 00

  If I want to write an entire component that I think is going to be like 100 lines of markup for the page.

• 40:11Speaker 00

  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. 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. 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.

• 40:52Speaker 00

  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 end game here. 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, a new command line tool, stuff like that, yeah. So it's interesting time for sure to be an engineer in general.

• 41:20Ryan Peterman?

  It's interesting, I mean, today and maybe soon also. It just 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 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?

• 41:48Speaker 00

  I think it's a cool future. We talk about all the cool things that engineers do 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.

• 42:32Speaker 00

  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 is probably like the perfect example of this, where he can just like plop into whatever he wants to work on 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. 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?

• 43:16Speaker 00

  Like, and it's kind of, AI is already 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 the 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. 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.

• 44:00Speaker 00

  Like, 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 an API and it's going to 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 mistakes. 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 do those things.

• 44:45Speaker 00

  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?

• 45:03Ryan Peterman?

  Right, right.

• 45:04Speaker 00

  That's where I stand on that, but yeah.

• 45:05Ryan Peterman?

  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?

• 45:18Speaker 00

  Yeah, I don't, I, it might fall under the specialist archetype, where you're really, really, really good at one stack. 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 it's like, you can look up the specs by 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 bucket. 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.

• 46:02Speaker 00

  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. So I kind of respect those engineers for what they do and I have like my thing and I think that the whole team is exceptional if it has these different players.

• 46:29Ryan Peterman?

  I see. So what impressed you about those engineers is that they solved problems that other people couldn't?

• 46:34Speaker 00

  Yeah. And 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. 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. So there were some similarities a little bit, but that I like respected that work a lot. 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.

• 47:18Speaker 00

  So I respected them for that.

• 47:20Ryan Peterman?

  I wanted to talk a bit about your career growth because you grew to, you know, senior staff for IC7 at Facebook. There were less IC7s at that time, so it's even more impressive that you did that and as quickly as you did it. So I'm curious to kind of dig into some of the, you know, behind the scenes in it. I think you've told this story publicly a few times, so I kind of want to ask some of the side topics on it. So 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.

• 48:02Ryan Peterman?

  How does that work if, you know, you're getting work from your current team? Can you talk about that?

• 48:07Speaker 00

  I think the way I framed it is like almost being like a senior engineer on a small team of 10 people and then spending like more than half my time doing kind of code based wide initiatives, cleanup, refactorings, a new framework, sometimes some random.

• 48:29Speaker 00

  Random one-off thing a team needs help with or something like that.

• 48:34Speaker 00

  Emergency like other work. 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, it wasn't like 30% of my eight-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, 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 mid-level.

• 49:12Speaker 00

  Those kinds of things, writing a lot of code on features that the team queued up, like the team had. Just, you know, contributing to them. 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 A, B, C. And it's like, okay, well, A and B, I think the team can do, C they can't do. Like, you know, the 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.

• 49:46Ryan Peterman?

  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 of that, that I see is doing majority of their bandwidth is solving problems all over the place. So how did you manage that relationship?

• 50:10Speaker 00

  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 more junior manager. I would almost like help them manage the team and then like. Really report to the skip kind of thing, like unofficially report on like vibe. So it was definitely like interesting relationships, like the head up, 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.

• 50:44Ryan Peterman?

  So in the org chart, you reported to a frontline manager, but in practice, you were almost dotted line reporting to some more senior people and you were known as a, it sounds like a weapon of the org. 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 IC seven, solving the hardest problems for the org role?

• 51:19Speaker 00

  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.

• 51:38Speaker 00

  Like there is, there was two different, a fork of the task tool. 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 slimmed down one with all the features of the bloated one. And it was, I just like literally just took the initiative entirely on my own. I didn't even like tell anyone.

• 52:21Speaker 00

  I mean, this is so early on, you could not do this now, but like I didn't tell anyone. I just 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 vibe, vibe, not, not in a mean way, just like it's done, like. Like, surprise. Right. That, so 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, patted me on the back and thought it was amazing because, like, no one could have done this. So like, all, overall, I was still positive, but like, that would not be, like, the things I learned were like,

• 53:05Speaker 00

  judgment calls about like, the scope to change things at, um, 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 Right. learn, take the feedback, and then keep going at the same speed while like, improving my judgment and building that taste.

• 53:45Speaker 00

  Um, and I think that accumulation of judgment and taste is what crosses the line to the E7. But the raw output, it wasn't like the raw output kept going up. 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 org, 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 talking 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

• 54:25Speaker 00

  In their org, similar to yours, like it's kind of, it's very dependent on the context, but yeah.

• 54:31Ryan Peterman?

  If I'm understanding correctly, then you were able to work on all this extracurricular, you know, org-wide 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 gonna stop you. Like, let's say you, you have your, your project on your team. No one's gonna 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.

• 55:09Speaker 00

  Yes, but I really think that the jud, the judgment and taste piece though is like so critical. 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 the coding machine. So I have to like build a relationship with the pushing team so that they really trust me.

• 55:52Speaker 00

  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.

• 56:01Speaker 00

  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, that, that is really important. It's not only the raw, it's like much more than the raw output there.

• 56:30Ryan Peterman?

  Would you have resigned if you, if you broke it, broke it again and you said you would?

• 56:35Speaker 00

  Yeah, I think I would have. It's like that's 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 the bottom 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.

• 56:55Ryan Peterman?

  You talked about taste and judgment when it comes to code and software engineering. What does that mean?

• 57:02Speaker 00

  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 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 context they're in, 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

• 57:45Speaker 00

  muscle memory about dancing or a 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.

• 58:27Speaker 00

  Like it's like every detail you will over time accumulate by putting in the time and gaining that experience. And I see far too many people rushing early on where in their careers where they're trying to like jump ahead or 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 following through on that, then you can get to that

• 59:11Speaker 00

  super top tier stage of I think like any any skill.

• 59:16Ryan Peterman?

  So when you say taste, are you saying 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?

• 59:31Speaker 00

  Both for different people, like a product and a product manager, their taste is probably more in terms of prioritizing what products, features to build. And they probably built they built 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. And then you see the like exceptional product managers, like 90% of the stuff they shipped was like not good and or failed for some reason. 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 for an engineer that applies to like, or for me at least, that applies to code itself

• 1:00:16Speaker 00

  and write code and the strategies to moving really fast and stuff like that, yeah.

• 1:00:20Ryan Peterman?

  You mentioned about 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 code base 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'd you handle that feedback?

• 1:00:45Speaker 00

  Like I think there were some times where like, you know, going into a code base, replacing some old like framework that on like the live version of their tool, the team's tool. 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 that, 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.

• 1:01:23Speaker 00

  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 change, right? And that's feedback to be careful for that stuff. Like I would, I didn't pay attention to that. So it's like, okay. That is one, one use case where you gotta be careful is if teams are working on complex, longer term thing migrations already, like be careful in that area of the code.

• 1:01:47Ryan Peterman?

  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? They said, hey, you add this feature, great, but who's owning this thing now? Who's gonna actually maintain it?

• 1:02:07Speaker 00

  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. 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 3am and you're gonna 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 wanna work nine to five, then you might wanna write more tests to make sure that

• 1:02:49Speaker 00

  your code's stable when you're not around. 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. But then I would fix the bug because even though it didn't cause the bug, it was just like, that is now my code. Now, I didn't, I didn't have any territorial conflicts because I don't, I don't know why. I didn't, I just didn't really come up.

• 1:03:25Speaker 00

  I never, I didn't like step on people's product. Judgment, I mean, this is part of the judgment calls, I guess, that you're building up. Like, it's kind of like performing a surgery and you're not really like, you gotta 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, like, messing up people's day-to-day and not, and still getting the refactor or the cleanup done.

• 1:04:00Ryan Peterman?

  One thing that I'm curious about, 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 focus as you got promoted to be a coding machine? You must have had a lot of focus time, even as IC7.

• 1:04:19Speaker 00

  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 would, like, would ask, like, what is this? Which, I think people, maybe, I don't know if it's still, like, the norms have changed, but I would push back on a lot of meetings. I generally didn't do, like, go to stand-ups unless it was, like, relevant. Like, there's a, we're working really hard to ship something in a month, I need to go to the stand-up every day because it's, like, important to be on pace. But if there was, like, a stand-up that was more, like, just social chit-chat, like, because the team, I don't know, some stand-ups end up being that way, I don't know if you've

• 1:05:02Speaker 00

  seen them, but, like, it happens, and I would not generally go to those. But, yeah, so just being pretty, pretty strict about time. And then also, like, having the manager's 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 whenever I did change teams. And the manager was, like, very, like, in tune with, like, managers at Meta...

• 1:05:28Speaker 00

  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, like if your, if your reports get promoted and have a lot of impact, like that's what makes you recognized as a high performing manager too. And so my managers are generally trying to 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.

• 1:06:10Speaker 00

  Like sometimes 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.

• 1:06:18Ryan Peterman?

  You said that?

• 1:06:19Speaker 00

  Yeah, like I just remember this happening a couple of times. And I'm like, wow, that was like not like good behavior. Like I wouldn't like, 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.

• 1:06:39Ryan Peterman?

  Yeah, yeah. Did HR ever reach out and say, hey, you're, you're productive, but can you be nicer and stuff like that?

• 1:06:48Speaker 00

  Uh, no, I don't. I mean, I, I don't, cause 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 fixed bugs really fast, like not even my own bugs. Just like if they had, the PMs, like the PMs that, a lot of the PMs that we met at a very high performing company, almost everybody's very strong. It works there and like the PMs are like, they wanna 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. And if I like walked out of, if I like had to leave a meeting, it was like,

• 1:07:33Speaker 00

  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 wanna spend time in meetings that I can't be coding. Like it was like that. That in that level of like strictness, I would say.

• 1:07:57Ryan Peterman?

  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?

• 1:08:18Speaker 00

  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 prioritizing in general. I pick things that I like know how to do, if that makes sense. Or I pick things where I see the answer in my head. And it's just how fast can I like type or like get this into the code? And which is also why L L Ms 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 L L Ms 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.

• 1:09:02Speaker 00

  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. 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.

• 1:09:46Speaker 00

  Because that limit, like if A really, really was so important and I, and it was not get 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 have, overall impact would probably be higher by doing A if I was able to do it. But I'm somewhat limited by like what I can figure out how to do. I frame it as a weakness, but yeah.

• 1:10:08Ryan Peterman?

  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?

• 1:10:20Speaker 00

  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 how it work, I think, yeah.

• 1:10:30Ryan Peterman?

  So once 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?

• 1:10:48Speaker 00

  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 reasons why they're there. Everyone had like certain traits that were common, like extremely strong diligence and conscientiousness.

• 1:11:11Speaker 00

  And very, I wouldn't say fast or quick, I don't know the right word, but like very like sharp. Sharp's the word I'm looking for. If, 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. 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 hour-long presentation on it and discussing it,

• 1:11:53Speaker 00

  everyone would be pretty sharp, sharply be like, oh, what about A, B, C, D? And like the follow-up questions would happen very quickly. Very sharp, fast conversations 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 in 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.

• 1:12:35Speaker 00

  Whereas when a lot of conversations with junior people, there's a lot less context, there's context missing. There's not necessarily, 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 like that.

• 1:12:56Ryan Peterman?

  One thing I wanted 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 is going to give me 80% of the benefit? To become more productive?

• 1:13:20Speaker 00

  The general advice is you have to move, move. You can say it in just in the shortest possible, just like do something, like write code. A lot of people I, who ask me for advice or questions, like they're like thinking too much about what to do and not doing enough. So like step one is like do something, just do anything. And then step two, which is critical, is getting feedback from.

• 1:13:49Speaker 00

  Like respected people or people who have that experience and taste and judgment are further down the line and getting feedback from them and then actioning that 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 kinds of things, right? And like, it sounds like that's annoying, but that's like step one is you gotta get like the raw, the raw gears turning. And then once the gears are turning, getting the feedback and then iterating.

• 1:14:34Speaker 00

  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. So like the biggest mistakes people make are, there's 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 bootcamp grad and you're getting feedback

• 1:15:16Speaker 00

  from another bootcamp 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 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. So you want to get feedback from people who have 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,

• 1:15:55Speaker 00

  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 it 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 you do it fast, you can accelerate your progress so much.

• 1:16:29Ryan Peterman?

  You're saying, 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, 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.

• 1:16:56Speaker 00

  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 are, you're in the code. Or, 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.

• 1:17:37Speaker 00

  So like, in that environment, like, if you're a coding machine on your department, like, you got to push beyond the department and push your comfort zone a bit. My advice to my, like, something, like I was 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 C-suite 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,

• 1:18:17Speaker 00

  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, it can be a step forward.

• 1:18:29Ryan Peterman?

  Coming to the end of the interview, just want to do some, you know, career reflections and stuff like that. You were at Meta for quite a while and you had a lot of success. I'm curious, why, why'd you leave Meta and what was your thinking behind the career planning there?

• 1:18:46Speaker 00

  So Meta got like quite big, quite fast. And there was like this turning point, six years, three quarters the way of 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. And then it felt more like a company, like a business, like a business relationship. It was changing. So that was kind of like the first sign where I was like open to leaving.

• 1:19:19Speaker 00

  And then I'll 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.

• 1:20:00Speaker 00

  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 hurrah? And then they did this project, worked on this project. And I kind of like slowly ramped down over that period. And I was like, taking home stuff from my desk every day, like slowly, slow ramp down. 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, that, but it's really like an all in, I'm like all in or not all in, and that all in-ness like broke like somewhere three quarters of the time through, through Metas, it got bigger and bigger. And I like needed to put that somewhere else, that dedication somewhere else.

• 1:20:43Ryan Peterman?

  Yeah, I mean, getting a 80% pay cut is, coupled with the cultural changes, you know, makes, seems like a good timing to leave, so. When it comes to the highest levels of performance in ICs, what's your take on how much of it is talent and how much of it is hard work and growth?

• 1:21:02Speaker 00

  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. 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,

• 1:21:43Speaker 00

  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 the whole thing, but it might limit it. On the other hand, Um, hard work is within your control. My friend Philip Su talks about this a lot.

• 1:22:29Speaker 00

  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. You can outwork people who are similar to you and you will probably be recognized more performance wise as well.

• 1:22:58Ryan Peterman?

  What percent of your career growth would you say is luck?

• 1:23:01Speaker 00

  Of the growth? I think it's 50 50 and I came from Canada. I, when I showed up on my first day of Facebook, they gave me, I like got my laptop and left the onboarding room and they like called me back because they said I didn't have my phone. I didn't know what they're 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 right red carpet. I was like, what is all this stuff? Like, I just need a computer. Like 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. So if I had like stayed in Canada and worked at a company, I would probably be doing quite

• 1:23:45Speaker 00

  well, but like I wouldn't have had the same acceleration. The luck 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.

• 1:24:27Ryan Peterman?

  Last question. If you could speak to yourself when you just graduated and give yourself some advice, knowing everything that you know now, what would you say?

• 1:24:37Speaker 00

  I think going back to what I said earlier, I was very much, and I see this a lot with people preparing for interviews at formation nowadays, seeking too much approval for things, like pats on the back, approval. They want to pass the test, they want to submit their lead code and see a green checkmark. They want to. 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.

• 1:25:22Speaker 00

  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 judgment or a grade.

• 1:25:40Ryan Peterman?

  Awesome. Well, thanks so much for your time, Michael. I was really looking forward to talking to you and hopefully the audience got something helpful out of this as well.

• 1:25:49Speaker 00

  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 have me to chat.

• 1:25:59Ryan Peterman?

  Hey, thanks for 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, 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.