YouTube Deep Summary

## Intro [00:00] Even if I see your diff is gonna blow up production, I will comment on it and be like, "This is gonna blow up production and then accept it and be like, "Yeah, make sure you fix that first." Right. This is Jake Bullum. He's a principal engineer or IC8 at Instagram who got promoted twice from staff engineer. So, I think IC8 was like, "So, let's go and put him on one of the projects we have that is like impossible and everyone thinks it's stupid." And yet, his work life balance is somehow reasonable. So, you have pretty good balance. Yes. And it's all the systems that I've been building my whole career that I think are like able to keep me here. Yeah, you probably want to know about. I thought he had a really interesting note-taking system. And my note-taking system is actually in VS Code. And he shared a lot more than you might think. I'm also a bit of a loose unit and sometimes say dumb stuff. Here's the full episode. Your work has such insane blast ## His rough onboarding to Facebook product team [00:50] radius cuz you got to I8 or principal engineer in the industry. on your path to IC8. What were you hired in as to Meta and maybe you can give a high level timeline of the teams you were on? Yeah, sure thing. Yeah, so I came into Meta as a six and actually joined Facebook groups at the time. So groups went from I don't know 10 or 15 people to like 700 in like 2 or 3 years. Wow. But yeah, so I joined right at the peak of it like 700. Yeah. And I was on some team like groups integrity was actually pretty wild for They had a pretty slow ramp up to meta because I joined when they we it was middle of co co had just started so they hadn't really figured out remote onboarding yet so it was really slow and then I joined my team and the election was coming so no one could really ramp me up so I was just kind of operating solo on like random stuff so yeah I had a really slow start to meta for most people so actually empathize with a lot of people that like took like a year to ramp up instead of like 3 months was your performance at risk initially because you were onboarding remotely or I think my manager like help helped a lot like with the system and I managed to get like a meets all or something like this you know definitely wasn't excelling and had a few little projects that like probably helped them sell that but yeah I'm pretty sure they told this like slow onboarding story during PSC which was kind of crazy uh especially cuz groups was like so critical at the time right they had so many engineers and right after that actually just I just decided to switch teams because I had some friends on Instagram and they were like, "Yo, come and work on Instagram web and this is this has actually been a bit of a theme throughout my career. So I joined Meta to work on UIs, right? To work on web to use React. I loved React and I joined this group's integrity team. We weren't doing really any of that." Like I was doing it like 20% of the time, but most of the time it was backend systems, right? So I was like, "Okay, cool. I'll move to this team." So is your background before Meta all more like full stack or front end work? Yeah, so I spent I started coding at a really young age and it was always on the front end and then when I went to companies I would like to do like front-end product and every single company I've ever worked at moved me into like front-end infrastructure very quickly and then backend infrastructure. And actually one of my big draws to Meta was, oh, they're so big. I'll always be able to work on front-end product, right? Like specializing. Yeah. And this thing continued where I got pulled into Instagram now to do front-end product and was like awesome. Within a couple months I was on the front end infrastructure team. Yeah. Yeah. In Instagram. And then yeah within like a year I was on the backend infrastructure teams and I was like oh it doesn't matter which company I'm at. How do you how do you keep getting pulled to the back end? Like what is drawing you? I think well now because you've done it so many times you end up knowing like a lot about it and like all the different like architecture and systems that you have to sort of put together and it it just it is more impactful now right with the big switch to mobile uh the only thing that's like rivaling it is the server right like web has become such a small amount of our traffic you've got to go to where the more important stack is I see so generally you are picking projects based off of where the impact is and that is leading you to go to backend stuff or like Yeah, exactly. Like on at Instagram at web we probably had like less than 100 people would work on it, you know, around the company part time and on the back end we have like 2,000 3,000 engineers working on it. Yeah, that makes sense. So even from the engineering point of view. Yeah. Right. ## Switching to Instagram [04:32] Right. So then so then you were IC6 on the group's team. You were on boarding slowly and you weren't liking it. It was this backend integrity system. You switched to Instagram web as a IC6. Is that Yes. Okay. And so it that's where your career started to really pick up. Yes. So I think I came in and like had all the skill sets. So I was like basically ramped up immediately and like landing impact immediately. And my managers on the team at the time recognized that I was like pretty strong. And we were we were growing too. They were moving from one of our stacks to another stack, right? and they were like, "Hey, we're going to have like two or three teams. What do you think about like stretching to be the Uber TL across these teams, right? Cuz that's six to seven carriers started. You're not on one team anymore. You're kind of leading like a bunch of teams, right?" And I was like, "Yeah, I think I can do it." So, they kind of gave me the opportunity to like do that, right? Why do you think they came to you for the opportunity? Because, yeah, I think that's one of the big things people look for, you know? I people who want to get to these levels they even if they want to sometimes they don't have the opportunity. So yeah I'm curious what did you do that that you think made them come to you and say hey we want you to do the IC7 thing. So when I was actually joining the team it was something that I was like looking forward to. So I was like yeah I want the career growth right. I think I can do this. Like I my previous companies I was actually leading four teams before I came to Meta. So Meta likes to down level you, right? So I went from leading four teams to one team when I came to Meta. Yeah. So they were like, "Yeah, like we'll see what happens in the first month and if you're like crushing it, we'll like give you that opportunity." So I came in and in the first month like did what they needed. So they like, "Okay, here we go." So when you like even before you switched, you said, "Hey, FYI, I'm I'm eager for IC7." And Yeah. And so they knew that and they basically just gave you the opportunity because and to see if you could do it. Yeah. So they knew that about me and then they knew that they needed it on the team too. Right. Right. Right. Right. So you talked about what is IC7 ## What IC7 scope looks like [06:39] scope? What does IC7 scope look like? Yeah. Uh so IC7 scope to me looks like Yeah. So six is like you're basically like the TL of a team, right? Maybe 10 12 people. It really depends on your team though. If you're on like a really complicated part of the stack or something, maybe your team skews differently, but generally like that. Or if you're on a really easy part, maybe it skews the other way. But generally like yeah, six is leading one team and then seven is like across multiple teams or across like a a different area, right? So then would eight be even just like another step of that progression? Yeah. So eight just keeps going up too, right, for different teams like your blast radius. And yeah, this is all dependent on how important the problem is that you're working on, right? Working on the backend infrastructure, right? If you're impacting 3,000 engineers by like making your frameworks better, right? And it's taking a lot to make those frameworks better, right? Right. You need like hundreds of people to make those frameworks better. Yeah. Like you're hitting pretty big blast radius. Yeah. So then your archetype is leading through other because there's also the other ones like framework specialist kind of someone that just digs deep somewhere and speeds up a thousand people but is not directing a thousand people. Maybe you can talk about like the archetypes you Yeah. Yeah. So this I'm Yeah. Talking through one very specific lens, right? So yeah, there's all these ways that people can, you know, contribute to the business and like be having that large blast impact. And yeah, the most extreme other end of the spectrum is like the specialties, right? So you've got the guys that are like, I don't know, deep on the compiler or like Yeah, they change like 10 lines of code down there and it saves the business, you know, hundreds of millions of dollars. So like a fixer, like the fixers. Yeah. So you've got you've got this range, right, that you can do it in. And maybe they don't like talking to people, right? They don't like running around. Yeah. But we still realize there's like really good value in having these folks around and give them the career path, too. Yeah. Yeah, definitely. Were you intentional about the archetype that you picked for yourself as you grew to ICA? So, I guess not really. My philosophy is always just do whatever it takes to get whatever project I'm on done. M but you know I'm leaning into my strengths and my strengths are like talking to people like being able to yeah coordinate people. I like to think I'm like fun and happy to be around which gives people like you know some motivation other than work to be there and like you know most of the projects I'm on are like marathon projects so we get to stick around for like a long time together and have some fun right so you're like a force multiplier like you take a group of people and you make them some percentage better because of you know your behaviors. Yeah, maybe that maybe that's what happens but I don't think about it like that. M I'm just trying to get us all doing the same thing. And I see the good in people, right? And I like see the strengths in people. I just want people around me to succeed. So I'm just trying to make them succeed. And I guess that ends up, you know, compounding and being best for all of us. Like have you ## Thoughts on management [09:48] ever thought about management? Cuz like a lot of what you just described, I feel like there's some overlap there. I've done some brief stints in management before meta. Yeah. And yeah, I think it's just it's not for me because I like to be able to then like if the project needs it, go and like, you know, land 500 diffs in a couple of months or whatever. Like go and land a ton of code to get us across the line. I see. You can't really do that in management. Yeah. I'm also a bit of a loose unit and sometimes say dumb stuff. So I think I need it's better if I'm not in management and like have people in management who can check me on that, you know, occasionally when it's needed. Right. Right. Right. Right. That makes sense. Yeah. I feel like you have to be a little more sensitive to things as a as a manager. Yes. Yeah. I noticed your ## Why he always makes time for others [10:32] internal profile said something like always open for a chat or something like that. But my view of an ICA is someone who's drowning in responsibilities and does not have time. Yeah. Why do you make time for or you know make yourself available like that if your time is like so precious? So yeah, definitely you know you're getting worked a lot at IC8 and you're you are overloaded but yeah I'll always make time for someone who will who is reaching out about something right you know maybe maybe I'll be completely overload and the meeting has to be like a few weeks from now but there's a lot of value in being accessible to everyone right like anyone can come to you and be like hey I have this idea or I have this problem like can you help me and you're just like helping your org or you learn about a problem that you wouldn't have known about otherwise, right? I kind of wonder though cuz someone like you is probably getting so many, you know, outreaches. Like I would have thought you'd have to pick and choose a bit, you know, like let's say intern comes to you and is just excited and wants a coffee chat or something. In a in a in a nice perfect world, you'd make time for them and you talk to them. But yep, in a impact driven world, some things are going to need to be dropped. What are your thoughts on picking and choosing your time? Yeah. So, I I do try to put the levels thing out of my head always. So, if an intern come, I try to treat them the same as everyone else. So, if they came and they were like asking good questions, right, or like, you know, you're giving you're telling them stuff and they're like acting on it and going for it, you know, I'm probably likely to give them more time again. But if they come in and they like kind of ignore it or they ask really bad questions and stuff, probably not likely to give them too much time again, right? This is assuming I had time in the first place. Yeah. If I'm completely overloaded, like it'll be like, "Hey, sorry, like can we do it in a month or this is here's another person that you can chat to, right? Who would be better and helpful, right?" Yeah. You mentioned So just trying my best, I guess. Right. Right. To a certain point. You mentioned bad questions and good questions and I think a lot of people who are earlier in their career that's something that they're thinking about a lot is should they ask or not what's good what's bad. Yeah. Do you have any tips on how to make your questions good? Haven't really thought about it too much but I don't I don't know. Just be be be genuine, right? Don't try and like script it or like pick up line it like Yeah. Just be genuine about what you want to ask or find out. Yeah. Yeah. Because then naturally you'll find the right person, right? If you ask me one of these questions that is like very helpful for you and I know someone better who can answer it, who has more time, right, then you're going to end up with someone better who has more time and it's going to be better for you in the long run. Yeah. Yeah. Yeah. Before ## His IC7 & IC8 stories [13:31] we leave the IC7 IC8, Yeah. I'm curious, you mentioned there was a big migration that got you promoted to IC7 and you were leading few teams and your management chain said we need we need a leader and you were eager and you you took that on. What was it for IC8? Yeah. Also just just on that like getting to the seven one you got to also land the project, right? So yeah, definitely. I think something that happened that helped with the 71 is I was like sort of seen as this person that would like come in and like fix it or get it back on track, right? So we were doing this this back the the infra migration and it was scoped at like 2 years or something. Yeah. And we came in and it wasn't just me like I came in and like we all started chatting and stuff and we got excited and we actually ended up delivering like the majority of it in like 6 months which was like crazy. No one expected that. which meant that we can then move 90% of the resources Yeah. onto other stuff which actually let us put ads on Instagram web the following half. Yeah. Which was also like a year behind and then we shipped it got on the team and shipped it in like 3 months which was kind of crazy. That's kind of crazy. So how how did you take something that was two years and make it happen? Did you cut scope or did you Yeah. What happened? Yeah, we cut scope, but I think more it was just like everyone on the team got got hungry for it and was like, "Yo, two years is silly. Like we can do this sooner." Like we' started to gel together, right? Everybody was sort of playing to their strengths, which you like hear is pretty common. And we're like, "Yeah, we can do this like way sooner than 2 years." Yeah. Yeah. I think before we were going very seriously too, like we were doing like one page at a time. Yeah. And someone was like, "Yo, why don't we do like a 100 pages?" And we're like, "Okay, let's try it." So then we tried it and it was like, you know, really hard at first because we've just done 100 pages, but then we had all the like compounding effects of putting it all together. So that was like accelerating us. So we were like switching parts of the strategy, too. Yeah. Yeah. Yeah. Yeah. How how did you get that team so excited about it? I can't take all the credit because I don't know what happens. These situations are organic. You just start talking about it and then people like bouncing off each other and doing it. But yeah, I was just bringing some some of that hungry energy and I guess it was infectious and then everybody was like on board with it. We're all having fun and we're like, "Yeah, we want to do great." And like cuz we shipped it early, right? It was it was good for me, but it was good for everyone else, too, right? Yeah. Lots of promotions on the team. Yeah. Yeah. And it super deserving. I mean, that's insane business impact. Like such a huge thing. Exactly. Yeah. Yeah. Yeah, cuz then we got ads on there and then I I can't remember but we're pulling in like a bunch of money on a surface that had never been monetized. Right. Right. Right. Which wasn't slated to happen for a long time. So yeah. Yeah. Yeah. That makes sense. So and that was the IC7 promo. So that was the IC7 promo. So I think IC8 was like at this point leadership like identifies you and like knows okay so Jake is the type of person we can go and throw on problems that no one else really wants to work on or is like really hard to move or the rest of the org thinks is stupid and impossible so let's go and put him on one of the projects we have that is like impossible impossible and everyone thinks it's stupid. Yeah. Yeah. Yeah. Which was like we're just on the front end moving it into the into the main meta stack. Right. Hey, can you like move the back end into the main meta stack? And I was like, cool, that sounds impossible. Let's let's try that. And that's yeah, you you're aware of the details of the project. But that that was an interesting one because yeah, 95% of the engineering org was like, "This is stupid. Why would we waste any resources?" Yeah. On this, right? So, we knew we wanted to migrate into the other stack, but we couldn't go out to the engineering or and say, "Hey, we're migrating." because we'd get shot down and like everyone would be like this is the dumbest thing ever and we'd like kill morale for the orgs. So we're like okay what can we do? All right, everyone's having this problem with interacting between these two stacks that we have. All right, we're going to go and fix the devx between the two stacks. And we made a big deal about fixing the devx between the two stacks. Yeah. Yeah. For the first year. I see. Yeah. So I mean you said people would think it's stupid. You're talking about the people who are using the existing IG backend stack and are used to it and they're saying what it works why switch over. Yes. Those Okay. Yeah. And so you had to you couldn't just immediately initiate a migration of infrastructure that thousands of engineers are using without bringing them along and saying look it's a good experience still. Yes. Yeah. I think so. So, and also I kind of like at the time I like agree with those engineers, right? Like the majority of our development is in this stack. All our important surfaces are here. Like it's way better to be in one. And I'm like, "Yeah, this is true." But like our other stack was growing in usage. There was already all this cross stuff happening. So like I don't know 30 or 40% of the org were impacted by this, right? but it maybe wasn't hitting the point where it was worth justifying putting like a hundred people on it to like move it move it all across, right? So, we did the building blocks, right? Like, okay, let's make the highway between the two better, which is like no one's really going to argue against that cuz they're like they come across it occasionally and they're like, oh, that would make my life better, so we'll do that. And then on the other side, okay, there's stuff missing from dubdubdub. So that was the first year and the second year it's like there's a bunch of stuff missing from dubdubdub that doesn't make it feel like Instagram. Mhm. Let's go and add all that stuff in there so it's actually easier to build in there. So that was year two. We went and did that. Mhm. Uh now we're in year three where it's like okay now we have these two things and during that time more of the crossstack stuff has happened right some surfaces did migrate because they were going to get bigger benefits. Uh now we've kind of got to the point where people are like, "Okay, we see the writing on the wall, like how can we get in there as fast as possible, right?" And now we're in like full migration mode. And so the IC8 promo cuz I guess the full migration is not fully complete, but there was some milestone in this larger strategy that was worth an IC8 promo. Yeah, I think so. So I think this project like at some point someone came to me and was like, "Yo, should be running this project." or something who's like a very senior engineer at Meta like I don't know 10 or 10 or 11. He's been around a while cuz the project was like it was it was so crazy trying to re rewrite Instagram right while you know the classic metaphor of like you know you're on the plane you got to switch the whole plane while you're still on it. Yeah. So yeah this project was scoped at like you know many IC8s worth of scope or an IC9 or something. Yeah. And we only had uh sevens working on it at the time. So there was space for that if you were like going to do it. And then we had we hit a couple of big milestones, right? So we had some of these surface milestones we had hit as well as we'd hit pretty big traffic ones. So we'd hit like massive milestones, right? Right. But yeah, that was still enough to be like, okay, yeah, they've done a lot of work. Yeah, there's 150 teams involved. There's like it's moving everything that is being moved is like, you know, 20% faster or is like way easier to work on. Okay. Okay. Okay. I mean, yeah, that blast radius is insane. I mean, it makes a lot of sense. Yeah. One thing I was ## Swapping out infra for 1000s of engs [20:54] curious about because you this is one of those projects where you're switching out a lot of the infrastructure that people are using. How did you make sure all these engineers are happy with the tooling? Cuz you're you're switching it out while they're doing their day-to-day work. Did you I don't know have some sort of way to engage the community and keep them happy? Uh yeah. So we have like at Instagram we have like a a group of people we call our server champions. Oh right. Right. And I think you have these like sort of horizontal groups in many orgs. I've had them at previous companies too. Right. They're always called different things. I don't know the server guild or whatever. You just need when you have so many teams people from all around the org to kind represent the platform that you're working on. And you want like some people from your infra teams, but you want majority people from your product teams because infra teams can get quite disconnected from how day-to-day developments happen. Yeah. So we had those folks. So we would always like it's basically a continuous channel like we have a chat group and stuff, right? I think there's about 40 of us. Yeah. So they're always giving us feedback. We're always asking for feedback. If stuff's coming up, we're asking them to like let us know, right? Like if someone on the team raises it to them, let us know. Mhm. I think that's actually like probably our most important feedback channel. We do have the big feedback channels of like, you know, the 2,000 person groups where people can post in Devx feedback like but we find it has to be really bad by the time it gets posted in that group and we probably know about it already. Whereas these server champion groups like we might know about it within an hour or two, right, of something rolling out or breaking. Yeah. In addition to like all the metrics that we monitor, which are very helpful, too. Yeah. Yeah, that makes sense. As you've grown from ## Work life balance tips (IC6 to IC8) [22:37] IC6 to IC8, you take on more responsibility. How's your your like hours worked per week changed over the over time? Yeah. So, I think sometimes I get really excited at work and I'll be like working like, you know, 60 hour weeks or something like that, 70 hour weeks. Mh. Uh and then other times like, okay, let's get this back under control. And I'll like drop it down to like, you know, my 40hour weeks. So if it's during the summer and I worked 60our weeks during the winter, I'll be like, "Okay, I'm going to do 35 hour weeks during the summer or something." Yeah. Yeah. So it does it does fluctuate and depends on what the project's going on. But most of the time I am trying to target like the 40 hours a week cuz I I want that work life balance. I've got more to life than just working, right? Yeah. Yeah. But yeah, if I get really excited, I might get into it. If I decide I need to do more personal, I'll like bow out of it. Yeah. Yeah. Yeah. So you have pretty good balance then. actually you're able to maintain your impact with a reasonable amount. You're not going crazy. Yeah. Over the last 6 months. Yes. And it's all the systems that have been building the whole my whole career that I think are like able to to keep me here. Yeah. Yeah. You probably want to know about it. Oh yeah. I got to know about these systems then. What are these systems that are making you able to have this level of impact with that time investment? So yeah, the the thing is so definitely do shield my time. So while I am open to people coming in, I do shield my time. So I think like focus blocks or Yeah, like nearly 50% of my week is focus blocks. So I try not to do any meetings on any mornings. So I'm a morning person and get a lot done in the mornings. So I will not take meetings until after lunch. Yeah. Yeah. And that's worked pretty well for me. In addition to that, I try to make it so Wednesday, Wednesdays and Fridays, I don't have any meetings. Yeah. And then also I'll try to put all my one-on ones on Monday afternoons. Is there some specific reason for beginning of the week or just uh Nope. Nothing for beginning of the week. I just picked a day that I was like, "Okay, I'm going to just do these all in a block." Yeah. And then that leaves basically Tuesday and Thursday afternoons for project meetings. Yeah. Yeah. This doesn't always work right because Yeah. I was about to say there's every week there's exceptions to the rule, but generally I find that shields a lot of my time so that I'm able to be able to do stuff to like move the projects forward that I need or like message people when I need to. Right. Okay. So, focus time. What about because you said sometimes you just you just really focus and you do 500 diffs and like in a couple months when you're in that hyper productive coding state, how do you do that? Oh, okay. Yeah. So in times where I'm doing that, yeah, like I'll just disappear for like two two or three week. Well, not disappear, but like I will cancel like lots of these meetings, right? If you once a project's going and has momentum or something, you can like, you know, skip a few weeks of project updates or sync groups if we're all together and know exactly what we need to be doing. Yeah. Yeah. So yeah, we'll cut out meetings. And I think I've been praised a little bit for like how few meetings I have on the teams and projects that I run. Like people are very surprised when they come in and learn that like this massive project doesn't have central meetings. Yeah. Yeah. Like there there are no meetings. Like people like, "Hey, I want to get involved. Can you add me to the syncs?" I'm like, "There are no sinks." Well, how do you keep how do you keep because those meetings have some value. So they have some value. So this the work streams that need to have them will, but like overall and overarching there isn't any. So there's not this tiered thing. It's like if you're on a particular work stream, right? There is one sync for that. Yeah. Yeah. You don't have to go to like a series of syncs where it's like, okay, we need to go to this one and then I need to go to like this level one and this level one. Yeah. Yeah. Yeah. Is there some high leverage like leads kind of meeting? So there isn't. So there isn't that. Yeah. But there is probably a core group of like you know 15 TLS across the different areas, but we don't all just sit in a meeting and meet together. If we need to we'll like chat in a chat in a group, but we don't even have a chat group. There's not even a chat. There's not even a chat group. as it's all ad hoc as needed. It's all as h ad hoc as needed. And like if we need to have some of these conversations, we'll just push it into the wider forums. Yeah. Or if there does need to be a thing that's like sensitive or something and we do need to chat about it together, we we will do the ad hoc stuff. Yeah. Yeah. Yeah. Yeah. I like that. I mean, most recurring cadences are suboptimal because they're just static, you know? So, yeah, I do kind of like that. Yeah. Yeah. So, this is part of the philosophy, too. always be available, right? So, if someone needs to talk to me that day, I will find time to like talk to that person, right? Yeah. Whether it's like I have to be out, I'm out going for lunch or something, I'll take the phone call. Like, I'll do meetings in all sorts of weird places to make sure that people like have the info they need and they're on the floor. Right. Right. Right. And in those times ## Diffs reviews & risk [27:26] where you're a coding machine, are you also diff machine and what's it look like? Yeah, whatever's needed. I actually usually when I fire up and I'm getting in the zone, I'll quickly I'll go to the diffs first because anyone who's got a needs review diff, right? Like they're se semilocked or like they're not being able to land what they're landing. So yeah, I'll go through all of that first, get that in before I even start coding myself and every hour I'll go back and check again. Yeah. Yeah. Oh wow. So you're like really on top of diff review then. Really on top of diff reviews. Yeah. Like actually I think there's probably lots of memes floating around for me cuz like people put up diffs and like 5 minutes later it's like stamp on me and they're like what the hell is going on? And that's a lot because I'm on top of it, but also because I have this philosophy on like diff reviews and risk where yeah, if like if I don't think the diff is risky, right, you're getting a very rudimentary review and like basically you can put that code in like so if it's like gated, it's not on a core system, right? These things then you're going to just get a very high level diff and then basically I'm just like trusting you. So um you're saying you you modulate your level of time investment based on how risky the diff is ba based on how risky the diff is right. So if you're rewriting it, right, we're it it's all gated right now and we just want the highle trunk architecture to be correct. If you're working on like some child component or something, it's like cool, it's gated. It's not critical to the system. Like yeah, I'm trusting you to do whatever you need to do over there. So you'll just stamp it stamp stamp it let it. Yeah. Some people view quality different view as a uh like an important thing rather than just stamping. So you ever get push back on? This is my controversial one for sure. So yeah, so I I think that is correct for like the the trunk of the system, the core core parts of the system or anything that's already live in prod like is going to get pretty thorough review. Yeah. If it's not live and prod and it is one of these sub like subp parts of the system or less critical things like I'll still skim it to make sure you didn't do anything like absolutely crazy like introduce like I don't know security issues or you know start mining crypto on our servers or something but uh yeah I'll just like let let that let that fly in. Yeah, I I mean it makes sense. So you're basically trading off speed for I guess quality, but it's not dumb quality. It's like these are places where it makes sense to make the trade-off where you make Yeah. So you can have like lower quality components for like these the child the child parts of the system, right? Or the leaf parts of the system. And also these parts are like generally easier to unit test. If they do fail, they only blow up like a small part of it, right? Just a little blow up. Just a little part of it. If it is badly architected, it's only on this like tiny part of the system. It's not impacting, you know, hundreds of engineers. Maybe it impacts a couple and someone one day is like, "What the hell's up with this?" Doesn't take a long time to rewrite. Right. Right. If you mess up the architecture in the core trunk, probably takes like hundreds of people a long time to like fix. Yeah. Yeah. Yeah. Have you have you ever had someone I remember early in my career I was all about speed and I was approving some diffs and then someone would come back to me and say why'd you approve this that was too you know like let's slow down a little bit on this they get some feedback or someone says hey you know calm down like this defin this definitely happens actually interesting thing so teach the people close to me in my teams that like hey it's okay I stamped your diff to like put it back in review again if you actually need deeper review or like flag it flag it in the summary or the test plan like or comment on it like hey I'm actually looking for a deep review on this if you know that's how our team operates now. Yeah. Um and this is actually really good because I might have thought it's like a child part of the system and maybe it is still a child part of the system but they've thought hey this is like could be like more performant or like I actually want you to double check this. U so then we use that signal to be like okay this person actually wants things. So if I missed it even if they put a comment on it they'll throw it back into review and like be like need real review or something like that cuz they knew they knew what happened. Yeah. Yeah. Yeah. Yeah. I see that makes sense. But yeah there's definitely this is not the philosophy of everyone at Meta, right? Like we most people it's like quality high quality for everything. Yeah. And it depends on the system though. It depends on the system. Also depends on like this is like trust you build on your team too. on the team probably not going to get this treatment for the first couple of weeks. Although I do want to defer to like how do I accept this diff, not how do I reject this diff, which I think is an important philosophy to have. Why is that? Yeah. Uh cuz like I'm not trying to like knit your code and get you to write it the exact way I would write it, right? I'm trying to be like, okay, what is absolutely blocking this thing from going to going to production? like big highle architecture things like I don't know some critical bugs like is it going to blow up prod right not like write it exactly the way I would write it right I think that takes a while to get to too right like more senior engineers usually become amendable to this but when you're in yeah when you're like in the first five years of your career maybe you've only seen a few ways of writing it right so you want people to write it that exact way yeah yeah definitely I I think when you're working in a team where there's high trust And you get to the point where people they have feedback but they accept with nits, you know. I I love that because you just everyone just trusting each other, you know, move fast. Yeah. And I have some feedback, but it's not that important. It's just like take it if you will. Man, this is where I push that needle even further again. So, I will like even if I see your diff is going to blow up production, I will I will comment on it and be like, "This is going to blow up production." And then accept it and be like, "Yeah, make sure you fix that first." Right. And I've never had a case where someone's like landed it with a comment on it that says, "Hey, this is going to blow up production." Cuz you can imagine like sitting in review or something and someone's like, "The diff had a comment on it. This is going to blow up production." And it blow up. That's wild that. Yeah. Except I just trust them to fix it, right? Like Yeah. Yeah. Yeah. Fix it the right way. Once again, if they have trust, if it's like a new person on the team and I'm not sure if they're going to fix it the right way, right? I might be like, "Ping me again when it's like ready." Yeah. Yeah. But yeah, 99% of the time I'll just like accept and go. And yeah, haven't had to do the thing where I pull back because I've never had one that's been shipped accidentally exploded. And that's actually a little bit of a philosophy I use across like I guess building these systems, judging how fast I'm moving. Yeah. If I'm doing something and it's not I'm not getting feedback that it's like broken or I'm not seeing negative effects from it, right? Even if it is controversial and crazy, I'll keep pushing the boundary on it, right? U same as our rollouts like if we're at 1% we're getting like very little feedback and like metrics are looking good and we might move to like 10% the next day and people like that's crazy like step to like two three five things it's like well not we're not getting any like signals that it's not going poorly as soon as we get signals that it's going poorly we start pulling back but otherwise I find you like move too slowly right you want to be moving at like the fastest speed you can without ruining things right so if you're not getting if you're not making anything worse like keep trying to find that edge. Yeah. Yeah. Yeah. I I had a tech lead early in my career and I had taken down prod or something and I was talking to him about it and he you know at one on one end you shouldn't break prod generally but he also said if you never break prod that's probably not also optimal like there there should be some level of risk otherwise you're moving too slowly and so yeah exactly yeah try not to break prod But if you never break it, you're probably like very slow and Yeah. And if you're breaking it every day, you're probably going way too fast. Yeah. Exactly. Exactly. Need to fix something. Do you use um AI at all? Yes. So, I've been I use it. I use chat GPT like I don't know 10 times a day outside of work and then internally we have like own things that I use too. But I think it's great, right? Like just like harness the tools that are coming. They have a bunch of caveats and they make mistakes and stuff, but like I don't know. I had to use if someone said, "Don't use a calculator," I'd be like, "What the fuck?" Use the to use the tool. The tool's there. Figure out a way to use it, right? Yeah. Then maybe we won't get replaced if we become masters of the tools. Yeah. Yeah. Yeah. Exactly. Exactly. Yeah. I wanted to talk about ## Being a good tech lead [36:07] being a tech lead a bit because I feel like that's one superpower that you have to start. What would you say is the role of a tech lead? Like what are the important things to do and how do you see that role? Yeah. So yeah, people probably have a different opinion on this all over the place, but yeah, mine is just like, okay, you're the tech lead. You're responsible for this project now, right? Like do whatever it takes to get this project done. Usually the highest leverage thing you can be doing is like making sure everyone else is like contributing to the project and moving in the right direction, right? But sometimes you might have to switch and do other things like writing code or jump into fixer mode. There's been a few times where I've had to like no one else can debug what this thing's doing. So, I spent two weeks chasing like the craziest bug through the system to like find that line of code that's messing up. At this point, you've probably coached tech leads because you're in a position with leverage. Yeah. What's the most common mistake you see people make if they're transitioning into more of a leadership role? I think getting like kind of disconnected from what the what the goal is of the project, right? So easy to get caught up in the day-to-day operations of like we need to be doing this and we need to be doing Y and like lose track of the fact that like the direction we're heading in might have actually shifted a little bit and it's like your responsibility like shift the team towards towards the goal again. Right. Right. I know at Meta regardless of how high level you are you're expected to make technical contributions. Yeah. But generally there is a sentiment of as you become a higher and higher tech lead you get further and further from the code. Yeah. And more in doc work and leadership meetings and things. How do you strike that balance? Yeah. So it's definitely is uh a hard balance to strike but I'll still I'll still write code probably nearly nearly every week even if it's like a smaller amount of code because then I'm using the full tool chain. Often it's because no one else wants to do it or it's something that, you know, maybe I'm going to do it 10 times faster cuz I know know that thing and I don't want them to waste a week on it. So I'll go and do it, right? Yeah. So I just I'll just like find the time and those focus blocks and stuff help with that too. Right. And it might if it gets to Wednesday and I haven't written code and nothing's come up, I might go and do that. Yeah. This is all caveed on the fact that I'm always trying to work on what I think is the most important thing, right? Mhm. Like if it was saving that person, you know, their whole week of doing it, it's going to take me an hour. I'll go and do Yeah. But there might be periods of time where we're doing a big review or, you know, we're going to get a headcount injection or I don't know, we need to be doing X, Y, or Z and then that's way higher leverage for me to be spending my time on and I won't code for a few weeks. Right. Right. How do you I think this is more, you know, junior people lack this, but how do you develop that skill of seeing what is impactful with your time? I mean, where's the ROI? Where'd you learn that? Yeah, I think it's uh I don't know, just like practice. Practice makes perfect. And you've seen a lot of scenarios, so you kind of know, right, which one after a while. Yeah. But yeah, when I didn't have that gauge, and I still use this a little bit now, it's always like, what do I what do I think myself is really important that no one else is willing to work on? Yeah. Um and that's usually the area I would go to. Before I had developed like a good sense of it because now there'll be sometimes where I'm like oh no one's working on it because it's stupid but like if I really think it's really important I will like find a way to work on it. Yeah. Oh interesting. Um there's a famous essay inside a workplace somewhere and the title of it is like go where you're rare or something like that. Oh and this kind of reminds me of that. It's a scarce thing that you could solve that problem. And yeah, you know, it makes sense, man. I haven't seen that essay. I love that. Yeah. Yeah. There's a lot of gold in workplace actually. A lot of people sleep on on the like the alltime essays in in workplace. Yeah. They're buried somewhere in there. There's another one from one of our like I don't know ICT 10s that we have at the company who talks about the 20% of the time he just works on stuff that like he's never going to get credited for, right? Right. It's like the kind of org contributions or if you get very senior, it might be the code contributions cuz like they don't really care if I code Yeah. or not anymore, right? What's the rationale that if you're always if you spend 100% of your time working on stuff that you get credited for, you're probably dropping a lot of stuff, right? And I see I see it happen like someone might come and be like, "Hey, can you like help me with this thing or something like that?" And I'll be like, "Well, I I'm know I'm never going to get credit for this, so I just say no to But there was actually a lot of value in helping that person. I'm just like when performance comes around, no one's going to be like, "Oh, he helped this person. Cool." So, I actually like that kind of mindset and it was kind of how I was operating before I read this, too. But like, yeah. 20 or 30% of my time. Yeah. I'll just do things that I know I'm not going to get credited for. Yeah. Yeah. PSC is all about doing things that are measurable. And there can be a hundred little things that you help people with that made them 5% better or something and that's not going to be in your PSC because your PSC is probably just giant migration item, giant, you know, this, giant that. Not all those little things. Not all the little things. And like those 20 or 30% you want them to from your point of view, you think they're valuable, right? But just no one else is going to think they're valuable. Like I think helping that person is valuable. I think doing things for the org, the wider or is valable. I think having some coding time is valuable, right? But yeah, a lot of people like probably not. Yeah. Yeah. I think also early in my career, I I worked so much extra hours just doing whatever people gave me that I do think it actually became valuable at a later time. Like, you know, I was kn credible and known as someone who's just going to like unblock you no matter what. Like, I'll be responding late or whatever just cuz I was into it. Yeah. So there's a hidden things outside of PSC that Yeah. And then that becomes valuable, right? Yeah. And then that becomes value. Yeah. Like a lot of people appreciate the fact that I'm a senior engineer who still ## Taking notes in VSCode [42:12] codes. I think we talked about the work diary thing. I wrote something about how it's important to have some documentation of the things you're landing or the state of investigations etc. and the value of writing. What's your process for keeping track of your work in writing? Oh yeah. So basically I have a really good note takingaking system because I'm terrible at remembering things. So and my note-taking system is actually in VS Code. Oh really? Yeah. So I just have another VS Code instance spun up so I can have two running or whatever. Is it just a text? It's just a text. Yeah. And uh so I'll have it and I don't I don't actually use multiple monitors. So I just have like the workspace thing or whatever on Mac where I can just use a couple of fingers and it just flicks across. Oh, like that. Okay. So it's always very easily accessible and I'll just dive across and I'll have I'll create a new readme file in one folder. I don't have the whole I don't have a folder archive. It's just one folder and I'll have like Yeah. like current project name or something just saved in there. Yeah. And that way I can like search for a file name in like two or three characters and jump between file names. So I have now on there there's probably like tens of thousands of files cuz I have notes for everything on there. Yeah. But I this is my like index way of like sort of jumping between lots of thoughts. Yeah. And writing them down. And then I have like keyboard shortcuts for inserting like the current date and time. Yeah. Right. So I can like kind of index it on that. Oh wow. It's like an extension of your brain. Just like you're just constantly noting things down at all. Constantly noting it down and I don't have to spend any time organizing it, right? Cuz there is no folder structure. Just one giant thing. The only thing that it's organized by is like searching for a file name. Or you can use word search, right, if you need to. F. Yeah. Crl+ F. But most of the time I'm like have a pretty good idea of what thing I saved it under. Right. Yeah. So every oneonone there's like a a name of a person, right? Like Right. Right. Right. Every project there's one I have like a couple of root level ones like priorities. For work there's priorities. So then in there I'll have use the time stamp each day. These are the priority things. Write some memos for me up the top like you know don't spend time on X today, right? or like this year, don't spend time on this. Like, don't focus on why. Yeah. Yeah. Which is actually helpful reminders because I'll jump in there once a week and be like, "Oh crap, I'm trying to break that habit." Yeah. Yeah. I'll get out of this. So, I guess that's you writing things in and cataloging when you pull like let's say you're writing your performance review. That's one reason people like use. Yes. So, you just kind of dive through there. Is there like one that's like achievements or like So I've only once in my career for a year kept track of the projects and stuff that I did. Um and yeah, this year I'm not keeping track again. Okay. So yeah, I don't keep track of what is actually happening on the like Okay. So you just at the end you just end I'll try to figure it out. Which has downsides, right? You know, it takes like a whole day to figure out what you did for the year. Yeah. Yeah. But yeah, I just haven't found value in tracking everything each day. Yeah. Yeah. because I already have like the system of like what I need. Yeah, I mean dailies probably be too much anyways. Like I feel I always liked writing launch posts because at the end of the year I just scroll through what just every launch post is like a bullet in my PC. So that's a good one. I like that because you got to put those out anyway, right? So yeah, you got to put those out anyways. So it's just like I'll just look at those later. Yeah. Okay. I like that that note-taking. It's simple. It's it's simple. And then the other thing that's part of it is there there are links between the files. Oh. Uh so I have a VS code extension which lets me put links between the files very easily. Yeah. Yeah. So I can just and it's I don't know it's like I press one key and same because I'm using everything based on the file name, right? I just like start typing file name. Bang. It's linked. Yeah. So that's the way that it's kind of organized. I can like jump between these thoughts or whatever. Yeah. And then it actually has a the same VS code extension has this thing where you can view it as a graph. So if you started linking all your files together, you can then view a graph and see how you've like organized your mind and you're like, "Holy [ __ ] well that's gimmicky." Like I never use it that like occasionally you fire it up, you're like, "Wow." It's like your own internal Wikipedia like what you got going on like linking between thoughts and Yeah. Exactly. And then once you've been doing it for a while now I've been doing it for like 10 years or something. It's just like 10 years of thoughts in there. And I have all my personal stuff in there, too, right? It's kind of weird cuz then you see the work and the personal overlap at some point. Yeah. Yeah. Yeah. Yeah. I wonder if it can you could feed it to an LLM one day and it can Oh, yeah. useful or something. You can retrieve that easier. Yeah. Yeah. It'll like know everything about me. Yeah. Yeah. Yeah. Cuz it's got my diary in there, too. It's got like all sorts of things. Yeah. Oh, that is so cool. I see we're like ## Advice for his younger self [47:03] low on time. So, the last thing that I want to ask you is let's say you were going back into the industry. This is like you just graduated college. Yep. And you were going to give yourself some advice. What would you what would you say? Oh, man. Well, okay. Go where you're valued. I've seen lots of people go onto teams where they're not val not valued. Like, what do you mean they're not valued? Like you're you're really good at working on front end, right? and then you end up on a backend team and all of a sudden your performance is crap or like you're really good at fixing or like you like working on framework things and you're on a product team and you're like constantly tweaking the frameworks and making them better and then you get a really bad rating at the end of the year even though you landed like 500 diffs or something. Yeah. Yeah. Like go into the environment in which like you're valued and maybe you end up being an environment you're not valued in for a year but just like recognize that and get out of it. Right. Right. So I think so like lean into your strengths basically. Yeah. You're you're trying to lean into your strengths but the your management chain or your team around you doesn't care about your strengths, right? Go and find a team that like likes your strengths and go there, right? And you're going to be way happier. It's going to work much better for you. Yeah, definitely. And it seems like your career, that's kind of where it started to you made that jump into a web team. Yeah. Instagram. You were excited about it and you just kind of went up from there. Yeah. Exactly. General philosophy is just like I don't know, be nice, be be good. What's the word? Have have fun. Like I I'm always being a joker, right? Like even even when I'm talking to leadership or like writing out these big posts, right? Like most of the time they're not super professional. I'm trying to be like, you know, have a little bit of fun with it. Yeah. Be be simple, right? Don't over complicate your posts orification. I mean a lot of people they present like a work you know a work form of themselves and then uh you know outside of work they're a different person. Yeah. So yeah I try to meld those things for me I try to do the do the same thing cuz that's like kind of true to me and like I think makes makes work more interesting and we're like we're having to work on it. We spend a lot of time here. Right. It' be more fun. But I wonder why there's got to be some trade-off because it seems like so many people are Yeah. What's the tradeoff? I think like depending on the type of person you are, like sometimes I can end up saying really dumb stuff, right? Yeah. And then the way that I've had to counter this at work, people know that like, "Oh, Jake's very nice." And if he says something dumb and you tell him, he'll like be like, "Oh, yeah, [ __ ] Sorry, that was dumb." and like apologize for it and like Yeah. stuff like this. Obviously, can't go out and say like really crazy stuff, but thankfully I don't do that in my personal life anyway. But yeah, I try to bring my like I don't know myself to ## Outro [49:54] work. Thanks for listening to this podcast. I hope that it was helpful. This podcast is a hobby of mine and so I'm not selling anything and I don't have any sponsors, but if you want to support the podcast, please drop a like. If you're on YouTube or wherever you're listening to this, if you're on Spotify or Apple Podcast, if you could leave a review, that would be much appreciated. And I'm always looking for new people to interview. So, if you have any suggestions on that, people you think would be interesting to bring on to the podcast, please let me know with a comment and I'll take a look.