The Peterman Pod - Instagram Principal Engineer (IC8) on Promotions, Breaking Prod, Tech Leading | Jake Bolam

Episode Date: May 31, 2025

Jake Bolam grew from Staff Eng (IC6) to Principal Eng (IC8) at Instagram. He had some hot takes about diff reviews and risk (he accepts diffs that’ll break prod). He also shared interesting stories about his promotions as well as many tips on how to have IC8 impact with a solid work life balance.We discuss:• Struggling initially at Facebook• His promotions from IC6 -> IC8• Accepting diffs that break prod• Systems for reasonable work life balance at IC8 • His note taking system in VSCode• Advice for his younger selfTimestamps:(00:00) Intro(00:50) His rough onboarding to Facebook product team(04:32) Switching to Instagram (06:39) What IC7 scope looks like(09:48) Thoughts on management(10:32) Why he always makes time for others(13:31) His IC7 & IC8 stories(20:54) Swapping out infra for 1000s of engs(22:37) Work life balance tips (IC6 -> IC8) (27:26) Diffs reviews & risk (36:07) Being a good tech lead (42:12) Taking notes in VSCode(47:03) Advice for his younger self(49:54) OutroWhere to find Jake:• LinkedIn: https://www.linkedin.com/in/jakebolam/• Threads: https://www.threads.com/@theregularbuiltozzyWhere to find Ryan:• Newsletter: https://www.developing.dev/• X: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.net/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman To hear more, visit www.developing.dev

Even if I see your diff is going to blow up production, 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? 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 is stupid. And yet his work-life balance is somehow reasonable. So certainly you have a pretty good balance, yes. And it's all the systems that have been building my whole career that I think are like able to keep me here. Yeah, you probably want to know about it. I thought he had a really interesting note-taking system.

And my note-taking system is actually in V-S-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 radius because you got to ICAid or a principal engineer in the industry. On your path to ICAid, what were you hired in as to me? meta and maybe you can give a high level timeline of the teams you were on yeah sure thing yes 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 two or three 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 me i had a pretty slow ramp up to meta because I joined when they, it was middle of COVID. COVID 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. It's actually empathize with a lot of people that like took like a year to ramp up instead like three months.

Was your performance at risk initially because you're onboarding remotely? I think my manager like helped a lot like with the system. I managed to get like a meets all or something like this. You know, definitely wasn't excelling. I 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. Yeah. Which was kind of crazy.

Especially because 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 in 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 with back end 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 ever worked at moved me into like front end infrastructure very quickly and then back end infrastructure. Actually, one of my big draws to meta was, oh, they're so big, I'll always be on. 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. It 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 get 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 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 back end stuff or like yeah exactly like on at instagram at web we probably had like less than a hundred people would work on it you know right on the company right time right and on the back end we have like 2 000 3 000 engineers working on it yeah that makes sense even from the engineering point of view right right so then so then you are ic6 on the group's team you were onboarding slowly yeah and you weren't liking it it was this back end integrity system you switched to instagram web as ic6 is Is there? Yes.

Okay. And so that's where your career started to really pick up. Yes. So I think I came in and 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 growing too. They were moving from one of our stacks to another stack.

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? Because that's six to seven barriers. 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? Yeah, I think that's one of the big things people look for. Yeah. People who want to get to these levels, they, even if they want to, sometimes they don't have the opportunity. So I'm curious, what did you do 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 for to. So I was like, yeah, I want the career growth right. I think I can do this. Like 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, FY, I'm, I'm eager for IC7. Yeah. And so they knew that and they basically just gave you the opportunity 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 scope? What does IC7 scope look like? Yeah. So IZ7 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 different area, right? So then would eight be even just like a. 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 back end 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 specialists 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 yeah so this i'm talking through one very specific lens yeah right so yeah there's all these ways that people can you know contribute to

the business and like be having that large blast in that 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 yeah like a fixer like the fixes 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 it's like really good value in having these folks around and give them the career part 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. 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 are monor 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. 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. Have you ever thought about management?

Because, 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. Yeah, yeah. Like, go and land a ton of code to get this across the line. I see.

You can't really do that in management. Yeah. also a bit of a loose unit and sometimes say dumb stuff. So I think 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. Yeah, I feel like you have to be a little more sensitive to things as a manager. Yes. Yeah. Yeah, I noticed your internal profiles that's 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 ICA and 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 overloaded 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? 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, because someone like you's 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 nice, perfect world, you'd make time for them and you talk to them. But in an 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 do try to put the levels thing out of my head always. So if an intern's coming here, 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 telling them stuff and they're like acting on it and going for it.

I'm probably likely to give them more time again. But if they come in and they kind of ignore it or they ask really bad questions and stuff, probably not likely to give them too much time again. 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 probably be better and helpful.

Right. Yeah. You mentioned to 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? I haven't really thought about it too much, but I don't, I don't know, just be genuine, right? Don't try and, like, script it or, like, pick up line it. Yeah. Pick up like that 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 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.

leading few teams and your management chain said, we need a leader. And you were eager and you took that on. What was it for ICAid? Yeah. Also just on that, like getting to the seven one, you got to also land the project, right? Right, right. So yeah, definitely, I think something that happened that helped with the seven one 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 infamigration right and it was scoped at like two 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 six months oh wow 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 three months which was kind of crazy. That's kind of crazy. Yeah. So 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 hungry for it and was like, yo, two years is silly. Like we can do this sooner. Like we'd started to gel together, right? Everybody was sort of playing to their strengths, which you're like, here is pretty common. And we're like, yeah, we can do this like way sooner than two years.

Yeah, yeah. I think before we were going very serially too, like we were doing like one page at a time. Yeah. And someone was like, yo, why don't we do like 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 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 of that hungry energy and I guess it was infectious and then everybody was like on board with it and we're all having fun and we're like, yeah, we want to do great. And like, because we shipped it early, right? It was good for me, but it was good for everyone else too. Yeah, yeah, yeah. Lots of promotions on the team. Yeah, yeah. And it's super deserving. I mean, that's insane business impact. Like such a huge thing. Yeah, exactly. Yeah, yeah. Because then we got ads on there and then 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. Yeah, yeah, yeah, yeah. That makes sense. And that was the IC7 promo. So that was the IC7 promo. So I think IC8 was like, at this point, leadership 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 it's 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 is stupid. Yeah, yeah, yeah. Which was like, we're just on the front end moving it into the main metastack, right?

Hey, can you move the back end into the main metastack? Yeah. And I was like, cool, that sounds impossible. Let's try that. Yeah. And that's, yeah, you're aware of the details of the project. But that was an interesting one because, yeah, 95% of the engineering org was like, this is stupid. why would we waste any resources

on this, right? So we knew we wanted to migrate into the other stack, but we couldn't go out to the engineering org and say, hey, we're migrating because we'd get shot down and everyone would be like, this is the dumbest thing ever. And we'd like kill morale for the org. 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, well, it works, why switch over? Yes. Those, okay. Yeah.

And so you had to, you couldn't just immediately initiate 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. And also I kind of like at the time I like agree with those engineers right. Like the majority of our development is in the stack. All our important surfaces are here. Like it's way better to be in one. Right. 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 just 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 because 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 dub dub dub dub so that was the first year and the second year it's like there's a bunch of stuff missing from dub dub dub that doesn't make it feel like Instagram. 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. Now we're in year three where it's like, okay, now we have these two things. And during that time, more of the cross-stack stuff has happened.

Some surfaces did migrate because they were going to get bigger benefits. 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 ICA promo, because I guess the full migration is not fully complete, but there was some milestone in this larger strategy that was worth an ICA 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. He's like a very senior engineer at meta, like, I don't know, 10 or 11. He's been around a while. Yeah. Because the project was like, it was, it was so. crazy trying to rewrite Instagram right while you know the classic metaphor of like you know you're on the plane you've got to yeah yeah yeah 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 yeah yeah and we only had uh sevens working on it yeah 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 the 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 like this is done this is 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 it's like way easy to work on okay okay okay okay i mean yeah that blast radius is insane i mean yeah makes a lot of sense yeah one thing i was curious about because you this

This is one of those projects where you're switching out a lot of infrastructure that people are using. How did you make sure all these engineers are happy with the tooling? Because 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? Yeah. So we have like an Instagram, we have like 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 the day-to-day developments are here. 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 let us know, right? Like if someone on the team raises it to them, let us know. 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. 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. Yeah, yeah, yeah. 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. Yeah. Yeah. Monitor. Right. Which are very helpful to. Yeah. That makes sense. As you've grown from IC6 to IC8, you take on more responsibility. How's your, like, hours work per week changed 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. 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 40 hour weeks. Or if it's during the summer and I work 60 hours a week 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 fluctuating depends on what the project's going on.

But most of the time I am trying to target like the 40 hours a week because 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 this. Yeah, yeah. Yeah. There's certainly you have a 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 six months, yes. And it's all the systems that have been building my whole career that I think are

like able to keep me here. Yeah. Yeah, you probably want to know about it. Oh yeah. I got to know about these systems then. One of these systems that are making you able to have this level of impact with that time investment. So yeah, 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 I get a lot done in the morning. 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 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? No, 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 do stuff to, like, move the projects forward that I need or like message people would I need to message. Right, 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 or three weeks. Or not disappear, but like I will cancel like lots of these meetings right. Once a project's going and has momentum or something, you can 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 are no meetings. Yeah. Like, people like, hey, I want to get involved. Can you add me to the sinks?

I'm like, there are no sinks. Well, how do you keep, how do you keep? Because those meetings have some values. They have some value. So 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 sinks 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 that yet, 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're like 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. So it's all ad hoc as needed. It's all as 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 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. Yeah. They do kind of like that. Yeah, yeah.

So this is part of philosophy too. So 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 and 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 where you're a coding machine, are you also diff review machine and what's it look like? Yeah, whatever's needed. 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 semi-blocked 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, though? Really on top of diff reviews.

Yeah, like actually, I think there's probably lots of memes floating around for me because like people put up diffs and like five minutes later it's like stamp. I mean, 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 a, 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? Right. These things, then you're going to just get a very high level diff review and then basically I'm just like trusting you. So you're saying you modulate your level of time investment based on how risky the dip is. Based on how risky the diff is, right? So if you're rewriting it right, right? It's all gated right now and we just want the high level 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. Yeah. Yeah, I'm trusting you to do whatever you need to do over there. So you'll just stamp it. So just stamp it, let us see. Yeah. Some people view quality differ view as a, like an important thing rather than just

so you ever get pushed back on that? So this is my controversial one. Okay. For sure. So yeah, so I think that is correct for like the trunk of the system, the core parts of the system or anything that's already live in broad like is going to get pretty. thorough review. Yeah, if it's not live and broad and it is one of these sub, like, sub 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. 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 parts of the system, right, or the leaf parts of the system. And also these parts are like generally easier to unit test. Yeah, yeah. 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 engineering. is maybe it impacts a couple yeah and someone one day is like what the hell's up with this yeah yeah doesn't take a long time to rewrite right right if you mess up the architecture on the core trunk probably takes like hundreds of people a long time to like fix yeah yeah have you have you ever had some i remember early in my career i was all about speed and i was approving some diffs and then someone come back to me and say why'd you approve this those two you know like let's slow down a little bit on yeah You ever get some feedback or someone says, hey, you know, calm down.

This definitely happens. Actually, interesting thing. So teach the people close to me in my teams that, like, hey, it's okay. Buy stamped or 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 deep review on this. If you know, that's how our team operates now.

Yeah. 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. 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 because they knew what happened. 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 depends on the system also depends on like this is like trust you build on your team too yeah yeah yeah and you're on the team probably not gonna get this treatment for the first couple of weeks yeah 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 because like I'm not trying to like knit your code and get you to

write it the exact way I 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 high level 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. Yeah. 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 think when you are 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 love that because everyone's just trusting. 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'll like, even if I see your diff is going to blow up production, 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? Yeah, yeah. I've never had a case where someone's like landed it. Yeah, yeah. Like with a comment on it that says, hey, this is going to blow up production.

Because you can imagine like sitting in Seb review or something and someone's like, the diff had a comment on it, this is going to block production. Yeah, yeah. That's wild that you accept that, though. Yeah, except I just trust him to fix it, right? 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. Yeah, yeah. Right? I might be like, ping me again when it's like ready. Yeah, yeah, yeah. But yeah, 99% in time, I'll just like accept and go. Yeah, yeah. And yeah, haven't had to do the thing where I pull back because I've never had one that's

been shipped accidentally. That exploded production. And that's actually a little bit of 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? Yeah.

even if it is controversial and crazy. Yeah, yeah. I'll keep pushing the boundary on it, right? Yeah, yeah. 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 are like, that's crazy. Like step to like two, three, five things. It's like, well, we're not getting any, like, signals that it's not going poorly. Right. As soon as we get signals that it's going poorly, we start pulling back. But otherwise I find you, like, move too slowly. Yeah, yeah, yeah. Right.

You want to be moving at, like, the fastest speed. can without ruining things. Yeah, yeah. So if you're not getting, if you're not making anything worse, like keep trying to find that edge. Yeah, yeah. Yeah. 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, on one end, you shouldn't break prod generally.

But he also said if you never break prod, you're probably, that's probably not also optimal. Like there should be some level of risk. Otherwise, you're moving too slowly. Yeah, exactly. Yeah, try not to break prod, but if you never break it, you're probably like very slow. Yeah, and if you're breaking it every day, you're probably going way too fast. Yeah, exactly. Need to fix something.

Do you use AI at all? Yeah, 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. 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 it'd be like what the fuck 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 tech lead of it because i feel like that's one super power 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 fix a mode. there's been a few times or had to like, no one else can debug what this thing is doing. So I spend 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 goal is of the project, right? It's so easy to get caught up in the day-to-day operations of like, like we need to be doing this and need to be doing why 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 to like shift the team towards towards the goal again right right i know i 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 further from the code yeah and more in dock work and leadership meetings and things. How do you strike that balance? Yeah, so it's definitely is 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 small 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 because 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 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 caveat on the fact that I'm always trying to work on what I think is the most important thing, right? Like if it was saving that person, you know, their whole week of doing it's going to take me an hour or I'll go and do it. But there might be periods of time where we're doing a big review or, you know, we're going to get a head count injection or I don't know, we need to be doing X, Y, or Z. And then. And 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 junior people lack this, but how do you develop that skill of seeing what is impactful with your time? You know, where's the ROI? Where'd you learn that? Yeah, I think it's, I don't know, just like practice. Practice makes perfect.

And you've seen a lot of scenarios so you kind of know 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. And that's usually the area I would go to. Oh, interesting. 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. Yeah. 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. Yeah. Yeah. It makes sense. Man, I haven't seen that essay. I love that. Yeah, yeah.

There's a lot of gold in workplace. There is a lot of gold. Sleep on, like the all-time essays and workplace. Yeah. They're buried somewhere in there. There's another one from one of our, like, I don't know, I see 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 it's

like the kind of all contributions or if you get very senior it might be the code contributions because like they don't really care if I code yeah 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 know i'm never going to get credit for this so i just say no to them 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 we help 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 percent 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 yeah There can be a hundred little things that you help people with that made them 5% better or something. Yeah. 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. Yeah, yeah. Like I think helping that person's valuable. I think doing things for the org, the wider org is available. I think having some coding time is valuable, right? Yeah, yeah, definitely. Like, probably not. Yeah, yeah.

Yeah. I think also early in my career, 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 not credible and known as someone who's just going to like unblock you no matter what. Like, be responding late or whenever just because I was into it. Yeah. So there's a hidden things outside of PSC. 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 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, et cetera, 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-taking system because

I'm terrible at remembering things. 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. It's just a tech stock? It's just a tech stock. Okay.

And so I'll have it. And I don't actually use multiple monitors. So I just have like the workspace thing or whatever on Mac. I can just use a couple of fingers and it just flicks across. Oh, I like that. Okay, yeah. So it's always very easily accessible. And I'll just dive across.

And I'll have, I'll create a new read-me 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 because I have no for everything on there yeah but I this is my like indexed way of like sort of jumping between lots of thoughts yeah and writing them down and then I have like like keyboard shortcuts are 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 it's like yeah you're just constantly noting things down and just constantly noting it down and I don't have to spend any time organizing it right because 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 yeah yeah control left but most of the time I'm like have a pretty good idea of what thing

I saved it under, right? Yeah. So every one on one, there's like a name of a person, right? Right, right, right. Every project, there's one. I have like a couple of root level ones, like priorities or something. Work, there's priorities. So then in there I'll have these timesant 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. Or like this year, don't spend time on this. Like focus on Y. 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. habit yeah yeah I'll get out of this so I guess that's you writing things in and

cataloging yeah when you pull like let's say you're writing your performance through you that's one reason people like you yep 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 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, at the end I'll try to figure it out.

Yeah. 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 to do on the day to do on the day. Yeah, I mean, daily is probably too much anyways. Like, see so that's a good one I like that because you got to put those out anyway right 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 no taking so it's simple it's simple and then the other thing that's part of it is there there are links between the files oh 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 talking file I'm bang, it's link. 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 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 your graph and see how you've like organized your mind and you're like, holy shit. But that's gimmicky. Like I never use it. But like occasionally you fire it up. You're like, wow. It's like your own internal Wikipedia, like what you got going on.

Yeah. Like linking between thoughts. 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? Just kind of weird because then you see the work and the personal overlap at some. Yeah, yeah, yeah. I wonder if you could feed it to an owl on one day and it can be useful or something. You can retreat from it. Yeah, yeah. It'll like know everything about me. Yeah, yeah. Because it's got my diary in there too. It's all sorts of things. Yeah. Oh, that is so cool. I see we're like 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 valued, not valued. Like, what do you mean they're not valued? Like you're really good at working on front end, right? And then you end up on a back end team.

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 like lean into your strengths basically yeah you're you're trying to lean into your strengths, but your management chain or your team around you doesn't care about your strengths, right?

Go and find a team that 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. Yep.

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 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 yeah don't overcomplicate your posts right right right i mean a lot of people they present like a work you know a work yeah form of themselves and then outside of work they're a different person yeah so yeah i say try to meld those things for me i try to do the do the same thing because that's like kind of true to me and like i think makes makes work more interesting like we're having to work on it yeah yeah spend a lot of time here right it'd 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 trade-off 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 he says something dumb and you tell him, he'll be like, oh, yeah, shit, sorry, that was dumb and, like, apologize for it. Yeah. Stuff like this.

Obviously, you can't go out and say, like, really crazy stuff, but thankfully I don't do that in my personal life anyway. Right, right, right. But yeah, I try to bring my, like, I don't know, myself to 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 Podcasts, 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 onto the podcast, please let me know with a comment and I'll take a look.