The Peterman Pod - Meta Distinguished Eng (IC9) On Influencing Engs, Failures, and Learnings

Episode Date: February 9, 2026

This is Adam Ernst, a Distinguished Engineer at Meta (IC9) who’s built iOS infrastructure that has impacted the entire company. We talked about how his career grew, a major failed project of his, and everything he learned growing to that level.🔸 My keyboard project link: https://read.compose.llc/p/our-keyboard-design-reveal𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:• YouTube: https://youtu.be/YA_OYJF3Mmw• Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835• Transcript: https://www.developing.dev/p/meta-distinguished-eng-ic9-on-influencing𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:00:00:00 - Intro00:00:47 - His middle school company00:03:50 - His first project and promo at Meta00:10:03 - Why code review is undervalued00:12:42 - Senior Staff (IC7) promo story and project00:19:26 - His major failed project00:26:35 - How to handle a failed project00:29:04 - Thoughts on management00:31:35 - Technical depth vs breadth00:33:32 - IC9 expectations00:34:46 - Senior engineers he admires00:37:39 - Advice for his younger self00:39:52 - Outro𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗔𝗱𝗮𝗺:• LinkedIn: https://www.linkedin.com/in/adamjernst/𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpeterman

When I run into a problem, instead of being like, all right, got to go talk to the GraphQL team. I'm like, screw it. I'm just going to figure out what the problem is. This is Adam Ernst. He's a distinguished engineer or IC9 at Meta who has built iOS infrastructure that impacted the entire company. And I asked them how his career grew. If you show up, you're like, hey, I did the work already for you. Much easier conversation.

1,600 diffs in six months. Why did you spend so much time also reviewing code? It's really valuable because you can influence other engineers in an organic way. He was unusually honest about a major failed project. So Component Script was interesting because it was a total and complete failure. And I worked on it for like two years. With all that pushback, did you ever doubt the direction that you're going in? There were some literally sleepless nights.

Here's the full episode. I saw that you have something on your resume. It says Cosmic Soft, which started in 2000. And if I have the math right, that's like, middle school for you. So what was that? And can you talk more about the story behind Cosmic Soft? Yeah, you dug deep, man. I got to take that off of there. That is indeed my middle school software company. I discovered at an early age that I liked writing software. My mom was a teacher. And I would often spend time in her classroom after school, just like messing around with computers.

and that gave me the inspiration for my first product to sell, which was online testing software. I wrote it in a tool called Real Basic, which was basically a cross-platform, visual basic-inspired language. So I was actually writing Basic, which, oh, God. And yeah, sold it on the internet to, like, tons of different countries. It was a lot of fun. I was not a programmer at that time. Can you give give some more context. Is that something that's running, I guess, native on like a Windows machine or something? Or what is that? Well, Real Basic was this product from a different company, not Microsoft. And it was inspired by Visual Basic, very clearly Visual Basic-esque, but it was cross-platform. And you could design the software on any platform. I used a Mac. The concept behind Digital Basic,

for those who haven't used it, is that you basically have this blank canvas and you can just drag and drop buttons and text fields and all this stuff on it. Very easy to get it. Very easy to get into, right? Because even nowadays with something like Swift UI or React, you're writing code that describes your user interface. There's a separation there. Whereas visual base, you're like, well, I want a button, drag, drop. When the button is clicked, I wanted to close the screen. Okay, double click on the button and you write some code that's like window. close. So really easy to get started with, not very scalable. And, you know, basic is a horrifying language. But it was a fun way to get started and really easy for me as basically a middle schooler to write an actual software

product that was useful. How are you selling that on the internet? Because at the time, they didn't have Stripe or anything like that. How do you even receive money from these people in other countries? There was a service called Ecelerate, which was like a proto stripe. It allowed you to create an online store for your software. It would help you create a code that you could enter to unlock the software. And so people would go to this website. They type in their credit. card info and they would get a code to unlock my software. Fun fact, I also accepted payment via check. So for a while, as like an eighth grader, I was getting checks from all over the United States from teachers. They'd mail me a check for 1995 and I would send them via email a code to unlock their

software. Good times. Did your parents know you were selling software to strangers on the internet? They did. I don't know what they thought of it or what they could make of it, but they did know I was doing it. Okay. That's so. cool. But yeah, let's get into kind of like the main part of your career, which is you joining Facebook. You joined the company to help with the native app rewrite from HTML5. And you got promoted to the staff equivalent or E6 very fast. Were you hired as a E5? I'm pretty sure I was hired as an E5 because I had industry experience. I was self-employed, but I, you know, like wrote software in the industry for iPhone. And yeah, it was funny because Facebook was just a total.

totally different company. I joined just before the IPO, like literally weeks before the IPO. And so it was already a large company, but compared to what it is today, totally different. All of the iOS engineers could meet in one conference room. And we did, right? Like every week we had a stand up and like we talked through what we did that week and all that stuff. And yeah, it was a fun time to join because we were totally rewriting the app. There was this cultural shift away from face web, this like HTML5 attempt at making a native app and towards the native code. And the nativeist engineers were very much like, ascendant, right? Like we had won the battle and now we needed to prove ourselves that it was going to work out and it did. And that also meant a lot of big problems, a lot of big opportunities, a lot of big problems that needed solving because our code base was brand new and we were discovering all the ways where it was going to fall over as we continued making the app bigger, adding new features. So that's what I walked into in 2012 and it was definitely a fun time. One of the first projects that you worked on was one of those scaling challenges. in adopting native code.

And that also happened to be your E6 promo. Could you talk a little bit about the core data problem and why it was E6? Yeah, core data is Apple's ORM database framework. It's great if you are a startup that has like two engineers and you just need a small little way to store data, it works great for that. We already had, like I said,

we had enough iOS engineers, we could all fit in one conference room. So we started with like 15 to 20 maybe by the time I got there. And we were rapidly growing, right? Like soon we had 100. Soon we had 200. Core data falls over completely at that scale.

So we needed to swap out how we store data. But this was also a really critical time, right? We had at this point just launched our native rewrite using core data. And so everyone wanted to add features. The groups team, the events team, the pages team. They all wanted to like rewrite their stuff in native and get all the great wins from native code. Meanwhile, at that time, at that time, mobile was a separate org inside of Facebook. We had the mobile team were like, uh, this is not going so well.

Like Cordata is going to fall over tomorrow and everyone's knocking down our door being like, please rewrite native. So we had to find a way to do it incrementally. We needed to find a better architecture, which was what we, you know, found along the way. So that's where we were in like 2012, 2013. And we called our new solution mem models, which was an immutable model system, which made it a lot easier to reason about thread safety, mutations, etc. You had this new offering that, you know, had a lot of benefits to it.

But still, I imagine you had to convince other teams to adopt it. So, you know, the core features of the app, feed, et cetera, were already bought in because the performance was miles better and they didn't require any convincing. It was driving it all the way to the finish line, giving the last straggler products to onboard that was harder, right? Because for them, they were like, yes, so our performance is a little bit better. Who cares? We don't care. We were more interested in other things. Also, it wasn't necessarily individual teams that were skeptical of the entire project, but we did get a lot of push

back from Apple-e engineers, for lack of a better word, like engineers who believe in Apple's built-in solutions and are like, why would we not use core data? Like, I'm an iOS engineer. We should use core data and everything else vanilla from Apple. I think that's lessened to someone over the years just because meta and Facebook and Instagram and all of our other properties have gotten so large. It's clear that Apple's solutions don't scale to that size. But at least in 2012 and 2013, there were a lot of people still clinging to this idea that, hey, we should just use the vanilla at Apple frameworks, and we needed to convince them over and over and over, like, here's why that's just not going to work. So that was a big challenge for us at the time. What did you learn

about influencing other engineers without authority? And do you have any tips on how to do that across like a large code base? My number one tip is talk in person or via video conference, if possible. You spend a lot of time trying to make your writing clear and accessible and have a good tone and you can often convey that tone way faster in person. My other feedback is to be sympathetic to their point of view, right? Like my, I would always start the conversation saying like, yes, I prefer vanilla Apple frameworks too. We're not going down this path just because I want to invent a new framework. Here are the specific reasons why we think it can't scale. Give data, give actual, you know, we were getting to the point where we were disassembling

core data's source code because it's not open source. To, understand what is it doing? Why is it taking so long to initialize? Having that data to give to other engineers is really useful, right? Like, hey, you don't know how it works because it's a black box. We know how it works. Here's how it works. And that's why that's not going to work for us. So, you know, I guess that sums up as do your research so that you can be convincing in that fashion. And the final one for me personally is just do the work for them. I think there are some engineers who would go about this project in the sense of, hey, I built the scaffolding. Now my job is to convince other people to do the work of migration. We call this archetype coding machine. I have mixed

feelings about archetypes in general, but in general, the idea is like, I write a lot of code. I like to write code. So my thought was, I'll just go do it for them. It's one thing to convince them, hey, you have to step up and do all this work. The other is like, if you show up, you're like, hey, I did the work already for you. Here are the benefits. I just need you to sign off and say, yes, this is fine in our code base. Much easier conversation. That mode of operation was very successful. Here. at meta for a long time. I think it's getting harder now. Our codebase is so big that one person can't necessarily do the entire migration.

You require some more alignment. But for a long time, that was a very good way to operate because you just show up and be like, hey, I solved the problem. And people would be like, great, love that you solved the problem and then I have to do nothing. I just say yes. It worked really well. I saw like in the career note that you wrote about this promotion that you'd also reviewed over 1,600 diffs and a half.

And that comes out to around like 14 diffs per workday. Why did you spend so much time also reviewing code? I think code review is super undervalued and I still do a ton of it. It's really valuable because you can influence other engineers in an organic way. Right. Someone's like, Adam, what's your message to other engineers at the company? What do you want to change? I'm like, I don't know.

But if I see a concrete diff and I'm like, I don't like how they're doing this and here's why, it gives me a perfect opening to get into it. However, I also try to be a very flexible diff reviewer, right? I feel like there were some different viewers who had that attitude of like, I'm going to help other engineers. And then they were very inflexible. Anytime they saw any little thing they didn't like reject. My view was like, all right, I see what you're doing and why you're doing it this way.

Here's my concern. And then either like, I'm going to let you do what you want if you really feel strongly, but here's what I would do differently next time. Or I'd be like, let's talk about how to redo your. work to accomplish whatever concern I have, basically hold their hand through the process, if I can. Because I feel like that's a great way to, you know, now they're going to hopefully, if they're convinced by my argument, they're going to hold that same change in how they operate

for their own future work and in all the future code review they do. It's like viral, right? And you see this would spread through the code reviews that they did. So I thought it was a really great way to like get my opinions out there and have those debates in a really structured format. Given that you've done just such an absurd volume of diff reviews, what makes a good diff comment versus a bad one, in your opinion? Talk through why you care about what you are nitpicking and not just what to change, right?

Don't say change X to Y, say, hey, X has some problems. So I really want you to use Y instead. But if you really feel strongly, if there's something I'm missing, then you can go ahead and use X, right? The other thing I was always open to in Diff Review comments was the fact that you that I might be missing context. And that's still the diff author's fault, maybe, because your diff should contain enough context

for anyone to review it on its own merits. But I'd often be like, hey, I don't understand why you're doing it this way. I want you to do it this way instead. But is there some missing context that would change my mind? If so, fill me in and put it in your diff summary, which again, I feel like make sure that if I'm making a stupid mistake, which happens, I don't look like a total idiot

who's just like getting it wrong. it really helps. So moving on to like, you know, E7 promo or the senior staff promo, I know that the main project that kind of drove that was component kit. Can you give some context on the story behind component kit? The years all blur together at this point, but this was like 2014 maybe. We had a very large and complex product, Facebook News Feed, which was growing and growing and growing so fast because the company hired lots of new engineers and they stuffed everyone on

news feed because that was the hot product at the time. So it was basically falling apart, right? We had constant crashes, constant layout bugs where like content would be overlapping in weird ways. And it was a struggle to keep performance good. I can't claim credit for the idea again here. It was Lee Byron, who was, I think, my manager at the time, but was for a long time, a very senior engineer at the company and co-invented GraphQL. And he had done a lot of work with React on the web, which was relatively new then too, even on the web, it was new. And he was like, you know what? We really need this React concept, but for iOS development.

At this time, React Native either didn't exist or was just a prototype. And so Lee told me, like, why don't you just take some time and think about how would the concepts of React work in an iOS first way? And Component Kit was my answer to that question. So it uses the same concepts of like components and we use the same. ability, re-render everything conceptually at least, when anything changes. View reconciliation, right? So you're not directly managing UI views.

You're instead just stating, hey, I want there to be a button that has this caption. The framework takes care of creating the actual button view. And I'm pretty proud of the balance that it struck in terms of the syntax was appealing, the performance was amazing. And it allowed us to solve a problem that we really needed to solve as a business. this. And again, this was 2014. So years before Swift UI, Swift didn't exist yet. Swift UI didn't exist yet. React Native didn't exist yet. It was very early on the scene. And it did take some convincing of other iOS engineers because it was still a very alien way to write code on iOS.

But once convinced, everybody loved it. Everybody thought this is a really great way to write the UI for a complex product like Facebook news feed. So the big challenge there was inventing the framework, getting it adopted in news feed and then getting it adopted everywhere else. So I had lots of work to do. How did you convince people? Because this declarative framework was such a different way of doing things. I imagine there was a lot of pushback. How did you drive those difficult conversations?

Tons of pushback. Some people were convinced when they saw concrete examples of, hey, here's what the same code would look like in component kit. It's now like a third as much code. Some people were convinced when they can see the performance, right? Oh, look, it allows us to render all the viewed hierarchies on a background thread and then only do the minimal amount of work on the main thread. They were like, that's really cool.

But there were plenty of people who were holdouts even then. And we had to call in mediators, right? Basically, like there were other senior engineers at the time because when I was inventing component kid I was an IC6. There were other more senior engineers who would, you know, get us to huddle up and try to talk through how do we find a path forward that we can all agree on. And I think Lee Byron was very involved in these conversations. I know Alan Kenastraro was a senior engineer at the time who was very involved in this,

helping us like mediate between these different groups. But I think the fact that React had a lot of cred as a framework at the company on the web really helped, right? Because we could point and be like, look at what React is doing on the web. We wanted to do the same on iOS. There aren't any really good reasons why we can't do it. It's not impossible to do on the platform. we have proven we can.

So get on board. And I acknowledge the downsides of Component Kit, right? By now, it's very creaky and old because it was a C++, objective C++ framework. Now we have a Swift API for it. That's great. But still, at the time, the weirdnesses of Component Kit were even then somewhat unappealing.

But my pitch was always, yes, it's a little weird. It's not the usual way of writing code in iOS. But here's all the amazing things we get. That's why you should do it. So that's the pitch that we had to make again and again and again to skeptical iOS engineers. Is there anything that you learned in trying to convince these people that were very against this approach that is kind of useful and general learning for anyone that's trying to have some new developer offering and convince people to use it?

Allies are super useful, right? I still remember there were some engineers like Clement Gensmer and Greg Meck, who carried a lot of weight in the company and they sought and liked it. great, I wasn't alone and they could help convince other people because, you know, I have one way of convincing people, which isn't always effective and they have other ways of convincing people, which often were more effective. And so it was nice to be able to break it down and like, you know, see the different ways that this discussion happened over time. There were opportunities for compromise. The other big alternative out there was this framework called panels, which hadn't really gotten off the ground

yet, but was supposed to be like the next way to write UI at Facebook. And I knew them really well because one of them was like my mentor. And so I, you know, was very, very close to Jonathan Dan, the guy behind panels. And boy, they had a really hard time because they felt like they were developing the next thing. And then I came along as like, actually, let's do component kit. Wasn't so good. But we found a way to compromise and we adopted some of the panels data source technology to power component kit, which was a good compromise and allowed us all to feel like we had to win. Instead of sticking to your guns and every little thing, if you can find a way to bring people into your fold into the tent, that's really, really helpful.

With all that pushback, did you ever doubt the direction that you're going in? No, I was very convinced that this was the right call for Facebook newsfeed. I will say, this goes for all declarative UI frameworks, React, Swift UI, Component Kit. They're really good at some things. Like a Facebook news feed is the perfect thing for it because it's like a scrolling list of complicated multi-level nesting. And it's mostly static, right? There's some animation and cool stuff, but mostly it just is like a list of stuff. That's the perfect application for it.

When you look at like a super dynamic drag and drop interface, eh, maybe not the right thing for it, right? Maybe not the ideal case anyway. You can make it work, but it's not going to be incredibly natural. So I'm very aware that like there are tradeoffs to these different paradigms.

And I wasn't drinking the Kool-Aid in terms of telling everyone, component kit's the only way to write UI's on Facebook. Like that should be the, you know, our only option is component kit. No. But in general, for what we wanted to use it for, yes,

I was very convinced that it was the right path forward. you know, the next project you worked on was Component Script. What was the motivation behind that project? And, you know, what's the story behind it? So Component Script was interesting because it was a total and complete failure. And I worked on it for like two years. At the time, my manager was a guy named Ari Grant, who was a force of nature, right? He was like all over the place, very busy, carried a lot of influence.

And Ari felt really strongly that we needed to get out of the per platform. platform silo, right? So like iOS had component kit, Android had a React and component kit inspired by then called Litho. But this meant we were writing everything multiple times, right? We had to write it in component kit for iOS. We had to write it in Android. So you wanted to have a cross-platform solution. React Native was not that solution. And we knew that. At this time, we tried React Native and it didn't go well. The reason was, in my opinion, this is just my opinion. React Native is designed to be in charge of the entire app. It works really well if your entire app is React Native. Or if you have entire app to React Native and then small

little pieces on the very bottom are native or bridged. Where it doesn't work is the way we wrote software at that time, which was we had this large, complex native app and we wanted to slot in small pieces of cross platform in different areas, right? So like, oh, maybe this little square on this screen is rendered using JavaScript. Maybe this tab is rendered in JavaScript and this tab is native. React Native could not do that for us at the time. They've done a lot of architectural changes to React Native in the last 10 years since then, and maybe it's better at it now, but at the time, it didn't really work. So we wanted cross-platform.

When you React Native was not it, what could we do? And so Ari asked me to go and work on this. And at the time, it was like, okay, this is the next nudge, right? Like, We Byron nudged me to work on React for iOS. That was Component Kit. Great. This is the next nudge. Work on cross-platform for our UI rendering frameworks that we use on iOS and Android.

And so I came up with a framework called ComponentScript. The idea was basically at first I took the React APIs, the actual React implementation. I said, what if we just made a different React Native, right? So exactly like React Native except that it works on top of Component Kit and Witho because that's what we already have. This turned out to be too difficult. React had a really large surface area and a very complex surface area and trying to make that work on component kit and with it was too challenging.

So I was like, all right, I'll do a smaller paired down API that feels just like React, but actually is simpler and make that. work on top of component kit and witho. And I made it work. It was a real framework. People built real features on it. You could build full screens. You could build individual units. You could do all kinds of, you know, bi-directional embeddings. You could have a native screen that had a component script unit, which had a native component inside of that. You could have a component script screen, which had a native section, all this stuff, really cool features. And for me, it was a real learning experience because I learned that just because it was technically excellent, didn't mean it was

going to win. It checked all the boxes we needed in terms of interop and type safety, but it didn't win and didn't come close to winning because there were many other factors that I didn't take into account. So a great example of writing a lot of code and doing a lot of technical work doesn't mean that it's going to win. I mean, if we were to kind of postmortem, why it didn't win, what are the things that you did well and what are the things that maybe could have gone better? I mean, doing well, I just mentioned it did check off. It checked all the technical boxes that we, as in like the core product interest group cared about, right?

Like it was type safe. It integrated with GraphQL and component kit and witho, our existing native frameworks. It was bidirectional. So you would never be suddenly cut off. There would never be a point where you're like, oh, I just need to embed this native component and I can't do it. No, you could always do it. The mistakes were, number one, I wasn't really aiming at a particular target engineer, right?

So React Native was focused on, like, web engineers who wanted to write for mobile. Component Kit was focused on, hey, we have iOS engineers that already know how to write iOS code. Let's let them write iOS code, but have excellent performance. ComponentScript is like, hey, you can write JavaScript, but it's not React. So like iOS engineers are like, I don't want to learn a whole new language.

I don't want to learn JavaScript. And JavaScript engineers were like, I'll use React Native. I don't want to touch this like weird not React API. No, thank you. So we were kind of stuck. Number two is that like we on the product infrastructure group really cared about GraphQL. We were like, hey, we want data consistency everywhere. So this framework needs to be based on GraphQL.

But it turns out GraphQL can be kind of a pain sometimes, right? Especially at that time, GraphQL tooling was slow and a lot of a lot of hassle. We fixed it a lot since then. But at the time, it was bad. And so trying to build on top of this slow, janky native GraphQL stack, really slowed us down. Meanwhile, there was another framework out there that was, you know, coming in with a server-driven sort of UI approach. And their solution was like, don't worry about data consistency. What if we just didn't do it? And we were all horrified. We're like,

what? You don't have data consistency. So if you like a post on one screen and you go to another screen, it won't show you that the post is liked. And the answer was yes, 60% of the time, 80% of the time, products just don't care. And for the 20% that do care, you can hack something in there that makes it work. So we were pretty horrified by not using GraphQL, but that was a huge advantage if you could just skip all that stuff. But I refused to compromise and that was a problem. And then finally, I went really wide. I was like, all right, I'm just going to talk to all engineers, all mobile engineers, and be like, you guys should all try out ComponentScript. And this meant that I got little pings of interest all over the place because there were a few engineers here and there that were

like, sure, I'll try JavaScript. Sure, I'll try cross platform. But there wasn't any individual team that was like, yes, this is how we want to write products from now on. And so that meant that it never went anywhere, right? Individual engineers would try individual little things here and there, but that was not going to get any momentum. Funny thing was, just when I finally pulled the plug-in component script, the group's team was like, oh, we just decided we were going to go all in on component script. And I was like, oh, man, no.

But even that would not have been enough momentum, right? It was too little too late. So you wrote about this retrospection. It's very detailed. One of the best retrospectives. I've read, why did you publish that so publicly? What was the motivation behind it? I don't recall. It might have been encouraged that I write it, but I certainly wanted to write it. It was cathartic to talk about what went wrong. And even at the time, I had a reputation, right,

people who knew who I was. So everyone would always be like, hey, how's that component script thing going? And the postmortem was a convenient way for me to rip the bandaid off and be candid about, hey, it didn't work and here's why and not have to constantly rehash that conversation over and over and over. But also, I hope that it would influence the way that people did stuff at the company in the future, right? Like, hopefully no one made the same mistake after that if they read my postmortem, or at least they were aware of what they were walking into. And, you know, in this case, you drove a very ambitious project. And it did fail in the end when it comes to performance reviews in a half where something like this is happening or a year where something like this is happening. How does that play out and should people be worried about, you know, their projects getting canceled or things like that?

The thing that made me realize it needed to be canceled is that I got a meets most. So performance did its job there. My manager at the time did the right thing and was like, this is not working. He was also a new manager for me. So I think he like could see it with fresh eyes and be like, this is not going to work. And then when I did cancel it, I like to think I did it in the right way, which is there were products and features. is written in ComponentScript, and I help those teams migrate back to Native code or to react native or whatever they wanted. And I completely deleted the framework. I didn't leave it as

like, you know, oh, this one product is still on Component Scripts where it's to weave it around forever and someone will have to clean it up someday. No, I was like, I'm driving this all the way and I'm deleting the code. It's going to be gone from the repo, which I think garnered some goodwill because it showed others. This is the right way to clean up after your mess. So I feel like I got, if anything, a positive bump after the fact, right? Like there was enough relief of like, all right, this showed people how to wind up, wind down a project that isn't working out. And he posted publicly about it, talking about the lessons learned.

And there's no mess left behind. So if anything, I feel like it helped in the immediate aftermath. So if anyone is like staring down the barrel of like, I think my framework's not going well, but I'm afraid to kill it. You might get more goodwill from killing it responsibly than just like dragging it out and constantly waiting until it's too late. Were there signs that, like, looking back, you could have maybe avoided some of the pain of, I don't know,

meets most or, you know, kind of like it going on as long as it did? Yeah, I mean, look, there were, there was, it was a two-year project. And for the last year, I knew it wasn't going right. And I should have listened to my gut, right? There were some literally sleepless nights, not a lot, but like somewhere. I was like, this doesn't feel right. It's not going well. I don't understand what to do.

And I'm a coding machine. So my reaction was, I just need to write more code. I just need to help more features convert and it'll suddenly take off. And I should have listened instead to that part of my gut that was telling me this is not going to work out. Just go do something you love and find a different way to have impact. And that would have been much better for me in the short and long run. You said before that, you know, for sure, you never wanted to try management and it was not

right for you. for someone who's considering that kind of decision, how did you know that management's not right for you? I like writing code. I really like writing code a lot. And as a manager, you can't write codes. I mean, for me, it's a no-brainer, right? I'm also just, I'm less good at the non-code-related parts of the job. So, like, driving alignment and writing docs. I'm just not good at that stuff. And so for me, I'm like, yeah, I don't want to touch that. And finally, I feel like I'm very good at communication with other. engineers in a technical role. I'm very good at like, hey, we need to solve this technical problem. Let's all get on the same page about how to solve it. I don't think I'm as good at doing that when I'm not quite, when I'm more removed from

the problem, right? Managers have to do a lot of direction setting and influencing people without directly pointing to like this line of code is the problem. And that I think I'm less good at. So for me, I always knew. Management is not for me. But it depends on the person. Obviously, I'm a pretty extreme case.

What about picking the don't. domain that you went with. So from what I see in your career, it's almost entirely on the iOS side with some cross-platform work. How did you align on iOS? And is that something that you feel strongly about being tied to? Or is that just where things have taken you? That's where things have taken me. I don't change around a lot. I've never really changed teams once at this company, right? Like I've been shifted on different teams as part of reorgs. But I don't know. I just kind of roll with the punches and I like what I'm doing. I feel like I like. like the team, so why mess it up? I admire engineers that are like, you know what, I want to go see

what this AI thing is about. I'm going to go check it out. Or like, oh, man, I really want to go arc on ARVR. That's not me. I knew I liked mobile and I felt like I was getting the right opportunities to work on stuff I cared about. So I just kept rolling with it. And I think it has worked out really well for me because it allowed me to build deep knowledge expertise about how all different parts of our system work. Right. If you want to know the guts of the GraphQL cogen or or value object generation or book or all these things, I know what's up. And so it's really helped me get really deep in this particular domain. And that means I have a lot of knowledge about it that helps answer questions from others.

Very useful. Would I do mobile if I was a brand new engineer today? Maybe not. Maybe I do AI because that seems like the hot stuff, right? Or I don't know what else. But I don't feel too bad about sticking with it. You talked about the technical depth. Let's say someone's goal was to be like you.

They really wanted to, you know, super aggressively pursue the high IC career path. They want to go IC9 or bust. Do you think that technical depth is better than breath for becoming the highest levels of senior IC? I mean, it depends on how you operate. I've seen lots of different engineers that operate in different ways. I will say I have breadth and depth, right? As in like not that, you know, it's perfect. It's not like I only know mobile though, right?

Like I know a lot about how Buck operates. I know a lot about how GraphQL schema works. And so for me, the thing that helped me personally worked for me, maybe not for everyone, when I run into a problem instead of being like, all right, got to go talk to the GraphQL team. I'm like, screw it. I'm just going to figure out what the problem is. I'm going to dive eight levels deep into their co-gen guts until I find the problem. And then I'll either fix it myself and now I know GraphQL code gen.

Or I will show up to the GraphQL team and I'll be like, hey, ran into this problem, debug it eight levels deep. Here's the problem. How do I fix it? Which impresses the GraphQL team means that I'm not taking up all their time. And I've learned something new about a new system. And if you keep doing that enough, then you will discover a lot about a lot of different systems. And you'll understand them. And that'll give you so much knowledge and so much, it's like a superpower to be able to dive into all these systems that you now know.

It's also organic. Right. We talked before about code review and how if you just review code that organically gives you actual discussions about how do we want to write our code? Same thing with this, right? Instead of being like, hmm, which systems do I need to go learn for my job? I'm like, they'll come to me.

I'm going to have a problem that I run into. GraphQL is going to block my code from landing. Great. Now I have a reason to go delve into GraphQL Code Gen. I'm not going to study it from first principles and be like, well, I should go learn the GraphQL CoGen systems just because. But when it comes up, sure, I'll do that. A lot of people that get promoted to these really high levels,

one thing I've noticed is the, the expectation, patients become, I guess, scarier and scarier for people or they get there and they kind of get worried that they can meet expectations. You know, for you as an IC9 and you're writing code, how do you make sure that it's, you know, I see nine code? Like there's this, does it, you don't worry about that. I've flipped the switch off. I just don't care.

I used to worry about that too, a lot. And then I was like, you know what? I'm just going to do what I love. And I'm going to check in with my manager often to make sure that I'm solving problems that needs solving, right? I'm not just going to go work on something that doesn't matter. But as long as I'm working on what's important for my org, and I like what I'm doing, I'm just not going to worry about it and I'm going to do it. And that has served me really well, right? Component script being the exception where like eventually it was no longer important for the

company or the org. And that was like someone needed to prod me to realize that. But they prodded me and I realized it and the problem was solved, right? Like in some sense, like getting a meat's most was freeing in the sense of like, well, if that happens again, I'll know that like I went too deep and too hard and didn't listen and now I go listen and fix it. So yeah, my answer is I just flip the switch off and don't worry about it because that's counterproductive. As a senior I see, you are in forums with other senior ICs and also you have a viewpoint that others don't, which you could see what work is technically difficult and exceptional.

What are some other engineers that you think are exceptional and what in your opinion makes their work exceptional? I've got a list, so I'm going to go down the list. Okay. I really admire Justin Chiquitapur, who's an engineer who works very much like me. He writes a lot of code. That's the part of the job he enjoys. He and I have a very similar working style.

So for that reason, I get along with him great. Another engineer that I've worked on for, worked with for a very, very long time is Wei Han, who joined the company on the same day I did in 2012. And our careers often overlapped. We work together on a lot of things, including component script for a while. And she is many different archetypes. She does not fit in one box, but she's more of a fixer. She's very good at like, hey, this metric is not right.

What is the deal? Which is something I can kind of do, but she can really do. And so I love someone that can dive again. It's like diving 10 layers into systems you don't know and figuring out what the hell is going on here. She's great at that. He's no longer with meta, but Michael Bolan was always an engineer I looked up to it because he was a great project starter. He could identify the need.

Hey, we need a fuzzy file searcher that works. on an insanely large repose. What do we do? He kickstarted a project called Miles and just did it, right? Which is like backend, binaries on multiple platforms, deployment, documentation, naming, all this stuff that he could just do. And he did it over and over and over again. That's just one of the many things he started. I think he started Buck, too.

Let's see here. Bob Baldwin is a very senior product engineer. I mean, I think he works on him for now, but for a long time he was on product. And he's an excellent communicator. He can really boil down the message, which is something I think, a lot of engineers very much struggle with. And it's a really important skill is writing and communication. So I really admired his communication and how he could make things clear.

Another engineer that's similar is Oliver Ricard, who is a very, very good writer and a very good communicator and his posts are an absolute masterworks. Whenever someone is like, hey, my engineer needs to work on communication, I'm like, go look at Oliver's posts. That's the bar. That's what you should be aiming for. And finally, I'm aware of what I'm not, the skills that I'm missing. So another senior engineer that I work with almost every day is Nolan O'Brien.

And he is like my polar opposite. He writes code, but not a whole lot. He is extremely good at driving alignment between different teams. And he's extremely good at managing the Apple relationship, which is something I never had patience to do, right? Like meta and Apple, they don't always get along. Nolan finds a way to communicate between these two companies and try to get us on the same page, focus on what we can do together. And I really admire him for that.

So that's my list of other senior engineers I really, really admire. The last thing that I'd like to ask you is you have a lot of, you know, experience at this point. And if you were to go back to yourself right when you had graduated Princeton and give yourself some career advice, what would you say? Nothing. It worked out pretty well for me. I'm not screwed with it, man. The funny thing is when I was graduating Princeton in 2010, I thought about applying. I was like, should I be self-employed and write iPhone apps? Or should I go work for a company? And I actually applied to Facebook.

And I'm pretty sure at the time, what they would do is they would send you this puzzle. They'd send you like a mysterious puzzle that you had to like solve the mystery and then you could apply. And I threw it in the trash. I was like, I don't have time for that. I'm not doing that. And so I'm like, what if I joined Facebook in 2010? What would that have been like? It probably would have been a lot worse because I would have been around for all the HTML5 stuff.

And I would have just been like, oh, no, no, no. But yeah, I don't think I would offer any advice to myself at the time because my personal situation worked out really well. As far as general career advice, I don't know, do what you like, right? Like, I feel like it's really hard to fake enthusiasm or like find enthusiasm for something you really don't enjoy doing. So like find what you love doing and do that. And if that intersects with what the industry needs, you're in a really lucky place. You know, I used to always hear that advice and think that is cliche. It's very cliche.

Yeah. But actually, there's so much stuff downstream of that. Like, your productivity comes from you loving the work. I mean, you have insane output. And your curiosity and the learning, it's got to be order of magnitude more than it would be if you hated it. And you didn't proactively dig, you know, 10 layers deep. So I think it's good if you, if you like solving problems. that's the thing, right? Because it's not like every single moment I'm debugging some really

bad code deep in some awful system. I'm loving what I'm doing. But I like the challenge of solving problems. And so if you like that, you're in good, you're in a good place. Thanks so much for your time, Adam. I really appreciate it. I was really looking forward talking to you. So thanks so much for sharing your career story with the community. Sure thing. Thanks, Ryan. Thank you for listening to the podcast. It's a passion project of mine that I really enjoyed building. Another passion project that I've been working on kind of in secret is building an ergonomic keyboard that I wish existed and I finally have a prototype so I'd love to show you what we've built. It's ultra low profile and ergonomic and I couldn't find anything like it

on the market. So that's why we built it. I'll put a link to the keyboard in the description. You can take a look and learn more about the project there. We could definitely use your support. Also, if you have any feedback for me about the show, I'd love to hear it. Comments on you have led to guests coming on like Ilya Gregoric and David Fowler. I wasn't aware of them until someone dropped a comment. Also, feedback in the comments helped me learn to reduce the number of cliffhangers in the intros. So your comments definitely make a difference. Please keep letting me know what you'd like to see more of in the show, and I'll see you in the next episode.