Tech Lead for Meta's Most-Used Programming Language (Promotion Story)

0:00Writing code is not what my job as a software engineer is. My job is to... This is Dwayne Reeves. He's a senior staff engineer or IC7 at Meta who joined the company as a new grad from MIT. Those promotions were kind of a surprise for me because... He shared a bunch of lessons he learned the hard way getting to that level. I was having the worst half I ever had at the company and I was really upset. What's the story behind you becoming a manager? You know, one of the things I had to get used to as a manager is... If you could go back to yourself and give yourself some advice, what would you say?

0:34Here's the full episode.

0:38Thank you, Duane, for coming on. I really appreciate your time. Today, I kind of wanted to go over your career story. I feel like there's a lot of interesting stuff because you started at Facebook when it was Facebook and pre-IPO and all of that. All right, well, let's start at the beginning of your story. I see that you started at Facebook right out of college and you went to MIT. I'm kind of curious, were there other offers that you're considering and what was the story behind you joining Facebook? It's actually an interesting story because I really wasn't interested in Facebook, to be honest.

1:12I was like really interested in Google and Twitter. Twitter because I was a big fan of Scala as a programming language. I know they use that at Twitter. and Google because I grew up on the East Coast and they had offices in Boston and New York and Facebook didn't at the time. Why I ended up interviewing for Facebook was actually as interview practice. I had a friend who was working at Facebook and he was trying to, he joined, I think back in 2007, actually. And he was trying to convince me throughout my time to come for internships or other things. I was like, I don't really know. I don't see myself going to California.

1:52And he was like, finally, hey, this will at least be good practice for your Google interviews. So I was like, sure, let me do it. So I did end up interviewing and ended up making to the final rounds. And when I actually got on campus, my whole viewpoint kind of started to change and open up. Just being able to talk to actual engineers and the kinds of problems they working on. I was, you know, obviously a user of Facebook being a college student at the time. And it was hard for me as someone who is kind of interested in more core CS problems of like, oh, Facebook's just a website. What is it really for me to do?

2:26And when I actually got on campus hearing like some of the problems they had to solve with Memcash and just how to scale up a system like this, hearing things around how they optimize PHP by having their own custom runtime time for it. All these things made me realize like, oh, they're actually doing some real engineering work here that got me pretty interested. And I mean, I imagine at Google, they're also, you know, they were obviously doing real engineering too. So what was the thing that made Facebook really stand out? Yeah. Uh, well, when is they actually gave me an offer, but I think, I think overall, the other thing is like, it's just a level of care I felt from Like they, they really wanted me and they showed it in, uh, sometimes not so sudden ways.

3:14Two things that come to mind. One was when I got my offer, it was the best offer I had. I think I didn't, I didn't end up getting an offer from Google. I did have an offer from Amazon. You know, I didn't accept right off the bat because I needed some time. I said, Hey, I need some time to mull over my offer. And a week later, I got a email out of the blue from my recruiter saying, Hey, we just increase your offer. I was like, oh, yeah. I was like, wow, I didn't need to ask for this versus like Amazon. I like talked to the recruiter and they're like, yeah, we don't negotiate with new grads. You just take what you give you.

3:49The second thing is at the time I remember, I think I had already decided to join Facebook at that time, but there was something where the CTO at the time, I think Brett Taylor, he actually came to MIT's campus and took all the new grads that were accepted and took us out for lunch at a local cafe to talk with us. So all these interactions, I was like, wow, I couldn't imagine any C-suite level person at Google or any of the other companies I was working at actually taking the time to talk with us personally. So that really felt special. Because they were smaller, they're able to do that more tailored recruiting.

4:28What was the rough size of them? Just to give people a sense of like, is this startup or is it kind of like growth stage Yeah, I think at the time it was probably between 1 ,000 to 1 ,500 employees. So not small, but also, well, given we're like, I think, 100 times bigger now, it is small. It's all relative, right? Yeah, hearing that you went to MIT, it's not controversial to say that obviously is a big leg up when getting interviews and kind of, You mentioned one of your peers had already been working at Facebook. But one thing I'm curious, now that you have all this experience in the industry, how much of a correlation is there between maybe the prestige of the college you went to and a career success?

5:19I think very little of it has to do with the actual education piece you get at different universities. My education at MIT was fantastic. There's a lot it taught me. I do think that's valuable. immensely valuable. But I've also met lots of engineers who I work with who some of them didn't even go to school. And so the thing I really know for sure was a big differentiator between me and them was I just had more opportunities because MIT had this name recognition that for my freshman year, I was talking to recruiters from any tech company. They would always come to a career fair and be willing to talk to me just because of the school I went to versus others, uh, engineers I work with is it was almost just by chance that even got on Facebook's radar and they were just as capable of engineers as me.

6:12But just because of, I guess, a different path they took in their career, they very easily could have not ended up at Facebook, which would have been a huge loss for the company. It definitely increases the opportunity and chance, like those kinds of elements of it. Yeah, I mean, I remember my freshman year, I had an internship from Microsoft. And almost that alone was enough for me to get an internship offer from Apple as well. It was just kind of crazy because I remember, you know, I grew up in Bridgeport, Connecticut, growing up in the inner city, going to public school, you know, child of immigrants, like working at companies like Apple or Microsoft was like the dream.

6:55I never thought real people actually worked there. Immediately going from that to, oh yeah, there's recruiters here and they actively want me to work with them was not anything in my head I would have even imagined being the case. But MIT was just normal for the students there. You joined Facebook. You got the offer. They kind of sold you in. What was the thinking behind joining a team like that when you entered Facebook? We were looking at developing kind of like a service that was meant to evaluate some pieces of code and move it outside of the main PHP code base because PHP was seen as like not a great language to develop in.

7:36So we were like, yeah, we can, if we use this new language we develop, we can do some computation closer to the data stores and all these ideas, you know, this will help efficiency and all these big dreams. Honestly, this was something like, it was not a team on my radar at all. But they reached out to me because, well, maybe my resume, they thought it would be interesting. And that was like, I think one of the great, like first times of actually trying to do something language related, where for the most part, all I was doing was trying to translate PHP code into their own custom DSL that they were developing.

8:13But I was on that team for maybe two years, and by the end of it, I was actually trying to develop new features for this language. Ultimately, that project ended up getting canceled. Then I started working on more things related to privacy infrastructure and how do we find ways of representing privacy policies and rules in an easier-to-manage way than just simple if-or-else statements. and I did that for a couple years. At that time, Hack was introduced to the code base and we were kind of the newest framework that like decided, hey, we're going to go all in on using Hack and types, which is what I love because I grew up working in statically typed languages.

9:01I just thought they were superior. So PHP was always weird. And after that project, I was trying to figure out what I wanted to do next and there was this opportunity of kind of different parts of the code base and all that was written with PHP was not typed in hack and I was like I could make an attempt of trying to type this using hack so it was meant to be like I think a week or two project it ended up taking a whole quarter but it was very rewarding because it allowed me to interact with the hack team a lot because they're anxious of like interested in having more people use hack in code base.

9:42And I was trying to do something which honestly no one else had attempted at the time of how do we take a very core piece of API that was not designed to be typed and how do we actually go about doing that? And there's a lot of hacks, a lot of bash scripts, a lot of ingenuity, I guess I would say. So the end result was after I completed this migration, about 20 % of the call sites, they're moving it to the Hack API, discovered that there was some kind of error in the code, usually around how it handled null types. This was kind of like, I view it as one of the big results of like, hey, Hack is not just this cool tool.

10:23It's actually finding mistakes in the code base at scale. And I feel that is really what started to have hack be taken a bit more seriously. It's like, hey, should we be more aggressive in terms of replacing PHP with hack? You mentioned dynamically typed, statically typed. Are statically typed languages objectively better than dynamically typed ones in industry code? It's subjective, but I think a lot of evidence points to, yes, they are superior. particularly in in the ways to think about is particularly if you think about the problems we face at a company or code base at the scale of we develop here at meta or any large industry it's like it's more of like a information communication problem where as the size of a code base grows the more you have to keep your mind of the context of like well this code is meant to do this and this code is meant to do that so if i change it this is how it needs to work it starts to break down as you have more people who are working in the code base and the size of the code base grows that you just naturally need tools to help you manage that.

11:31And type systems just happen to be a effective tool for communicating intent. Maybe there's cases if you're just you're hobbyists and you're working on your own and you could just keep everything in your own head. Yeah, you could probably move faster with a dynamic language at the scale we operate with where you even if you get like a hundred engineers, like you need something that helps you communicate ideas and keeps track of that. And that's where I feel types really help. Types also help with tooling, right? So you have all the complete, it helps you search the code base and all these other things beyond just like given errors that it provides value in.

12:09It's not surprising. You see, even for dynamic languages, most of them have some form of optional types, at least for that reason alone. I guess some of the obvious advantages are it brings more of the state or what we're trying to communicate explicitly written into the code via the types. And then also because of that, tooling and various static tools can traverse that and provide value to us. So that's a big value add for industry code. Is that right? Yeah. And it's actually kind of incredible to think about that you write some text in a file, and because you write it in this way, that we have developed ways of proving that, hey, this text you've written does not exhibit these classes of errors at all.

12:59And you could just rely on it. And that's really powerful. Right. And it's, you know, one of the, I think, main achievements we've had in the space of computer science. Definitely. Like formally verifying that this bug cannot happen because of those types. Exactly. In my research and kind of studying some of the type migrations, I think you mentioned before this uncanny valley of type systems. I'm curious, can you explain what that phenomenon is and what you mean by uncanny valley? I grew up playing video games. So this is a term I learned in that space where from there, it's from more like if you have computer graphics, as you try to make something look more human-like, in general, you feel better about it.

13:45Like you feel more connected to it as it starts to look more human. But then it gets to a certain point where it's almost human-like, but it's off in subtle ways. And all of a sudden you get kind of put off from it. And me being familiar with this term, I feel the same thing will happen in terms of as you move from dynamic languages to static languages. And the reason I felt this way is at the time, people only worked with dynamic languages that are only fully statically typed languages. And they didn't necessarily have the muscle memory or weight trained in their brain. What does it mean if I have a type?

14:23It actually is not correct. And as you add more and more of these, the places where the types actually aren't doing what you would expect in a static language that exists, the more off-putting it will fail. And so that's how I came up with that concept, right? Was comparing this to how it applies to the space of graphics, human graphics, and trying to make a similar analogy to communicate this point. And it proved to be a really effective way of contextualizing the problem we were trying to solve on the hack team at the time. In the process of migrating to a fully statically typed code base, that last bit, actually things start to get worse because you're almost there.

15:07And so the bugs that come are much more subtle and the behaviors are much more subtle and it's actually worse for a bit, till 100%. Yeah. And I think there's even something particular because we were, you know, the foundation of the language was PHP, was that at the time there were certain behaviors PHP had, which were incompatible with trying to make a sound type checker for. And there were some questions at the time of like, well, should we keep those behaviors or should we get rid of them? And I think my post was more making the statement, we should get rid of those behaviors. Because if you have a language, even if you had everything typed, the fact that the types can't be relied upon because of these subtle behavior differences, then that will be a problem or will create a less than ideal state for development.

15:59So I think that it's also some of it is, you know, because of PHP and some of the peculiar decisions they made of how their runtime would operate. I see. I see. That makes sense. And so in your time as an IC, I know eventually you transitioned to management. So you must have had some promotions and things that helped your career grow. Are there any stories, like particular times where you felt like, okay, that was a really good learning experience and helped you grow as an IC? Yes. Two of them come to mind. So one was when I got promoted as a senior engineer. I kind of mentioned earlier about this project I worked on of trying to create a hack API for the ENTS framework.

16:44So since that went well, I was asked to, hey, can we do this at a larger scale? Like, can we move more code from PHP to hack? And so I ended up spending a half doing that. And at that time, up to that point, my idea of what value I gave to the company was 100 % based off of what code I was able to output. And so when I started this, I was talking to so many people. I was like giving ideas to the hack team, giving ideas to other engineers who were to work on that had almost no time to actually write code myself. And because of this, I felt I was having the worst half I ever had at the company. And I remember like having a conversation with my manager about this.

17:30And she was like, you know, it's important that, you know, you're doing the right thing in terms of talking to other people and getting them involved. But you should find some time to write some code on yourself. And I don't know if she talked to her manager afterwards, but I think the next one or one, she was like, yeah, that thing I told you, that's actually wrong. Keep on focusing on just what the end results were. And for me, the thing that really connected is still at the end of the half, I thought that I was like, yeah, we had some results. Yes, we increased the amount of hack adoption or coverage from like, I think, 20 or 30 % of the code base to like 60 or 70%.

18:12Now, like hack felt like it was a fixture in the company. Like people weren't really looking to write PHP first. Everyone was starting to write hack first. So I felt like I had good results. But again, I wrote the least amount of code in my career so far. So I wasn't sure how it was going to play out in terms of my performance review. and the thing that really connected was like oh actually that was the highest review I ever got I ended up getting redefined set half um wow and I got promoted to IC5 which I wasn't even in the conversation because I thought oh I'm not writing enough code to even justify that and it really solidified to me that writing code is just is not what my job as a software engineer is my job is to identify and solve problems sometimes that's the best way of doing that is writing code sometimes it's me bringing clarity to a problem in the path forward for how to solve it and if others end up writing the code then that's fine um so that's something i think was a pretty big mind shift there of experiencing of like okay i don't have to be the most uh efficient you know coding machine out there right there's other ways i could add value so that was definitely one of the one of the pieces and the second one was also I guess what led to my promotion to IC6 so after that half right I just explained I was asked to join the hack team so I wasn't even on the hack team at the time so this was started in I think 2015 I joined the team they said like hey you would be the tech lead I have no idea what that was and most of the engineers who were on the team before, they ended up leaving.

19:53So it was like me, another engineer I brought on the team who I worked with before, and like a new grad hire. And we were like, this whole system we were now responsible for. I quickly struggled for a few years trying to understand what was my role as a tech lead. You know, I was comfortable that my output didn't necessarily need to be related to the code I wrote, but I still felt like I was responsible for seeing the outcomes end to end. so one of the things I worked on was trying to redesign how our collection system work arrays and stuff within hack and I spent all this work on the design spent a whole year on it convinced our runtime team to implement it started with the implementation and started to roll in we had some people join the team and I was like all right here's my you know project to get me to IC6 is trying to complete this.

20:44And I remember my manager telling me, okay, Duane, I actually want you to work on something else. And I was really upset because I was like, why are you telling me to work on something else? This is my project. It's up to speed. Why do you want me to do something else? And this is my path. And he was saying like, and he gave this analogy, which is really interesting. It's like, think of what you're doing. It's like, you're like a rocket ship and like there's different stages as you are firing. And like, you know, you have the initial set of like engines that are meant to like leave the orbit. Right.

21:14But once you escape the orbit, there's like other jets that can fire. And he was like, I only cared about you getting us out of orbit. Now that we've done that, you should pass this off to someone else. And now you can find something else to do instead. And he wouldn't let me leave the 101 until I agreed to do it. And, you know, I passed this on to another engineer and I was I don't even remember what I was focusing on. But I remember, you know, the half ended. And again, I was like, okay, well, I did that. So let's talk about, you know, what my path for six to be. It's like, oh, actually, I just got you promoted.

21:48So congratulations, you're now six. So in both cases, like those promotions were kind of a surprise for me because I had a mismatch between what my expectations in my head of what I needed to do to perform at the next level versus what in reality was important. And each time it felt like being okay with having less direct control on the outcome. And the real important thing I did was just align in what the right strategy and what the right problems were in the first place. a lot of more senior ICs, the value is they come in, they figure out what's important to solve, why, you know, get all the alignment.

22:28And now there's this, it kind of like the, you've left orbit at that point. This is something everyone's interested in. Then you hand it to someone who's great at, you know, getting it done. And so, and it's cool that your managers were proactive and driving your growth because it sounds like you weren't really eagerly involved and figuring out hey what do i do to six and you know scale myself okay i'm gonna go scale myself it's almost like you begrudgingly did the things and they were coaching you and you just got promoted as a byproduct yeah uh you know it was also a bit earlier at the company so some of it was like probably they were willing to move faster like hey duane we we see the potential in him why like hold the promotion for another half.

23:13Having a strong relationship with your manager is the thing I see most consistent in like my career. Whenever I felt disconnect with my manager is when I felt most frustrated. The times when I felt most connected is when I felt I was doing my best work. And I think I see that through line in a lot of people's careers. Like almost everyone who has had success, they had a good relationship with their manager. And so speaking of management, I know you eventually transitioned to being a manager. Curious what made you want to try management? What's the story behind you becoming a manager? It's interesting because it's kind of similar to how I ended up at Facebook.

23:52It's like I didn't want to be a manager. It was not a part of my career plans. The team was at this point growing rapidly. And my manager at the time, he was like, hey, we need more managers on the team just because of the growth rate. Here's an opportunity for you. And we could either try and find another manager externally, or you can give this a shot. And I said, no. And the next time I met him, I heard about the TLM role, like tech lead manager. And I was like, oh yeah, I could do some coding and maybe a little management. This might be a nice transition. And I mentioned it to my manager. And he was like, oh, you don't want to do this.

24:28I was a TLM at another company. It's like you're doing two jobs. I wouldn't recommend this as a manager. So I was like, oh, okay, that's fine. I won't be a manager. and I think he probably talked to my director because he came back the next 101 he was like actually yeah we should we should try this you could you know be a TLM or whatever you want you know just try this management thing and since I you know was starting to get more comfortable with like delegating I was like okay if I'm still technically evolved so I could try being a manager and still have some technical influence on the team and for me the main decision around like And that point in my career was there's so many times that I've discovered if I was set in my way of just trying what I felt comfortable with, that anytime I did the opposite and did something I felt was like I would be uncomfortable with led to better results.

25:20So I was like, OK, I don't really want to be a manager, but it will force me to learn a lot and it will force me to be uncomfortable. So I was like, OK, I'll give it a shot. I hear that advice often on that TLM is, you know, two jobs and it's not super sustainable. After you tried it, what was your experience with being a TLM and would you recommend it to others? The first couple of years, it was actually pretty, it went pretty well. As a new manager, I was quickly, you know, I started off with like three reports, I then went to four and five. Then like there's this big shift where essentially I had the whole team under me.

26:01they were supposed to be a manager in seattle for part of her team that had left so i had maybe like 12 or 13 reports and i started you know saying like all right can i convert this person to be a manager as well and i started having managers report to me and i was still given technical direction but i think the thing that became tough was as the org started we we were successful so continued to grow and it came harder and harder to think about all right how can i continue to contribute as a tech lead while also figuring out how to scale out this org and there was you know some ideas i had around how to do it which was basically i need fewer reports that we get like three managers to do all the management and i'll just manage them then i have time to think as a tech lead.

26:52You know, my own manager at the time, he didn't think that was the best outcome as for building a healthy org, which I think makes sense because he has a lot more experience being an org leader. Ultimately, I got scaled down to here's a fewer direct ICs I worked with, and I continued being a tech lead overall. So it wasn't necessarily the workload that was the issue, but it became something where does the thing that helps the team the most align with the base responsibilities I need to do as a manager? So here's a way to kind of demonstrate this, right? So as a tech lead, at the time, I think there was something like 35 to 40 individuals on the larger team that we were working with on the language team.

27:37And so the best thing for that 35 to 40 group of individuals of what I should do is different versus the maybe six or seven ICs I was directly supporting. And so I had a PSC where if I would be great as an IC, I was told I would get a GE. Like basically my role as a tech lead for this group of 35 to 40 individuals I was doing really great at. But as a manager, I wasn't failing. I was a good manager, but I had to do that job successfully. I wasn't necessarily looking to exceed as a manager or do or maximize the growth of those six to seven individuals I was supporting directly. And this became something is like, is this actually what's best for the team long term?

28:25And ultimately, I had a choice of I could basically try to replace myself as a tech lead so I could focus on being a org manager or go back to be in the IC so I could focus more freely my time on what the needs of the larger organization needed from technical leadership. And the choice became obvious for me as like, it was just easier to find a manager for six to seven people than me trying to find someone who can be effective tech lead for a group. So that's what led me back to be in the IC. You mentioned that along that journey, you managed some EMs and you managed ICs as well. I'm kind of curious, what's the difference between managing an IC and EM?