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

Episode Date: July 11, 2025

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 archetypeTimestamps:(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) OutroWhere 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

This needs to get in, and if it breaks the site, I will resign. This is Michael Novati. He joined Facebook pre-IPO and shared a ton of interesting early stories. Like, this is so much better than Zucks 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 LLMs will kill the coding machine archetype? 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? 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 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 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. And meta was just like our 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. That's exactly what I wanted to work on. I really wanted to work on like 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 and he was my manager

and 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 220-ish. There's some debate because at the time, production engineers, I don't think were classified as software engineers. So there was like the math in a very 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 your favorite parts? Yeah, 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 at my dev server, and it was just hitting a data. database, my SQL 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 just felt like I was home kind of vibe. And from that point forward, technically, I just felt really like in tune 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

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. When I joined Facebook and a lot of my peers also joined as well. PHP was something that, I don't know what I want to say, it's scared. It definitely was something that we were not attracted to.

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? So now Meta uses primarily hack, which is the derivative of PHP. I don't know if the language is officially forked or I don't know. 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 a 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 code base, 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 a 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. 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 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 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 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 with 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 breaking move fast and break things was about like trying to break established norms and thinking about things the different way and trying things from scratch and it was a really like I think

more in the spirit of first principles thinking than actually just causing havoc. So I still think that that's a good motto if they had it today. But at the same time, like when a company's 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. So financial impact. So I think it's also, I can see also that motivation for including it too. And throughout your tenure, I mean, 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? 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. 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 like 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 engineers. 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. So that actually gave like a 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 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 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 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 that's just an example of the engineering empowerment too.

I see. What was it like when meta IPO? What was like the feeling among the team? Was it ecstatic or people were scared because the drop in the stock price? 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, 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.

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 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 post it 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 it was like some there's way more to that story that you should dig into uh ask it ask internally about about that there's probably something about it but yeah but 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 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 yeah I mean financially all the stock vested like six months out 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. Right. When it vested, 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 sitting there and then like the stock hit their accounts. So it's like all the phones like went off and it's like you're vested stock.

has been deposited. Yeah. And it was kind of, I remember that moment. 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 having kids in the Bay Area is, like, super expensive. So having kids is even, like, a thing that you might, 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 going to go off and, you know, we've got this? Or were you the type that's diversify, put in index funds type of, you know, as soon as you get vestings? I held them at all my IPO stock and I still have all of it. Oh my God, you really believe. But I 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 old guard, so to speak, 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 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 compensation. I grew up in Canada, stock-based compensation was, like, I had no idea what that was. Like I didn't, 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 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 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. Are 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 retirement, like, collapsed, like, type thing. It wasn't that. Yeah. Like, it was definitely sweating a bit like, like, oh, these numbers are low. Like, yeah. 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 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 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 there 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 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 control. So I was talking with one of my old managers who's been at 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 was that and what made you start it? It sounds really immature in retrospect, but it was 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 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 mean, I supported rich text. In a single hackathon, it's like an 11,000. You can probably find the PR somewhere, or the diff somewhere, but it was 11. thousand 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. Anyways, to add rich text editing and kind of spruce 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 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 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 any. anything in San Francisco. And it's 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 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, 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? Why is that? So, okay, there was that 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 pleasant trees and facades and like what are things like more objectively and like what can we do? How can you improve them or like if you build a product and it got like a lot attraction 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. Whereas like I see a lot of startups, a lot of boot camps. Like if they get a little bit of attraction, 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. Generally my like philosophy is to be. just barely, 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 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 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. changed 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 are like my goal I'm working on this problem. I didn't like really did not help us like call this out like we have to

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 right 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, you need to take this down, like for the company, like, I don't know. 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. And 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 friction. But 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 posting. 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 FOS, 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. and Chris Cox and Shrepp and Jay and Boz 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 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 to 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, 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? Actually, he 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 was like working with him on that during a hackathon and with another engineer, Tom Wittner. We kind of got it working, but the code was just so bad. It never got shipped at the time.

But he was up 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, 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 Zucks code. But 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 there was like this lockdown period in 2010 where Facebook was very concerned about Google Plus 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, all in person. So I was there like all weekend. But during that period, I at one of the company Friday Q&A's company wine Q&As, 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 rip sticking.

which is 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 can't remember what the penalty was man I don't remember what it was but ripstick is that thing that like

you go like this right? Yeah you have to like 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 was 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 the time, I didn't realize this, but this was 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 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. Or else it could be like a revolt That was like a big tangent

But yeah I just Oh yeah What about the Zuck thing He merged the PR And basically it was a bit Yeah Bat in front of the whole company

And then he actually like merged the PR So then I think I was banned From riding ripsticks Out Indoor or outdoors I think they like qualified it Just to There was like a loophole

But yeah There's all these stories Of like early Facebook Where Zock 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 source control early was. Would you see like those people's names in there? 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 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 Microsoft like poked a bunch of former Harvard people from Microsoft I think boss 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 who really started writing more of the core abstractions

and the stuff that was the foundation for the product infrastructure team. I know if the team still exists today, but it existed for a really long time who builds all those core abstractions and maintains them. And that wave of people, their names are all over the code base, 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. Yeah, I'm kind of curious. You know, you grew into such a strong engineer, 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 nowadays, but at the time it was more like the php abstractions, 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 going to 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 a minute. 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 cause 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 certain type of humor, I would say. But he was very prolific. He single-handedly wrote the 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. 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? Evan Priestley. Wow. Okay. So how many senior engineers does it take till 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 who 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 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 you were like Michael's the coding meeting, let's put him on like Oculus. 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, 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 code base, 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 it's like that's kind of what makes you the coding machine at that level. is you're 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 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 path 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 complexity with suspense and spending and all these like more intricate things.

But 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 were thousands of classes throughout the code base that people would be interacting with on a daily basis that were preparable structured. And I like manually, relentlessly. refactor 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 it did take several months but like I don't think that would have happened and it was 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, 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. 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? So when I was doing all this work 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 code base, but it was a proprietary tool outside of any ID, 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. So the current wave of AI tools and the LLM based AI tools are kind of like a next step of going from VIM to VES code.

It's like going to a LLM AI powered mode that lets you be more productive, makes certain things faster, certain refactings faster and changes faster. The next evolution going into that, you know, we're seeing some some agentic flows encoding 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. 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 can 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 people who are pushing the leaning edge. So like everyone used. the tools, the way the 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. And then the agentic flows that happen after that, like, I don't know, I'm not decided yet on how that's going to impact the coding machine 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 code base, not a tiny code base, but it's like the size of a popular, like, open source big project. It's a reasonably sized code base. but it's small enough that I like still know most of the code structure in my head and everything so I'm not using that many code wide agentic flows or multifile 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 that code faster. If I want to write an entire component that I think is going to be like 100 lines of markup for the page, if 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 out 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. And I'm producing like five.

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 time a new model comes out, I am 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. 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? 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 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 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 i 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 build that, which is 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, 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. 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.

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

Right, right, that's where I stand on that, but yeah 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? How would you describe the archetype? Yeah, I don't know 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 a, I think it falls in a specialization bucket. Like in general, and the fan of the sports team analogy. So, like, you want, like, a professional sports team

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

So I kind of respect those. 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. I see. So what impressed you about those engineers is that they solved problems that other people couldn't. 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 made the thought process less overhead for an engineer to fetch data and stuff like that. So there were some similarities a little bit that I 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 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 your career growth because you grew to, you know, senior staff or 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. How does that work if 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 spending like more. than half my time doing kind of code-based wide initiatives, clean up refactorings, a new framework, sometimes some random, random one-off thing a team needs help with or something like that, emergency, like other work. So like the, I'd 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 a 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, 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 ABC, and it's like, okay, well, A and B, I think the team can do C, they can't do. Like, you know, general things the 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 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 I see 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 more junior manager. I would almost like help them manage the team and then like really report to the skip kind of thing.

Like an officially report to them 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. So in the org chart, you reported to a frontline manager, but in practice, you are 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 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 did you transition into that IC7 solving the hardest problems for the org role? Because in my case, 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. like 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 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 floated one. 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 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.

Not in a mean way. Which is 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 pat to 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 the things I learned. learned were like judgment calls about like the scope to change things at 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 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.

And I think that accumulation of judgment and taste is what crosses the line to the E7. But the rot 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, 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 talking 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, 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, 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's going to stop you. Like, let's say you have 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 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 really think that the judge the judgment and taste piece though is like so critical. Um, and it's more than just the code. It impacts like a 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 that 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 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 broke it again and you said you would? Yeah, I think I would have. It's like this weird. Maybe it's like 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 hot and break. You know, 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. 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 profile. That's to me like taste. There are some people who who naturally have instincts for maybe it comes from the way they grew up and their past experiences. They have and the context they're in, they have stronger taste to 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 a sport, other sports and stuff too are similar. It's kind of like that, but in the coding context of, you might read a book on how to be the best, like, 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 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 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 tastes like which problems are worth solving for the business which code matters more 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 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 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 and code and the strategies to moving really fast and stuff like that. Yeah. 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? 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 had 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. 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's this one one use case where you've 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 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 are okay being woken up at 3 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. So I think if I like 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 touch 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

I never I didn't like step on people's product judgment I get that made 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 like messing up people's day to day and not, and still getting the refactor or the cleanup done.

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? 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, you 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. in, 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 chit chat, like, because 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. 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 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, 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. Like, sometimes I definitely remember walking out on a meeting or two where I was just like, I don't think his meeting is useful for me anymore.

I'm leaving. You said that? Yeah, like, I just remember this happening a couple of times, and I'm like, wow, that was, like, not, like, good behavior. Oh, my God. Like, I wouldn't, like, I, like, almost feel really bad because, like, the person running the meeting probably felt really bad. And now I feel, like, really, believe it.

Yeah, yeah. Did HR ever reach out and say, hey, you're productive, but can you be nicer and stuff like that? No. I don't, I mean, 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 fixed bugs really fast. Like not even my own bugs. Just like if they had, at the PMs, like the PMs that, a lot of the PMs that, I mean, is a very high performing company.

almost everybody's very strong it 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 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 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, that level of like, strictness, I would say. You mentioned that your productivity over your whole career 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 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

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. Um, 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 LLMs 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 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 help 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 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. That's interesting. So you always

optimized, rather than business value fully, 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 different way of thinking of work, I think, yeah. So once you got promoted 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 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 reasons why they're there. everyone had like certain traits that were common like extremely strong diligence and conscientiousness and very uh 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 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 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, everyone would be pretty sharp, sharply be like, oh, what about ABCD? And like the follow up questions would happen. very quickly, very sharp, fast conversations and very high attention to detail. Some people 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. Whereas when a lot of conversations with junior people, there's a lot less contact. 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. 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 machines abilities is there a you know top 20 percent of tips that get is going to give me 80 percent of the benefit to become more productive the general advice is you have to move move you can say it to 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 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 running, he's 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.

really well. 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 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, like, that feedback is probably, it doesn't, you're not, you can, 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 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, 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. 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 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 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. 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 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, 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 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, 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. Coming to the end of the interview, just want to do some 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 did you leave Meta and what was your thinking behind the career planning there? So Meta got like quite big, quite fast. fast. And there was like this turning point, I don't know, 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. And then I don'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 ramp down. So I think after the previous performance

recycle, when that was coming up, I basically said, like, I'm going to be leaving in three months. 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, 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 inness like broke like somewhere three quarters a other time through through Medas.

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 a couple. with cultural changes, you know, seems like a good timing to leave. 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? 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 a 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 challenge 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 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, hard work is within your control. My friend Phillips, Sue talks about this a lot, 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 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 good at your job, it's maybe not your 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. What percent of your career growth would you say is luck? Of the growth, I think it's 50-50. And I came from Canada. When I showed up 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 that 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 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. Um, so if I had like stayed in Canada and worked at a company, I would probably be quite well, but like I wouldn't have had the same acceleration. The luck was really landing 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. 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? 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, like pads on the back approval. They want to pass the test.

They want to submit their leak 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 plus 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 judgment or a grade. Awesome. Well, thanks so much for your time, Michael. 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 chat. 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. 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.