Turn repeated engineering pain into leverage for the team

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1. 44:38

   At this point, and this is kind of the end of that part one of your story, you credit a lot of your success to, again, the side quests and like having these side projects or a running list of, you call them 20% time ideas. And I'm curious, do you have any tips on how to find opportunities for engineers? Yeah, I think at some point there was probably, I forget the exact numbers, but there was probably like 50, 100 engineers or something like this that were just like working on these like side quests that I like scoped out and like spun out of various points.

2. 45:08

   And so pretty much like every week I would think of like some project, you know, just like on a run or something, or maybe like while I'm coding, I think of some idea. I'll just do some basic validation and then I'll just ping an engineer that I know and be like, yo, are you interested in this? And then I'll connect them with a couple other engineers that might be interested. And this kind of added up very quickly.

3. 45:27

   I think that for me, one way that I really think about my work is how can I do less of it? And as an engineer, our superpower to do this is automation. The most tedious stuff you can automate. And this is something that's like really hard actually for other fields. But for us, it's this incredible thing that we can do. And it's something a lot of engineers don't really do for whatever reason. But we should all be doing it all the time.

4. 45:51

   It's so important. It's leverage. It's like free leverage. And so a thing I often did was every time I did a code review, if I was commenting about a particular kind of issue, maybe like a stylistic issue or something, I literally had a spreadsheet where I would tally up that issue. And I posted kind of the link to that pull request. And then I would do this for every code review. And then when I commented about the same kind of thing more than a few times, I would just write a lint rule for it to just automate that.

5. 46:18

   So this is kind of an example of leverage. So, and at some point I automated most of my code reviews because like, I just had a, you know, like a flock of lint rolls that were just like doing all this work for me. And I think this is actually kind of similar because all these side quests, it was improving prod infra and dev infra. And these are things that slowed me down in my day-to-day coding. And this is why, like, when I was doing less coding, this was actually very dangerous because as an engineer, you need to be anchored to reality. You need that intuition. And if you're not in the code anymore, then you lose it very quickly. It's a very dangerous place to be in.

6. 46:50

   and so for me when i was in the code a lot there was all these really cool ideas that came out of it and it was leverage not just for me but for the whole engine team because again of this principle that if you have a problem probably other people have it too and you know i did like yc back in the day and in yc they teach you that first you build for yourself you have to build like awesome stuff you have to build stuff people love but if you're trying to find a market to build for you start by building for yourself and that's a pretty good indicator other people probably have that the same problem yeah there was a quote that you wrote i thought was really good you said better engineering is the easiest way to grow your network and gain influence as an engineer so i could totally see um you had like your scope of influence was so much further than just the

7. 47:34

   code you're writing because you're passing people all these great ideas and you know overseeing them it's the the leverage is really uh insane absolutely yeah and and it's also just like an example of being contextually uh was it situationally aware um because you know i met at the time engineers were evaluated in the performance cycle uh we looked at project impacts people do you remember the direction direction and and excellence and eng excellence yeah and the eng excellence is a thing that a lot of engineers struggled with and so you know i was you know one of the people that came along and was like hey if you want to do eng excellence here's a project and people are already incentivized to do it so they see it as an opportunity and i think this is just like i don't know i think it was a chance for me

8. 48:19

   to kind of hone my skills about working with people where you never ever want to tell anyone what to do in any in any context in a personal context in a work context everyone hates being told what to do. But if you understand what a person wants, then you can go to the right person with a right opportunity and they see it as an opportunity. And this just always works better for everyone. When I think about these 20% time ideas, I mean, there's the top of funnel finding the ideas and then there's actually executing on them, getting someone to do it or whether it's yourself or someone else. The thing I'm interested in is the top of funnel. How do you source so many ideas as an engineer for these side quests that are impactful? Just common sense.

9. 49:05

   I don't know, maybe spidey sense. I don't know the right word. Spidey sense. Like how so? Like what's a concrete example? Yeah, like a really concrete example is, you know, like I think literals are a good one. Maybe another one is there were all these cases where we had SEVs because Facebook groups were not being tested with very large sets of Ahsoks. And so like, for example, and Ahsok kind of like, this is kind of like a Facebook way of saying like, you know, rows in a database.

10. 49:35

    So you could imagine like a Facebook group with like 10 million members. Like no one's ever tested this. There's no like unit test for this. You only see it in production. And when I looked across the org, I started seeing similar cases of this. There's, for example, like if you have a profile with like 20 million followers, a lot of stuff breaks, but obviously like no one tests this in an automated way just because it's kind of annoying to write a unit test with this much data and so there's a bunch of instances of this and then I pitched an engineer to build a way to write unit tests for large data sets so you know like a really big object like a group with a lot of members a profile with a lot of followers an event with a lot of attendees and I think this infra still exists and it's you know prevents a

11. 50:16

    lot of issues. And this is something where you can scope it. And then he brought in a bunch of other engineers to do the work and help him out with it. So I guess just think about the problems that you actually hit day to day. Got it. Okay. So think about the problems. And if you're experiencing that problem repeatedly, then it's time for automation. And that's like a great, better engineering project. Yeah, exactly. Exactly. Like if you hit the same problem, like