Farhan Thawar: recommendation

Transcript context

…I feel like, the more I dig into the Shopify way of working, the more fun stuff I never expected emerges. I'm curious what else is going to emerge. So we've been talking about ways that y'all, and you specifically, have created intensity, especially in the engineering organization. And then, you've also shared just broadly Shopify. What else is on that list? What else have you found helps create more kilojoules per hour? Yeah, so again, I think there's nothing, I would say again, start from the beginning, there's nothing more than pair programming, because literally you can't do anything else but be on your computer. So pair programming is the number one. I will say, the weekly cadence helps a lot, right, which you mentioned. Again, which is part of GSD, which is sharing the updates, and then the six-week reviews, that does a lot. On the other side, we also have a lot of metrics and alerts that help us see when potentially things might be happening in the system that can allow us to be like, "Hey, wait a sec, there's too many things going on of this type. We probably have to sit back and reset and figure out what's going on." So one thing that happened, for example, was we started seeing that it was taking a lot of time to develop in our admin, like engineers at Shopify developing in the admin. So we called, what's called, a code yellow, which is before code red. But code yellow is this idea of like, "Hey, we're going to call a code yellow on the admin." We want to make sure that the developer experience inside Shopify is really good. It should be easy to start up the repo. It should be easy to make changes, it should be easy to see the changes. And so, those are the things that, again, we can create intensity, because this code yellow allows the champion to tap anyone on the shoulder and say, "Stop what you're doing and come help this thing." Which is an infrastructure layer thing. And by building out this infrastructure, it allows you to go fast. It takes longer to build infrastructure, but it makes you go fast forever afterwards, right? I'll actually give you an example of one of these. So, we in 2020, 2021, the heyday of pandemic, obviously, there was a crypto summer again and crypto was going nuts. And we were sitting back and saying, "Wow, a lot of our merchants are now asking for NFT gating." NFT gating, which is, "If you have the token, you can now go into the storefront and see my products. You can see my prices and you can check it out, but only if you have the token." And, we were getting a lot of demand from merchants to be like, "We want to do this. We want to sell an NFT. And we want our buyers to have the NFT to have this great experience." And we're like, "We agree. We want you to be able to do whatever you want. And so, we want to build this for you too." And, sitting with Toby, he's like, "You guys are thinking about it wrong." He goes, "How long would it take to build NFT gating?" I'm like, "I don't know. Two, three weeks." He goes, "Now, how long would it take to build a platform layer, which exposes APIs so anyone could build NFT gating in one hour?" I'm like, "I don't know. Two, three months." He goes, "Do that." He goes, "Because you don't know what they're going to build on top of the platform." Is so anyone could build NFT gating in one hour?" I'm like, "I don't know. Two, three months." He goes, "Do that." He goes, "Because you don't know what they're going to build on top of the platform." NFT gating is one thing, one use case, but if you spend the time to build out the infrastructure layer, he calls it putting gas in the tank, if you put the gas in the tank, people could drive on that gas for a long time going forward. And so, he goes, "I always want you to think about..." And the key part was, "What can you build so anyone could build this in one hour?" Right? So, he does this thing to us all the time where he goes, "Oh, this should only be..." He'll say it and people get the wrong thing. He'll say, "Oh, you could write this in a day." And what he means is, "What has to be true so that you could write this in a day? What infrastructure do you need?" And, he actually develops this way. He will write code against an API that doesn't exist, because he's like, "You know what should exist here? This API." He'll write the code, he'll go back and forth and refine the client on the server, and then he'll go, "This is correct, the correct client code. Now, let me go implement the server code." And this is notion of building things as infrastructure that sound slower today, because it's going to take... It's two, three months, instead of two or three weeks. But after that, the things that people built on top, right, were so easy to build, there were so many more scenarios that were emerged. It's just a different way of thinking about software. And, it's intensity in a different way, it's intensity around building this infrastructure layer, which we want to build quickly, but takes two or three months, in this case, but then can get everyone building on top of our infra in a much, much quicker way. And of course, who knows what can flourish from there?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.