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

35:52Michael Novati: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 um in the future or maybe even now, to be honest.

36:33And so my question is, do you think that LLMs will kill the coding machine archetype?

36:39Michael Novati: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 IDE, like a command line tool or a web tool. um so i used that to find things and i think i had tab completion in vim like a plugin for like class names that was it um and i was very productive so even if i would have had like vs code with modern tools that we have now i probably would have been more productive so the the current wave of ai tools and the llm based ai tools um are kind of like a next step of going from vim to vs code it's like going to a llm ai powered mode that lets you be more productive makes certain things faster certain refactorings faster and changes faster the next evolution going into like that you know we're seeing some some agentic flows 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 the people who are pushing the leaning edge.

38:29Michael Novati: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. 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. What's the biggest difference between 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 LLMs.

39:12Like what are the biggest differences you noticed?

39:13Michael Novati: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 the and and everything so i'm not using that many uh code-wide agentic flows um 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. 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.

40:27Michael Novati: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 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 command line tool, stuff like that.

41:16Michael Novati:So it's an 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.

41:56Michael Novati:But like if you actually clock your time and look at what you do as an engineer, there's a lot of stuff that's like copy, paste, search, copy, paste, change some lines, like sit there and stare at the screen and think for a bit. Like there's a lot of things that are like not as fun. and if you could really just like focus on the fun parts like the creative product pieces or even sometimes just like building i find joy and excitement in like cleaning up code and combining things that didn't seem like they have any overlap and merging them into one like frame one concept like like there's things like that that i just like doing that maybe as a hobby or maybe it's just like sergey brin at google is probably like the perfect example of this where he can just like plop into whatever he wants to work on um and like contribute what he wants to contribute there and like it's more he's doing what he wants to do and there's and not the day-to-day stuff so i think it's probably it's exciting in some sense in that sense for sure um it's definitely like scary to the software engineering profession because it kind of like raises like what does it mean to be a software engineer is it actually writing the code is it architecting the data models?

43:12Michael Novati:Is it coming up with the systems level stuff? Is it gluing it all together? Like it, 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 next little while, like AI and LLM tools are going to make engineers more productive, specifically engineers with a lot of experience and strong taste are going to be more and more productive and if you're not an engineer with lots of experience it's going to be harder and harder to to build that um which is more confident in that but in the future beyond that like if ai can write its own code and maintain its own code i don't think code will be the same as it is today like it's if an ai can do its own thing it's not going to be writing javascript it's going to be managing its own services that have like an API and it's going to do its thing.

44:11Michael Novati: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 to do those things it's going to be like i don't think it's going to be like this dystopian future overnight it's going to be step by step as we get there and i think it's not going to feel and i think it's going to happen so i don't think we should push back on it we should be thinking about like how do we make this ai world the best that it can be instead of like pushing back that it can possibly work right that's where i stand on that but yeah you you mentioned there were some react engineers that you looked up to and their archetype was different from yours what what impressed you about what they were doing what how would you describe the archetype yeah i don't it might fall under the specialist archetype where you're really really really good at one stack um another example is like this engineer who knew email protocols and was like one of the 10 people in the world who deeply understood email protocols to like i know 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 um bucket um like in general and like the fan of the sports team analogy so like you want like a professional sports team that where every every every player on a baseball team can play like any position like pretty well even like the pitchers who only throw can probably hit the ball better than most typical people or like even amateur baseball players like so it's kind of like you want your team to have those different roles and you want to respect each other's place on the field um so i kind of respect those those engineers for what what they do and I have like my thing and I think that the whole team is exceptional if it has these different these different players I see so what impressed you about those engineers is that they solve problems that other people couldn't yeah and uh the abstractions they were creating specifically were very impactful because all the engineers are using them on a daily basis so like a lot of the coding machine work I'm doing that impacted everyone was like cleaning up and making their lives easier.

46:51Michael Novati: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. So I respected them for that. I wanted to talk a bit about your career growth because you grew to senior staff for IC7 at Facebook. There were less IC7s at that time.

47:30So 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 behind the scenes in it. I think you've told this story publicly a few times. So I kind of want to as 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?

48:07Michael Novati: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 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 I'm it wasn't like 30 percent of my eight hour day was the team and it's like only contact me then it was more like 30 percent of my mental space or my focus I think so I would still be like on the team all day long I would be um as like a senior person you're reviewing a lot of code you're bouncing ideas off more junior people you're mentoring helping junior people grow in scope to get promoted from entry level to mid-level those kinds of things um writing a lot of code on features that the team queued up like the team had um just you know um contributing to them um going to like product meetings and contributing to like the product direction evaluating feasibility of things like when product managers like we want to do A, B, C.

49:34Michael Novati: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 a senior engineer would do. But the volume of code produced was more like a senior engineer on the team, I would say. How did you manage the relationship with your team or, you know, your manager, for instance, typical manager knows you have bandwidth kind of positions you in a certain area but it's a little unconventional if that that 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 um like unofficially report on like vibe so it was definitely like interesting relationships like the head like one of the vps i would meet with like monthly for the whole work 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 were almost dotted line reporting to some more senior people and you were known as a, it's almost like a weapon of the org that you kind of just go wherever.

51:00You 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 did you transition into that IC7 solving the hardest problems for the org role?

51:19Michael Novati:Is in my case, like I was almost like the coding machine from day one. and the thing that improved was my taste and judgment but the like even the raw output was probably honestly the same when i was like a week into facebook um like there was there was two different a fork of the task tool um it was called laltana and cortana and it was the same like data source for the internal task management tool and there was two different like uis one was like streamlined and fast and one was like bloated with features and slow and there was like competition between them and like i in like a week or less i merged the two code bases into one that was like the speed of the like slim down one with all the features of the bloated one um and it was i just like literally just took the initiative entirely on my own i didn't even like tell anyone i mean this is so early on you could not do this now but like i didn't tell anyone i just 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 which is like it's done like like surprise um right that so what what i learned along like the output was really the same what i learned though was like that's not the best way to like merge tools that are used by hundreds of people to just be like, surprise, like URLs changed, like deal with it.

52:50Michael Novati:Like I didn't deeply understand like the consequences for teams. Everyone like, like patting me on the back and thought it was amazing. Cause like no one could have done this. So like all overall, it was still positive, but like that would not be like the, the things I learned were like judgment calls about like the scope to change things at, um, the, the, how to like pay attention to the impact the changes will have on other people, building up intuition about what spots are more sensitive than others to make changes in um and that like judgment of doing these massive things like over and over and over again and doing some of them too fast and having too many bugs and there's some people who will like forever not like me because i like caused a really bad bug because i went a little like made a bad judgment call and then i learn take the feedback and then keep going at the same speed while like improving my judgment and building that taste.

53:45Michael Novati: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 in their org similar to yours like it's kind of um it's very dependent on the context but yeah if i'm understanding correctly then you were able to work on all this extracurricular you know, org wide projects because you had such high productivity.

54:42And that was true from day one. And you had the initiative to like, no one, no one's going to stop you. Like, let's say you, you have your, your project on your team. No one's going to stop you from doing extra work that solves some, you know, problem on the side. And so you, you took that initiative and you have exceptional productivity. So you just became known as this person that's constantly solving

55:06Michael Novati: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 the push process so like now there's continuous integration at facebook at the time there wasn't if you broke something and it shipped to production and you needed a fix like the pushing team like would not generally be happy. And you have to like negotiate with them in a sense. And if you break things too much, they don't trust you. And they will not accept your changes. They might even push back on your normal changes. So that hurts a coding machine.

55:46Michael Novati:So I have to like, build a relationship with the pushing team. So they really trust me. And more than once I've said, like, this needs to get in. And if it breaks the site, I will resign. Like, quote, unquote, I've said that. because i burned credibility before like the day before shipping something too fast i had to be very sure so sure with the fix that i would like you can fire me if it breaks things and like those types of like things to build that that trust and credibility like another engineer who just shows up and writes a lot of code probably would not be able to get away with it because they didn't have the years of building that up so it's that that is really important it's not only the raw it's like much more than the raw output there would you have resigned if you if you broke it 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 not break you know like i will like i will like triple check every line i will think about every weird case that could possibly happen yeah you talked about taste and judgment when it comes to code and software engineering what does that mean like people who cook with like cast iron pans they talk about building a patina where you have to like build up layers of like history and it gets burned into the pan and it has a profile um that's to me is 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 there they have stronger taste faster but generally it just requires like experience in some way like you might have experience outside of code that might build up you might do lots of like dancing and you build up all this like intuition and muscle memory about dancing or 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 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 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 super top tier stage of, I think, like any, any skill.

59:16So 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:31Michael Novati: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 or failed for some reason um and that's why they're so good is because they learned all they learned each step of the way and then they made changes and grew from it so i'm talking about for an engineer that applies to like or for me at least that applies to code itself and right code and the strategies to moving really fast and stuff like that yeah you mentioned about uh changing other people's code or the social norms around touching code that other people own and you know You said something about landing a bug in that code base kind of really could blow up in your face.

1:00:37So did you ever get feedback from other teams? Because it sounds like you were kind of touching everyone's code. And how did you handle that feedback?

1:00:44Michael Novati: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 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 um 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 this is one one use case where you got to be careful is if teams are working on complex longer term thing migrations already like be careful in that area of the code what about the case of ownership so you know software isn't just about creating it but there's all this management and maintenance burden after it's created.

1:01:58Did any team get upset? They said, hey, you add this feature, great, but who's owning this thing now? Who's going to actually maintain it?

1:02:07Michael Novati: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 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 um so i think if i like i i didn't just like touch code didn't refactor code and forget it i was responsible if there was any bugs and then in the future like sometimes two years later there's like something that i get an automatic bug assigned to me because it's like you touched this code last and i'm like oh man i don't even remember doing this um but then i would fix the bug because even though it didn't cause the bug it was just like that is now my code um now i didn't i didn't have any territorial conflicts because i don't i don't know why i i didn't i just didn't really come up um i never i didn't like step on people's product judgment i mean this is part of the the judgment calls i guess that you're building up like it it's kind of like performing a surgery and you're not really like you got to be really careful about what you're changing you don't want to impact like I said I learned maybe learn 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 your focus as you got promoted to be a coding machine you must have had a lot of focus time even as ic7 i really try to minimize my meetings if someone like just added i don't know if this still happens but people would like just make meetings add you to the calendar there's no context it's just like something something like sync you're like you don't know what this is i would like would ask like what is this um 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 um 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 seen them but like it happens and i would not generally go to those um but yeah so just being pretty pretty strict about time and then also like having the manager support was like pretty important like i wouldn't i was pretty choosy and i like went on very i made very conscious team changes when i whenever i did change teams and the manager was like very like in tune with like managers at meta um 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.

1:06:03Michael Novati: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 this 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 like i wouldn't like i i i like almost feel really bad because like the person running the meeting probably felt really bad and now i feel like really yeah yeah did hr ever reach out and say hey you're you're productive but can you be nicer and stuff like that uh no i don't i mean i i don't because i wasn't like mean it wasn't like a flip the table type thing it was like very right 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 pms that i mean meta is 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 this test wasn't configured right and there's like things that i was very helpful to pm so they actually like liked me a lot um and if i like walked out of me if i like had to leave a meeting it was like they would almost like give me permission like yeah like michael you don't 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.

1:07:50Michael Novati:It was that level of strictness, I would say. You mentioned that your productivity over your whole career was high, and it didn't change that much. What changed was what you wrote code about and the problems that you solved. How did you 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 all right i pick things where i see the answer in my head and um it's just how fast can i like type or like get this into the code 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 i don't have it if i don't have it in my head i can't do that like super fast i like need to have i need to like see the answer you know in a sense um so i'm gonna work on b it's like can you please work on a it's like i have to do b c d e f g h it's like okay that's like a lot of work and that's like helpful but like a would be really good and i just like i that was like and i think that that's one of the things that probably held me back in general because that limit like if a really really was so important and i and it was not done you know it's like you get a passing grade for doing all the other stuff and it's appreciated but like the company would overall impact would probably be higher by doing a if i was able to do it but I'm somewhat limited by like what I can figure out how to do.

1:10:07Michael Novati:I frame it as a weakness but yeah. That's interesting so you always optimize rather than business value fully you your rank order list of priorities was what can I just crank out instantly. Yeah and if you crank out enough stuff it adds up and it can have a huge amount of impact but it is definitely definitely like a a different way of thinking at work, I think, yeah. 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:47Michael Novati:There was a certain kind of bar that everyone had, regardless of if they were a coding machine, regardless of if they were a specialist or a fixer these different like uh reasons why they're there um everyone had like certain traits that were common like extremely strong diligence and conscientiousness um and very uh i wouldn't say fast or quick i don't know the right word but like very like sharp sharp'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 the most of these people are still are like smarter like these are exceptionally smart people of who I would who I have to like acknowledge might be smarter than me um but we all could be in the same room and talk about something like very and very quickly move through the concepts so like here's this new proposed protocol and instead of like having an hour long presentation on it and discussing it, everyone would be pretty sharp, sharply be like, oh, what about ABCD?

1:11:57Michael Novati:And 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. For me, these are more personality traits, I would say. like it's like leveraging like ocd and like a way a productive way to be like obsessed about every detail of the product instead of like things that are not productive for other people they had like their 25 years of experience and they kind of built these things through different ways but like everyone kind of had that um whereas when a lot of conversations with junior people there's a lot less 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 want to go over is kind of like a set of topics on just how do you how do you land code fast like let's say you're I'm a new software engineer.

1:13:07I want to absorb your coding machine's abilities. Is there a top 20 % of tips that is going to give me 80 % of the benefit to become more productive?

1:13:20Michael Novati:The general advice is you have to move. You can say it in the shortest possible, just do something. Write code. A lot of people who ask me for advice or questions, they're thinking too much about what to do and not doing enough. So step one is do something. Just do anything. and then step two which is critical is getting feedback from like respected people or or people who 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'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 well the like the biggest mistakes people make are there's uh three mistakes i think the first one like not turning the gears and not doing anything like i said earlier the second one is not getting feedback from the right people.

1:15:10Michael Novati:So if you get feedback from like, if you're a bootcamp grad and you're getting feedback 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 encapsulate that experience and taste and that judgment that you want to learn from, that you're trying to learn from in this process. it encapsulates the judgment of someone who's like a little tiny bit further ahead of you um so you want to get feedback from people who have that the judgment and taste that you aspire to and then the third mistake is and this is a mistake that i made a lot that i would tell myself to not do um but is not actioning the feedback and taking it more like judgment and approval rather than feedback So if someone gives you feedback and you're taking it as like a judgment or an approval, you want to pass the test and it's like you failed and you want to pass it and you're not actually reflecting on the feedback, you're just taking it as approval.

1:16:14Michael Novati: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 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?

1:16:53Let's say I'm pretty productive already.

1:16:55Michael Novati:i would be ambitious more ambitious probably if you're like if you have like your coding machine thing going like take on something ambitious that is pushing yourself a little bit outside of your normal scope of wherever you're you are you're in the code or um like this is very specific to Facebook and meta though in general because your impact is somewhat judged by like uh 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 gotta push beyond the department and push your comfort zone a bit my advice to my like something like i saying i'm not good at accepting prioritization from leaders but that's actually the advice i would give though if you're stuck is to ask like talk like ask your i don't know i had many many one-on-ones with like the 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 like reaching out to more senior people in different areas and trying to get some ideas of those wider scoped projects if you're really stuck um it can be a step forward coming to the end of the interview just want to do some you know career reflections and stuff like that and you were at Meta for quite a while and you had a lot of success.

1:18:40I'm curious, why did you leave Meta and what was your thinking behind the career planning there?

1:18:46Michael Novati:So Meta got like quite big, quite fast. And there was like this turning point, I don't know, six years, three quarters of the time through there where I felt like when I was all in 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'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.

1:19:30Michael Novati: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 percent in a month like in a certain over a certain period so i was kind of like okay you know like this is maybe the time to like ramp down so i think after the previous performance review cycle when that was coming up I basically said like I'm going to be leaving in three months um and then I did a little farewell tour on messenger for kids to be like my manager was like okay like do you want one last hurrah and then they did this project worked on this project um and I kind of like slowly ramped down over that period um and I was like taking home stuff from my desk every day like slowly slow ramp down um but it was definitely it was just kind of that like at formation now I mean obviously i'm a founder so it's also i have more control over the that but um it's really like an all it i'm like all in or not all in and that all inness like broke like somewhere three quarters of a time through through meta as it got bigger and bigger and i like needed to put that somewhere that that dedication somewhere else yeah i mean getting a 80 pay cut is uh coupled with the cultural changes, you know, seems like a good timing to leave.

1:20:52So when it comes to the highest levels of performance and ICs, what's your take on how much of it is talent and how much of it is

1:21:01Michael Novati:hard work and growth? There is talent. Some people have more talent than others. Some of it is maybe your biology. Some of it's just how you grew up and opportunities you had. And some of it is you have raw talent that's not discovered yet there's like all kinds of views on talent but it is a thing and it does come into play um so there is an aspect of things that are talent in quotes if you feel like you're like oh no i'm not talented like you might actually be talented and it hasn't been discovered yet or you might be like talented at something that isn't your day job right now and you should figure out what that is and that's actually like a formation that's our of 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.

1:21:53Michael Novati: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 a 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 Philip Zhu talks about this a lot.

1:22:29Michael Novati: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 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. What percent of your career growth would you say is luck? Of the growth, I think it's 50-50.

1:23:04Michael Novati:and I came from Canada I 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're 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 doing quite well but like i wouldn't have had the same acceleration um 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.

1:24:26Michael Novati: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 uh like pats on the back approval they want to pass the test they want to submit their leak code and see a green check mark they want to um i was that person i wanted to get the highest grades and i didn't really like know what i was learning even i just wanted to get like an a plus or a hundred percent 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.

1:25:19Michael Novati: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 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.

1:25:57Michael Novati:And happy to have me 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 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.