The Pragmatic Engineer
01:10:06 · Maude Lemaire
[01:10:06] S1: Yeah, yeah. Because I think a lot of the problems that I work on are more of the, like, product platform-y problems. And the whole point is to solve a problem holistically And to create that foundation that you can build on top of, right? And if you only built the foundation to cover like 80% of the house, like what's the point? Because that other 20% that was not built on the foundation is going to be really shaky and impact the rest of the house that you did build. And if you already did that over here, well, nothing's really stopping you from, say, tacking on another 10% off past the foundation and then that spiraling, right? And so I think especially now that I think AI is so good at just duplicating things in places because that seems fine and it doesn't have a sense of it's not great at going, but why? But why? 20 levels removed. It leans more towards, I will just tack on, I'll just build an extra bathroom past the foundation. That's fine, right? Like you asked me to build an extra bathroom, that's where I'm doing it. Rather than questioning the underlying fundamental assumptions, which are, should one build a bathroom not on top of a foundation? And those are the questions that I'm asking myself all the time. And I think part of it is because I'm coming from a product platform perspective.
01:11:40 · Gergely Orosz
[01:11:40] S2: I have a sense that the product platform work, the platform work reliably performance, it will only be more important because, again, we'll have systems that have so much load, so much test. What advice would you have for a software engineer who What are paths that you've seen people make it onto platforms that you worked on? How did they transition?
01:12:12 · Maude Lemaire
[01:12:12] S1: I'm such a strong advocate for more product folks, more interchange actually between product folks and product platform teams. I've seen it so many times where product platform teams, are spun up out of product engineers who care a lot about the fundamentals. They care about reliability. They care about performance already. They're trying to improve that and inject that into the way that they're building product all the time. And I think the best product platform folks that I've worked with get to a point where they've seen a pattern enough times in the things that they are building as product engineers. And they're like, I want to dig in and solve this problem across the board. Like this specific problem, I understand really deeply from having implemented it two, three, four times. I want to go solve it once and for all and be done and like have this thing that other people can also use. Right. They get annoyed with the toil and then they go and maybe embed with the product platform team or they like spin one up with some other folks and then they do that. And then a lot of times those folks end up staying on product platform teams and continuing to really like the product platform work. But then they get further and further detached from what product development actually feels like. And I think that's where you see sort of the chasm that ends up being created between product platform teams and product teams is just there's not enough cross pollination between the teams. And so one of the ways that I've seen that chasm merge back together is having like rotation cycles between those teams, sort of always having someone on the product platform team, having a core set of folks who are like maintaining the main systems and platforms that they've built, but sort of always having someone on rotation from a product team. On the product platform team bringing like, oh, well, I don't know what you all are doing here, but like on product, we're just like YOLO shipping all this AI slop all the time. Like what you're reading your code, what?
01:14:05 · Gergely Orosz, Maude Lemaire
[01:14:05] S2: It's a thing. It's a thing. On product, code reviews are totally dying. [01:14:10] S1: It's completely different, right? But if you're not close to that, then you also don't know how to bolster your platform to be the best that it can be so that they can do that. I see my role in this phase of the world right now as a product platform person to be... The guardrails need to be better than they have ever been before because... Product people need, I mean, need is a strong word, but should ideally be able to slop out whatever the heck they want. [01:14:42] S2: And the platform should stop them or warn them or... [01:14:46] S1: Yes.
01:14:46 · Maude Lemaire, Gergely Orosz
[01:14:46] S1: Yes. [01:14:47] S2: So do I understand that your suggestion is like, look, if you today are on a product team, you're building products, you're shipping to customers, to users, obviously understand what the business cares about, try to build quality stuff, but also ask yourself, are you carrying out performance and reliability? If not, first of all, why not? Yeah. And second of all, as you start caring about this, and if you are working with the platform team, start working with them, hang out with them, see how you can, these problems that you're having, can I help build a solution for that? If you have the option, transfer onto this team, it's pretty useful. And if you are on this team, Try to have a way to work a little bit, like implement the feature with the team, understand why they're shipping so quickly and so seemingly carelessly, because this will both ways will just make like it seems like we need both, especially now that product teams are pushed to ship a lot faster. And they are shipping faster, by the way. And there's new tools. Some of them work. Some of them don't. And, you know, this is how we're going to be better engineers and how we will build better systems that allow us to, like, ship reliable and quality experiences, which I'm all for. I hate seeing quality degradation on software. [01:15:56] S1: Oh, no, no, I know. [01:15:58] S2: But we can stop it or we can actually build better software, hopefully.
01:15:58 · Gergely Orosz, Maude Lemaire
[01:15:58] S2: But we can stop it or we can actually build better software, hopefully. [01:16:02] S1: Yeah, yeah, I think so. I think it is really similar to... For folks who are familiar with like the embedded SRE model, like there's a reason why that's really, really effective. And I think that there's real parallels with product platform as well. I kept talking to my team about like, I mean, we always had to fight against spaghetti code, right? So easy. But now we're at this point where like the spaghetti has like a life of its own and it like actively wants to spill out of the plate. Whereas before people were like, okay, like I got to kind of keep it on the plate. No, no, no. The spaghetti like wants out and we have to almost like red team our own situation. [01:16:42] S2: We do. Well, Mo, thank you so much for this conversation. [01:16:45] S1: Thank you so much for having me.