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.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
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:34:46 - Senior engineers he admires
00:37:39 - Advice for his younger self
Transcript
00:00:47 — His middle school company
Ryan:
[00:00:47] I saw that you have something on your resume that 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?
Adam:
[00:01:07] 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.
[00:01:41] 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.
Ryan:
[00:01:51] 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? What is that?
Adam:
[00:02:02] Well, Real Basic was this. 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 can just drag and drop buttons and text fields and all this stuff on it.
[00:02:23] Very easy to get into. Right? Because even nowadays with something like SwiftUI 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. 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 close. So really easy to get started with.
[00:02:44] 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.
Ryan:
[00:02:56] 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 there was a service.
Adam:
[00:03:06] Called Ecelerate, 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 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.
[00:03:32] They’d mail me a check for 1995 and I would send them via email a code to unlock their software. Good times.
Ryan:
[00:03:38] Did your parents know you were selling software to strangers on the Internet?
Adam:
[00:03:42] They did. I don’t know what, I don’t know what they thought of it or what they could make of it, but they did know I was doing it.
00:03:50 — His first project and promo at Meta
Ryan:
[00:03:50] 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?
Adam:
[00:04:09] 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.
[00:04:32] 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 native Engineers were very much like ascendant, right? Like, we had won the battle and now we were.
[00:04:54] We needed to prove ourselves that it was going to work out, and it did. And that also meant a lot of big prop, 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.
Ryan:
[00:05:16] 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.
Adam:
[00:05:31] 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.
[00:05:55] 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, like, rewrite their stuff in native and get all the great wins from native code. Meanwhile, we on, at that time, mobile was a separate org inside of Facebook.
[00:06:20] We on the mobile team were like, 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 in 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.
Ryan:
[00:06:46] 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.
Adam:
[00:06:55] 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 regular products to onboard that was harder, right? Because for them they were like, yes, our sort of performance is a little bit better. Who cares? We don’t care. We were more interested in other things.
[00:07:14] Also, it wasn’t necessarily individual teams that were skeptical of the entire project, but 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 lesson to someone over the years.
[00:07:34] Just because Meta and Facebook and Instagram and all of our other properties have gotten so large, it’s clear that Apple solutions don’t scale to that size. But at least in 2012 and 2013 there was, 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.
[00:07:54] So that was a big challenge for us at the time.
Ryan:
[00:07:57] 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?
Adam:
[00:08:06] 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.
[00:08:24] 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.
[00:08:48] Having that data to give to other engineers is really useful, right? 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 the scaffolding.
[00:09:12] 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, 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 and you’re like, hey, I did the work already for you.
[00:09:33] 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. Dart 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.
[00:09:57] And people would be like, great, love that you solved the problem, and I have to do nothing. I just say, yes. Worked really well.
00:10:03 — Why code review is undervalued
Ryan:
[00:10:03] 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?
Adam:
[00:10:22] 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. What’s your message to other engineers at the company? What do you want to change? I’m like, I. 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.
[00:10:43] 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.
[00:11:16] 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. Would spread through the code reviews that they did.
[00:11:37] 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.
Ryan:
[00:11:43] 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?
Adam:
[00:11:51] 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 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.
[00:12:15] 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, makes 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.
[00:12:40] It really helps.
00:12:42 — Senior Staff (IC7) promo story and project
Ryan:
[00:12:42] 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?
Adam:
[00:12:54] The years all blur together at this point, but this was like 2014, maybe. We had a very large and complex product, Facebook Newsfeed, which was growing and growing and growing so fast because the company hired lots of new engineers and they stuffed everyone on Newsfeed 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.
[00:13:23] 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.
[00:13:52] 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 like components, immutability, rerender, 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.
[00:14:21] 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 SwiftUI. Swift didn’t exist yet. SwiftUI 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.
[00:14:54] 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 Feedback. So the big challenge there was inventing the framework, getting it adopted in newsfeed and then getting it adopted everywhere else. So I had lots of, lots of work to do.
Ryan:
[00:15:11] 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.
Adam:
[00:15:23] 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.
[00:15:46] 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 an 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. And I think Lee Byron was very involved in these conversations.
[00:16:09] I know Alan Canestraro 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 credit 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.
[00:16:30] 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.
[00:16:55] 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.
Ryan:
[00:17:05] 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.
Adam:
[00:17:20] Allies are super useful, right? I still remember there were some engineers like Clement Gensmer and Greg Mech, 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 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.
[00:17:40] 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.
[00:17:59] 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 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.
[00:18:20] 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.
Ryan:
[00:18:26] With all that pushback, did you ever doubt the direction that you’re going in?
Adam:
[00:18:31] No. I was very convinced that this was the right call for Facebook Newsfeed. I will say. And this goes for all declarative UI frameworks. React, SwiftUI 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.
[00:18:56] 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 on Facebook.
[00:19:17] 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.
00:19:26 — His major failed project
Ryan:
[00:19:26] 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?
Adam:
[00:19:36] 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 component kit, Android had a react and component kit inspired by then called Litho.
[00:20:03] But this meant we were writing everything multiple times, right? We had to write it in component kit for iOS, we needed 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 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.
[00:20:20] It works really well if your entire app is React Native or if you have entire app 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.
[00:20:51] 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. So we wanted 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 at the time it was like, okay, this is the next nudge, right?
[00:21:11] 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 in 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, and said, what if we just made a different React native, right?
[00:21:32] 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 Litho was too challenging. 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.
[00:21:56] And Litho 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.
[00:22:16] 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.
Ryan:
[00:22:43] 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?
Adam:
[00:22:52] I mean, doing well. I just mentioned it did check. It checked all the technical boxes that we, as in like the core product inference group, cared about, right? Like it was type safe. IT integrated with GraphQL and component kit and litho our existing native frameworks. It was bidirectional. So you would never be suddenly cut off. There’d never be a point where you’re like, oh, I just need to embed this native component and I can’t do it.
[00:23:15] 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. Component Script was like, hey, you can write JavaScript, but it’s not React.
[00:23:41] 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.
[00:24:01] 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 hassle. We’ve 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 coming in with a server driven sort of UI approach and their solution was like, don’t worry about data consistency.
[00:24:34] What if we just didn’t do it? And we were all horrified. We were 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.
[00:24:56] 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 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.
[00:25:20] 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 componentscript.
[00:25:40] And I was like, oh, man, no. But even that would not have been enough momentum, right? It was too little, too late.
Ryan:
[00:25:46] 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?
Adam:
[00:25:59] 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.
[00:26:24] 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.
00:26:35 — How to handle a failed project
Ryan:
[00:26:35] 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?
Adam:
[00:26:54] The thing that made me realize it needed to be canceled is that I got a means 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 likes 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 componentscript and I helped those teams migrate back to native code or to react native or whatever they wanted.
[00:27:24] And I completely deleted the framework. I didn’t leave it as like, you know, oh, this one product is still on component script, so 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. Which I think garnered some goodwill because it showed others this is the right way to clean up after your mess.
[00:27:44] 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.
[00:28:09] You might get more goodwill from killing it responsibly than just like dragging it out and constantly waiting until it’s too late.
Ryan:
[00:28:17] 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?
Adam:
[00:28:28] 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? I. 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.
[00:28:47] 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 and find a different way to have impact. And that would have been much better for me in the short and long run.
00:29:04 — Thoughts on management
Ryan:
[00:29:04] You said before that you know for sure you, 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?
Adam:
[00:29:17] I like writing code. I really like writing code a lot and as a manager you can’t write code so 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.
[00:29:38] 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.
[00:30:01] So for me, I always knew management is not for me, but it depends on the person. Obviously I’m a pretty extreme case.
Ryan:
[00:30:08] 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?
Adam:
[00:30:26] 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 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.
[00:30:46] I’m going to go check it out. Or like, oh man, I really want to go Aron 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, right? If you want to know the guts of the GraphQL code gen or value object generation or buck or all these things, I know what’s up.
[00:31:15] 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.
00:31:35 — Technical depth vs breadth
Ryan:
[00:31:35] 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 IC nine or bust. Do you think that technical depth is better than breadth for becoming the highest levels of senior ic?
Adam:
[00:31:56] 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.
[00:32:18] 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. I’m gonna dive eight levels deep into their cogen 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 8 levels deep, here’s the problem.
[00:32:39] 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?
[00:33:02] 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, 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 Cogen.
[00:33:24] I’m not going to study it from first principles and be like, well, I should Go learn the GraphQL code Gen systems just because when it comes up, sure, I’ll do that.
00:33:32 — IC9 expectations
Ryan:
[00:33:32] 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 does it. You don’t worry about that.
Adam:
[00:33:56] 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 my, check in with my manager often to make sure that I’m solving problems that need 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.
[00:34:19] 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 them meets 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.
[00:34:42] So yeah, my answer is I just flip the switch off and don’t worry about it because that’s counterproductive.
00:34:46 — Senior engineers he admires
Ryan:
[00:34:46] 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? What are some other engineers that you think are exceptional and what, in your opinion, makes their work exceptional?
Adam:
[00:35:07] I’ve got a list, so I’m going to go down the list.
Ryan:
[00:35:10] Okay.
Adam:
[00:35:10] I really admire Dustin Shahidipur, 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.
[00:35:33] 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 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 hell is going on here.
[00:35:55] She’s great at that. He’s no longer with our with Meta, but Michael Bolan 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 multiple platforms, deployment documentation, naming, all this stuff that he could just do.
[00:36:19] 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 infra 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.
[00:36:38] 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. He’s 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.
[00:36:59] 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, 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.
[00:37:23] Right. Like Meta and Apple, they don’t always get along. No one finds a way to communicate between these two companies and try to get us on the same page, focused 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.
00:37:39 — Advice for his younger self
Ryan:
[00:37:39] 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?
Adam:
[00:37:54] Nothing. It worked out pretty well for me. I’m not screwing 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.
[00:38:18] And I threw it in the trash and 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.
[00:38:42] 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.
Ryan:
[00:38:59] You know, I used to always hear that advice and think that is cliche. And 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 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.
Adam:
[00:39:26] So I think it’s good if you, if you like solving problems. That’s the thing, right? Cause 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.
Ryan:
[00:39:42] 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.
Adam:
[00:39:50] Sure thing. Thanks Ryan.
