1 00:00:00,040 --> 00:00:02,800 You always want to look at what is your business need to do 2 00:00:02,800 --> 00:00:06,040 differently or your organization need to do differently than 3 00:00:06,040 --> 00:00:09,520 other organizations. If you can, outsource it. 4 00:00:09,720 --> 00:00:13,160 If it's not something that makes you different, you should use a 5 00:00:13,160 --> 00:00:18,120 service because you will always be asked to do more things that 6 00:00:18,120 --> 00:00:21,840 you can build as a developer that are differentiated, that 7 00:00:21,840 --> 00:00:24,400 are like special to your organization. 8 00:00:24,560 --> 00:00:26,440 So don't add in things that aren't. 9 00:00:31,480 --> 00:00:36,680 Hey everyone, my name is Henry Surya Virawan and you're 10 00:00:36,680 --> 00:00:40,240 listening to the Technically Journal Podcast, the show where 11 00:00:40,240 --> 00:00:42,480 I'll be bringing you the greatest technical leaders, 12 00:00:42,760 --> 00:00:46,320 practitioners and thought leaders in the industry to 13 00:00:46,320 --> 00:00:50,560 discuss about their journey, ideas and practices that we all 14 00:00:50,560 --> 00:00:54,080 can learn and apply to build a highly performing technical team 15 00:00:54,600 --> 00:00:56,800 and to make an impact in your personal work. 16 00:00:57,440 --> 00:01:05,280 So let's dive into our journal. Hello Joe, it's great to have 17 00:01:05,280 --> 00:01:06,880 you here. Welcome to the Technical Journal 18 00:01:06,880 --> 00:01:08,440 Podcast. Great. 19 00:01:08,440 --> 00:01:11,280 Thanks for having me. So Joe, I always love to start 20 00:01:11,280 --> 00:01:14,120 my conversation by asking my guest to actually share a little 21 00:01:14,120 --> 00:01:16,200 bit more about yourself. Maybe if you can share any 22 00:01:16,200 --> 00:01:18,840 highlights or turning points that you think we all can learn 23 00:01:18,840 --> 00:01:20,880 from. I'd be happy to. 24 00:01:20,960 --> 00:01:25,080 You know, I think my main journey started as a tech lead, 25 00:01:25,240 --> 00:01:28,640 and I think the main thing I've learned across my career is how 26 00:01:28,640 --> 00:01:33,000 important it is to understand the business goals and the 27 00:01:33,000 --> 00:01:37,560 business itself that I'm working with or nonprofit organization 28 00:01:37,560 --> 00:01:40,240 or whatever. I think when I started, I really 29 00:01:40,240 --> 00:01:44,080 wanted to work on cool technical things, and that was my focus. 30 00:01:44,520 --> 00:01:48,320 And you know, I realized over time that the quality of the 31 00:01:48,320 --> 00:01:51,400 business, the quality of the organization and the quality of 32 00:01:51,400 --> 00:01:55,320 the leadership and the culture really mattered a lot more than 33 00:01:55,320 --> 00:01:58,240 how cool the technical problem was. 34 00:01:58,720 --> 00:02:03,120 And so I've kind of developed a rubric for myself that it's much 35 00:02:03,120 --> 00:02:06,800 more fun and rewarding to work with people you like working 36 00:02:06,800 --> 00:02:08,840 with in an organization that's grown. 37 00:02:09,120 --> 00:02:14,240 Because the organization that's growing is creating more wealth, 38 00:02:14,440 --> 00:02:17,520 essentially in many different ways that can be shared. 39 00:02:17,800 --> 00:02:21,040 And so it's an organization that there's like a healthiness to it 40 00:02:21,240 --> 00:02:23,200 that makes it a lot more pleasant to work for. 41 00:02:23,200 --> 00:02:25,560 And that that's nothing that I optimize for. 42 00:02:25,560 --> 00:02:29,000 At the beginning of my career I I'm on my 6th, starting my 6th 43 00:02:29,000 --> 00:02:32,040 company that I've been with now for about 5 years. 44 00:02:32,560 --> 00:02:37,040 But every company along the way I've made mistakes around not 45 00:02:37,040 --> 00:02:41,480 thinking deeply enough about how growing and how great is this 46 00:02:41,520 --> 00:02:45,320 garden that I'm working in as opposed to you know, how cool 47 00:02:45,320 --> 00:02:48,000 does it seem? That's the primary piece of 48 00:02:48,000 --> 00:02:50,960 advice I'd love to go back and give myself if I could from 49 00:02:50,960 --> 00:02:54,640 earlier in my career. Hey, thank you for being part of 50 00:02:54,640 --> 00:02:57,960 the technicianal community. This show wouldn't be the same 51 00:02:57,960 --> 00:03:01,400 without your ears, and you are the reason this show exists. 52 00:03:02,160 --> 00:03:05,160 If you're loving TLJ and want to see it keep on growing. 53 00:03:05,560 --> 00:03:10,040 Consider becoming a patron at Techligional dot Dev Patron or 54 00:03:10,040 --> 00:03:13,480 buying me a coffee at Techligional dot Dev Coffee. 55 00:03:14,280 --> 00:03:18,120 Every little bit helps field the research, editing, and sleepless 56 00:03:18,120 --> 00:03:21,120 nights that go into making this show the best it can be. 57 00:03:21,920 --> 00:03:24,720 Thanks for being the best listeners any podcast could ask 58 00:03:24,720 --> 00:03:26,800 for. And now let's get back to our 59 00:03:26,800 --> 00:03:28,480 episode. Yeah. 60 00:03:28,480 --> 00:03:31,640 Thanks for reminding us as well about choosing the right place 61 00:03:31,640 --> 00:03:33,600 to work with. And it's not all about cool 62 00:03:33,600 --> 00:03:35,800 technologies, right? I think there are still some of 63 00:03:35,800 --> 00:03:38,480 us technologies who love to play with the new techs, right? 64 00:03:38,480 --> 00:03:41,280 Especially these days, there are a lot of advancements, new 65 00:03:41,280 --> 00:03:43,960 things all the time. So always understand about the 66 00:03:43,960 --> 00:03:46,480 business, the quality of the business, the people you work 67 00:03:46,480 --> 00:03:49,480 with, the culture. I think that's also important. 68 00:03:49,520 --> 00:03:52,160 And yeah, working in a growing organization, I think that's 69 00:03:52,160 --> 00:03:55,080 also very important. I was just to say, you know, if 70 00:03:55,080 --> 00:03:57,920 you pick a growing organization, there's going to be plenty of 71 00:03:57,920 --> 00:04:01,320 money and advancement and things for everyone. 72 00:04:01,320 --> 00:04:03,080 And so that one I think is a real key. 73 00:04:03,160 --> 00:04:06,200 It is a way to get everything. You have a good culture and it's 74 00:04:06,200 --> 00:04:09,200 not growing and it's not going to create those benefits for 75 00:04:09,200 --> 00:04:10,440 you, but if it's growing, it will. 76 00:04:11,240 --> 00:04:14,280 Yeah, not to mention when the organization grows, there's so 77 00:04:14,280 --> 00:04:15,800 many challenges you can learn from. 78 00:04:15,800 --> 00:04:17,560 I mean like it's a double edged sword. 79 00:04:17,560 --> 00:04:20,839 Yeah, lot more challenges means a lot more headaches probably. 80 00:04:21,079 --> 00:04:23,560 But also at the same time you grow much, much better as a 81 00:04:23,560 --> 00:04:25,560 person or maybe in terms of skill set. 82 00:04:26,040 --> 00:04:28,920 So you wrote a book, Serverless Game Changer, How to Get the 83 00:04:28,920 --> 00:04:31,760 Most out of the cloud. So maybe before we start talking 84 00:04:31,760 --> 00:04:34,200 about your book, tell us a little bit more your 85 00:04:34,200 --> 00:04:36,680 relationship with Serverless. How did you bump into 86 00:04:36,680 --> 00:04:39,280 serverless? And yeah, what made you started 87 00:04:39,280 --> 00:04:42,000 to write this book? Yeah, you know, I've been on a 88 00:04:42,000 --> 00:04:47,360 journey, I think my entire tech career, of trying to leverage 89 00:04:47,360 --> 00:04:50,720 the benefits of advancements in technology. 90 00:04:51,000 --> 00:04:56,080 And one of the things that I've realized over the past 25 years 91 00:04:56,280 --> 00:05:01,200 is that we get really big, important advancements in how to 92 00:05:01,200 --> 00:05:03,720 build software about every 18 months. 93 00:05:04,080 --> 00:05:07,840 Now, every 18 months, it's not so much better that you should, 94 00:05:07,840 --> 00:05:10,160 like, throw away everything you're working on and like, just 95 00:05:10,160 --> 00:05:13,680 change everything. But there's a compounding effect 96 00:05:13,920 --> 00:05:17,280 to this, like every 18 months, big changes. 97 00:05:17,480 --> 00:05:21,080 And this really hit me hard in about 2007. 98 00:05:21,080 --> 00:05:24,960 I had been building software for more than 10 years at that point 99 00:05:24,960 --> 00:05:27,680 in time. And we had someone, I had 100 00:05:27,680 --> 00:05:30,840 started a company and we had a company looking at making an 101 00:05:30,840 --> 00:05:34,080 investment in US and they sent someone to do technical due 102 00:05:34,080 --> 00:05:37,000 diligence on us and was looking at what we had done. 103 00:05:37,280 --> 00:05:40,360 And he said well you know, what are you doing with continuous 104 00:05:40,360 --> 00:05:42,320 integration And we were feel like I don't know what 105 00:05:42,320 --> 00:05:43,880 continuous integration, what are you talking about? 106 00:05:44,120 --> 00:05:46,880 And he recommended the book, the sort of the key book on 107 00:05:46,880 --> 00:05:50,960 continuous integration, to us. And it really changed everything 108 00:05:50,960 --> 00:05:54,560 in terms of how I thought about not only like, wow, we need to 109 00:05:54,560 --> 00:06:00,040 do this, but also wow. I had no way of knowing this, 110 00:06:00,040 --> 00:06:02,280 like in the way I had been practicing. 111 00:06:02,720 --> 00:06:07,160 And so at that time I started asking how do I learn about new 112 00:06:07,160 --> 00:06:09,720 things? How do I go on my own continuing 113 00:06:09,720 --> 00:06:13,800 education journey? And that led me pretty quickly 114 00:06:13,800 --> 00:06:19,760 to a hypothesis of we continue to figure out what parts of 115 00:06:19,760 --> 00:06:24,520 building software are undifferentiated for us and we 116 00:06:24,520 --> 00:06:28,640 continue to be able to hand those to other companies and pay 117 00:06:28,640 --> 00:06:32,120 them and really pay them for use. 118 00:06:32,480 --> 00:06:37,480 Even in 2007, this was true. I mean 2007 we had S3 and was on 119 00:06:37,480 --> 00:06:41,440 S3 as a great, wonderful way to just store data that it would 120 00:06:41,440 --> 00:06:43,880 stay forever. It was very cheap, I mean 121 00:06:43,880 --> 00:06:45,840 relative to anything else at that point in time. 122 00:06:46,040 --> 00:06:49,680 And when EC2 came out the next year, we had a company that 123 00:06:49,680 --> 00:06:54,600 really needed not so much to dynamically scale, but we had a 124 00:06:54,600 --> 00:06:57,400 scheduling problem. We would get all this data in 125 00:06:57,400 --> 00:07:02,760 and need to process it and being able to like flex out to north 126 00:07:02,760 --> 00:07:05,880 number of virtual machines and then close them off when 127 00:07:05,880 --> 00:07:08,600 running, it was a perfect need that we had. 128 00:07:09,040 --> 00:07:12,240 Then Hadoop came out and we saw wow then this all of the stuff 129 00:07:12,240 --> 00:07:14,920 we were building ourselves we could actually like outsource 130 00:07:14,920 --> 00:07:18,720 that even a bit more elastic map produce was Amazon service at 131 00:07:18,720 --> 00:07:23,000 that point in time. And so I saw this trajectory of 132 00:07:23,280 --> 00:07:27,080 I can take these parts of these programs that we're making or 133 00:07:27,080 --> 00:07:30,760 the workloads that we're running and processing for our companies 134 00:07:31,160 --> 00:07:33,840 and we can hand them more and more off to people and we can 135 00:07:33,840 --> 00:07:36,560 break them into chunks. I mean from the beginning was 136 00:07:36,560 --> 00:07:40,440 let's break the application into pieces and then use services for 137 00:07:40,440 --> 00:07:44,240 the pieces. And so when Lambda came out, I 138 00:07:44,240 --> 00:07:49,760 think in 2014, it was just another progression to me of how 139 00:07:49,760 --> 00:07:52,960 do I break an application up and just not have to worry about 140 00:07:52,960 --> 00:07:55,760 running things. And I was already at that point 141 00:07:55,760 --> 00:07:59,880 in time I had started four companies and the amount of time 142 00:07:59,880 --> 00:08:04,000 and pain that we had to spend as a fairly small staff just 143 00:08:04,240 --> 00:08:07,600 keeping things up. I mean we used RDS early, but 144 00:08:07,600 --> 00:08:10,960 like we had cases where the volumes filled up and it took us 145 00:08:10,960 --> 00:08:16,000 down and so there was never a case where those services were 146 00:08:16,160 --> 00:08:20,240 fully like I can sort of just delegate the running of these. 147 00:08:20,480 --> 00:08:26,120 And so really feeling like I can delegate my uptime to a managed 148 00:08:26,120 --> 00:08:29,600 service it, you know, starting in 2014, 2015, I was like, this 149 00:08:29,600 --> 00:08:32,240 is it, this is perfect. But you know, interesting 150 00:08:32,240 --> 00:08:36,440 immediately what I saw was people, in my opinion, designing 151 00:08:36,440 --> 00:08:39,159 things poorly like looking at Lambda and saying, oh, we're 152 00:08:39,159 --> 00:08:41,159 gonna like put every function in a different Lambda, they're 153 00:08:41,159 --> 00:08:43,080 gonna call different lambdas. And we're gonna like take an 154 00:08:43,080 --> 00:08:46,240 application which is here and we're gonna like spread all that 155 00:08:46,240 --> 00:08:49,720 complexity out across like network latency calls to all 156 00:08:49,720 --> 00:08:53,120 these lambdas. And so I started talking. 157 00:08:53,120 --> 00:08:55,880 So I gave a talk at the first serverless conf I think it was 158 00:08:55,880 --> 00:09:01,480 in 2016, 2015, 2016 hosted by A Cloud Guru and started writing 159 00:09:01,480 --> 00:09:05,480 more and started arguing more about not only like this is how 160 00:09:05,480 --> 00:09:08,720 we should build in serverless, also building serverlessly on 161 00:09:08,720 --> 00:09:11,840 Firebase and even building applications like on Google 162 00:09:11,840 --> 00:09:15,040 Sheets and Google Apps Script. Really trying everything and 163 00:09:15,040 --> 00:09:18,840 interacting with a lot of skeptical developers who would 164 00:09:18,840 --> 00:09:22,560 say, oh, that's nice, you get to build toy applications that are 165 00:09:22,560 --> 00:09:25,440 very simple. The real developers don't use 166 00:09:25,440 --> 00:09:26,640 serverless. It doesn't work. 167 00:09:26,640 --> 00:09:30,040 It's too expensive. And so I started this insurance 168 00:09:30,040 --> 00:09:31,960 company. Branch is a full stack insurance 169 00:09:31,960 --> 00:09:33,920 company. We bear the risks. 170 00:09:34,160 --> 00:09:37,760 Sell home auto, renters, condo umbrella insurance. 171 00:09:37,960 --> 00:09:42,320 We're the fastest to be able to sell those bundles by orders of 172 00:09:42,320 --> 00:09:44,120 magnitude over any other carrier. 173 00:09:44,480 --> 00:09:46,600 And I was in all these conversations with people saying 174 00:09:46,600 --> 00:09:49,320 you only know how to build toys, Serverless is just a toy. 175 00:09:49,320 --> 00:09:53,360 And so I said OK, I think I need to address all of those 176 00:09:53,440 --> 00:09:57,760 complaints and skepticisms about building serverlessly and really 177 00:09:57,760 --> 00:10:01,080 write down now like no, we built a full stack in a financial 178 00:10:01,080 --> 00:10:03,800 services carrier that has lots of regulatory compliance 179 00:10:03,880 --> 00:10:06,640 requirements on it. We built it fairly serverlessly. 180 00:10:06,640 --> 00:10:08,480 There are no VMS or no containers. 181 00:10:08,480 --> 00:10:13,000 There's no Kubernetes anywhere. And so how do we think about it? 182 00:10:13,000 --> 00:10:15,520 How do we do it? And why does this actually work? 183 00:10:15,520 --> 00:10:18,480 Why is it not a toy? And so that has been the arc, 184 00:10:18,480 --> 00:10:22,960 but I feel like it's been this sort of constant attempt to take 185 00:10:22,960 --> 00:10:27,320 advantage of We get these new technologies and like they can 186 00:10:27,320 --> 00:10:30,000 really change how we develop software and make it cheaper, 187 00:10:30,000 --> 00:10:33,520 faster and better. And so that's been my focus and 188 00:10:33,520 --> 00:10:35,000 I'm happy to share it in this book. 189 00:10:35,160 --> 00:10:38,960 If you're very skeptical of it, this book is designed for you. 190 00:10:39,400 --> 00:10:42,560 It's not designed to say you believe in serverless. 191 00:10:42,880 --> 00:10:45,480 Here's how to do it. It's a book that's for the 192 00:10:45,480 --> 00:10:48,800 skeptics to help you understand how this actually works. 193 00:10:49,560 --> 00:10:51,680 Yeah, thanks for sharing your interesting story. 194 00:10:51,680 --> 00:10:54,040 So actually when I read the book in preparation of this 195 00:10:54,040 --> 00:10:57,600 conversation, I'm not a skeptic of serverless, but I get more 196 00:10:57,600 --> 00:11:01,080 intrigued by reading what you are trying to explain in your 197 00:11:01,080 --> 00:11:03,720 book, including Branch, right, which I'll probably will talk 198 00:11:03,720 --> 00:11:06,200 more about later. Like what makes Branch unique in 199 00:11:06,200 --> 00:11:09,040 terms of adoption of serverless? But what piqued my interest in 200 00:11:09,040 --> 00:11:11,480 the beginning when you said right, so technology keeps 201 00:11:11,480 --> 00:11:14,280 advancing every 18 months or so, right? 202 00:11:14,600 --> 00:11:17,240 And the gap, I think you mentioned in your book, the gap 203 00:11:17,240 --> 00:11:20,280 between the best software development teams and average 204 00:11:20,280 --> 00:11:22,600 software development teams is getting more enormous. 205 00:11:22,920 --> 00:11:24,840 I think it's related to all these advancement. 206 00:11:24,840 --> 00:11:27,520 Maybe if you can pick a little bit like why you think the gap 207 00:11:27,520 --> 00:11:29,760 is getting much bigger. Yeah. 208 00:11:29,760 --> 00:11:32,480 I mean, I think if you think about like, if there's like a 209 00:11:32,480 --> 00:11:36,400 huge change over 18 months, there's this compounding effect. 210 00:11:36,400 --> 00:11:40,640 And so startups that get to start today get to take 211 00:11:40,640 --> 00:11:42,680 advantage. There's no legacy, right? 212 00:11:42,680 --> 00:11:44,800 They're not relying on any existing technologies. 213 00:11:44,800 --> 00:11:48,960 So they can just use the absolute fastest, best way to 214 00:11:48,960 --> 00:11:52,080 build something today. And if you started a company 215 00:11:52,080 --> 00:11:56,240 like we did five years ago, you're already gonna be 216 00:11:56,240 --> 00:12:00,120 committed to some choices that if you were gonna rebuild it 217 00:12:00,120 --> 00:12:02,520 today, you would build it differently and it would be 218 00:12:02,520 --> 00:12:05,200 cheaper, faster and better, you know, if you had all the 219 00:12:05,200 --> 00:12:08,480 knowledge that you could have. And so we, you know, we look at 220 00:12:08,480 --> 00:12:11,960 that ourselves even. And so in the book, I give an 221 00:12:11,960 --> 00:12:16,720 example of Instagram, when it was acquired had 13 developers 222 00:12:16,960 --> 00:12:22,120 and doing about the same thing roughly Facebook had hundreds of 223 00:12:22,120 --> 00:12:24,160 developers. And then before that, you know 224 00:12:24,160 --> 00:12:26,960 Friendster and Myspace had over 1000 developers. 225 00:12:26,960 --> 00:12:29,520 And so there's. And actually Instagram had 13 226 00:12:29,520 --> 00:12:31,280 employees. I think they might have had like 227 00:12:31,280 --> 00:12:35,080 5 or 6 developers. And if anyone has gone through 228 00:12:35,080 --> 00:12:38,400 the process of like how much can one developer do and then how 229 00:12:38,400 --> 00:12:42,680 much can 4 developers do, There are these step points where you 230 00:12:42,680 --> 00:12:46,120 lose massive efficiency per developer. 231 00:12:46,120 --> 00:12:48,960 I mean, I tend to think of it as kind of like 1 developer, 4 232 00:12:48,960 --> 00:12:53,080 developer, 12 developer, 25 developers, 50 developers, 100 233 00:12:53,080 --> 00:12:55,240 developers. And once you're at 100 234 00:12:55,240 --> 00:12:59,200 developers, there's like a core inefficiency that's in the whole 235 00:12:59,200 --> 00:13:01,560 operation. You know, you're getting an 236 00:13:01,560 --> 00:13:04,400 order of magnitude less productivity than if you have a 237 00:13:04,400 --> 00:13:06,680 solo developer. Now, you can't run everything on 238 00:13:06,680 --> 00:13:09,160 a solo developer. It's not a sustainable thing for 239 00:13:09,160 --> 00:13:11,480 a company. But there's also a reason why 240 00:13:11,480 --> 00:13:14,440 Amazon has these like 2 pizza teams and trying to keep these 241 00:13:14,440 --> 00:13:17,080 services small. It's the only way to keep really 242 00:13:17,080 --> 00:13:19,840 good quality and velocity together. 243 00:13:20,320 --> 00:13:24,480 And so when I say that the top teams are orders of magnitude 244 00:13:24,480 --> 00:13:28,200 better than the average teams, it's largely that the top teams 245 00:13:28,320 --> 00:13:33,920 are leveraging technology so much better than the average 246 00:13:33,920 --> 00:13:35,880 teams that they're just not bogged down. 247 00:13:35,880 --> 00:13:39,680 And I feel that very much at Branch, the company that I was 248 00:13:39,840 --> 00:13:44,640 working on 10 years ago built fax which was fully in the cloud 249 00:13:44,640 --> 00:13:48,880 infrastructure as code, but like running on VMSI mean it's still 250 00:13:48,880 --> 00:13:51,360 probably is. You know, in Amazon load 251 00:13:51,360 --> 00:13:54,360 balancing, we were using right scale at the time to do some of 252 00:13:54,360 --> 00:13:57,520 the orchestration. There was a core inefficiency 253 00:13:57,520 --> 00:14:00,320 that we had in running and a core inefficiency that we had in 254 00:14:00,320 --> 00:14:02,480 building new features. That branch doesn't have 255 00:14:02,520 --> 00:14:05,720 branches, just faster. And so the average developer at 256 00:14:05,720 --> 00:14:09,960 branch is just producing more for Branch and at a higher code 257 00:14:09,960 --> 00:14:12,880 quality than the average developer was at build facts. 258 00:14:13,680 --> 00:14:16,120 Yeah, it's quite astounding when you mentioned about this. 259 00:14:16,120 --> 00:14:19,320 Instagram only have maybe 13 employees or five developers in 260 00:14:19,320 --> 00:14:21,600 total, right? But can build a world kind of 261 00:14:21,600 --> 00:14:24,320 scale, you know, like with users from all around the world. 262 00:14:24,680 --> 00:14:26,800 And I think what you say is right. 263 00:14:26,960 --> 00:14:29,440 So for people like me who has been around in industry for 264 00:14:29,440 --> 00:14:32,160 quite some time as well, right. I mean the reason, yes, you can 265 00:14:32,160 --> 00:14:34,760 actually see that, oh, there are so many technologies that I'm 266 00:14:34,760 --> 00:14:37,160 not even aware of. But actually it's really cool to 267 00:14:37,360 --> 00:14:39,880 probably prototype new applications, right, building 268 00:14:39,880 --> 00:14:42,680 something from scratch and even like for example, you mentioned. 269 00:14:42,680 --> 00:14:45,840 So you can actually build something like only Google or 270 00:14:45,840 --> 00:14:49,120 Amazon can do last time, right? And now you can actually tap 271 00:14:49,120 --> 00:14:51,800 into those technologies to build similar things like them. 272 00:14:52,360 --> 00:14:56,120 And I think what you mentioned as well, right, If the developer 273 00:14:56,120 --> 00:14:58,960 can produce more, that means they're focusing a lot more on 274 00:14:59,240 --> 00:15:02,000 the right thing, right, which you mentioned as differentiated 275 00:15:02,000 --> 00:15:05,240 versus undifferentiated things. I think this concept is very 276 00:15:05,240 --> 00:15:08,160 important for you to actually adopt as technology leader or 277 00:15:08,160 --> 00:15:11,600 technologist in general, right. So tell us more about this 278 00:15:11,600 --> 00:15:13,480 differentiated versus undifferentiated? 279 00:15:14,280 --> 00:15:16,120 Yeah. I think you always want to look 280 00:15:16,120 --> 00:15:19,000 at what does your business need to do differently or your 281 00:15:19,000 --> 00:15:21,320 organization need to do differently than other 282 00:15:21,320 --> 00:15:24,080 organizations. And what are things that it's 283 00:15:24,080 --> 00:15:28,360 fine for your company or organization to do as well as 284 00:15:28,800 --> 00:15:31,520 other companies do, like the best other companies doing it. 285 00:15:31,800 --> 00:15:35,880 And so let me give 2 examples that are both undifferentiated, 286 00:15:35,880 --> 00:15:39,760 but that will generally, in my experience, get very different 287 00:15:39,760 --> 00:15:42,600 reactions from lead developers. So let's start with the simple 288 00:15:42,600 --> 00:15:44,080 one where I think we'll all agree. 289 00:15:44,400 --> 00:15:48,480 So if I talk about sending text messages, sending text messages 290 00:15:48,480 --> 00:15:51,800 is undifferentiated. You don't care if you send text 291 00:15:51,800 --> 00:15:55,040 messages as well as the best other company sends text 292 00:15:55,040 --> 00:15:56,320 messages. Now, by the way, there's 293 00:15:56,320 --> 00:15:58,760 probably some listeners who are going then no, if you don't 294 00:15:58,760 --> 00:16:01,560 register your 10 DLP campaigns, you know, you'll get the 295 00:16:01,560 --> 00:16:02,880 messages rejected. Yeah, yeah, yeah. 296 00:16:02,880 --> 00:16:07,440 But if you do it as well as the top people, you're fine, right? 297 00:16:07,440 --> 00:16:10,920 If you can send text messages as well as you know a quality 298 00:16:11,120 --> 00:16:13,640 things, you will be registering 10 DLP campaigns. 299 00:16:13,880 --> 00:16:17,400 You know you'll have your short codes and you'll use Twilio or 300 00:16:17,400 --> 00:16:20,000 something like Twilio. But Twilio is a great product. 301 00:16:20,280 --> 00:16:22,520 I know it's a little expensive for what it is, but it's a great 302 00:16:22,520 --> 00:16:26,240 product and so I don't run into a lot of lead developers who 303 00:16:26,240 --> 00:16:28,960 will tell me no. I need to buy, you know, 304 00:16:28,960 --> 00:16:32,760 separate boxes and hook up phone lines and have telephony cards 305 00:16:32,760 --> 00:16:34,240 and like run them in a data center. 306 00:16:34,240 --> 00:16:37,320 I don't find that although I did that in 2005. 307 00:16:37,320 --> 00:16:40,720 I ran IV Rs that way so I remember that it was awful. 308 00:16:40,720 --> 00:16:43,680 I would never do that. And so I think everybody agrees 309 00:16:43,680 --> 00:16:47,080 that sending SMS is undifferentiated heavy lifting 310 00:16:47,080 --> 00:16:49,880 and you should use a service like Twilio to do it right? 311 00:16:50,160 --> 00:16:53,600 And in fact, you should probably use a service like Braze or 312 00:16:53,600 --> 00:16:58,200 Iterable or Customer IO to like actually trigger those, cause 313 00:16:58,200 --> 00:17:00,960 those help make it even easier and you can do templating and 314 00:17:00,960 --> 00:17:02,480 have people do that. And if you don't know these 315 00:17:02,480 --> 00:17:04,440 services, you should look at them up because they'll make 316 00:17:04,440 --> 00:17:06,480 your life easier. And the back of my book actually 317 00:17:06,480 --> 00:17:08,880 has a whole appendix on you should know all these services 318 00:17:08,880 --> 00:17:11,000 'cause they're very useful. Now let me get to a 319 00:17:11,000 --> 00:17:13,359 controversial example and I don't know why this is. 320 00:17:13,480 --> 00:17:15,240 I mean, I know sort of why it's controversial. 321 00:17:15,520 --> 00:17:21,280 Most lead developers want to run Elastic Search or like Amazon 322 00:17:21,280 --> 00:17:23,839 Open Search themselves as their search index. 323 00:17:24,319 --> 00:17:28,240 When there is a service called Algolia, they will do all of the 324 00:17:28,240 --> 00:17:31,760 painful stuff for you. I will tell you that running 325 00:17:32,160 --> 00:17:35,120 search index that's performing is undifferentiated. 326 00:17:35,200 --> 00:17:38,680 You do not need to do it better than anybody else. 327 00:17:38,680 --> 00:17:41,800 I mean, unless you're competing with Algolia as a business and 328 00:17:41,800 --> 00:17:44,560 so you can outsource a lot more to Algolia. 329 00:17:44,600 --> 00:17:47,040 It works phenomenally. It's really fast. 330 00:17:47,360 --> 00:17:50,800 Elastic search, open search, they're very finicky services. 331 00:17:50,960 --> 00:17:53,400 You'll have to be responsible for their up time. 332 00:17:53,680 --> 00:17:55,920 Indexing to them is kind of a pain in the butt. 333 00:17:56,280 --> 00:17:59,440 Generally speaking, front ends can't talk directly to them 334 00:17:59,440 --> 00:18:01,560 because the security model is too poor. 335 00:18:01,640 --> 00:18:04,280 So you'll have to build a proxy. You'll have to query through 336 00:18:04,320 --> 00:18:06,520 your back end. It'll slow it down. 337 00:18:06,760 --> 00:18:09,680 It adds more development. But most lead developers will 338 00:18:09,680 --> 00:18:12,720 say, wow, I looked at the pricing for Algolia. 339 00:18:12,720 --> 00:18:15,880 It's really expensive and I'm not quite sure, oh wait, how do 340 00:18:15,880 --> 00:18:18,840 I do it in a dev environment and the right way to save costs? 341 00:18:18,840 --> 00:18:21,080 And no, no, no, it's just safer. I'll run it myself. 342 00:18:21,080 --> 00:18:23,160 I know how that works. We'll run these things, we know 343 00:18:23,160 --> 00:18:26,080 how to run. But like that is classically 344 00:18:26,080 --> 00:18:29,600 undifferentiated heavy lifting. Everything you're choosing to do 345 00:18:29,600 --> 00:18:33,400 there to run open search or elastic search when Algolia 346 00:18:33,400 --> 00:18:39,040 exists is undifferentiated. And if you take an actual cost 347 00:18:39,040 --> 00:18:43,200 of ownership view, like the time that it costs and the people 348 00:18:43,200 --> 00:18:46,520 that are needed internally to run that thing, Al Golia is much 349 00:18:46,520 --> 00:18:50,400 cheaper, just period. But most developers will make 350 00:18:50,400 --> 00:18:53,520 the choice on behalf of their organization to in house this 351 00:18:53,520 --> 00:18:57,640 undifferentiated heavy lifting with something like open search 352 00:18:57,640 --> 00:19:02,160 or elastic search because of honestly this misplaced stance 353 00:19:02,240 --> 00:19:03,720 of how they should be optimizing. 354 00:19:03,720 --> 00:19:05,680 And so that's my favorite example for this 355 00:19:05,680 --> 00:19:09,880 undifferentiated heavy lifting. If you can outsource it, if it's 356 00:19:09,880 --> 00:19:12,880 not something that makes you different, you should use a 357 00:19:12,880 --> 00:19:17,800 service because you will always be asked to do more things that 358 00:19:17,800 --> 00:19:21,560 you can build as a developer that are differentiated, that 359 00:19:21,560 --> 00:19:24,080 are like special to your organization. 360 00:19:24,240 --> 00:19:26,120 So don't add in things that aren't. 361 00:19:27,000 --> 00:19:28,560 Yeah, I like their last line, right. 362 00:19:28,560 --> 00:19:31,920 So you are always being asked to do more things that bring 363 00:19:31,920 --> 00:19:33,960 differentiators to the business, right? 364 00:19:34,240 --> 00:19:36,720 So I think not just Elastic search or such kind of a 365 00:19:36,720 --> 00:19:40,320 technology, people these days run their own logging, you know, 366 00:19:40,320 --> 00:19:43,520 messaging bus, maybe even containers, right on Kubernetes 367 00:19:43,520 --> 00:19:46,000 and all that. So I think that takes a lot of 368 00:19:46,000 --> 00:19:49,600 engineers hours and also effort and not to mention like if you 369 00:19:49,600 --> 00:19:52,720 want to make it production scale with high availability, right, 370 00:19:52,720 --> 00:19:55,400 that takes even much more effort and actually cost. 371 00:19:55,400 --> 00:19:56,800 Yeah, right. Yep. 372 00:19:57,120 --> 00:19:59,440 Yeah. So speaking about cost, right, I 373 00:19:59,440 --> 00:20:02,360 think this is probably where the, I don't know, misconception 374 00:20:02,360 --> 00:20:05,760 or miscalculation, so to speak, right, like why people are still 375 00:20:05,760 --> 00:20:07,840 opting for managing things themselves. 376 00:20:08,040 --> 00:20:10,200 They think, oh, it's open source, I can also run it 377 00:20:10,200 --> 00:20:13,360 myself, you know, maybe build POC, it works pretty simple, 378 00:20:13,360 --> 00:20:15,000 right? And they just start from there. 379 00:20:15,200 --> 00:20:18,840 But I think the most important challenge is to understand the 380 00:20:18,840 --> 00:20:20,480 real cost, right. In your book, you have some 381 00:20:20,480 --> 00:20:23,200 breakdown of cost. Maybe from your advice, how 382 00:20:23,200 --> 00:20:26,360 would you tell us to look at cost differently so that we can 383 00:20:26,360 --> 00:20:28,640 actually see? The differentiated versus 384 00:20:28,680 --> 00:20:32,480 undifferentiated. I mean, I think that you really 385 00:20:32,480 --> 00:20:37,960 need to internally understand how much it costs for you to 386 00:20:37,960 --> 00:20:41,560 develop and run things yourself in terms of your people costs. 387 00:20:42,080 --> 00:20:45,400 And I think you also need to understand and in terms of your 388 00:20:45,440 --> 00:20:50,640 velocity costs. So in general, the more teams 389 00:20:50,640 --> 00:20:54,400 that you have in your company that are required to get code 390 00:20:54,400 --> 00:20:56,920 live, the more inefficient you are. 391 00:20:56,920 --> 00:21:00,440 And it's a compounding effect. In my book and everywhere I 392 00:21:00,440 --> 00:21:03,840 talk, I recommend people read Accelerate and use the Dora 393 00:21:03,840 --> 00:21:06,760 metrics. We use Linear B at Branch as a 394 00:21:06,760 --> 00:21:08,640 way of monitoring the Dora metrics. 395 00:21:08,960 --> 00:21:15,080 The cycle time is critical. And so you know, what I see is 396 00:21:15,080 --> 00:21:19,520 that the more undifferentiated work you do, the longer your 397 00:21:19,520 --> 00:21:23,520 cycle time and especially when the undifferentiated work is 398 00:21:23,520 --> 00:21:27,600 running the things. And so when you use a service 399 00:21:27,600 --> 00:21:31,360 like Algolia versus you are running, you know, your own 400 00:21:31,680 --> 00:21:34,160 Amazon Opensearch or you're running elastic search on 401 00:21:34,160 --> 00:21:37,200 containers and you're building a proxy service in there, those 402 00:21:37,200 --> 00:21:40,480 are orders of magnitude different impact on cycle time 403 00:21:40,480 --> 00:21:43,920 when you release changes to how things go to the index. 404 00:21:44,240 --> 00:21:46,600 And I think if you're honest with yourself, both about the 405 00:21:46,640 --> 00:21:51,120 actual cost of people and about the impact on something like 406 00:21:51,120 --> 00:21:54,280 cycle time or the other dorometrics, it gets really 407 00:21:54,280 --> 00:21:57,840 clear that you just don't want to run. 408 00:21:58,120 --> 00:22:01,440 I mean, ideally use managed services or, you know, don't 409 00:22:01,440 --> 00:22:04,760 write code, use managed services always gives you better 410 00:22:05,000 --> 00:22:07,040 outcomes. Here now always does have an 411 00:22:07,040 --> 00:22:09,400 asterisk. I mean, there are services that 412 00:22:09,400 --> 00:22:13,120 are very expensive, that don't make sense for you to use. 413 00:22:13,120 --> 00:22:16,160 So like, Algolia isn't the solution for everyone all the 414 00:22:16,160 --> 00:22:19,320 time because, you know, if you have an index where you're 415 00:22:19,320 --> 00:22:23,360 searching, you know, billions of records, probably Algolia is not 416 00:22:23,360 --> 00:22:26,080 reasonable. But the way I generally think of 417 00:22:26,080 --> 00:22:30,240 this is there's like 9095% of the time we're all kind of 418 00:22:30,240 --> 00:22:32,760 building the same apps. They don't have like enormous 419 00:22:32,760 --> 00:22:35,280 traffic. By enormous traffic, I mean they 420 00:22:35,280 --> 00:22:38,960 don't have so much traffic that your data transfer costs are 421 00:22:38,960 --> 00:22:40,800 like the biggest part of your bill. 422 00:22:41,160 --> 00:22:43,680 Generally speaking. You know, none of us have more 423 00:22:43,680 --> 00:22:46,920 than, I don't know, 1000 simultaneous users. 424 00:22:46,920 --> 00:22:48,920 I mean, generally speaking, most applications don't have more 425 00:22:48,920 --> 00:22:52,240 than like 15 simultaneous users, truly simultaneous. 426 00:22:52,240 --> 00:22:55,720 But you know, 1000 simultaneous users, most of our database 427 00:22:55,720 --> 00:23:00,840 tables at most are sort of in the 10s of millions at most. 428 00:23:00,880 --> 00:23:02,720 You know, there's a way to set that up. 429 00:23:02,920 --> 00:23:07,320 And so there's sort of a standard 9095% of the time. 430 00:23:07,320 --> 00:23:12,680 And yet most or many lead developers I find always want in 431 00:23:12,680 --> 00:23:16,040 their head to be designing for like huge amount of data 432 00:23:16,040 --> 00:23:19,760 transfer like you know millions of like that's the model of 433 00:23:19,760 --> 00:23:21,840 aspirations like built this like take. 434 00:23:22,520 --> 00:23:24,600 But the problem is like those just need to sit. 435 00:23:24,600 --> 00:23:28,680 Those are all exceptions. And most of the time, actually 436 00:23:28,680 --> 00:23:31,600 looking at Dora metrics, actually looking at cost, you'll 437 00:23:31,600 --> 00:23:35,360 find that managed services that are used by everyone at Twilio 438 00:23:35,360 --> 00:23:38,360 and Algolia, Cloudnary, whatever, are just going to be 439 00:23:38,360 --> 00:23:41,520 any sort of honest and fair comparison of actually taking 440 00:23:41,520 --> 00:23:46,000 into account the cost. And I'm always shocked at how 441 00:23:46,000 --> 00:23:49,200 many people just don't want to even think about how much 442 00:23:49,200 --> 00:23:51,360 developers cost. They want to view them as like 443 00:23:51,360 --> 00:23:54,440 developers are free, and so if you're a lead developer, you 444 00:23:54,440 --> 00:23:57,680 don't know how much your development team costs and 445 00:23:57,680 --> 00:24:00,720 you're making decisions based upon this is more expensive than 446 00:24:00,720 --> 00:24:02,280 that. Like you need to find out how 447 00:24:02,280 --> 00:24:05,400 much the team costs. I mean, like if you don't know, 448 00:24:05,400 --> 00:24:08,160 you obviously can't leave making good decisions on what actually 449 00:24:08,160 --> 00:24:10,800 costs too much or too well. Yeah. 450 00:24:11,000 --> 00:24:13,960 So I think speaking from my experience, what I can see in my 451 00:24:13,960 --> 00:24:17,000 area, right, industry start-ups, a lot of people, especially 452 00:24:17,000 --> 00:24:19,880 during the tough time recently, right, the winter time some 453 00:24:19,880 --> 00:24:22,000 people call it right. So they just look at the bill, 454 00:24:22,000 --> 00:24:23,920 they will see for example all these managed service or 455 00:24:23,920 --> 00:24:27,240 serverless, it costs a lot. The easiest one to reduce is 456 00:24:27,240 --> 00:24:29,160 actually you know those Bill, right. 457 00:24:29,480 --> 00:24:31,800 And since we have already a number of people, right. 458 00:24:32,080 --> 00:24:34,760 OK, maybe let's just switch that to something that we can manage 459 00:24:34,760 --> 00:24:36,560 ourselves. But what you're saying is true, 460 00:24:36,560 --> 00:24:37,800 right? So at the end of the day, the 461 00:24:37,920 --> 00:24:40,440 cost of the people needs to be calculated equally, right? 462 00:24:40,440 --> 00:24:43,600 So you cannot just say I reduced the managed service bill, but 463 00:24:43,600 --> 00:24:46,960 actually that cost is translated to your engineer hours, right. 464 00:24:47,200 --> 00:24:49,560 And also probably headache whenever there's an incident or 465 00:24:49,560 --> 00:24:52,640 trying to scale things, right, the on call thing will create 466 00:24:52,640 --> 00:24:55,640 some kind of a cultural issue within the team as well, right? 467 00:24:55,640 --> 00:24:58,200 So the harmony might not be as good as before. 468 00:24:58,760 --> 00:25:02,200 And speaking about this managed bills, sometimes I find as well 469 00:25:02,240 --> 00:25:06,160 the bill is so high because it's unoptimized, the usage is 470 00:25:06,160 --> 00:25:09,240 unoptimized. So maybe also you can think of 471 00:25:09,240 --> 00:25:12,400 just optimizing rather than switching gear to managing 472 00:25:12,400 --> 00:25:14,480 yourself. So I think that's my experience 473 00:25:14,480 --> 00:25:16,720 as well. We have these built in moments, 474 00:25:16,720 --> 00:25:19,760 right, where every quarter or so we take a look at all the bills 475 00:25:19,760 --> 00:25:23,320 that are more than $50,000 a year or $30,000 a year and we 476 00:25:23,320 --> 00:25:25,600 just go ask you know, what can we do to get them down. 477 00:25:25,800 --> 00:25:28,320 We move services a lot. And one of the benefits of 478 00:25:28,320 --> 00:25:31,440 Serverless is because you have this really nice container, 479 00:25:31,440 --> 00:25:33,960 right? I'm using this service, it's got 480 00:25:33,960 --> 00:25:36,800 a well documented APII know what I'm using in it. 481 00:25:36,800 --> 00:25:40,120 It's all isolated over here. It actually turns out to be much 482 00:25:40,120 --> 00:25:43,840 easier to switch them and move them out than it is if you build 483 00:25:43,840 --> 00:25:46,320 it internally. So we're on our like 4th 484 00:25:46,320 --> 00:25:51,160 referral management service and we used airplane dot dev as an 485 00:25:51,160 --> 00:25:54,360 automation tool and they shut down with 60 days notice. 486 00:25:54,360 --> 00:25:57,400 I think today is the last day they're running and we actually 487 00:25:57,400 --> 00:26:00,840 decided to in house what we had put there. 488 00:26:00,960 --> 00:26:03,800 But it was so much easier to do it because we could just copy 489 00:26:03,800 --> 00:26:07,320 their API and so we were able to take all this stuff we'd written 490 00:26:07,320 --> 00:26:10,520 for airplane and port it over. You know, I mean, I don't want 491 00:26:10,520 --> 00:26:12,920 to understate the developers who've been working on that have 492 00:26:12,920 --> 00:26:15,920 like been working very hard and like week nights and weekends to 493 00:26:15,920 --> 00:26:18,720 like get that done. But to think that we took a 494 00:26:18,720 --> 00:26:22,440 service that we were spending like $60,000 a year on and we 495 00:26:22,440 --> 00:26:26,760 were able to rebuild parts of it like a little Shim 496 00:26:26,760 --> 00:26:30,200 infrastructure for what we were using of it in about in less 497 00:26:30,200 --> 00:26:33,520 than 60 days. Probably more like 35 days was a 498 00:26:33,520 --> 00:26:36,800 result of having used that service, was a result of having 499 00:26:36,800 --> 00:26:40,240 this serverless mindset and of being able to say, OK, now we 500 00:26:40,240 --> 00:26:44,240 understand the problem so well and we isolated it so well that 501 00:26:44,240 --> 00:26:47,040 actually rebuilding it or understanding how to shift it 502 00:26:47,040 --> 00:26:49,240 somewhere else ended up being much easier. 503 00:26:49,520 --> 00:26:54,600 And so I love being in an environment where everything is 504 00:26:54,600 --> 00:26:57,160 kind of contained and small. There's good separation of 505 00:26:57,160 --> 00:27:00,080 concerns, and the best way to do that isn't micro services. 506 00:27:00,080 --> 00:27:02,680 The best way to do that is to use a lot of managed services 507 00:27:02,880 --> 00:27:05,920 because they've already built all those great APIs for you. 508 00:27:06,120 --> 00:27:09,400 And then if, look, the case of it's too expensive or I'm locked 509 00:27:09,400 --> 00:27:11,960 in is you just build it, then. I mean, that thing that's so 510 00:27:11,960 --> 00:27:14,880 wild to me is people saying like serverless is about locking, 511 00:27:14,880 --> 00:27:17,240 It's terrible. It's actually like a very cheap 512 00:27:17,240 --> 00:27:19,440 way to like learn how to build something and then if you're 513 00:27:19,440 --> 00:27:21,760 gonna build it yourself, just copy the parts of it that you 514 00:27:21,760 --> 00:27:23,800 like. It's actually much faster. 515 00:27:24,680 --> 00:27:26,120 Yeah, interesting insights, right. 516 00:27:26,120 --> 00:27:29,240 So I think many people are, I mean do afraid about the lock in 517 00:27:29,240 --> 00:27:31,000 and all that. But I think, hey, if you can get 518 00:27:31,000 --> 00:27:34,840 started very easily and you can use all the power of the people 519 00:27:34,840 --> 00:27:38,600 operating those services, right. So they are very well expert in 520 00:27:38,600 --> 00:27:41,320 running those services, right. You can actually just use that 521 00:27:41,480 --> 00:27:44,320 because, yeah, it will make you start really, really easily. 522 00:27:44,600 --> 00:27:48,000 And I think you mentioned earlier that if you have a 523 00:27:48,000 --> 00:27:51,680 choice of writing code versus picking up managed service, you 524 00:27:51,680 --> 00:27:53,600 should always choose, you know, managed service. 525 00:27:53,960 --> 00:27:56,120 And in your book you mentioned this thing called code is a 526 00:27:56,120 --> 00:27:58,520 liability. So I think some people think 527 00:27:58,520 --> 00:28:01,080 code is asset, right. Some people think code is the 528 00:28:01,080 --> 00:28:02,640 most important thing in your company. 529 00:28:02,800 --> 00:28:04,480 So tell us why code is a liability. 530 00:28:05,040 --> 00:28:08,840 Yeah, I mean code is something you have to maintain and so this 531 00:28:08,880 --> 00:28:11,280 idea doesn't come from me. And so in the book, there are 532 00:28:11,280 --> 00:28:14,200 some good links here. But you should think about 533 00:28:14,280 --> 00:28:17,920 anything that I write is something there that's necessary 534 00:28:17,920 --> 00:28:20,520 for my organization to work properly. 535 00:28:20,720 --> 00:28:23,880 Then I have to make sure has proper testing, like doesn't 536 00:28:23,880 --> 00:28:26,960 regress, keeps working, and so I have to maintain all of that. 537 00:28:26,960 --> 00:28:29,440 That's a liability. You know, the asset is the 538 00:28:29,440 --> 00:28:33,840 experience you're building. And so if I can build something 539 00:28:33,840 --> 00:28:37,320 with 10 lines of code, or I can build it with 1000 lines of 540 00:28:37,320 --> 00:28:40,880 code, I'm gonna be much happier in the long run with the 10 541 00:28:40,880 --> 00:28:42,760 lines of code. It'll be easier to maintain, 542 00:28:43,040 --> 00:28:44,920 it'll have less bugs, it'll be easier to test. 543 00:28:44,920 --> 00:28:46,800 All of those things will be much better. 544 00:28:47,120 --> 00:28:49,200 And so the less code, the better. 545 00:28:49,560 --> 00:28:53,000 At Branch, we have a kind of a waterfall process where when 546 00:28:53,000 --> 00:28:56,080 somebody says, hey, can we build this thing and will you build 547 00:28:56,080 --> 00:28:58,080 this thing? Our first question is actually, 548 00:28:58,080 --> 00:28:59,600 do we need to build anything at all? 549 00:28:59,840 --> 00:29:03,200 And so we do a lot of why don't you use this software as a 550 00:29:03,200 --> 00:29:05,840 service instead? And if we need to make some sort 551 00:29:05,840 --> 00:29:09,120 of integration, we'll do that. But like, let's just just go buy 552 00:29:09,120 --> 00:29:11,920 a software as a service. That's step one. 553 00:29:12,280 --> 00:29:14,960 Step 2 is kind of can we like down scope it? 554 00:29:15,080 --> 00:29:17,480 Because if you buy a software as a service like you get all those 555 00:29:17,480 --> 00:29:20,240 features, those are great. If that won't work, how do we 556 00:29:20,240 --> 00:29:23,480 like take out what you're asking for and make it really small? 557 00:29:23,760 --> 00:29:26,960 One of the things that I've found over my career, what 558 00:29:26,960 --> 00:29:29,160 generally happens in organizations is people say I 559 00:29:29,160 --> 00:29:33,520 want this thing and they usually make it really big because they 560 00:29:33,520 --> 00:29:36,880 know that you're gonna go develop it and as soon as you 561 00:29:36,880 --> 00:29:39,840 put it live, you can't work on it again for a really long 562 00:29:39,840 --> 00:29:41,840 period of time. And so they're gonna pack 563 00:29:41,920 --> 00:29:44,920 everything they can into it because that's the only way they 564 00:29:44,920 --> 00:29:48,040 know how to get. If you reorganize and this is 565 00:29:48,040 --> 00:29:51,400 very much in line with the Dora metrics and the Agile Manifesto, 566 00:29:51,720 --> 00:29:55,160 if you say, look, two things, one, I'm gonna make you down 567 00:29:55,160 --> 00:29:59,280 scope this thing to Tiny. But two, I promise we'll keep 568 00:29:59,280 --> 00:30:02,240 working on it immediately. Like we won't stop working on 569 00:30:02,240 --> 00:30:04,000 it. It's not a limited time window. 570 00:30:04,000 --> 00:30:06,520 Then we work on other projects for a year, keep working on it 571 00:30:06,520 --> 00:30:08,600 as soon as it gets released. It's got to be really small. 572 00:30:09,160 --> 00:30:12,240 Then you get all this benefit of the feedback in the cycle. 573 00:30:12,240 --> 00:30:16,000 So you just squash down what people want to like very tiny, 574 00:30:16,200 --> 00:30:19,240 like just helping them a little bit, and then you get it live 575 00:30:19,240 --> 00:30:21,000 and then they can see it, and then they can make that next 576 00:30:21,000 --> 00:30:22,920 request. If you train an organization 577 00:30:22,920 --> 00:30:24,880 that way. And it's easier as a founder 578 00:30:25,200 --> 00:30:27,520 than as someone who's inside an organization with other 579 00:30:27,520 --> 00:30:29,960 founders. But I can tell you, you can 580 00:30:29,960 --> 00:30:33,600 train an entire organization to think this way, and as long as 581 00:30:33,600 --> 00:30:37,560 you deliver on, we will make updates, you come to us, we'll 582 00:30:37,560 --> 00:30:40,520 go get other small updates in as quickly as possible. 583 00:30:40,800 --> 00:30:43,280 Everything gets more efficient because, you know when you build 584 00:30:43,280 --> 00:30:46,360 these big projects, like they're poorly designed, you put them 585 00:30:46,360 --> 00:30:48,720 live, they don't work right. We realize like, oh, that was a 586 00:30:48,720 --> 00:30:50,320 bad idea. That's a bad interface. 587 00:30:50,320 --> 00:30:53,240 People don't understand it, like, just build it small and 588 00:30:53,240 --> 00:30:54,640 watch what happens and iterate on it. 589 00:30:54,880 --> 00:30:59,040 So we have this whole process of buy SAS downscope, use a managed 590 00:30:59,040 --> 00:31:02,440 service, use open source, everything we can to not write 591 00:31:02,440 --> 00:31:05,560 custom code or to write as little custom code as possible. 592 00:31:06,480 --> 00:31:08,840 Yeah, I think it's a good principle thought process for 593 00:31:08,840 --> 00:31:11,240 anyone who listen, right. So code is a liability. 594 00:31:11,240 --> 00:31:13,800 It's a reminder again. So if you think writing a lot 595 00:31:13,800 --> 00:31:16,720 more code and infrastructure code or configuration also 596 00:31:16,720 --> 00:31:19,440 counts as code, right? So you do remind yourself. 597 00:31:19,960 --> 00:31:22,520 It does although and we don't have a ton of it. 598 00:31:22,520 --> 00:31:26,080 But I do think that, and this may be an unpopular opinion, but 599 00:31:26,080 --> 00:31:30,880 I do find that domain specific languages for infrastructure 600 00:31:30,880 --> 00:31:34,400 like YAML and like cloud formation I do in my head put 601 00:31:34,400 --> 00:31:37,480 that in a different category. And for this reason, my 602 00:31:37,480 --> 00:31:42,280 experience is when we write cloud formation YAML and we get 603 00:31:42,280 --> 00:31:47,560 it right, we never change it and so the maintenance cost of cloud 604 00:31:47,560 --> 00:31:52,000 formation YAML is very low. And so I I don't really worry 605 00:31:52,000 --> 00:31:55,960 about having a lot of that. In contrast, something like 606 00:31:55,960 --> 00:32:00,080 Pulumi or CDK, that's like code. I find it gets a lot edits, 607 00:32:00,080 --> 00:32:02,560 people keep updating it, it's got a lot of maintenance and so 608 00:32:02,560 --> 00:32:05,120 it has a different profile to me. 609 00:32:05,360 --> 00:32:09,000 And so I would view CDK infrastructure, Pulumi 610 00:32:09,000 --> 00:32:12,840 infrastructure as code, as this code that you want to minimize. 611 00:32:13,120 --> 00:32:17,120 I actually think of YAML as more like a YARN lock file or 612 00:32:17,120 --> 00:32:19,920 something like that, Like it can get really big, but it's not a 613 00:32:19,920 --> 00:32:22,920 maintenance headache. So I actually don't find lots of 614 00:32:22,920 --> 00:32:26,920 YAML to have the same liability problem, because generally 615 00:32:26,920 --> 00:32:29,000 speaking you get it up and it works and you don't cheat. 616 00:32:29,800 --> 00:32:32,000 Interesting. So speaking about serverless, 617 00:32:32,000 --> 00:32:34,480 right, I think we have talked a lot about serverless, but I 618 00:32:34,480 --> 00:32:36,840 think it's appropriate to get the definition right. 619 00:32:36,840 --> 00:32:40,080 Some people think serverless is, you know, Lambda. 620 00:32:40,160 --> 00:32:42,200 Some people think it's a function as a service. 621 00:32:42,520 --> 00:32:44,640 So in your view, right? What is your definition of 622 00:32:44,640 --> 00:32:46,600 serverless? Because I think from your book 623 00:32:46,880 --> 00:32:49,480 it encompasses more than just a function as a service. 624 00:32:50,280 --> 00:32:53,560 Yes, and I give I think like 4 definitions in my book of it. 625 00:32:53,560 --> 00:32:56,960 My favorite definition of serverless is it's not my up 626 00:32:56,960 --> 00:33:02,560 time and so it's functionally about not having to run that. 627 00:33:02,560 --> 00:33:04,880 If it goes down and it's my fault, it has to be like I 628 00:33:04,880 --> 00:33:08,240 misconfigured it or I wrote bad code, but otherwise I don't 629 00:33:08,240 --> 00:33:11,400 control the up time. But Ben Keogh also has, you 630 00:33:11,400 --> 00:33:14,840 know, Ben Keogh's definition here is I'm only doing 631 00:33:14,840 --> 00:33:17,160 differentiated coding, right? Everything that's 632 00:33:17,160 --> 00:33:20,000 undifferentiated, I'm handing off and there's a bunch of stuff 633 00:33:20,000 --> 00:33:22,000 about scale to zero and things like that. 634 00:33:22,080 --> 00:33:25,800 If your view of serverless is And I I saw a post on LinkedIn 635 00:33:25,800 --> 00:33:28,960 recently which had somebody saying serverless is expensive 636 00:33:28,960 --> 00:33:31,960 and it'll send you in a ruin and it's too complex and just had 637 00:33:31,960 --> 00:33:34,400 all these diagrams of like lambdas, calling lambdas and 638 00:33:34,400 --> 00:33:37,320 using AWS services. And like I tend to agree that 639 00:33:37,320 --> 00:33:39,240 those are I don't like those infrastructure. 640 00:33:39,480 --> 00:33:42,480 I've never built one of those and I think that they're overly 641 00:33:42,480 --> 00:33:44,280 complex and I I don't think he under. 642 00:33:44,280 --> 00:33:47,480 I mean he's never read any of kind of the serverless 643 00:33:47,480 --> 00:33:50,240 practitioners that I agree with the least about what serverless 644 00:33:50,240 --> 00:33:53,120 is. And so to me Serverless is very 645 00:33:53,120 --> 00:33:58,040 much about asking how do I use. Most of our serverless footprint 646 00:33:58,040 --> 00:34:01,440 at branch is managed services. So it is not. 647 00:34:01,440 --> 00:34:04,800 I mean, we use Lambda, we use Dynamo DB, we use Cognito, we 648 00:34:04,800 --> 00:34:07,560 use AWS App Sync. These are amazing services. 649 00:34:07,760 --> 00:34:10,920 My book explains how we use them and why they're so great. 650 00:34:11,199 --> 00:34:15,280 And so we do use Lambda, but Lambda isn't everything in the 651 00:34:15,280 --> 00:34:17,080 application. It's like where we need to run 652 00:34:17,080 --> 00:34:20,280 some back end code. We run it with Lambda, but most 653 00:34:20,280 --> 00:34:22,639 of the lambdas are getting triggered by calls through app 654 00:34:22,639 --> 00:34:24,239 sync. But if you don't know what app 655 00:34:24,239 --> 00:34:27,199 sync is like, to me it's like a key part of the infrastructure. 656 00:34:27,360 --> 00:34:29,360 I also written a lot with Firebase. 657 00:34:29,520 --> 00:34:31,560 I think Firebase is also wonderful. 658 00:34:31,719 --> 00:34:34,120 I think what in writing kind of hobbyist apps. 659 00:34:34,120 --> 00:34:37,480 I think Firebase is just easier to work with than app sync and 660 00:34:37,480 --> 00:34:40,280 the Amazon infrastructure. So I like that Firebase 661 00:34:40,280 --> 00:34:42,719 infrastructure for simpler applications. 662 00:34:42,920 --> 00:34:45,840 The Amazon one is just much better for like financial 663 00:34:45,840 --> 00:34:47,960 services. At least it's it's more robust 664 00:34:47,960 --> 00:34:51,360 in a bunch of ways, but that's how I think about it is really, 665 00:34:51,520 --> 00:34:54,760 am I responsible for uptime? As long as the code functions 666 00:34:54,760 --> 00:34:56,760 properly, then that's serverless. 667 00:34:56,760 --> 00:35:00,840 And so I often will tell people you know it's serverless to go 668 00:35:00,840 --> 00:35:03,320 build your shopping site on Shopify. 669 00:35:03,440 --> 00:35:06,360 Like that's a serverless architecture for me, and if you 670 00:35:06,360 --> 00:35:08,720 don't think about it that way, then I don't think you're in 671 00:35:08,720 --> 00:35:11,560 line with what serverless actually is and how to get the 672 00:35:11,560 --> 00:35:13,760 business benefits out of it. Right. 673 00:35:13,920 --> 00:35:15,760 And you also mentioned managed service. 674 00:35:15,800 --> 00:35:18,200 I think for some people there is a lot of confusion as well. 675 00:35:18,200 --> 00:35:20,280 What do you mean by managed service? 676 00:35:20,840 --> 00:35:23,560 I think Twilio is the best example for people at a managed 677 00:35:23,560 --> 00:35:27,200 service. It is cloud based API usually 678 00:35:27,200 --> 00:35:30,680 that you pay and they have a well documented API. 679 00:35:30,680 --> 00:35:33,760 They've got a whole operations team, it's multi tenant as a 680 00:35:33,760 --> 00:35:36,320 service and you pay them money and they're just up and they do 681 00:35:36,320 --> 00:35:37,520 things for. You. 682 00:35:37,520 --> 00:35:40,320 Yeah, and I think in your book, if I remember, I also see like 683 00:35:40,360 --> 00:35:43,880 for example, if you have to patch something, right, if you 684 00:35:43,880 --> 00:35:47,200 have to choose the size, if you have to scale it somehow, right. 685 00:35:47,240 --> 00:35:48,880 I think that's not serverless, right? 686 00:35:48,880 --> 00:35:50,000 So. Right, right. 687 00:35:50,000 --> 00:35:51,560 And there are these Gray areas, right? 688 00:35:51,560 --> 00:35:55,880 Because in Lambda you will pick a size and so like I view Lambda 689 00:35:55,880 --> 00:35:58,480 as serverless and I would just say in Lambda just by the 690 00:35:58,480 --> 00:36:01,680 largest size because you get more CPU with it. 691 00:36:01,680 --> 00:36:04,680 At least by, I don't know, 4 gigs, they default to this 692 00:36:04,680 --> 00:36:06,280 minimum size. That's terrible and you 693 00:36:06,280 --> 00:36:08,640 shouldn't use it, but you know, that's a Gray area. 694 00:36:08,640 --> 00:36:11,240 But yeah, I I also think about it like, yes, if you have to 695 00:36:11,240 --> 00:36:14,200 patch it, but also if it runs out of disk space, whose 696 00:36:14,200 --> 00:36:16,200 responsibility is it to manage that? 697 00:36:16,200 --> 00:36:17,880 That's a question I like to ask a lot. 698 00:36:18,160 --> 00:36:20,480 And so if it's your responsibility if you fill up a 699 00:36:20,480 --> 00:36:23,320 disk like, it's not circles, right? 700 00:36:23,760 --> 00:36:25,520 So I think that's a good reminder definitely. 701 00:36:25,560 --> 00:36:28,000 And of course when we talk about serverless, there are many 702 00:36:28,000 --> 00:36:29,400 skeptics like you mentioned, right? 703 00:36:29,400 --> 00:36:32,480 So many objections in the beginning we talked about cost 704 00:36:32,680 --> 00:36:35,800 lock in, some people also think about security, right, Because 705 00:36:36,040 --> 00:36:37,920 if let's say you use managed service for those managed 706 00:36:37,920 --> 00:36:40,240 services like a vendor, third party, right, you don't know 707 00:36:40,240 --> 00:36:43,000 them, your data spreads across different services. 708 00:36:43,320 --> 00:36:45,160 What's your take about all these objections? 709 00:36:45,160 --> 00:36:48,160 Maybe tell us how would you actually, you know, advise 710 00:36:48,160 --> 00:36:50,760 people? Yeah, the most important thing 711 00:36:50,760 --> 00:36:53,560 that you need is good third party risk management in your 712 00:36:53,560 --> 00:36:56,000 organization. And I would actually say one of 713 00:36:56,000 --> 00:36:59,280 the biggest hindrances to serverless adoption 714 00:36:59,280 --> 00:37:03,160 organizations that really want to is that they have very poor 715 00:37:03,160 --> 00:37:05,720 third party risk management programs in their company. 716 00:37:05,920 --> 00:37:09,640 And what they have decided to do in the company, maybe not even 717 00:37:09,640 --> 00:37:11,920 consciously. What they've decided to do in 718 00:37:11,920 --> 00:37:14,840 their company is basically make it really hard to do contracts 719 00:37:14,840 --> 00:37:18,640 with other companies as a way of security. 720 00:37:18,760 --> 00:37:21,520 That's not security, that's just pretending you're secure. 721 00:37:21,760 --> 00:37:24,160 And I recognize a lot of lead developers may not have full 722 00:37:24,160 --> 00:37:26,720 control over this, but it's useful to know It's useful to, 723 00:37:26,720 --> 00:37:29,880 like, have this in your head. Your company should have a 724 00:37:30,120 --> 00:37:35,160 robust way for you to say I would like to use this company 725 00:37:35,480 --> 00:37:38,560 and to be able to review it in a reasonable amount of time and 726 00:37:38,560 --> 00:37:41,320 see if it meets the security guidelines for the information 727 00:37:41,320 --> 00:37:44,320 that that service will get. You should have a good way of 728 00:37:44,320 --> 00:37:47,960 looking at its historic uptime and evaluating whether you think 729 00:37:47,960 --> 00:37:50,720 it's uptime is going to be appropriate for your use for it. 730 00:37:51,000 --> 00:37:53,040 And then you know your finance department or your legal 731 00:37:53,040 --> 00:37:55,160 department need to be able to review the contracts and make 732 00:37:55,160 --> 00:37:58,400 sure that they have an appropriate DPA, for example, 733 00:37:58,480 --> 00:38:00,160 and have other things. And then if they don't meet 734 00:38:00,160 --> 00:38:01,920 those things, you shouldn't do business with them. 735 00:38:02,280 --> 00:38:05,120 But I'll tell you, as a regulated US insurance company, 736 00:38:05,120 --> 00:38:08,960 there are a few companies regulated, you know as heavily 737 00:38:08,960 --> 00:38:12,320 as you as insurance companies. We use lots of these services 738 00:38:12,320 --> 00:38:15,680 and it's not a problem, but it's about having really good third 739 00:38:15,680 --> 00:38:17,920 party risk management. And that third party risk 740 00:38:17,920 --> 00:38:21,880 management understanding that they exist to help us do 741 00:38:21,880 --> 00:38:25,040 contracts and work with other companies because that's a key 742 00:38:25,040 --> 00:38:27,480 differentiator in how fast we can build. 743 00:38:27,840 --> 00:38:31,560 So getting the company aligned with that is a top down goal of 744 00:38:31,560 --> 00:38:34,200 like helping everybody understand we need this function 745 00:38:34,240 --> 00:38:36,720 within our company to be able to do these things. 746 00:38:37,040 --> 00:38:39,080 But that's how you do it. I've been in charge of 747 00:38:39,080 --> 00:38:42,800 information security, you know, many organizations that have had 748 00:38:42,800 --> 00:38:46,760 a lot of compliance requirements and every time I run in, anyone 749 00:38:46,760 --> 00:38:48,720 says, well, we we never pass compliance with that. 750 00:38:48,720 --> 00:38:50,440 I'm just like, no, you just don't know how to do it. 751 00:38:51,000 --> 00:38:53,360 I guess to quote Twitter, that's a skill issue. 752 00:38:53,520 --> 00:38:56,920 It's not difficult, but it does require sometimes creativity and 753 00:38:56,920 --> 00:38:58,520 it does require knowing your stuff. 754 00:38:58,840 --> 00:39:01,320 You do need to understand like, you know, what is our 755 00:39:01,320 --> 00:39:03,640 information security policy? Why do we have these rules? 756 00:39:03,800 --> 00:39:07,600 Why do these regulations exist? And you need to be fluent enough 757 00:39:07,600 --> 00:39:10,200 in it and have a good Chief Information Security Officer who 758 00:39:10,200 --> 00:39:12,320 understands them and cares about productivity. 759 00:39:12,760 --> 00:39:14,520 So you don't have all these things that can be very 760 00:39:14,520 --> 00:39:17,400 difficult. But I can tell you it is so much 761 00:39:17,400 --> 00:39:22,560 easier to be secure with serverless and manage services 762 00:39:22,560 --> 00:39:24,800 than it is with an internal network. 763 00:39:24,800 --> 00:39:28,280 And so like we are fully no internal network, fully zero 764 00:39:28,280 --> 00:39:32,360 trust at Branch and the levels that we can achieve and what we 765 00:39:32,360 --> 00:39:35,960 are able to do on the budget we have which is very low is 766 00:39:35,960 --> 00:39:38,240 absolutely phenomenal and would have been completely 767 00:39:38,240 --> 00:39:41,880 unattainable for me 10 years ago at Guildfax, which honestly has 768 00:39:42,200 --> 00:39:44,400 what would be considered like a best practices cloud 769 00:39:44,400 --> 00:39:46,800 architecture today. I mean it's full infrastructure 770 00:39:46,800 --> 00:39:49,120 as code. It's got great network roles and 771 00:39:49,120 --> 00:39:52,920 great in VPCS and everything, but managing that, proving that 772 00:39:53,160 --> 00:39:55,400 and everything around that is so much harder. 773 00:39:55,600 --> 00:39:58,960 And so, you know, didn't leave a lot of budget for other things. 774 00:39:58,960 --> 00:40:02,720 And at Branch we have managed to make budget for just amazingly 775 00:40:02,720 --> 00:40:06,280 high quality security. I'm very amazed when I, you know 776 00:40:06,280 --> 00:40:09,840 read that branch is a insurance company, highly regulated and 777 00:40:09,840 --> 00:40:13,040 yet you succeed in adopting all these serverless right, because 778 00:40:13,080 --> 00:40:15,720 I think security compliance is always top of mind especially in 779 00:40:15,920 --> 00:40:18,440 Fintech or you know financial services industry, right. 780 00:40:18,680 --> 00:40:21,440 But I think what you mentioned is probably like it's more about 781 00:40:21,760 --> 00:40:24,560 understanding the compliance itself, right, and be creative 782 00:40:24,560 --> 00:40:28,280 in solving it and maybe you put more proper checks and balances 783 00:40:28,320 --> 00:40:30,200 before you actually use those managed service. 784 00:40:30,560 --> 00:40:33,360 And speaking about, you mentioned it's not our up time, 785 00:40:33,360 --> 00:40:35,200 right. So what happens in incidents 786 00:40:35,200 --> 00:40:37,960 where the third party is down, right, I think it's also one of 787 00:40:37,960 --> 00:40:41,600 the most common objection. If those core services is down, 788 00:40:41,600 --> 00:40:44,120 then we are also down and we can't do anything. 789 00:40:44,120 --> 00:40:45,880 So what's your take on this objection? 790 00:40:46,480 --> 00:40:50,480 Well, one thing is we run in US E 1, which is great because if 791 00:40:50,480 --> 00:40:53,040 there are problems in US E one, we know a large chunk of the 792 00:40:53,040 --> 00:40:56,120 Internet's going down as well. And generally speaking, we go 793 00:40:56,120 --> 00:40:58,040 down less than the rest of the Internet. 794 00:40:58,040 --> 00:41:01,640 So I've been in USC Swan since 2008 and this is what I found. 795 00:41:01,640 --> 00:41:04,960 So I remember the outage in like 2012 and there was a Netflix 796 00:41:04,960 --> 00:41:07,080 outage there. I just realized that, you know, 797 00:41:07,560 --> 00:41:10,440 you get a lot of grace when it's a USC Swan problem. 798 00:41:10,440 --> 00:41:14,240 So in the last five years, there was only one significant USC 799 00:41:14,240 --> 00:41:15,920 Swan outage. It was a couple hours. 800 00:41:15,920 --> 00:41:18,440 It didn't take us fully down. It was the one that like 801 00:41:18,440 --> 00:41:22,840 affected Route 53 DNS where it became clear that that service 802 00:41:22,840 --> 00:41:27,600 is bound in USC one and it's not really free from USC One. 803 00:41:28,120 --> 00:41:30,840 And so you know everyone says why would you be in USC one. 804 00:41:30,880 --> 00:41:33,600 But I'll tell you like if USC One has problems, like no one's 805 00:41:33,600 --> 00:41:35,800 going to blame you because every all of their other products 806 00:41:35,800 --> 00:41:38,160 aren't going to work either. And then outside of that, you 807 00:41:38,160 --> 00:41:40,040 know we basically don't have outages. 808 00:41:40,360 --> 00:41:44,360 We did have one in January 2022. So we've been selling insurance 809 00:41:44,360 --> 00:41:47,520 since the middle of 2019. And so I can tell you other than 810 00:41:47,520 --> 00:41:53,640 that couple hour USC one and this January 2022 where this 811 00:41:53,640 --> 00:41:57,280 insurance specific vendor we used and so there aren't a lot 812 00:41:57,280 --> 00:41:59,240 of other choices. This insurance specific vendor 813 00:41:59,240 --> 00:42:01,480 we used went down. Other than that you know there 814 00:42:01,480 --> 00:42:04,680 were kind of partial or degraded services from time to time. 815 00:42:05,040 --> 00:42:07,640 Occasionally something won't be available like we have to pull 816 00:42:07,640 --> 00:42:10,520 motor vehicle records and those come from the States and those 817 00:42:10,520 --> 00:42:13,200 services go down like every other day. 818 00:42:13,360 --> 00:42:16,680 One of those services down for like 15 or 20 minutes and so you 819 00:42:16,680 --> 00:42:18,560 know you just build a lot of alerting around it. 820 00:42:18,560 --> 00:42:21,240 And so our applications are very aware of that. 821 00:42:21,240 --> 00:42:23,880 But in terms of the core infrastructure of app Sync, 822 00:42:23,880 --> 00:42:27,920 Dynamo, Cognito, Lambda and US E One, I don't think those have 823 00:42:27,920 --> 00:42:31,200 really gone down at all ever. Even in that US E one problem 824 00:42:31,200 --> 00:42:34,560 they were all still working. I think Cognito had some issues 825 00:42:34,560 --> 00:42:38,200 but was just slow. So I would say my experience 826 00:42:38,200 --> 00:42:42,440 with it's not my uptime. I hired a company that is very 827 00:42:42,440 --> 00:42:45,920 good at uptime has resulted in we basically don't go down. 828 00:42:45,920 --> 00:42:48,440 We have much better up time than I've ever had running you know 829 00:42:48,440 --> 00:42:50,520 in any of these organizations running my own infrastructure 830 00:42:50,920 --> 00:42:53,160 and so we're running some of the infrastructure. 831 00:42:53,600 --> 00:42:55,720 So I think it's kind of a non issue. 832 00:42:55,920 --> 00:42:59,280 It is certainly possible. I I will give one sort of caveat 833 00:42:59,280 --> 00:43:03,360 here is I did build an application using off 0 for 834 00:43:03,360 --> 00:43:07,200 authentication and that service went down all the time in my 835 00:43:07,200 --> 00:43:09,160 view. Not for long periods of time but 836 00:43:09,160 --> 00:43:11,120 all the time and like I would never. 837 00:43:11,320 --> 00:43:14,400 I mean maybe they fix this. I'm skeptical though after their 838 00:43:14,400 --> 00:43:17,640 acquisition and like everything that's happening with Okta I 839 00:43:17,640 --> 00:43:20,480 would never use off 0 again and I would be very cautious in 840 00:43:20,480 --> 00:43:23,600 authentication services. But I can personally vouch for 841 00:43:23,600 --> 00:43:28,200 Cognito and Firebase off, having been very reliable services. 842 00:43:29,640 --> 00:43:31,840 Yeah. So when you speak about up time 843 00:43:31,840 --> 00:43:34,160 and reliability, right, when you choose serverless, it's not like 844 00:43:34,160 --> 00:43:35,960 any kind of serverless or managed service, right. 845 00:43:35,960 --> 00:43:38,720 You also look at the historical up time you have, Yeah. 846 00:43:38,720 --> 00:43:40,720 Can they guarantee a good SLA, right? 847 00:43:41,040 --> 00:43:43,120 Is there any compensation that they will give or never? 848 00:43:43,120 --> 00:43:46,320 This yeah, I tend to look, SLAS are non compensatory, like 849 00:43:46,320 --> 00:43:51,080 they'll never compensate you. So I tend to like an SLA where 850 00:43:51,080 --> 00:43:55,160 it's punitive to the company. What I'd like to feel is like if 851 00:43:55,160 --> 00:43:59,120 you go down, it hurts EU. And I do think like Amazon use 852 00:43:59,120 --> 00:44:01,680 these outages very personally and reputationally. 853 00:44:01,680 --> 00:44:03,640 And I think it matters to them quite a lot. 854 00:44:04,040 --> 00:44:06,960 And so they're never going to like compensate me appropriately 855 00:44:06,960 --> 00:44:09,360 in the SLA. But I think the historic up time 856 00:44:09,360 --> 00:44:11,680 is the thing to look at and just to make sure you're getting an 857 00:44:11,680 --> 00:44:14,160 honest look at the historic up time because that's the best way 858 00:44:14,160 --> 00:44:16,720 to tell. We do use some services that are 859 00:44:16,720 --> 00:44:20,760 in beta and you know, we just do a lot of testing to get comfort 860 00:44:20,760 --> 00:44:22,640 with them. But there are occasionally times 861 00:44:22,640 --> 00:44:24,560 we'll say, yeah, we're not going to use that yet. 862 00:44:24,560 --> 00:44:27,760 We're going to wait another six months or a year, but we use 863 00:44:27,760 --> 00:44:30,600 Neon really early. Serverless Postgres because we 864 00:44:30,600 --> 00:44:34,280 really wanted it, and Amazon, Serverless, Postgres are not 865 00:44:34,280 --> 00:44:37,680 Serverless, They're terrible. And Neon is a great Serverless 866 00:44:37,680 --> 00:44:40,040 Postgres database. And so we started using them 867 00:44:40,120 --> 00:44:42,680 when they were in private beta. We tested them out. 868 00:44:42,680 --> 00:44:45,240 We were like, how do we feel? And we've just built in some 869 00:44:45,240 --> 00:44:47,600 backup caching in case it wasn't available. 870 00:44:47,600 --> 00:44:49,160 And that's worked out really well. 871 00:44:49,160 --> 00:44:53,240 Leon's been very reliable. Yeah, apart from the historical 872 00:44:53,240 --> 00:44:56,240 up time, I think one thing that is quite, you know, recent 873 00:44:56,240 --> 00:44:59,240 trend, right, people updating postmortem whenever there's an 874 00:44:59,240 --> 00:45:01,240 incident, right. If the company diligently 875 00:45:01,440 --> 00:45:04,560 uploads postmortem and they take it seriously, I think that may 876 00:45:04,560 --> 00:45:07,600 also be an indicator that the company is serious about their 877 00:45:07,600 --> 00:45:10,040 up time, right? Yeah, it's not a reason why 878 00:45:10,040 --> 00:45:13,200 Amazon is so serious about that in a way that Google and 879 00:45:13,200 --> 00:45:17,160 Microsoft are not as serious about it, But I just feel a lot 880 00:45:17,400 --> 00:45:20,480 safer for production workloads in Amazon, although again, I run 881 00:45:20,480 --> 00:45:21,720 them in the other clouds as well. 882 00:45:22,280 --> 00:45:25,680 I think many people here would have been intrigued by Branch, 883 00:45:25,680 --> 00:45:27,240 right? Let's talk a little bit about 884 00:45:27,240 --> 00:45:29,120 Branch. What makes it unique, maybe in 885 00:45:29,120 --> 00:45:31,880 terms of how you run the development team, how you run 886 00:45:31,880 --> 00:45:33,720 the infrastructure? There are a few things that you 887 00:45:33,720 --> 00:45:35,760 mentioned in the book. Maybe let's start with your 888 00:45:35,760 --> 00:45:39,160 primary development principle, right, where you say when we 889 00:45:39,160 --> 00:45:41,600 write code, we optimize for maintainability. 890 00:45:41,600 --> 00:45:42,920 I think this is very interesting. 891 00:45:42,920 --> 00:45:44,680 Maybe can you talk more about it? 892 00:45:45,160 --> 00:45:48,640 Yeah, I'm always surprised at how infrequently development 893 00:45:48,640 --> 00:45:51,680 teams will say what they're optimizing for in terms of what 894 00:45:51,680 --> 00:45:53,960 they're doing. Like, most teams don't have this 895 00:45:53,960 --> 00:45:56,480 principle. But it's very useful to know 896 00:45:56,480 --> 00:45:58,720 when you're like looking at code or when you're sitting down to 897 00:45:58,720 --> 00:46:01,800 write something like what is my guiding principle on how to 898 00:46:01,800 --> 00:46:04,800 write this? My experience is if you write 899 00:46:04,800 --> 00:46:07,200 something for a good organization that is going to 900 00:46:07,200 --> 00:46:11,360 live for a while, you know I wrote code in 1997 that's still 901 00:46:11,360 --> 00:46:14,880 being used widely in Pearl in 1997. 902 00:46:14,880 --> 00:46:18,680 And so I think a lot about what is the most important for the 903 00:46:18,680 --> 00:46:20,760 company. And I don't think it's about 904 00:46:20,760 --> 00:46:24,360 making it speedy, right? I don't think it's about other 905 00:46:24,360 --> 00:46:25,240 things. I think it is. 906 00:46:25,240 --> 00:46:28,360 I want an average developer to be able to understand this and 907 00:46:28,360 --> 00:46:31,160 work on this. I think far too many companies 908 00:46:31,320 --> 00:46:34,520 are like, we've got these 10X ninjas, we write for 10X ninjas, 909 00:46:34,520 --> 00:46:37,680 we're 10X ninjas, we just hire 10X ninjas and all that. 910 00:46:37,680 --> 00:46:40,280 First of all, if you have a bunch of people who think 911 00:46:40,280 --> 00:46:42,760 they're 10X ninjas, one they're probably not, and two, they're 912 00:46:42,760 --> 00:46:44,640 probably writing unmaintainable garbage. 913 00:46:44,840 --> 00:46:47,840 It's a lot better to have people to have the cultural identity of 914 00:46:47,840 --> 00:46:49,440 like, it's important for me to write. 915 00:46:49,440 --> 00:46:52,560 I do like the idea of like I'm writing this and next developer 916 00:46:52,560 --> 00:46:55,680 has to work on this, has a gun to my head like write this thing 917 00:46:55,680 --> 00:46:58,360 so it makes sense, so it's easy to read. 918 00:46:58,520 --> 00:47:01,920 So that the code review that you have one you should have code 919 00:47:01,920 --> 00:47:03,800 review. You know everyone, not senior 920 00:47:03,800 --> 00:47:05,600 developers should have their code reviewed. 921 00:47:05,600 --> 00:47:06,920 Everyone should have their code reviewed. 922 00:47:07,280 --> 00:47:10,360 And we should have you know an understanding that I'm writing 923 00:47:10,360 --> 00:47:14,440 this so that somebody else, an average developer can come along 924 00:47:14,720 --> 00:47:17,960 and understand what the heck I was doing and like let's do that 925 00:47:18,120 --> 00:47:21,480 And it makes code reviews easier to know. 926 00:47:21,480 --> 00:47:23,120 Like this is what I'm optimizing for. 927 00:47:23,120 --> 00:47:26,240 It's like having an elinter or having style rules. 928 00:47:26,400 --> 00:47:30,200 You just like have opinions about things and everything gets 929 00:47:30,200 --> 00:47:32,400 easier. And so that's our primary 930 00:47:32,400 --> 00:47:34,360 principle. And there's a corollary to that, 931 00:47:34,360 --> 00:47:38,720 which is less code in general is more maintainable than more 932 00:47:38,720 --> 00:47:41,400 code. And so there's a lot of debate 933 00:47:41,400 --> 00:47:44,480 about like, should you DRY things up, how do you think 934 00:47:44,480 --> 00:47:47,000 about repetition? I think you can obviously go 935 00:47:47,000 --> 00:47:50,640 overboard with DRY, but I do think in general, you know, it's 936 00:47:50,680 --> 00:47:52,600 very common. We hire a lot of junior 937 00:47:52,600 --> 00:47:54,960 developers at branch. It's very common for junior 938 00:47:54,960 --> 00:47:58,720 developers to have patterns that are too repetitive that are just 939 00:47:58,720 --> 00:48:00,640 much better and much more readable. 940 00:48:00,880 --> 00:48:04,080 These are just everybody knows the pattern of like if I equals 941 00:48:04,080 --> 00:48:08,400 one then you know return one, if I = 2 then return 2 or whatever 942 00:48:08,400 --> 00:48:10,240 like that. Obviously that's a you shouldn't 943 00:48:10,360 --> 00:48:13,440 that's too much repetition. Like, I find more junior 944 00:48:13,440 --> 00:48:17,920 developers tend to not have these like ways of like how do I 945 00:48:17,920 --> 00:48:20,680 abstract this? Like there's a pattern that I'm 946 00:48:20,680 --> 00:48:23,040 repeating here. How do I abstract that. 947 00:48:23,240 --> 00:48:27,280 So in a very normal setting, I find that I do reviews and like 948 00:48:27,440 --> 00:48:29,720 somewhat frequently say, hey, you can get rid of some of this 949 00:48:29,720 --> 00:48:31,880 repetition, like abstract some of this logic. 950 00:48:32,320 --> 00:48:35,160 And, you know, I think that that's the key part of the 951 00:48:35,160 --> 00:48:38,360 principle is to have a less good, but not at the expense of 952 00:48:38,360 --> 00:48:41,400 maintainability. Yeah, speaking about developers, 953 00:48:41,440 --> 00:48:43,280 I think this is also unique in branch, right? 954 00:48:43,560 --> 00:48:46,680 You said that you hire more junior developers and actually 955 00:48:46,680 --> 00:48:50,080 you have less so-called infra developers or engineers, right? 956 00:48:50,320 --> 00:48:53,880 So tell us like, how do you actually run a good insurance 957 00:48:53,880 --> 00:48:56,080 company with mostly junior developers? 958 00:48:56,960 --> 00:49:01,440 Yeah, my hypothesis in starting branch was that, and I had seen 959 00:49:01,440 --> 00:49:05,800 this at a small scale but not at a large scale before, is that if 960 00:49:05,800 --> 00:49:08,920 we build serverlessly then mostly we're going to be 961 00:49:08,920 --> 00:49:12,160 building interfaces. And so my belief was I could 962 00:49:12,160 --> 00:49:15,800 hire front end developers and I could basically make them full 963 00:49:15,800 --> 00:49:18,360 stack developers as long as we were using the same language, 964 00:49:18,360 --> 00:49:21,120 JavaScript, TypeScript on the front end of the back end. 965 00:49:21,560 --> 00:49:24,520 And I thought if it's not our uptime, if other people are 966 00:49:24,520 --> 00:49:28,760 doing the uptime, then I should in theory just be able to hire 967 00:49:28,760 --> 00:49:32,800 front end developers, make them full stack developers and then 968 00:49:32,800 --> 00:49:35,040 that's all we would have. And then everyone would just be 969 00:49:35,040 --> 00:49:37,400 a developer, and then everybody could work on anything. 970 00:49:37,400 --> 00:49:39,400 They could work on the infrastructure, which is in 971 00:49:39,640 --> 00:49:41,280 YAML. So they could work on the phone 972 00:49:41,280 --> 00:49:42,160 and they could work on the back end. 973 00:49:42,160 --> 00:49:43,440 And then we'd have it all in a mono repo. 974 00:49:43,840 --> 00:49:47,120 Oh, and we'd have a mobile app. It would also be using 975 00:49:47,120 --> 00:49:50,240 JavaScript and React as well. And you know, everything would 976 00:49:50,240 --> 00:49:51,800 be kind of the same. It would all be the same 977 00:49:51,800 --> 00:49:53,400 repository. We would deploy it 978 00:49:53,400 --> 00:49:55,160 monolithically. Everyone would have their own 979 00:49:55,160 --> 00:49:57,280 isolated Amazon account to deploy it. 980 00:49:57,640 --> 00:49:59,440 And so this was the vision from the beginning. 981 00:49:59,440 --> 00:50:02,400 And it worked. It worked so well. 982 00:50:02,640 --> 00:50:03,720 And actually, let me take a step back. 983 00:50:03,720 --> 00:50:08,280 So at the beginning I said I can't hire a typical senior 984 00:50:08,280 --> 00:50:11,520 developer because a typical senior, I know what's going to 985 00:50:11,520 --> 00:50:14,640 happen if I hire a typical lead who's listening to this podcast. 986 00:50:14,920 --> 00:50:17,920 If I'd hire them into that, the average one of them would have 987 00:50:17,920 --> 00:50:19,800 said like oh, I know how to build. 988 00:50:19,800 --> 00:50:21,920 It's not like this. We need containers. 989 00:50:21,920 --> 00:50:23,040 We need to go build some containers. 990 00:50:23,040 --> 00:50:24,400 We need to do this thing. We need to do that thing. 991 00:50:24,400 --> 00:50:28,160 And my vision would be eroded. And and I believe in empowering 992 00:50:28,160 --> 00:50:30,520 people I hire. I want to hire someone and I 993 00:50:30,520 --> 00:50:32,360 want to let them do it the way they want to do it. 994 00:50:32,440 --> 00:50:36,360 And so I said I can't do that. So I said, OK, the safest thing 995 00:50:36,360 --> 00:50:41,360 that I can do that is if I hire more junior front end developers 996 00:50:41,400 --> 00:50:44,240 who I feel are capable on the front end side, like I think I 997 00:50:44,240 --> 00:50:48,560 can teach them how I'm thinking about building this and I they 998 00:50:48,560 --> 00:50:50,480 won't know any differently, right? 999 00:50:50,480 --> 00:50:52,600 By the way, it'll be so empowering because instead of 1000 00:50:52,600 --> 00:50:55,000 just being a front end developer who's like dependent on other 1001 00:50:55,000 --> 00:50:56,880 people, they'll be able to work on everything, They'll work on 1002 00:50:56,880 --> 00:50:59,520 infrastructure and everything. And so we did this and it worked 1003 00:50:59,520 --> 00:51:01,360 really well. And we said, OK, let's hire 1004 00:51:01,360 --> 00:51:04,840 people directly out of boot camps now instead of, like, with 1005 00:51:04,840 --> 00:51:07,240 a little experience. And so we did that. 1006 00:51:07,240 --> 00:51:10,280 And we realized these boot camps aren't teaching people anything 1007 00:51:10,280 --> 00:51:11,560 useful. Like, we're having to, like, 1008 00:51:11,560 --> 00:51:14,280 retrain them on everything. I've got lots of thoughts about 1009 00:51:14,280 --> 00:51:17,400 boot camps. And so then we said, let's run 1010 00:51:17,400 --> 00:51:20,520 our own boot camp because the boot camps aren't useful. 1011 00:51:20,520 --> 00:51:21,680 And then we run our own boot camp. 1012 00:51:21,840 --> 00:51:24,880 And we did it again. And so you know, my opinion 1013 00:51:24,880 --> 00:51:28,920 today is if you set this up correctly and if you hire the 1014 00:51:28,920 --> 00:51:32,840 right people who don't have preconceptions about you know 1015 00:51:32,840 --> 00:51:37,360 how things should be done, then we have lots of people are very 1016 00:51:37,360 --> 00:51:40,440 happy in this environment. By the way, we did a search for 1017 00:51:40,440 --> 00:51:44,800 AVP engineering fairly early on, about 3 1/2 years ago and found 1018 00:51:44,800 --> 00:51:48,440 this wonderful guy Ivan Herndon, who had been an engineering 1019 00:51:48,440 --> 00:51:52,760 manager at Stock X, but mainly front end and but like really 1020 00:51:52,760 --> 00:51:54,920 understood everything and had taught at a boot camp. 1021 00:51:55,160 --> 00:51:57,240 And he was like fully bought into. 1022 00:51:57,240 --> 00:52:00,680 Like this is a great model. I like this, but it took like 8 1023 00:52:00,680 --> 00:52:02,680 months to find him. Like it was just like a long 1024 00:52:02,680 --> 00:52:04,400 journey, but we had built enough. 1025 00:52:04,880 --> 00:52:08,360 Then then we went out and hired more senior developers and we 1026 00:52:08,360 --> 00:52:11,640 basically screamed for like who's going to like this, you 1027 00:52:11,640 --> 00:52:13,040 know? And we found senior developers 1028 00:52:13,040 --> 00:52:14,320 who were like, I love this, this is great. 1029 00:52:14,440 --> 00:52:15,680 Like this is exactly what I want. 1030 00:52:15,680 --> 00:52:17,640 Like it's so easy and I have so much control. 1031 00:52:17,640 --> 00:52:21,720 And like again, when our senior developers are given a feature, 1032 00:52:22,000 --> 00:52:24,720 they do all of it. They can do 100% of everything. 1033 00:52:24,720 --> 00:52:27,200 The infrastructure, the front of the back, and like, we truly 1034 00:52:27,200 --> 00:52:30,680 have full stack developers, but they're full stack developers 1035 00:52:30,680 --> 00:52:32,880 because the stack is simple, right? 1036 00:52:32,880 --> 00:52:36,360 It's all the same language, It's all in the same repository, 1037 00:52:36,360 --> 00:52:38,240 right? It has a monolithic deploy. 1038 00:52:38,560 --> 00:52:42,520 And so we can make full stack developers if we make the stack 1039 00:52:42,520 --> 00:52:44,280 simpler. Otherwise it's much harder to 1040 00:52:44,280 --> 00:52:45,720 have full stack developers because you need to know too 1041 00:52:45,720 --> 00:52:49,040 many different technologies. And so it's worked phenomenally 1042 00:52:49,040 --> 00:52:50,440 well. We just have developers. 1043 00:52:50,440 --> 00:52:53,200 There's no front end, there's no back end, there's no API, 1044 00:52:53,200 --> 00:52:55,760 there's no infrastructure people, there's no OPS people 1045 00:52:55,840 --> 00:52:58,760 because it's not our Uptown. Yeah, I think it's really 1046 00:52:58,760 --> 00:53:00,960 interesting model, right? If people haven't heard about 1047 00:53:00,960 --> 00:53:03,640 it, I think this is a very interesting thing that you can 1048 00:53:03,640 --> 00:53:07,040 learn from Joe's book, right? So I think how to make it work 1049 00:53:07,040 --> 00:53:09,920 is something that maybe you need to work on more, like for 1050 00:53:09,920 --> 00:53:12,360 example training people, make sure your code is maintainable. 1051 00:53:12,600 --> 00:53:15,440 But I can imagine for example, having everything as a 1052 00:53:15,440 --> 00:53:16,800 serverless managed service, right? 1053 00:53:16,800 --> 00:53:20,440 Every developer is empowered to not just code and commit their 1054 00:53:20,440 --> 00:53:23,160 changes, but also bring it up to the production, right? 1055 00:53:23,160 --> 00:53:26,400 And even operating it in a sense because they can just see it end 1056 00:53:26,400 --> 00:53:28,200 to end. And many people these days try 1057 00:53:28,200 --> 00:53:31,320 to build platform engineering right simply because they cannot 1058 00:53:31,320 --> 00:53:33,880 do self-service right. They cannot make deployment 1059 00:53:33,880 --> 00:53:35,960 themselves. So I think this is a different 1060 00:53:35,960 --> 00:53:38,440 kind of perspective how you run the engineering team. 1061 00:53:38,440 --> 00:53:41,600 So if you use more serverless, I think you probably don't need so 1062 00:53:41,600 --> 00:53:43,240 much platform engineering effort, right? 1063 00:53:43,240 --> 00:53:46,280 So you can do it end to end. And I think there are many other 1064 00:53:46,280 --> 00:53:49,040 things in the book that you can learn from branch, like for 1065 00:53:49,040 --> 00:53:52,240 example, a few things that I learned, the department head 1066 00:53:52,240 --> 00:53:55,240 actually is the one who kind of like negotiate contracts with 1067 00:53:55,240 --> 00:53:56,960 the SAS, not like the central team. 1068 00:53:57,360 --> 00:54:00,280 And the other thing is like the engineering lead is the one who 1069 00:54:00,480 --> 00:54:04,360 configure the cloud or be the DevOps engineer kind of thing, 1070 00:54:04,360 --> 00:54:05,680 right. So I think that's also 1071 00:54:05,680 --> 00:54:08,560 interesting. Maybe one thing if you can share 1072 00:54:08,560 --> 00:54:11,600 right, people might be intrigued like how much Cloud Bills 1073 00:54:11,640 --> 00:54:14,960 actually Branch is running. Yeah, I mean I think in the book 1074 00:54:14,960 --> 00:54:18,160 I shared. So we have an Amazon account for 1075 00:54:18,160 --> 00:54:20,360 every developer and for every environment. 1076 00:54:20,360 --> 00:54:23,280 And every developer in every environment has a full copy of 1077 00:54:23,280 --> 00:54:27,840 production. And this is cheap when you use 1078 00:54:27,840 --> 00:54:30,000 serverless because everything scales to 0. 1079 00:54:30,000 --> 00:54:33,440 So like the average developer who's working at least 40 hours 1080 00:54:33,440 --> 00:54:37,160 a week doing development, their environment might cost four or 1081 00:54:37,160 --> 00:54:40,360 $5 a month because it's just not that much usage. 1082 00:54:40,640 --> 00:54:43,840 But yeah, I think I shared a bill where our entire all 1083 00:54:43,840 --> 00:54:47,360 developer environments, all everything was about $1000 at 1084 00:54:47,360 --> 00:54:50,040 Amazon for that month. We're now significantly bigger. 1085 00:54:50,040 --> 00:54:53,200 So you know, that production environment is probably more 1086 00:54:53,200 --> 00:54:56,240 like the full bill 7 or $8000 a month right now for branch. 1087 00:54:56,440 --> 00:54:59,520 But it's every environment, every developer, everything, 1088 00:54:59,520 --> 00:55:02,440 including like all of the continuous integration testing 1089 00:55:02,840 --> 00:55:05,000 that we have. So it's so much cheaper. 1090 00:55:05,000 --> 00:55:09,160 I mean at build fax in 2015, I think dams on monthly bill was 1091 00:55:09,160 --> 00:55:13,120 probably $30,000 a month and that was doing so much less 1092 00:55:13,240 --> 00:55:16,080 honestly in that environment, but having to run, you know 1093 00:55:16,080 --> 00:55:20,760 those VMS and containers. Wow, 78000 a month for all 1094 00:55:20,760 --> 00:55:22,560 environments. That's really all environments. 1095 00:55:23,040 --> 00:55:24,440 Yeah. And you are a full running 1096 00:55:24,440 --> 00:55:27,640 insurance company as well. So kudos for you to run that. 1097 00:55:27,960 --> 00:55:30,320 So I think we reached the end of our conversation. 1098 00:55:30,320 --> 00:55:33,000 So before I let you go so to speak, I have one last question 1099 00:55:33,000 --> 00:55:34,440 for you, Joe. It's been a pleasant 1100 00:55:34,440 --> 00:55:36,720 conversation by the way. So this question I called the 1101 00:55:36,720 --> 00:55:38,120 three technical leadership wisdom. 1102 00:55:38,200 --> 00:55:40,360 You can think of it just like advice that you want to give to 1103 00:55:40,360 --> 00:55:44,720 us to learn from you. Yeah, so I've got 3 here for 1104 00:55:44,720 --> 00:55:47,040 you, and I'll start with some things I've said before, which 1105 00:55:47,040 --> 00:55:51,480 is one you should have an optimization principle for how 1106 00:55:51,480 --> 00:55:53,680 to write code. It's just as important as having 1107 00:55:53,680 --> 00:55:58,080 linting rules or style rules. You should also have an opinion 1108 00:55:58,080 --> 00:55:59,600 about what you're optimizing for. 1109 00:55:59,600 --> 00:56:01,560 So we optimize for maintainability. 1110 00:56:01,880 --> 00:56:04,520 I think it would be fine at you know in some places and might be 1111 00:56:04,520 --> 00:56:07,560 we're optimizing for like the lowest latency execution or 1112 00:56:07,560 --> 00:56:09,560 whatever it is. But you should have that. 1113 00:56:09,560 --> 00:56:13,520 You should write it down because it will help solve problems and 1114 00:56:13,520 --> 00:56:16,600 it will help resolve questions and doubts when you're not 1115 00:56:16,600 --> 00:56:18,880 there. So you should do that and then 1116 00:56:19,080 --> 00:56:22,360 you know, my view is optimize for maintainability is a great 1117 00:56:22,360 --> 00:56:24,960 default. And the second thing is less 1118 00:56:24,960 --> 00:56:27,440 code is more maintainable than more code. 1119 00:56:27,640 --> 00:56:31,520 And that is just true outside of like obfuscation contests for 1120 00:56:31,520 --> 00:56:35,960 like small lines of code and so you should strive for less code. 1121 00:56:35,960 --> 00:56:38,200 Again, the book has sort of an interesting waterfall about how 1122 00:56:38,200 --> 00:56:41,280 do I what is a tactic when I'm being asked to build something? 1123 00:56:41,280 --> 00:56:43,520 How do I end up with less code there and then? 1124 00:56:43,520 --> 00:56:46,840 Finally I have a saying that I give all the time, so I'll give 1125 00:56:46,840 --> 00:56:49,760 that as my final one, which is along the same lines. 1126 00:56:49,760 --> 00:56:54,960 But it is that it is better to spend 2 weeks researching and 1127 00:56:54,960 --> 00:56:58,840 two days developing than it is to spend 2 days researching and 1128 00:56:58,840 --> 00:57:03,440 two weeks developing. And I'm always just amazed by 1129 00:57:03,440 --> 00:57:07,560 organizations that don't give developers time to research how 1130 00:57:07,560 --> 00:57:10,560 they would do something. And I'm actually less amazed at 1131 00:57:10,560 --> 00:57:12,000 developers who just want to start building. 1132 00:57:12,000 --> 00:57:14,960 It's the hardest thing I know. I mean, I always wanted to start 1133 00:57:14,960 --> 00:57:18,200 building too. But the more you can train 1134 00:57:18,200 --> 00:57:23,360 yourself and your teams to think about how do I spend a good 1135 00:57:23,360 --> 00:57:27,120 period of time where I'm just trying to understand what's out 1136 00:57:27,120 --> 00:57:30,480 there, What are the options and how do I make that a good thing. 1137 00:57:30,880 --> 00:57:33,400 And like, I'm going to throw away whatever's done at the end 1138 00:57:33,400 --> 00:57:35,280 of it. And this really you need 1139 00:57:35,280 --> 00:57:36,800 leadership to help you with this. 1140 00:57:36,800 --> 00:57:39,320 But I think as a tech lead, you can set this tone. 1141 00:57:39,680 --> 00:57:43,040 And I'll give us the example. Our airplane migration, when we 1142 00:57:43,040 --> 00:57:45,760 found out essentially like January 5th that we were going 1143 00:57:45,760 --> 00:57:50,120 to have 60 days, we actually spent basically all of January 1144 00:57:50,120 --> 00:57:51,680 trying to figure out what we were going to do. 1145 00:57:52,000 --> 00:57:55,120 We looked at a bunch of other services that were options that 1146 00:57:55,120 --> 00:57:57,800 we evaluated them and we talked to their teams and tried to 1147 00:57:57,800 --> 00:58:00,320 understand things. We looked at what it would take 1148 00:58:00,320 --> 00:58:02,560 to build it ourselves and what that would look like. 1149 00:58:02,760 --> 00:58:05,360 And so we spent, I think a lot of people would stay. 1150 00:58:05,360 --> 00:58:08,440 You spent too much time, you know, like not acting because 1151 00:58:08,440 --> 00:58:10,280 the service was going to shut down and it was critical 1152 00:58:10,280 --> 00:58:13,640 production functions. But the reality is you just 1153 00:58:13,640 --> 00:58:16,600 can't make the right decision unless you spend time 1154 00:58:16,600 --> 00:58:19,840 understanding what's out there. And today, if you're building 1155 00:58:19,840 --> 00:58:22,240 new things, one of the things you need to know what's out 1156 00:58:22,240 --> 00:58:25,840 there is what are the managed services that could do a big 1157 00:58:25,840 --> 00:58:28,360 chunk of this for me. And you're not going to 1158 00:58:28,360 --> 00:58:31,720 understand those unless you give yourself the time to play around 1159 00:58:31,720 --> 00:58:33,520 with them. And almost all of these 1160 00:58:33,520 --> 00:58:35,680 providers will give you free trials. 1161 00:58:35,920 --> 00:58:38,520 You may have to talk to someone. And I know a lot of developers 1162 00:58:38,520 --> 00:58:41,480 really hate scheduling the meeting and doing the Zoom demo 1163 00:58:41,480 --> 00:58:42,640 and stuff. You may have to do that. 1164 00:58:42,640 --> 00:58:44,920 I'm sorry, but it's still worth it. 1165 00:58:44,920 --> 00:58:47,640 You should do it. Don't say I can't do a self sign 1166 00:58:47,640 --> 00:58:49,360 up on this thing. I'm not even going to consider 1167 00:58:49,360 --> 00:58:50,680 it because there's no pricing page. 1168 00:58:50,680 --> 00:58:52,120 We can't consider it. Don't do that. 1169 00:58:52,400 --> 00:58:55,160 Go understand it. Even if you don't use it, 1170 00:58:55,520 --> 00:58:58,880 there's actually real important value in understanding what is 1171 00:58:58,880 --> 00:59:01,360 the service. Get access to documentation, 1172 00:59:01,360 --> 00:59:04,240 understand what that interface is, understand what that price 1173 00:59:04,240 --> 00:59:06,200 is. All of that will really help you 1174 00:59:06,200 --> 00:59:08,920 understand what you need to do better, even if you don't use 1175 00:59:08,920 --> 00:59:10,640 it. And we just don't do that. 1176 00:59:10,640 --> 00:59:13,520 We don't do any research and planning in dev. 1177 00:59:13,520 --> 00:59:15,800 It's like, oh, I know one way to build that, so I'm just going to 1178 00:59:15,800 --> 00:59:17,280 do it that way. And like, don't do that. 1179 00:59:17,360 --> 00:59:19,680 Do take weeks to research. It's worth it. 1180 00:59:20,680 --> 00:59:23,200 Yeah, not just research in terms of product, but sometimes like 1181 00:59:23,240 --> 00:59:25,200 design, right? Like how would you design your 1182 00:59:25,200 --> 00:59:26,520 solution? Yeah, And sometimes 1183 00:59:26,600 --> 00:59:28,280 understanding the problem itself, right. 1184 00:59:28,280 --> 00:59:29,880 Because sometimes. Oh, absolutely, Yeah. 1185 00:59:29,920 --> 00:59:31,680 All of them is critical, yeah. Yeah. 1186 00:59:32,160 --> 00:59:34,840 So thank you so much, Joe, for this opportunity for this great 1187 00:59:34,840 --> 00:59:36,120 talk. So if people love this 1188 00:59:36,120 --> 00:59:38,920 conversation, they would want to connect with you or find more 1189 00:59:38,920 --> 00:59:41,480 about your resources, your book. Is there a place where they can 1190 00:59:41,480 --> 00:59:44,640 reach out online? Yeah, I'm Joe Emerson on 1191 00:59:44,640 --> 00:59:46,120 Twitter. Slash X. 1192 00:59:46,200 --> 00:59:49,480 And yeah, my book's on Amazon. Serverless as a game changer. 1193 00:59:50,280 --> 00:59:52,960 I really highly recommend people to read it if you are into 1194 00:59:52,960 --> 00:59:55,640 serverless and if you're skeptics, I think you can also 1195 00:59:55,640 --> 00:59:57,080 read this book just for your knowledge, yes. 1196 00:59:57,360 --> 00:59:58,600 So thanks again for your time, Joe. 1197 00:59:59,120 --> 01:00:04,160 Thank you. Thank you for listening to this 1198 01:00:04,160 --> 01:00:06,560 episode and for staying right until the end. 1199 01:00:06,920 --> 01:00:10,040 If you highly enjoyed it, I would appreciate if you share it 1200 01:00:10,040 --> 01:00:13,040 with your friends and colleagues who you think would also benefit 1201 01:00:13,040 --> 01:00:15,840 from listening to this episode. And if you're new to the 1202 01:00:15,840 --> 01:00:18,840 podcast, make sure to subscribe and leave me your valuable 1203 01:00:18,840 --> 01:00:21,840 review and feedback. It helps me a lot in order to 1204 01:00:21,840 --> 01:00:25,120 grow this podcast better. You can also find the full show 1205 01:00:25,120 --> 01:00:27,960 notes of this conversation on the episode page at 1206 01:00:27,960 --> 01:00:31,440 techlitjournal dot dev website, including the full transcript, 1207 01:00:31,720 --> 01:00:35,320 interesting quotes, and links to the resources mentioned from the 1208 01:00:35,320 --> 01:00:38,160 conversation. And lastly, make sure to 1209 01:00:38,160 --> 01:00:41,160 subscribe to the show's mailing list on techlitjournal dot dev 1210 01:00:41,520 --> 01:00:43,960 to get notified for any future episodes. 1211 01:00:44,560 --> 01:00:48,080 Stay tuned for the next Techly Journal episode, and until then, 1212 01:00:48,280 --> 01:00:48,800 goodbye.