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

Episode Date: July 25, 2025

Dwayne Reeves is a Senior Staff Engineer (IC7) at Meta who is the Tech Lead of the most used programming language (Hack) at the company. He started at the company as a new grad from MIT and shared the story of how his career grew. We discussed:• His promotions to Senior (IC5), Staff (IC6), and Senior Staff (IC7)• The value of type systems• Transitioning to a TLM and why he switched back• Working with brilliant engineers and overcoming imposter syndrome• Advice for his younger selfTimestamps:(00:00) Intro(00:39) Joining Facebook(04:52) Did MIT help with career?(07:13) His first team(10:37) Why static typing is superior(13:17) The uncanny valley of type systems  (16:11) Senior Eng (IC5) promotion story (19:24) Staff Eng (IC6) promotion story (23:38) Manager transition story(28:57) Managing ICs vs EMs(32:54) Senior staff Eng (IC7) promotion story(35:42) Impressive ICs(40:33) Why stay at Meta(44:28) Advice for younger self(45:46) Outro Where to find Dwayne:• LinkedIn: https://www.linkedin.com/in/dwaynereeves/Where to find Ryan:• 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• Newsletter: https://www.developing.dev/

Writing 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? Here's the full episode. Thank you, Dwayne, 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, you know, pre-IPO and all of that.

So, 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 interesting story because I really wasn't interested in Facebook, to be honest. I was like really interested in Google and Twitter. Twitter because I was a big fan of Scala as a programming language, and I know they used 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. And he was like, finally, hey, this would 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 it 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 were working on, I was, you know, obviously a user, 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? And when I actually got on campus, hearing some of the problems they had to solve with MECASH and just how to scale up a system like this, hearing things around how they optimize PHP by having their own custom runtime 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 mentioned 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. Well, I mean, they actually gave me an offer. But I think overall, the other thing is like, it's just a level of care I felt from, like, they really wanted me. And they showed it in sometimes not so sudden ways. Two things that come to mind.

One was when I got my offer, it was the best offer I had. I think 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. Oh, wow.

Yeah. I was like, wow, I didn't need to ask for this versus like Amazon. I like talk to the recruiter. And they're like, yeah, we don't negotiate with new grads. You just take what you give you. The 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 like lunch, like at local cafe to like 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. What was like the rough size of 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 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's, it is small. It's all relative. 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, like, 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? I think very little if it has to do with the actual education piece you get at different universities.

Like my education at MIT was fantastic. There's a lot it taught me. I do think that's valuable and immensely valuable. But I've also met lots of engineers who I work with who some of them didn't even go to school. Right. 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, you know, 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 engineers I work with. It was almost just by chance that even got on Facebook's radar. And they were just as capable of engineers as me. But 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 a internship offer from Apple as well. It was just kind of crazy because I remember, you know, I grew up in Bridgeport, Connecticut, growing

it 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. Like I 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 with 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, you know, 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. So 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. But by 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 a easier to manage way than just simple if or else statements. And I did that for a couple years. At that time, HAC was introduced to the codebase. 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. I just thought they were superior. So Ph.P 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, they're 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. code base and 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 tight 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 is some kind of error in the code, usually around how it handled null types. This was kind of like, I view as like one of the big results of like, hey, hack is not just this cool tool. It'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, you know, 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 the ways to think about it, is particularly if you think about the problems we face at a company or code based 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 in 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. And type systems just happen to be an effective tool for a communicating intent. Maybe there's cases if you're just your 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 100 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, it'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. And 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, you know, studying some of the type migrations, I think you've mentioned before, like, 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. Like 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 are only fully, fully statically type languages.

And did that necessarily have the muscle, like, memory or, like, weight trained in their brain? What does it mean if I have a type? It 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 offput it will fail. And so that's how I came up with that concept, right? It 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 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. And so the bugs that come are much more subtle and the behaviors are much more subtle. And it's actually worse for a bit until 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 P-HP 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 a statement, we should get rid of those behaviors because if you have a language, even if you had everything tight, 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. So I think that's, 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, for the N's framework. So since that went well, I was asked to, hey, can we do this? this at a at a larger scale like can remove 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 some

way people I was like giving ideas to the hack team given ideas to other entities of with the work on that I 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 having a conversation with my manager about this. And 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 like I think the next

one of one, she was like, yeah, that thing I told you. that's actually wrong. Like 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, you know, 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%. Now, like hack felt like it was a fixture in the company. Like people weren't really looking to write PHP first. Everyone. when we're starting to write hack first. So I felt like I had good results.

But again, I wrote the least amount of code at 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 redefines that half. 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 a path forward for how to solve it. And if others end up writing the code, then that's fine. 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 efficient, you know, coding machine out there.

there's other ways I could add value. So that was definitely one of the pieces. And the second one was also, I guess, what led to my promotion to IC6. So after that half, right, did I just explain I was actually joined the hack team. So I wasn't even on the hack team at the time. So this was starting 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. So 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 the 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. And 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 you tell 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 is 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? But once you escape the orbit, there's like other jet. 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 were six to be. It's like, oh, actually, I just got you promoted. So, uh, 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 aligning what the right strategy and what the right problems were in the first place.

A lot of more senior I sees, the value is they come in, they figure out what's important to solve why, you know, get all the alignment. And 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 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 going to 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. 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 see the potential in him. why, like, hold the promotion for another half. Having 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, you know, 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, kind of similar to how I ended up at Facebook. It'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, you know, my manager at the time, he was like, hey, we need more managers on a 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. That 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'd probably talk to my director because he came. back the next one-on-one he was like actually yeah we should we should try this you could you know be a t lm or whatever you want you know just try this management thing and since i you know was starting to get more comfortable of 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 the main decision around like that point in my career was there's so many times that i've discovered it I was set in my way, I was just trying what I felt comfortable with, that any time I

did the opposite and did something I felt was like I would be uncomfortable with led to better results. So I was like, okay, 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, okay, 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 years, it was actually pretty, 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 was this big shift where essentially I had the whole team under me. They 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. I think the thing that became tough was as the org started, we were successful.

So we continued to grow. And it became 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. You 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.

You 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 line. larger team that we were working with her on the language team. And 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 supported. 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 was 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 as like, is this actually what's best for the team long term? And 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 being an 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 67 people than me trying to find someone who can be effective tech lead for a group. So that's what ended 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? It's really the difference between trying to support someone as they are working through technical problems versus people problems. You know, one of the things I had to get used to as a manager is, you know, when you're at IC or you're doing something technically, the feedback loop between you doing an action versus you seeing the, the results of that action is shorter versus what you try to do as a manager, right? So if I'm working with a IC, I'm trying to up-level them so they could take on larger bits of work or learn how to be more creative or thorough in terms of the work that they do. As a manager, the things I attempt to do in one meeting, one-one-on-one, I have no idea if it helps.

there isn't something I could tell like, oh, I hit compile and then I, it passed or I run the unit test and now it pass. But as a manager, like it might be like six months, nine months down the line where like something clicks or they come to a meeting or one or one and say, hey, I finally got that thing you said and I'm actually seeing results for me. Now that same thing applied to a people manager is even like a longer loop. I'll say, of like, the problems they have with like, and some of it was I was a new manager. So I wasn't always necessarily clear around like, well, what's the best ways of getting them, the things they were struggling with as a manager? What advice can I give them? How can I coach them up?

It wasn't something that I actively went in. It's like, I need to do something different for these managers, right? I was kind of a vibe manager. I was just like, this feels like the right thing. And I think for the most part, things were fine, right? From a standpoint, the team, the org was doing well. But I wasn't necessarily focused on optimizing the org. I was like, fine if the org just ran, right?

And I was able to do technical work. So, you know, I know you asked about what's the difference between the IC and the manager into the management. It was more like for me, I was realizing that my brain was focused more as like still as I see is like the org is fine for the most part. I'm not looking for other opportunities to see this organization operate more. And those are the kinds of stuff I think you should be thinking more about as you are more of an org lead and are supporting other managers. It's helping them think about as they have their own team, like how they should coach others or how what

opportunities they should be thinking about or even seeing like doesn't even make sense for them to be a manager's deal or should I or is there some other opportunities so these are the types of stuff I probably should have been doing more of as a as a skip manager you know I think the thing I enjoyed the most around management though was around the coaching and so that's what I leaned on a lot more with like 101 was like what's your problems how can I help and it sounds like the coaching that you enjoyed most was I see coaching because you liked being an I see yourself so and you're saying that for EMs reporting to you, the best thing is to kind of flip that switch and start thinking about the best org design and how do we grow people and how they're going to support

their team. Yeah. And that just wasn't the natural way I was thinking, like, day to day, particularly because, yeah, I was the tech lead. So if I came in 80% of my day focus on what's the technical challenges we have and how can we best tackle them, trying to switch to 20% in my brain of like, well, is this even the right structure we have the best execute on this plan? I just was not good at switching between the two. Yeah, at some point you're promoted to senior staff or IC7 equivalent. I'm curious, what's the story behind the promotion? So we talked earlier about this uncanny Valley post, and that was, really that vision was what drove the team for a while. Like, as we started the scale,

up the size of the team and what we were pursuing a lot. If you ask anyone on the team, what were we doing? It was like, oh, we're trying to cross the Uncanny Valley. And I think what led to the promo was basically enough things lined up as we were executed and we were making progress towards this that was like attributable to my vision that it made sense to be promoted, right, at that point. It was something I remember being a bit more active talking to my manager about and I point in time was kind of seen as like, it's just a matter of time. We just need to see more

like results because I had a clear vision I had laid out and we were starting to see results from it. So we just needed to see it a little bit further along before we got the promotion through. And yeah, I ended up getting it the half before I switched back to be in the IC. So I was actually still a manager when I got promoted. I think at the time, they said officially TLMs didn't start until M2 equivalent. So if you're at M1 and you're a tech. manager, like, no, you're just a manager, right? But I think the promo to M2 was based on the technical contributions I gave as more I see as opposed to my ability as an org lead. If I'm understanding the blast radius of what you'd done was basically a migration of the full to fully statically

typed on one of the base, I guess, languages that almost everyone was using. I don't know the exact percentages, but hundreds, at least maybe even thousands of engineers using this. Is that right? Yeah, I joined a team in 2015. We had a mix of some hack and some PHP, and we soon moved to basically everything being hack. We also had some notion of like hack strict mode versus a partial mode, which strict had requirements that you wrote all the types that were necessary versus partially you could leave things out or whatever. And by this time I got promoted, we basically got all the code base. So back in 2015, out of the hack files, which were in the code base,

maybe only like 5 or 10% were strict. So by the end of this, around the time where I got promoted, we more or less had all the code base now being strict hack. And so that was like a pretty remarkable difference, you know, plus a bunch of other work we did of changes to the language runtime. and other things that had kind of paid off at that point. Coming to the end, I kind of wanted to go over like some career reflections going over the story. One thing that I was curious about is because you're early at Facebook,

you've probably had a lot of chance to work with some very legendary ICs. I'm curious, is there any IC that you worked with or you thought you were really impressed by them or maybe you have a story working with someone? Oh, yeah. There's so many excellent ICs I've worked with. So I almost feel a miss if I call some out. But I'll mention one, Kendall Hopkins. I worked with him when he first joined the company,

and he's an excellent IC who was really good at understanding for a code base, our main code base that was running hack. I was thinking from a language perspective. He was thinking more from the developer perspective, like what are they actually trying to do? Like what are products needs? Like what the product engineers need? within this code base.

And he just was an excellent engineer in helping to think and strategize like how do we make these larger changes at scale across the code base. So he was very key, I think, instrument of my success. Another one that comes to mind was Paul Bisonet.

You know, I don't know if I said this explicitly, but when I joined Hack, I had no prior experience with languages or compilers or anything. Honestly, I didn't even know where the Lexer was, which is like a dairy-based component of a parser. And Paul, he answered, he was my sounding board. Like, I could ask him

anything and I felt comfortable no matter how dumb it was. He would take the time to explain it. And so I don't think I would have survived, particularly when talking with the HHVM team, if I didn't have Paul there to kind of teach me different concepts. Yeah. And another one I just want to call out is, you know, he's still a colleague of mine, Andrew Kennedy. This guy is incredible he's literally written foundational papers on type theory like you do some research like let me look up some things around type theory and you're like oh Andrew Kennedy his name is here and he and he kind of figured this out and um it was one of those cases I did that when I first met him I did not know how amazing are his pedigree that he had and he's one of the most humblest guys I I've met

for someone who's so accomplished already working with him has really showed like I shouldn't be afraid of someone's prestige, right? I have value to add, even if it seems like I'm not, you know, I'm more junior or anything else, right? That there's always something, everyone has their strengths and there's something you could always add to that. And with Andrew, there at times we talk about different language features or ways of typing. And even though I didn't have the same background he had, finding ways where we can communicate and see, like, he'll say, oh, Duane, it's actually an interesting viewpoint. I hadn't thought about that.

Made me feel like, hey, I could actually, you know, punch and hold my weight. And then there's stuff he'll do. I'm like, I had no idea, like, how do you even think about this problem. So, yeah, those are just some of the, some of the I sees I really call out as like me haven't worked a lot with and seeing just some of the amazing work they've done at the company. It sounds like it was humanizing working with them. I mean, I guess if you had just heard about it. about him, you'd think this guy's untouchable, but getting to work with him, seeing him be friendly,

adding value and discussions kind of made it so that you were, I guess, not scared of his pride degree. Is that right? Yeah. And that's something for myself, you know, having, you know, been on the hack now for 10 years and been at the company for almost 14, it's something I'm sensitive to as well because I still remember that time when I was just a younger engineer. And so every once in a while, I'll go, I'll meet someone and I'll introduce myself and they're like, wait, you're the Dwayne? Like, you're like the hack guy. And I be like, oh, like, don't think of me like that.

You know, I want to be approachable. I want people's ideas to feel valued. And, you know, yeah, we're all humans. We all learn things, right? And just because of whatever I've accomplished in the past or any ideas I have doesn't mean I'm always right. I'm always looking to learn more. And I think that's one of the things was great around the team I had, was just so many senior ICs, those with, you know, some I talked to had more experience working on programming languages than I was alive at the time. But yet how willing they were to talk to me and explain their, their,

approach. And I just think that's something all senior I see should try to emulate that, like humility. You mentioned you've been at the company for a long time. I'm curious, like what is the thing that you find keeps you at meta? I think in this industry, a lot of people hop jobs. Yeah. So there are definitely some times I think of where I was considering jumping ship. And the thing that I always reflect on, right, is my motivation for moving is it trying to solve a temporary problem? So let's say, like, hey, at the time, I'm not particularly happy with the project I'm working on.

Is that really a reason for me to leave the company? Right. And versus like, and each time I, you know, I would interview and I'll have an offer and I would think, like, is me making this change or move really going to change, like the fundamental problem I feel I have at the moment? And each time I reached at that point, I would just objectively look at, well, what are the problems I have? And what are also the things I enjoyed about the work I did?

And particularly growing up at this company, you know, things that I was being, I had a voice that had carried weight. I had opportunities to help bring in diverse talent into the company. And frankly, how many opportunities is there? to work on a on the programming language. That was also the piece. And I had a great team. And so if there is a moment of like, yeah, there's some discomfort that was for like two months, is that really worth changing over.

And for me, I always was like, yeah, I could sit through it. And most of the time, things ended up improving. And so that was for me, my like perspective is that I don't, want to make permanent decisions based off of temporary circumstances. And it sounds like, I guess in those cases when it wasn't good, the situation was resolvable. It was not something that you couldn't change or your manager couldn't help you with. Yeah. You know, I feel some of the things in terms of what would lead, what would have led me to, like, leave, right? Is if I didn't feel valued. And in a lot of cases, I, when I would

look at it's like, no, there's all the signs that I am valued here. here at this place. And so the issues was not focused on that. It was like something else. Like, oh, it's the project I'm working on. Do I feel it's not getting the recognition it deserves? And some of it realistically might be like, I just have a war view of what I think should be recognized. And if I talk, it really faces like, yeah, I'm actually wrong here. Or maybe they are wrong. And me with enough time, they've realized that. You know, if, I fundamentally did not believe in the mission of the company or like I felt my manager was creating a toxic work environment. Things like that would be more of what I would see.

It's like, yeah, if I'm in that situation, I would have left already. But none of those were like the circumstances I had. And honestly, I feel I'm a bit privileged and fortunate of that to experience that in my career. And it's at least to a lot of like there's just been so many great people in my time. I've been able to work with both managers and others at the company that it's let me really have a career so far that like goes beyond my wireless dreams right when I was first learning the code as a high school student you know the child of Jamaican immigrants I would have never in my wildest dreams have thought that I would have end up with the opportunities I've had working at this

company and it's not I want to want to say sentimental but it's really appreciating that like I've actually been really blessed and really fortunate. And I guess the last question I want to ask you is now that you have all this experience, if you could go back to yourself right when you graduated college and give yourself some advice, what would you say? I get to ask this often. And the thing is, the thing I'll say is, hey, Duane, I know you like code in. But the thing you should realize, right, is when someone goes and tells you, hey, can you write some code to do this,

you should stop and think, how do they know that's the right code to write? You should aim to be the person who's making those decisions around what's the right thing to do. There's a lot of imposter syndrome and other stuff I dealt with early in my career, that having this clarity is like, it's not about, you know, I'm more than what I can type on the keyboard. My ideas and the value I derive is greater and, like, focus not on just being an output machine, but really being the one and focus, like, can I be in those rooms that's deciding what's the right thing to do? Yeah, thanks for sharing.

And I feel like someone with your amount of career success sharing that you had imposter syndrome, I think that can be helpful for a lot of people. So, yeah, thank you so much for your time, Dway. I really appreciate you coming on. Yes, it was a pleasure, Ryan. Thank you so much. Hey, thanks for watching the show. I don't sell anything or do sponsorships.

but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interviews. So if anyone comes up who you think you really want to hear their career story, let me know. And I'll try to reach out to them and get them on the show. Thanks for listening as always. And I'll see you next time.