Meta Distinguished Eng (IC9) On Influencing Engs, Failures, and Learnings

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 - Intro 00:00:47 - His middle school company 00:03:50 - His first project and promo at Meta 00:10:03 - Why code review is undervalued 00:12:42 - Senior Staff (IC7) promo story and project 00:19:26 - His major failed project 00:26:35 - How to handle a failed project 00:29:04 - Thoughts on management 00:31:35 - Technical depth vs breadth 00:33:32 - IC9 expectations 00:34:46 - Senior engineers he admires 00:37:39 - Advice for his younger self 00: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

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  When I run into a problem, instead of being like, "All right, gotta go talk to the GraphQL team." I'm like, "Screw it. I'm just gonna figure out what the problem is."

• 0:07Ryan Peterman?

  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 him how his career grew.

• 0:18Speaker 00

  If you show up and you're like, "Hey, I did the work already for you," much easier conversation.

• 0:22Ryan Peterman?

  1,600 diffs in six months. Why did you spend so much time also reviewing code?

• 0:28Speaker 00

  It's really valuable because you can influence other engineers in an organic way.

• 0:32Ryan Peterman?

  He was unusually honest about a major failed project.

• 0:36Speaker 00

  So component script was interesting because it was a total and complete failure. And I worked on it for like two years.

• 0:41Ryan Peterman?

  With all that pushback, did you ever doubt the direction that you're going in?

• 0:45Speaker 00

  There were some literally sleepless nights.

• 0:47Ryan Peterman?

  Here's the full episode.

• 0:53Ryan Peterman?

  I saw that you have something on your resume that says CosmicSoft, 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 CosmicSoft?

• 1:07Speaker 00

  Yeah, you dug deep, man. I gotta 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.

• 1:51Ryan Peterman?

  I was not a programmer at that time. Can you give some more context? Is that something that's running, I guess, native on like a Windows machine or something? Or what is that?

• 2:02Speaker 00

  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, meaning you could design the software on any platform. I used a Mac. The concept behind Visual Basic, for those who haven't used it, is that you basically have this like blank canvas and you could just drag and drop buttons and text fields and all this stuff on 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 Basic, you're like, well, I want a button, drag, drop. Hmm, when the button is clicked, I want it to close the screen. Okay, double-click on the button and you write some code that's like window dot close. So really easy to get started with, not very scalable.

• 2:46Speaker 00

  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.

• 2:56Ryan Peterman?

  How are you selling that on the internet? Because at the time, they didn't have Stripe or anything like that. Like, how do you even receive money from these people in other countries?

• 3:05Speaker 00

  There was a service called eCellerate, which was like a proto-Stripe. It allowed you to create an online store for your software. It would help you create, you know, like a code that you could enter to unlock the software. And so people would go to this website, they'd 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, I was like an eighth grader. I was getting checks from all over the United States from teachers. They'd mail me a check for $19.95 and I would send them via email, a code to unlock their software. Good times.

• 3:38Ryan Peterman?

  Did your parents know you were selling software to strangers on the internet?

• 3:42Speaker 00

  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.

• 3:50Ryan Peterman?

  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?

• 4:10Speaker 00

  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 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 FaceWeb, this like HTML5 attempt at making a native app and towards the native code. And the native engineers were very much like ascendant, right?

• 4:52Speaker 00

  Like we had, we had won the battle and now we were, we needed to prove ourselves that it was going to work out and it did. And that also meant a lot of big, 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.

• 5:16Ryan Peterman?

  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?

• 5:30Speaker 00

  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, 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 rewrite their stuff in native

• 6:14Speaker 00

  and get all the great wins from native code. Meanwhile, we on, at that time, we mobile was a separate org inside of Facebook. We and the mobile team were like, uh, this is not going so well. Like Core Data 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, et cetera.

• 6:46Ryan Peterman?

  You had this new offering that had a lot of benefits to it, but still I imagine you had to convince other teams to adopt it.

• 6:55Speaker 00

  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, getting the last rag or products to onboard that was harder, right? Because for them, they were like, yes, 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 there, we did get a lot of pushback from Apple-y 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 somewhat over the years, just because Meta and Facebook and Instagram and all of our other properties have gotten so large.

• 7:39Speaker 00

  It's clear that Apple's solutions don't scale to that size. But at least in 2012 and 2013, there were, there were a lot of people still clinging to this idea that, hey, we should just use the vanilla 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.

• 7:57Ryan Peterman?

  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?

• 8:06Speaker 00

  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?

• 8:51Speaker 00

  Like, hey, you don't know how core data 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 this scaffolding. Now my job is to convince other people to do the work of migration. We call this code the archetype coding machine. I have mixed feelings about archetypes in general, but like 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.

• 9:35Speaker 00

  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 code base 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, well, you solved the problem and I have to do nothing. I just say yes. Worked really well.

• 10:03Ryan Peterman?

  I saw like in the career note that you wrote about this promotion, that you'd also reviewed over 1,600 diffs in a half. And that comes out to around like 14 diffs per workday. Why did you spend so much time also reviewing code?

• 10:22Speaker 00

  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 diff reviewers 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.

• 11:07Speaker 00

  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 gonna, 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.

• 11:43Ryan Peterman?

  Given that you've done such an absurd volume of diff reviews, what makes a good diff comment versus a bad one, in your opinion?

• 11:51Speaker 00

  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 I might be missing context. And that's still the diff author's fault, maybe. Because like, 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.

• 12:36Speaker 00

  I don't look like a total idiot who's just like getting it wrong. It really helps.

• 12:42Ryan Peterman?

  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?

• 12:54Speaker 00

  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.

• 13:35Speaker 00

  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, immutability, re-render everything, conceptually at least, when anything changes. View reconciliation, right? So you're not directly managing UI views.

• 14:17Speaker 00

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

• 15:02Speaker 00

  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, lots of work to do.

• 15:11Ryan Peterman?

  How did you convince people? Because, you know, this declarative framework was such a different way of doing things. I imagine there was a lot of pushback. How did you, you drive those difficult conversations?

• 15:23Speaker 00

  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 could 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. And 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 Kit, I was on IC6. There were other more senior engineers who would, you know, get us to huddle up and try to just talk through, how do we find a path forward that we can all agree on?

• 16:07Speaker 00

  And I think Lee Byron was very involved in these conversations. I know Alan Canastral 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 want 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? It's, 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.

• 16:52Speaker 00

  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.

• 17:06Ryan Peterman?

  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?

• 17:20Speaker 00

  Allies are super useful, right? I still remember there were some engineers like Clement Genzmer and Greg Mek, who carried a lot of weight in the company and they saw it and liked it. So 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.

• 18:04Speaker 00

  And boy, they had a really hard time because they felt like they were developing the next thing and then I came along and was 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 a 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.

• 18:26Ryan Peterman?

  With all that pushback, did you ever doubt the direction that you're going in?

• 18:31Speaker 00

  No, I was very convinced that this was the right call for Facebook News Feed. I will say, and this goes for all declarative UI frameworks, React, Swift UI, Component Kit. They're really good at some things like a Facebook newsfeed 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 trade-offs 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 UIs

• 19:16Speaker 00

  on Facebook. Like that should be the, you know, our only option is component kit. Uh, no. But in general, for what we wanted to use it for, yes, I was very convinced that it was the right path forward.

• 19:26Ryan Peterman?

  You know, the next project you worked on was ComponentScript. What was the motivation behind that project? And, you know, what's the story behind it?

• 19:36Speaker 00

  So ComponentScript 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 silo, right? So like iOS had ComponentKit, Android had a React and ComponentKit inspired by then called Litho. But this meant we were writing everything multiple times, right? We had to write it in ComponentKit for iOS. We had to write it in Android. He wanted to have a cross-platform solution. React Native was not that solution, and we knew that. At this time, we'd 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

• 20:20Speaker 00

  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 the 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, didn't really work.

• 21:02Speaker 00

  So we want to cross-platform. We knew React Native was not it. What could we do? And so Ari asked me to go and work on this. And I, at the time, it was like, okay, this is the next nudge, right? Like, Lee 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 Component Script. 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 Witho was too challenging.

• 21:47Speaker 00

  So I was like, all right, I'll do a smaller pared-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, bidirectional 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

• 22:32Speaker 00

  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.

• 22:43Ryan Peterman?

  I mean, if we were to kind of post-mortem why it didn't win, what are the things that you did well? And what are the things that maybe could have gone better?

• 22:52Speaker 00

  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 infrastructure 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.

• 23:33Speaker 00

  Let's let them write iOS code but have excellent performance. Component Script was like, hey, you can write JavaScript, but it's not React. So like iOS engineers were 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've fixed it a lot since then, but at the time it was bad.

• 24:17Speaker 00

  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.

• 25:01Speaker 00

  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 Component Script. 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 on 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.

• 25:45Ryan Peterman?

  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?

• 25:59Speaker 00

  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 Band-Aid 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.

• 26:35Ryan Peterman?

  And 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 their projects getting canceled or things like that?

• 26:54Speaker 00

  The thing that made me realize it needed to be canceled is that I got a meet's 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 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 written in component script and I helped 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. We have to leave 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 is going to be gone from the repo,

• 27:38Speaker 00

  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, 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.

• 28:17Ryan Peterman?

  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?

• 28:28Speaker 00

  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 just, it 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.

• 29:04Ryan Peterman?

  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?

• 29:17Speaker 00

  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

• 29:26Speaker 00

  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. Like, 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.

• 30:08Ryan Peterman?

  What about picking the 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. Well, 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?

• 30:26Speaker 00

  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 like been shifted on to 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 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 work on AR VR. 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.

• 31:07Speaker 00

  Right? If you want to know the guts of the graphical Cogen or value object generation or Buck 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.

• 31:35Ryan Peterman?

  You talked about the technical depth. Let's say someone's goal was to be like you. They, they really wanted to, you know, super aggressively pursue the high IC career path. They want to go IC nine or bust. Do you think that technical depth is better than breadth for becoming the highest levels of senior IC?

• 31:56Speaker 00

  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, it 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 code 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?

• 32:40Speaker 00

  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 like 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.

• 33:24Speaker 00

  I'm not going to study it from first principles and be like, well, I should go learn the GraphQL code and systems just because, but when it comes up, sure, I'll do that.

• 33:32Ryan Peterman?

  A lot of people that get promoted to these really high levels. One thing I've noticed is the the expectations become, I guess, scarier and scarier for people. Or they they they get there and they kind of get worried that they can meet expectations. You know, for you as an IC9 and you're you're writing code. How do you make sure that it's, you know, IC9 code? Like, there's this, there's a, you don't worry about that.

• 33:56Speaker 00

  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 gonna do what I love and I'm going to check in with my manager often to make sure that I'm solving problems that need solving. Right? I'm not just gonna 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 gonna worry about it and I'm gonna 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.

• 34:40Speaker 00

  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 kind of productive.

• 34:46Ryan Peterman?

  As a senior IC, 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. You know, what are some other engineers that you think are exceptional? And what, in your opinion, makes their work exceptional?

• 35:07Speaker 00

  I've got a list, so I'm gonna go down the list.

• 35:10Ryan Peterman?

  Okay.

• 35:11Speaker 00

  I really admire Dustin Shahidapur, 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 worked 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, 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.

• 35:56Speaker 00

  He's no longer with our company, with Meta, but Michael Boland was always an engineer I looked up to because he was a great project starter. He could identify the need. Hey, we need a fuzzy file searcher that works on insanely large repos. What do we do? He kickstarted a project called Miles and just did it, right? Which is like backend, binaries on a 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 Bock too. Let's see here. Bob Baldwin is a very senior product engineer. I mean, I think he works on it 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.

• 36:41Speaker 00

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

• 37:02Speaker 00

  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, 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, 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.

• 37:40Ryan Peterman?

  The last thing that I'd like to ask you is you have a lot of 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?

• 37:54Speaker 00

  Nothing. It worked out pretty well for me. I'm not screwed with it, man.

• 37:58Speaker 00

  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.

• 38:33Speaker 00

  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.

• 38:59Ryan Peterman?

  You know, I used to always hear that advice and think that is a cliche.

• 39:04Speaker 00

  It's very cliche.

• 39:05Ryan Peterman?

  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 gotta 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.

• 39:27Speaker 00

  I think it's good 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 a good place.

• 39:42Ryan Peterman?

  Thanks so much for your time, Adam. I really appreciate it. I was really looking forward to 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.

• 40:25Ryan Peterman?

  Comments on YouTube have led to guests coming on like Ilya Grigorik 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.