#168 - Serverless as a Game Changer - Joseph Emison ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fd3t3ozftmdmh3i.cloudfront.net%2Fproduction%2Fpodcast_uploaded_nologo%2F6336609%2F6336609-1679195199932-b698770720e3b.jpg&w=100&h=100) ## Metadata - Author: [[Tech Lead Journal]] - Full Title: #168 - Serverless as a Game Changer - Joseph Emison - Category: #podcasts - URL: https://share.snipd.com/episode/48538abb-d450-4265-af62-1f58c74a403c ## Document Notes ## Highlights - **Widening Developer Team Gap** - The gap between top and average software teams widens due to rapid tech advances every 18 months. - Startups gain leverage by adopting the latest tools, avoiding legacy tech inefficiencies. Transcript: Speaker 2 But what picked my interest in the beginning when you said, right? So technology keeps advancing every 18 months or so, right? And the gap, I think you mentioned in your book, the gap between the best software development teams and average software development teams is getting more enormous. I think it's related to all these advancements. Maybe if you can pick a little bit, like why you think the gap is getting much bigger. Yeah. Speaker 1 I mean, I think if you think about like, if there's like a huge change every 18 months, there's this compounding effect. And so startups that get to start today get to take advantage. There's no legacy, right? They're not relying on any existing technologies. So they can just use the absolute fastest best way to build something today. And if you started a company like we did five years ago, you're already going to be committed to some choices that if you were going to rebuild it today, you would build it differently And it would be cheaper, faster and better. You know, if you had all the knowledge that you could have. And so we, you know, we look at that ourselves even. And so the book I'd give an example of Instagram when it was acquired, had 13 developers and doing about the same thing, roughly Facebook had hundreds of developers. And then before that, you know, friends are in my space at over a thousand developers. And so there's an actually Instagram at 13 employees. I think they might have had like five or six developers. And if anyone has gone through the process of like, how much can one developer do? And then how much can four developers do? There are these step points where you lose massive efficiency per developer. I mean, I tend to think of it as kind of like one developer, four developer, 12 developer, 25 developers, 50 developers, 100 developers. And once you're at 100 developers, there's like a core inefficiency that's in the whole operation. You know, you're getting an order of magnitude less productivity than if you have a solo developer. No, you can't run everything on a solo developer. It's not a sustainable thing for a company. But there's also a reason why Amazon has these like two pizza teams and trying to keep these services small. It's the only way to keep really good quality and velocity together. And so when I say that the top teams are orders of magnitude better than the average teams, it's largely that the top teams are leveraging technology so much better than the average teams That they're just not bogged down. And I feel that very much at branch. The company that I was working on 10 years ago built facts, which was fully in the cloud infrastructure as code, but like running on VMs, I think it's still probably is, you know, in Amazon Load balancing, we were using right scale at the time to do some of the orchestration. There was a core inefficiency that we had in running and a core in efficiency that we had in building new features that branch doesn't have branches just faster. And so the average developer at branch is just producing more for branch and at a higher code quality than the average developer was at build back. Speaker 2 Yeah, it's quite astounding when you mention about this Instagram only have maybe 13 employees or five developers in total, right? But can build a world kind of scale, you know, like with users from all around the world. And I think what you say is right. So for people like me who has been running industry for quite some time as well, right? I mean, the recent years, you can actually see that, oh, there are so many technologies that I'm not even aware of, but actually it's really cool to probably prototype new applications Right, building something from scratch. And even like, for example, you mentioned, so you can actually build something like only Google or Amazon can do last time, right? And now you can actually tap into those technologies to build similar things like them. And I think what you mentioned as well, right? If the developer can produce more, that means they are focusing a lot more on the right thing, right? Which you mentioned as differentiated versus undifferentiated things. I think this concept is very important for you to actually adopt as technology leader or technologies in general, right? So tell us more about this differentiated versus undifferentiated. Speaker 1 Yeah, I think you always want to look at what does your business need to do differently, or your organization need to do differently than other organizations? And what are things that it's fine for your company or organization to do as well as other companies do, like the best other companies doing it? And so let me give two examples that are both undifferentiated, but that will generally, in my experience, get very different reactions from lead developers. So let's start with the simple one where I think we'll all agree. So if I talk about sending text messages, sending text messages is undifferentiated. You don't care if you send text messages as well as the best other company says text messages. Now, by the way, there's probably some listeners who are going, no, if you don't register your 10 DLP campaigns, you'll get the messages rejected. Yeah, yeah, yeah, but if you do it as well as the top people, you're fine, right? If you can send text messages as well as a quality things, you will be registering 10 DLP campaigns, and you'll have your short codes, and you'll use Twilio or something like Twilio, But Twilio is a great product. I know it's a little expensive for what it is, but it's a great product. And so I don't run into a lot of lead developers who will tell me, no, I need to buy, you know, separate boxes and hook up phone lines and have telephony cards and like run them in a data center. I don't find that. Although I did that in 2005, I ran IVRs that one. So I remember that it was awful. I would never do it. And so I think everybody agrees that sending SMS is undifferentiated heavy lifting and you should use a service like Twilio to do it, right? And in fact, you should probably use a service like braise or iterable or customer I owe to like actually trigger those because those help make it even easier and you could do templating And have people do. And if you don't know these services, you should look at them up because they'll make your life easier. And the back of my book actually has a whole appendix on you should know all these services because they're very used. ([Time 0:11:07](https://share.snipd.com/snip/96770ca4-ea46-40c7-865d-fedd5d98cd02)) - **Outsource Undifferentiated Tasks** - Outsource undifferentiated tasks to services instead of building them internally. - Focus engineering on what makes your business unique to maximize output and innovation. Transcript: Speaker 1 Yeah, I think you always want to look at what does your business need to do differently, or your organization need to do differently than other organizations? And what are things that it's fine for your company or organization to do as well as other companies do, like the best other companies doing it? And so let me give two examples that are both undifferentiated, but that will generally, in my experience, get very different reactions from lead developers. So let's start with the simple one where I think we'll all agree. So if I talk about sending text messages, sending text messages is undifferentiated. You don't care if you send text messages as well as the best other company says text messages. Now, by the way, there's probably some listeners who are going, no, if you don't register your 10 DLP campaigns, you'll get the messages rejected. Yeah, yeah, yeah, but if you do it as well as the top people, you're fine, right? If you can send text messages as well as a quality things, you will be registering 10 DLP campaigns, and you'll have your short codes, and you'll use Twilio or something like Twilio, But Twilio is a great product. I know it's a little expensive for what it is, but it's a great product. And so I don't run into a lot of lead developers who will tell me, no, I need to buy, you know, separate boxes and hook up phone lines and have telephony cards and like run them in a data center. I don't find that. Although I did that in 2005, I ran IVRs that one. So I remember that it was awful. I would never do it. And so I think everybody agrees that sending SMS is undifferentiated heavy lifting and you should use a service like Twilio to do it, right? And in fact, you should probably use a service like braise or iterable or customer I owe to like actually trigger those because those help make it even easier and you could do templating And have people do. And if you don't know these services, you should look at them up because they'll make your life easier. And the back of my book actually has a whole appendix on you should know all these services because they're very used. Now, let me get to a controversial example. And I don't know why this is I mean, I know sort of why this controversial. Most lead developers want to run Elasticsearch or like Amazon Opensearch themselves as their search index. When there is a service called Algolia that will do all of the painful stuff for you, I will tell you that running search index that's performing is undifferentiated. You do not need to do it better than anybody else. I mean, unless you're competing with Algolia as a business. And so you can outsource a lot more to Algolia. It works phenomenally. It's really fast. Elasticsearch, Opensearch, they're very vinicky services. You'll have to be responsible for their uptime indexing to them is kind of a pain in the butt. Generally speaking, front ends can't talk directly to them because the security model is too poor. So you'll have to build a proxy. You'll have to query through your back end. It'll slow it down. It adds more development. But mostly developers will say, wow, I looked at the pricing for Algolia. It's really expensive. And I'm not quite sure. Oh, wait, how do I do it in a dev environment in the right way to save costs? No, no, no, no. It's just safer. I'll run it myself. I know how that works. We'll run these things. We know how to run. But like that is classically undifferentiated heavy lifting. Everything you're choosing to do there to run Opensearch or Elasticsearch when Algolia exists is undifferentiated. And if you take an actual cost of ownership, like the time that it costs and the people that are needed internally to run that thing, Algolia is much cheaper, just period. But most developers will make the choice on behalf of their organization to in house this undifferentiated heavy lifting with something like Opensearch or Elasticsearch because Of honestly this misplaced sense of how they should be optimizing. And so that's my favorite example for this undifferentiated heavy lifting. If you can outsource it, if it's not something that makes you different, you should use a service because you will always be asked to do more things that you can build as a developer that Are differentiated, that are like special to your organization. ([Time 0:15:14](https://share.snipd.com/snip/e776775a-7d42-4cac-a647-4647bc420241)) - **Calculate Real Software Costs** - Calculate real software costs by including developer salaries and velocity delays. - Managed services often reduce overall costs despite appearing expensive on the surface. Transcript: Speaker 1 I mean, I think that you really need to internally understand how much it costs for you to develop and run things yourself in terms of your people costs. And I think you also need to understand it in terms of your velocity costs. So in general, the more teams that you have in your company that are required to get code live, the more inefficient you are. And it's a compounding effect. In my book, and everywhere I talk, I recommend people read, accelerate, and use the Dora metrics. We use linear B at branch as a way of monitoring the Dora metrics. The cycle time is critical. And so, you know, what I see is that the more undifferentiated work you do, the longer your cycle time. And especially when the undifferentiated work is running the things. And so, when you use a service like Algolia versus you are running, you know, your own Amazon Open Search, or you're running Elasticsearch on containers and you're building a proxy Service in there, those are orders of magnitude different impact on cycle time when you release changes to how things go to the index. And I think if you're honest with yourself, both about the actual costs of people and about the impact on something like cycle time or the other Dora metrics, it gets really clear that You just don't want to run, I mean, ideally, use managed services or, you know, don't write code, use managed services always gives you better outcomes here. Now, always does have an asterisk. I mean, there are services that are very expensive that don't make sense for you to use. So like Algolia isn't a solution for everyone all the time, because, you know, if you have an index where you're searching, you know, billions of records, probably Algolia is not reasonable. But the way I generally think of this is there's like 90, 95% of the time, we're all kind of building the same apps. They don't have like enormous traffic. By enormous traffic, I mean, they don't have so much traffic that your data transfer costs are like the biggest part of your bill. Generally speaking, you know, none of us have more than, I don't know, a thousand simultaneous users. I mean, generally speaking, most applications don't have more than like 15 simultaneous users, truly simultaneous. But you know, a thousand simultaneous users, most of our database tables at most are sort of in the tens of millions at most, you know, there's a way to set that up. And so there's sort of a standard 90, 95% of the time. And yet most or many lead developers I find always want in their head to be designing for like huge amount of data transfer, like, you know, millions of simultaneously, like that's the Model of aspirations like built this life. Hey, but the problem is like those just need to sit. Those are all exceptions. And most of the time, actually looking at door metrics, actually looking at cost, you'll find that managed services that are used by everyone at Twilio and Algolia, Cloudinary, whatever, Are just going to beat any sort of honest and fair comparison of actually taking their account of costs. And I'm always shocked at how many people just don't want to even think about how much developers fast they want to view them as like developers are free. And so if you're a lead developer, you don't know how much your development team costs, and you're making decisions based upon this is more expensive than that, like, you need to find Out how much the team costs. ([Time 0:20:30](https://share.snipd.com/snip/93f94044-af7d-4d1a-8de8-646df9e1d992)) - **Easy Service Migration with Serverless** - Branch migrated a critical referral management service from a costly third-party with only 35 days of rebuilding. - Serverless architecture made switching easier due to well-defined APIs and isolated service boundaries. Transcript: Speaker 1 And they shut down with 60 days notice. I think today is the last day they're running. And we actually decided to in a house what we had put there, but it was so much easier to do it because we could just copy their API. And so we were able to take all this stuff we'd written for airplane and port it over. You know, I mean, I don't want to understate the developers who've been working on that have like been working very hard and like week nights and weekends to like get that done. But to think that we took a service that we were spending like $60,000 a year on, and we were able to rebuild parts of it, like a little shim infrastructure for what we were using of it in About in less than 60 days, probably more like 35 days, was a result of having used that service was a result of having this serverless mindset. And being able to say, okay, now we understand the problem so well, and we isolated it so well, that actually rebuilding it or understanding how to shift it somewhere else ended up being Much easier. And so I love being in an environment where everything is kind of contained and small, there's good separation of concerns. ([Time 0:25:51](https://share.snipd.com/snip/660976d6-27bc-494a-94b3-388df80e3af6)) - **Code is a Liability** - More code means greater maintenance liability; less code improves quality and ease of updates. - Prioritize maintainability and small incremental releases over monolithic development cycles. Transcript: Speaker 2 So I think some people think code is asset, right? Some people think code is the most important thing in your company. So tell us why code is a liability. Speaker 1 Yeah, I mean, code is something you have to maintain. And so this idea doesn't come from me. And so in the book, there are some good links here. But you should think about anything that I write is something there that's necessary for my organization to work properly, that I have to make sure has proper testing, like doesn't Regress, keeps working. And so I have to maintain all of that, that's a liability. You know, the asset is the experience you're building. And so if I can build something with 10 lines of code, or I can build it with 1000 lines of code, I'm going to be much happier in the long run with the 10 lines of code, it'll be easier to maintain, It'll have less bugs will be easier to test. All of those things will be much better. And so the less code, the better at branch, we have a kind of a waterfall process where when somebody says, Hey, can we build this thing? Will you build this thing? Our first question is actually, do we need to build anything at all? And so we do a lot of why don't you use this software as a service instead? And if we need to make some sort of integration, we'll do that. But like, let's just just go buy a software as a service. That's step one. Step two is kind of, can we like down scoop it? Because if you buy a software as a service, like you get all those features, those are great. If that won't work, how do we like take out what you're asking for and make it really small? One of the things that I've found over my career, what generally happens in organizations is people say, I want this thing. And they usually make it really big, because they know that you're going to go develop it. And as soon as you put it live, you can't work on it again for a really long period of time. And so they're going to pack everything they can into it, because that's the only way they know how to get if you're reorganize. And this is very much in line with the Dora metrics on the agile manifesto. If you say, look, two things, one, I'm going to make you down scoop this thing to time. But two, I promise, we'll keep working on it immediately. Like we won't stop working on it. It's not a limited time window. Then we work on other products per year, keep working on it as soon as it gets released. It's got to be really small. Then you get all this benefit of the feedback and the cycle. So you just squash down what people want to like, very tight, like just helping them a little bit. And then you get it live, and then they can see it, and then they can make that next request. If you train an organization that way, it's easier as a founder than as someone who's inside an organization with other founders. But I can tell you, you can train an entire organization to think this way. And as long as you deliver on, we will make updates. You come to us, we'll go get other small updates and as quickly as possible. Everything gets more efficient. Because you know, when you build these big projects, like they're poorly designed, you put them live, they don't work right. We realize like, oh, that was a bad idea. That's a bad interface. People don't understand it. Like just build it small and watch what happens and iterate up. ([Time 0:27:57](https://share.snipd.com/snip/cc1c0078-f749-4185-bd0a-a5e01b3c3f36)) - **Defining Serverless Beyond Lambda** - Serverless means not being responsible for uptime; it encompasses using managed services beyond just functions. - Branch uses Lambda plus many managed AWS services to achieve a resilient serverless system. Transcript: Speaker 2 Because I think from your book, it encompasses more than just a function as a service. Speaker 1 Yes. And I give, I think like four definitions in my book of it. My favorite definition of serverless is it's not my uptime. And so it's functionally about not having to run that if it goes down and it's my fault, it has to be like, I'm misconfigured it or I wrote bad code. But otherwise, I don't control the uptime. But Ben Kio also has, you know, Ben Kio's definition here is, I'm only doing differentiated code, right? Everything that's undifferentiated, I'm handing off. And there's a bunch of stuff about scale to zero and things like that. If your view of serverless is, and I saw it post on LinkedIn recently, which had somebody saying serverless is expensive and it'll send you in a ruin and it's too complex and just had all These diagrams of like lambdas calling lambdas and using AWS services. And like, I tend to agree that those are, I don't like those infrastructure. I've never built one of those. And I think that they're overly complex. And I don't think he had, I mean, he's never read any of kind of the serverless practitioners that I agree with, at least about what serverless is. And so to me, serverless is very much about asking, how do I use most of our serverless footprint at branch is managed services. So it is not, I do we use Lambda, we use DynamoDB, we use Cognito, we use AWS AppSync. These are amazing services. My book explains how we use them and why they're so great. And then so we do use Lambda, but Lambda isn't everything in the application. It's like where we need to run some back-end code, we run it with Lambda, but most of the lambdas are getting triggered by calls through AppSync. But if you don't know what AppSync is like to me, it's like a key part of the infrastructure. I also written a lot with Firebase. I think Firebase is also wonderful. I think what writing kind of hobbyist apps, I think Firebase is just easier to work with than AppSync and the Amazon infrastructure. So I like that Firebase infrastructure for simpler applications. But the Amazon one is just much better for like financial services, at least it's more robust in a bunch of ways. But that's how I think about it is really, am I responsible for uptime as long as the code functions properly, then that's serverless. And so I often will tell people, you know, it's serverless to go build your shopping site on Shopify. ([Time 0:32:44](https://share.snipd.com/snip/f1ec7c86-5f48-41b3-9ce7-10955ca20ad0)) - **Manage Third Party Risk Strongly** - Establish strong third-party risk management for secure and compliant use of managed services. - Bad contract processes can block serverless adoption; proper security policies facilitate collaboration. Transcript: Speaker 1 Yeah, the most important thing that you need is good third party risk management in your organization. And I would actually say one of the biggest hindrances to serverless adoption organizations that really want to is that they have very poor third party risk management programs in Their company. And what they have decided to do in the company, maybe not even consciously, what they've decided to do in their company is basically make it really hard to do contracts with other companies As a way of security. That's not security. That's just pretending you're secure. And I recognize a lot of lead developers may not have full control over this, but it's useful to know it's useful to like have this in your head. Your company should have a robust way for you to say I would like to use this company and to be able to review it in a reasonable amount of time and see if it meets the security guidelines For the information that that service will get. You should have a good way of looking at its historic uptime and evaluating whether you think it's uptime is going to be appropriate for your use for it. And then, you know, your finance department, your legal department need to be able to review the contracts and make sure that they have an appropriate DPA, for example, and have other Things. And then if they don't meet those things, you shouldn't do business with them. But I'll tell you, as a regulated US insurance company, there are a few companies regulated, you know, as heavily as US insurance companies, we use lots of these services. And it's not a problem, but it's about having really good third party risk management and that third party risk management understanding that they exist to help us do contracts and Work with other companies, because that's a key differentiator in how fast we can build. So getting the company aligned with that is a top down goal of like helping everybody understand we need this function within our company to be able to do these things. But that's how you do it. I've been in charge of information security at, you know, many organizations that have had a lot of compliance requirements. And every time I run into it and says, well, we would never pass compliance with that. I'm just like, no, you just don't know how to do it. I guess to quote Twitter, that's a skill issue. It's not difficult, but it does require sometimes creativity. And it does require knowing your stuff. You do need to understand like, you know, what is our information security policy? Why do we have these rules? Why do these regulations exist? And you need to be fluent enough and have a good chief information security officer who understands them and cares about productivity. So you don't have all these things that can be very difficult. But I can tell you, it is so much easier to be secure with serverless and managed services than it is with an internal network. ([Time 0:36:49](https://share.snipd.com/snip/492797a6-a8f9-495c-82f3-bfc9f41e4026)) - **Trust Verified Managed Services** - Review historical uptime carefully before trusting third-party managed services. - Reliable serverless services like AWS Cognito rarely go down, improving overall system uptime. Transcript: Speaker 2 So what happens in incidents where the third party is down, right? I think it's also one of the most common objection. If those core services is down, then we are also down, and we can't do anything. So what's your take on this objection? Speaker 1 Well, one thing is we run in USC one, which is great because if there are problems in USC one, we know a large chunk of the internet's going down as well. And generally speaking, we go down less than the rest of the internet. So I've been in USC one since 2008. And this is what I found. So I remember the outage in like 2012, and there was Netflix outage there, I just realized that, you know, you get a lot of grace when it's a USC one problem. So in the last five years, there was only one significant USC one outage. It was a couple hours. It didn't take us fully down. There was the one that like affected route 53 DNS where it became clear that that service is bound in USC one and it's not really a free from USC one. And so, you know, everyone says, why would you be in USC one? But I'll tell you, like, if USC one has problems, like no one's going to blame you because every all their other products aren't going to work either. And then outside of that, you know, we basically don't have outages. We did have one in January 2022. So we've been selling insurance since the middle of 2019. And so I can tell you other than that couple hour uss one and this January 2022 where this insurance specific vendor we used. And so there aren't a lot of other choices, this insurance specific better we use went down. Other than that, you know, they're kind of partial, they're degraded services from time to time. Occasionally something won't be available. Like we have to pull motor vehicle records and those come from the states and those services go down. Like every other day, one of the services down for like 15 or 20 minutes. And so, you know, you just build a lot of alerting around it. And so our applications are very aware of that. But in terms of the core infrastructure of AppSync Dynamo, Cognito, Lambda, and USC one, I don't think those have really gone down at all ever, even in that USC one problem, they were All still working. I think Cognito had some issues but was just slow. So I would say my experience with it's not my uptime. I hired a company that is very good at uptime has resulted in. We basically don't go down. We have much better uptime than I've ever had running, you know, in any these organizations running my own infrastructure. And so we're running some of the infrastructure. So I think it's kind of a non issue. ([Time 0:40:33](https://share.snipd.com/snip/f65f137a-6089-492f-84af-d79d748be58e)) - **Junior Devs Power Full Stack at Branch** - Branch runs a serverless startup with mostly junior developers trained in full-stack JavaScript. - Simplified architecture enables everyone to work end-to-end including infrastructure, avoiding specialized roles. Transcript: Speaker 2 And actually, you have less so-called infrared developers or engineers, right? So tell us like, how do you actually run a good insurance company with mostly junior developers? Speaker 1 Yeah, my hypothesis in starting branch was that, and I had seen this at a small scale, but not at a large scale before, is that if we build serverlessly, then mostly we're going to be building Interfaces. And so my belief was I could hire front end developers, and I could basically make them full stack developers as long as we were using the same language JavaScript type script on the front End of the back end. And I thought, if it's not our uptime, if other people are doing the uptime, then I should, in theory, just be able to hire front end developers, make them full stack developers. And then that's all we would have. And then everyone would just be a developer. And then everybody could work on anything. They could work on the infrastructure, which is in YAML. They could work on the front end, they go over the back end, and we have it all in a monorita. Oh, and we'd have a mobile app. They would also be using JavaScript and React as well. And you know, everything would be kind of the same. It would all be the same repository. We would deploy it monolithically. Everyone would have their own isolated Amazon account to deploy it. And so this was the vision from the beginning. And it worked. It worked so well. And actually, let me take a step back. So at the beginning, I said, I can't hire a typical senior developer, because a typical senior, I know what's going to happen. If I hire a typical lead dev, who's listening to this podcast, if I'd hire them into that, the average one of them would have said like, Oh, I know how to build. It's not like this. We need containers. We need to go build some containers. We need to do this thing. We do that thing. And my vision would be eroded. And I believe in empowering people I have. I want to hire someone and I want to let them do it the way they want to do it. And so I said, I can't do that. So I said, okay, the safest thing that I can do that is if I hire more junior front end developers, who I feel are capable of the front inside, like, I think I can teach them how I'm thinking About building this. And they will know it differently, right? By the way, it'll be so empowering, because instead of just being a front end developer who's like, depending on other people, they'll be able to work on everything, that we're going To infrastructure and everything. And so we did this and it worked really well. And we said, okay, let's hire people directly out of boot camps now, instead of like with a little experience. And so we did that. And we realized these boot camps aren't teaching people anything useful. Like we're having to like retrain them on everything. I've got lots of thoughts about boot camps. And so then we said, let's run our own boot camp, because the boot camps aren't useful. And then we run our own boot camp. And we did it again. And so, you know, my opinion today is if you set this up correctly, and if you hire the right people who don't have preconceptions about, you know, how things should be done, then we have Lots of people who are very happy in this environment. By the way, we could search for a VPN engineering, fairly early on about three and a half years ago, and found this wonderful guy Ivan Herndon, who had been an engineering manager at StockX, But mainly front end, but like really understood everything and had taught at a boot camp. And he was like fully bought into like, this is a great model. I like this. But it took like eight months to find him. Like it was just like a long journey. But we had built enough. Then that we went out and hired more senior developers. And we basically screamed for like, who's going to like this? You know, and we found senior developers who were like, I love this. This is great. Like, this is exactly what I want. Like it's so easy. And I have so much control. And like, again, when our senior developers are given a feature, they do all of it. They can do 100% of everything, the infrastructure, the front of the back, and like, we truly have full stack developers, but they're full stack developers, because the stack is simple, Right? It's all the same language. It's all in the same repository, right? It has a monolithic deploy. And so we can make full stack developers if we make the stack simple. Otherwise, it's much harder to have full stack developers because you need to know too many different technologies. And so it's worked phenomenally well. We just have developers. There's no front end. There's no back end. There's no API. There's no infrastructure people. ([Time 0:48:45](https://share.snipd.com/snip/e3224a41-661e-4652-9f92-3d16b7abe60c)) - **Research Before Coding** - Define your code optimization principle clearly, like maintainability, as a team standard. - Spend ample time researching solutions before starting development to choose best options and reduce rework. Transcript: Speaker 1 From you. Yeah, so I've got three here for you. And I'll start with something that I said before, which is one, you should have an optimization principle for how to write code. It's just as important as having linting rules or style rules. You should also have an opinion about what you're optimizing for. So we optimize for maintainability. I think it would be fine. You know, in some places, it might be we're optimizing for like the lowest latency execution or whatever it is, but you should have that you should write it down, because it will help Solve problems and it will help resolve questions and doubts when you're not there. So you should do that. And then, you know, my view is optimized for maintainability is a great default. And the second thing is less code is more maintainable than more code. And that is just true outside of like obfuscation contests for like small lines of code. And so you should strive for less code. Again, the book has sort of an interesting waterfall about how do I, what is a tactic when I'm being asked to build something? How do I end up with less code there? But then finally, I have a saying that I give all the time. So I give that as my final one, which is along these same lines, but it is that it is better to spend two weeks researching and two days developing than it is to spend two days researching And two weeks developing. And I'm always just amazed by organizations that don't give developers time to research how they would do something. And I'm actually less amazed at developers who just want to start building. It's the hardest thing. I know. I mean, I always want to just start building. But the more you can train yourself in your teams to think about how do I spend a good period of time where I'm just trying to understand what's out there, what are the options and how do I make that a good thing? And like, I'm going to throw away whatever's done at the end of it. And this really, you need leadership to help you with this, but I think as a tech lead, you can set this tone. And I'll give as the example, our airplane migration, when we found out essentially like January 5th, that we were going to have 60 days, we actually spent basically all of January trying To figure out what we were going to do. We looked at a bunch of other services that were options that we evaluated them and we talked to their teams and tried to understand things. We looked at what it would take to build ourselves and what that would look like. And so we spent, I think a lot of people would stay, you spent too much time, you know, like not acting because the service was going to shut down and it was critical production functions. But the reality is you just can't make the right decision unless you spend time understanding what's out there. And today, if you're building new things, one of the things you need to know what's out there is what are the managed services that could do a big chunk of this for me. And you're not going to understand those unless you give yourself the time to play around with them. And almost all of these providers will give you free trials. You may have to talk to someone. I know a lot of developers really hate scheduling the meeting and doing the zoom demo and stuff. You may have to do that. I'm sorry. But it's still worth it. You should do it. Don't say I can't do a self sign up on this thing. I'm not even going to consider it. There's no pricing page we can't consider it. Don't do that. Go understand it. Even if you don't use it, there's actually real important value in understanding what is the service, get access to documentation, understand what that interface is, understand What that price is. All of that will really help you understand what you need to do better, even if you don't use it. And we just don't do that. We don't do any research and planning in dev. It's like, Oh, I know one way to build that. So I'm just going to do it that way. And like, don't do that. Do take weeks to research. It's worth it. ([Time 0:55:42](https://share.snipd.com/snip/060a1514-b8ec-46ec-8429-b22be4c1cc53))