1 00:00:00,080 --> 00:00:02,640 When you work professionally as software engineer, this is not 2 00:00:02,640 --> 00:00:04,960 practicing a hobby. You need to have numbers right, 3 00:00:05,000 --> 00:00:08,240 not just fluffy words. What was the actual landed 4 00:00:08,240 --> 00:00:10,760 impact on the business? Sometimes solving business 5 00:00:10,760 --> 00:00:13,320 problems means building software that is good enough. 6 00:00:13,440 --> 00:00:15,880 Good enough for today. I just want things to be simple. 7 00:00:15,880 --> 00:00:18,600 Simple is complicated enough, especially at scale. 8 00:00:19,160 --> 00:00:22,880 System design, a skill that separates good engineers from 9 00:00:22,880 --> 00:00:25,720 great ones. So if you want to level up as 10 00:00:25,720 --> 00:00:28,200 software engineer, this conversation is for you. 11 00:00:28,760 --> 00:00:31,800 Joining me today is Bassem Dakaidi, senior software 12 00:00:31,800 --> 00:00:35,280 engineer over at GitHub and especially at GitHub, they 13 00:00:35,280 --> 00:00:38,520 operate at scale. He shares how they design their 14 00:00:38,520 --> 00:00:41,800 software and solve specific problems in a way I didn't 15 00:00:41,800 --> 00:00:47,960 expect. So enjoy from an outside 16 00:00:47,960 --> 00:00:49,920 service. I feel, I feel like I've shared 17 00:00:49,920 --> 00:00:52,120 this many times on the podcast, but I feel like the tech 18 00:00:52,400 --> 00:00:55,440 community is quite unique. People create software, they 19 00:00:55,440 --> 00:00:57,920 create products and they put them out in the open for free. 20 00:00:58,200 --> 00:01:00,920 And GitHub is like the backbone that enables a lot of these 21 00:01:00,920 --> 00:01:03,120 things. I feel like I don't see another 22 00:01:03,120 --> 00:01:05,680 industry and it's it's kind of typical for me to say that 23 00:01:05,680 --> 00:01:08,560 because I'm in this industry, but I don't see any similar 24 00:01:08,560 --> 00:01:09,920 other industry where this is possible. 25 00:01:09,920 --> 00:01:10,520 Right. Precisely. 26 00:01:10,520 --> 00:01:13,080 And not only that, like the learning, the teaching aspect 27 00:01:13,080 --> 00:01:17,160 that we have, how openly we share what we learn and and we, 28 00:01:17,160 --> 00:01:20,760 we have this status associated with people who actually teach 29 00:01:21,040 --> 00:01:23,760 in our industry, which I don't often see elsewhere. 30 00:01:23,760 --> 00:01:26,360 A lot of industries, and I worked in other industries, like 31 00:01:26,360 --> 00:01:28,680 I've worked in container terminals for example, for a 32 00:01:28,680 --> 00:01:30,880 while we were building the whole infrastructure and what not. 33 00:01:31,440 --> 00:01:33,480 It's very rare to find information about how a 34 00:01:33,480 --> 00:01:35,920 container terminal operates. Unless you've like went to a 35 00:01:36,200 --> 00:01:39,040 specific program that teaches that or taken specialized 36 00:01:39,040 --> 00:01:41,560 courses, you're never going to get that information anywhere. 37 00:01:41,560 --> 00:01:44,120 Like there are no blog posts that describe how things work. 38 00:01:44,280 --> 00:01:46,880 You just got to learn it either from people who have been doing 39 00:01:46,920 --> 00:01:49,600 or practicing this industry for a while or you go do a 40 00:01:49,600 --> 00:01:52,440 specialized program. So I I definitely relate to what 41 00:01:52,440 --> 00:01:54,920 you're saying and I think it's pretty unique, which is awesome. 42 00:01:55,240 --> 00:01:58,480 There are some topics that I have in mind and especially that 43 00:01:58,480 --> 00:02:00,880 I think are going to be a bigger focal point going towards the 44 00:02:00,880 --> 00:02:02,520 future. Something like system design 45 00:02:02,520 --> 00:02:05,640 where there's a lot of theory out there and then actually 46 00:02:05,640 --> 00:02:07,560 putting it in practice. You can understand the the 47 00:02:07,560 --> 00:02:09,639 theory, but then putting it to practice is still very 48 00:02:09,639 --> 00:02:13,400 challenging, especially in what type of organization you are. 49 00:02:13,400 --> 00:02:15,520 How, How far in the future are you going to design? 50 00:02:17,040 --> 00:02:19,080 I feel like it's challenging bridging the gap between theory 51 00:02:19,080 --> 00:02:21,720 and practice for that aspect A. 100% And I was thinking about 52 00:02:21,720 --> 00:02:25,000 this topic earlier today, right? I was just reading a, a, a post 53 00:02:25,000 --> 00:02:28,040 on X that went viral where a start up was talking about the 54 00:02:28,040 --> 00:02:32,480 migration to Kubernetes and then it almost cost them their start 55 00:02:32,480 --> 00:02:34,080 up. Like the start up could have 56 00:02:34,080 --> 00:02:36,240 almost failed because of that particular migration. 57 00:02:36,720 --> 00:02:40,160 And the owner was listing the the the reasons why they went 58 00:02:40,160 --> 00:02:42,840 for the migrations and none of them were technical like the 59 00:02:42,840 --> 00:02:45,600 reasons were. Their VCs were pushing for cloud 60 00:02:45,600 --> 00:02:50,320 native, their engineers wanted the Kubernetes experience and 61 00:02:50,520 --> 00:02:54,920 they thought that they can deploy faster, bigger scale 62 00:02:54,960 --> 00:02:56,840 better. But what they ended up with is 63 00:02:56,840 --> 00:03:00,560 just a fatter AWS bill and then the much more complication 64 00:03:00,560 --> 00:03:02,960 feature shipment crawled to a halt. 65 00:03:02,960 --> 00:03:04,880 They had to dedicate certain engineers for this. 66 00:03:05,320 --> 00:03:09,120 And I think this stems from the fact that a lot of people want 67 00:03:09,120 --> 00:03:14,320 the status associated with fancy architectures and they want the 68 00:03:14,320 --> 00:03:17,080 experience of working with fancy architectures and not 69 00:03:17,080 --> 00:03:19,720 necessarily solving problems with fancy architectures or 70 00:03:19,720 --> 00:03:22,760 growing organically a certain architecture to solve a 71 00:03:22,760 --> 00:03:25,640 particular problem. And the problem with system 72 00:03:25,640 --> 00:03:29,040 design is, again, a lot of people want the fancy stuff, but 73 00:03:29,040 --> 00:03:33,080 they the boundaries for when you need to scale are very blurry. 74 00:03:33,400 --> 00:03:35,880 There are no concrete empirical numbers that tell you like when 75 00:03:35,880 --> 00:03:38,920 you hit this particular scale you need to do this, and when 76 00:03:38,920 --> 00:03:40,680 you hit this particular number you need to do that. 77 00:03:41,360 --> 00:03:45,720 So people assume that as soon as they hit on their service or API 78 00:03:45,720 --> 00:03:48,160 or whatever, like 1000 requests per second, that's a lot. 79 00:03:48,160 --> 00:03:51,200 So now they need to build for the next evolution of the 80 00:03:51,400 --> 00:03:53,600 system. And often that's not really the 81 00:03:53,600 --> 00:03:56,720 case. At GitHub, for example, I've 82 00:03:56,720 --> 00:03:59,720 built services that handle millions of requests per second 83 00:04:00,640 --> 00:04:05,320 that are just simply running on a 5 or 6 containers and a very 84 00:04:05,320 --> 00:04:07,880 tiny Kubernetes cluster. Somewhere that's not what I 85 00:04:07,880 --> 00:04:09,560 would expect right at all. Precisely. 86 00:04:09,680 --> 00:04:14,200 So there's a lot. There's a lot you can do with 87 00:04:14,200 --> 00:04:19,120 very little and you can even run entire services on very basic 88 00:04:19,120 --> 00:04:22,079 VMS and scale some stuff around it. 89 00:04:22,480 --> 00:04:25,360 And the way we approach problems of scale, we'd never design or 90 00:04:25,360 --> 00:04:27,440 over engineer. So when I designed certain 91 00:04:27,440 --> 00:04:29,440 things, I recently did a lot of that. 92 00:04:30,440 --> 00:04:34,400 We were rewriting some parts of actions, GitHub Actions. 93 00:04:34,400 --> 00:04:37,200 That's what I work on. So we're going to talk more 94 00:04:37,200 --> 00:04:39,120 about that in engineering blog posts and whatnot. 95 00:04:39,120 --> 00:04:41,960 This is like, in my opinion, a case study for decades to come 96 00:04:41,960 --> 00:04:43,960 because this doesn't often happen. 97 00:04:43,960 --> 00:04:45,280 That's awesome. Yeah. 98 00:04:45,280 --> 00:04:49,400 So when we were designing this, we were designing for scale. 99 00:04:49,400 --> 00:04:51,800 But we know already we have established scale. 100 00:04:52,080 --> 00:04:54,560 So we know that we've hit the limit of what the previous 101 00:04:54,560 --> 00:04:57,520 architecture could do. And now is the point where we 102 00:04:57,520 --> 00:05:01,360 need to squeeze more out of a different tech stack to get to 103 00:05:01,360 --> 00:05:03,920 that next level. And we know that we're going to 104 00:05:03,920 --> 00:05:05,320 get to that next level because we are. 105 00:05:05,600 --> 00:05:08,640 We see the demand, we see how it's growing, we see the curve, 106 00:05:09,080 --> 00:05:11,760 we see how where it's going to be in five years from now, 107 00:05:11,920 --> 00:05:14,280 right. So we solved for that. 108 00:05:14,480 --> 00:05:18,600 We didn't prematurely scale. We just went all the way to the 109 00:05:18,600 --> 00:05:21,720 end with the existing architecture, and that's when we 110 00:05:21,720 --> 00:05:25,440 made the decision to rewrite some components and redesign 111 00:05:25,440 --> 00:05:29,040 certain aspects of it and make tradeoffs based on data we had 112 00:05:29,040 --> 00:05:31,760 and based on projections that we're going to attain or get. 113 00:05:32,120 --> 00:05:34,360 Is this then your advice as well? 114 00:05:34,480 --> 00:05:37,600 So to stick with what you have, start with an initial design 115 00:05:37,600 --> 00:05:40,960 that is simple, and then stick with it until you actually reach 116 00:05:40,960 --> 00:05:44,680 certain limits and you can kind of based on your usage, forecast 117 00:05:44,880 --> 00:05:47,520 what the next iteration would. Precisely, If I was a start up 118 00:05:47,520 --> 00:05:51,560 founder or ACTO of a start up right, I would never go and 119 00:05:51,560 --> 00:05:55,040 start building for 100 X scale. Even if I'm like a firm believer 120 00:05:55,040 --> 00:05:58,840 in my idea and know that it's going to reach the masses and 121 00:05:58,840 --> 00:06:01,360 it's going to be global, I would never design for that. 122 00:06:01,680 --> 00:06:06,120 I would design for getting 100 users or maybe even 1000, right? 123 00:06:06,560 --> 00:06:08,680 And I would just run everything on a single VM, to be honest. 124 00:06:08,680 --> 00:06:11,480 Maybe 2, make it a bit more available. 125 00:06:12,040 --> 00:06:15,680 I would not go and build massive database clusters. 126 00:06:15,960 --> 00:06:20,160 Just start with one, maybe 2 nodes pops replication, that's 127 00:06:20,160 --> 00:06:22,320 it. And this will like carry you 128 00:06:22,320 --> 00:06:27,720 really, really far. To be honest, once I attain or 129 00:06:27,720 --> 00:06:31,240 I'm get, I'm like close to 80% of these limits of what my 130 00:06:31,240 --> 00:06:33,680 resources can do. And by the way, vertical scaling 131 00:06:33,680 --> 00:06:36,600 can take you a long way. Like you have no idea. 132 00:06:36,600 --> 00:06:42,080 We have my SQL nodes that have hundreds of CP us on them. 133 00:06:43,600 --> 00:06:47,240 So you don't really need to go and start sharding and doing all 134 00:06:47,240 --> 00:06:50,480 sorts of fancy stuff when vertical scaling can still carry 135 00:06:50,480 --> 00:06:54,560 you. And right now with cloud native 136 00:06:54,560 --> 00:06:56,160 solutions, you can go pretty far. 137 00:06:56,160 --> 00:07:00,160 Like you can get a one VM with 120 CP cores, right? 138 00:07:00,160 --> 00:07:03,680 You can get terabytes of memory, Yeah. 139 00:07:04,360 --> 00:07:07,280 And that can do a lot for you. You don't need to start doing 140 00:07:07,280 --> 00:07:09,720 horizontal scaling before you get you really start hitting 141 00:07:09,720 --> 00:07:11,080 these limits. Interesting. 142 00:07:11,720 --> 00:07:15,440 See, I, I feel like I'm not great at system design. 143 00:07:15,480 --> 00:07:19,040 It's just not something that I specifically put my thoughts to, 144 00:07:19,040 --> 00:07:21,480 not something I prepared like from an interview style. 145 00:07:21,880 --> 00:07:24,680 And then I actually did a system design interview and my 146 00:07:24,680 --> 00:07:28,160 architecture was, it was very simple and I wanted it to be 147 00:07:28,160 --> 00:07:30,560 simple because I don't like complexity when we don't need 148 00:07:30,560 --> 00:07:31,800 it. And it was also for the use 149 00:07:31,800 --> 00:07:33,120 case. I was like, this is, this is the 150 00:07:33,120 --> 00:07:35,280 simple aspect. Then the question was, OK, but 151 00:07:35,280 --> 00:07:38,480 what if we hit X amount of scale and then we need, indeed, we 152 00:07:38,480 --> 00:07:41,040 need high availability and we need charting and we need 153 00:07:41,040 --> 00:07:43,240 consistency. And then I was like, but the 154 00:07:43,480 --> 00:07:46,320 like the argument that I had is in this case it it actually 155 00:07:46,320 --> 00:07:49,320 doesn't matter for me. The part of the benefit that we 156 00:07:49,320 --> 00:07:52,200 have a lot of information out there, people can self educate 157 00:07:52,520 --> 00:07:55,840 is not also turning into this pitfall where complex system 158 00:07:55,840 --> 00:08:00,000 design is almost I think in most industries where we don't 159 00:08:00,000 --> 00:08:03,720 actually have high availability across the globe is not needed. 160 00:08:04,280 --> 00:08:07,280 Yeah, people see that and they look up to big organizations 161 00:08:07,280 --> 00:08:09,640 like GitHub where they say, OK, this is what GitHub has. 162 00:08:09,880 --> 00:08:11,400 So we're going to do the same. We're going to build for the 163 00:08:11,400 --> 00:08:15,160 future. 100% And this is in my opinion, again, going back to 164 00:08:15,160 --> 00:08:17,560 the original thought that people chase status. 165 00:08:18,440 --> 00:08:23,280 So, and this was honestly also very badly perpetuated by big 166 00:08:23,280 --> 00:08:26,760 tech companies, right? And a lot of people followed 167 00:08:26,840 --> 00:08:30,240 like in an interview for, for, for. 168 00:08:30,240 --> 00:08:32,520 If you're interviewing for for a place like GitHub, for example, 169 00:08:33,039 --> 00:08:36,559 it's understandable that they would want you or that they want 170 00:08:36,559 --> 00:08:40,480 to explore problems of scale with you just because from day 171 00:08:40,480 --> 00:08:42,799 one you're going to be exposed to these problems. 172 00:08:43,159 --> 00:08:45,960 So what we are, what we are looking for typically is people 173 00:08:45,960 --> 00:08:49,520 who have that experience who are going to come in and actually 174 00:08:49,520 --> 00:08:53,160 use it on day one. Not that we might use it in a 175 00:08:53,160 --> 00:08:55,280 few years time. We just hire for what we need 176 00:08:55,280 --> 00:08:57,120 today. Because let's say you're 177 00:08:57,120 --> 00:09:00,320 shipping, you're shipping features to a service and a lot 178 00:09:00,320 --> 00:09:03,680 of our services have hundreds of millions of requests in short 179 00:09:03,680 --> 00:09:07,520 periods of time. So you cannot really do a lot of 180 00:09:07,520 --> 00:09:10,040 the you. You need to think about a lot of 181 00:09:10,040 --> 00:09:12,160 things, right? You need to think about caching 182 00:09:12,160 --> 00:09:15,200 from the from day zero. You need to think about your 183 00:09:15,200 --> 00:09:16,600 queries someday. You need to think about your 184 00:09:16,600 --> 00:09:18,880 data access patterns. You need to think about non 185 00:09:18,880 --> 00:09:21,360 relational databases and non relational solutions for 186 00:09:21,360 --> 00:09:23,360 whatever you're building. You need to think about how 187 00:09:23,360 --> 00:09:24,600 you're going to gradually deploy this. 188 00:09:24,600 --> 00:09:26,560 You need to think about feature flags, how they're going to play 189 00:09:26,560 --> 00:09:29,040 in this game. You're going to think about 190 00:09:29,040 --> 00:09:31,400 authorisation, authentication, all of the security problems 191 00:09:31,400 --> 00:09:35,120 that might happen when you have introduced a security problem at 192 00:09:35,120 --> 00:09:37,760 some at a place like GitHub, It's, it's going to be on the 193 00:09:37,760 --> 00:09:40,680 news in a week or or less, right? 194 00:09:41,040 --> 00:09:42,720 So you cannot make these mistakes. 195 00:09:43,680 --> 00:09:46,880 It's very tricky. So we look for experience in 196 00:09:46,880 --> 00:09:49,600 these domains so that people they still have there's room to 197 00:09:49,600 --> 00:09:54,720 learn, but they need to deliver from very early on, right. 198 00:09:55,200 --> 00:10:00,080 For smaller companies, they interview for the same, but they 199 00:10:00,080 --> 00:10:02,280 don't need it. And that's where the problems, 200 00:10:02,280 --> 00:10:06,360 that's where the problem stands. If I was in a start up and I'm 201 00:10:06,560 --> 00:10:08,320 I'm doing system design, I would interview. 202 00:10:08,320 --> 00:10:12,760 I would want to hear from a person who has exactly what we 203 00:10:12,760 --> 00:10:16,720 need for today. Forget to 100 million tomorrow. 204 00:10:16,720 --> 00:10:18,760 Sure. We'll start hiring for tomorrow 205 00:10:19,120 --> 00:10:23,240 when we get to it, to be honest. And with the churn rate in our 206 00:10:23,240 --> 00:10:26,080 industry being two or three years, like people don't stay in 207 00:10:26,080 --> 00:10:30,000 the same job for more than that. Why would you, you know, hire 208 00:10:30,000 --> 00:10:32,040 for the next 10 years a person? Yeah. 209 00:10:32,600 --> 00:10:36,320 I feel like people really underestimate like how much they 210 00:10:36,320 --> 00:10:39,160 should or overestimate how much they should design for the 211 00:10:39,160 --> 00:10:41,040 future. Like I'm in a consultancy right 212 00:10:41,040 --> 00:10:42,040 now. I go from assignment to 213 00:10:42,040 --> 00:10:44,920 assignment and some assignments that I've been in, I'm like, the 214 00:10:44,920 --> 00:10:46,760 system is way too complex for what we had. 215 00:10:46,920 --> 00:10:49,000 We used to have 30 engineers. Now we have 8. 216 00:10:49,400 --> 00:10:52,440 And the system we architected that was maintained by 30 people 217 00:10:52,440 --> 00:10:54,440 and now we have a problem because we only have 8 because 218 00:10:54,440 --> 00:10:57,360 budget is running out. We're behind on KPIs because 219 00:10:57,360 --> 00:11:00,280 likely we we worked on a big rocket ship, but we actually 220 00:11:00,280 --> 00:11:03,240 needed a car. We needed to drive and actually 221 00:11:03,240 --> 00:11:05,880 make meters and. And I talk about this stuff in 222 00:11:05,880 --> 00:11:09,240 my system design course because in consulting and when you sell 223 00:11:09,240 --> 00:11:11,880 a solution to a company, the company wants to pay for that 224 00:11:11,880 --> 00:11:14,160 solution. Once they don't understand that 225 00:11:14,200 --> 00:11:18,560 software is evolved, it's not built right. 226 00:11:19,120 --> 00:11:21,520 And the the term here is evolving it. 227 00:11:21,720 --> 00:11:24,280 So software needs to continuously be evolved and it 228 00:11:24,280 --> 00:11:27,200 needs to continuously fight entropy in the sense that you 229 00:11:27,200 --> 00:11:28,680 continuously need to maintain it. 230 00:11:28,920 --> 00:11:33,160 That is a fixed or running cost for maintenance of software that 231 00:11:33,160 --> 00:11:34,760 you don't necessarily find in other industries. 232 00:11:34,960 --> 00:11:37,920 When you buy a car, there is a cost for maintaining it, but 233 00:11:37,920 --> 00:11:41,320 it's not very regular or as regular as software, right. 234 00:11:41,600 --> 00:11:44,480 In our industry, the maintenance cost is is pretty high. 235 00:11:44,680 --> 00:11:47,680 So companies want to pay once for a solution and they wanted 236 00:11:47,680 --> 00:11:51,920 to scale to to the next 10X100X. And that's not very realistic in 237 00:11:51,920 --> 00:11:55,640 our industry at all. We need to build literally for 238 00:11:55,640 --> 00:12:00,720 the next order of of magnitude. So if we are at 0 today, just 239 00:12:00,720 --> 00:12:04,840 build for 10X or 100X. If we're at 10X or 100X, we 240 00:12:04,840 --> 00:12:08,120 build for the other order, right, 1001 million and so on 241 00:12:08,120 --> 00:12:09,320 and so. Forth, what is then your 242 00:12:09,560 --> 00:12:12,240 perspective on building systems that can evolve? 243 00:12:12,240 --> 00:12:14,520 Because some people, you can say, OK, this is the system 244 00:12:14,520 --> 00:12:18,040 design that we have and we're going to continue on this until 245 00:12:18,040 --> 00:12:20,760 we reach a certain level of scale and then we're going to 246 00:12:20,760 --> 00:12:23,520 revamp and say this would be the next iteration. 247 00:12:23,920 --> 00:12:26,920 But some people also say, OK, we have a system now and this is 248 00:12:26,920 --> 00:12:29,520 evolvable to whatever skill we need. 249 00:12:29,520 --> 00:12:31,880 And then they put in the extra effort to make sure that that is 250 00:12:31,880 --> 00:12:36,280 there from the beginning. In our industry, very few 251 00:12:36,280 --> 00:12:40,960 technologies last for like a decade plus and the rest is 252 00:12:41,320 --> 00:12:44,960 changing often. And that's why I personally 253 00:12:44,960 --> 00:12:48,560 don't invest or I wouldn't design a solution that will last 254 00:12:48,560 --> 00:12:52,400 like 1020 thirty years, unlike what we did in the 80s or 90s. 255 00:12:52,400 --> 00:12:54,480 That's why that's how they that was the design mentality. 256 00:12:54,480 --> 00:12:56,920 But things were way less complicated than they are today 257 00:12:58,160 --> 00:13:02,640 and the scale was different. So I would always come with the 258 00:13:02,640 --> 00:13:05,000 mindset that I'm just going to design for the next order of 259 00:13:05,000 --> 00:13:07,040 magnitude and then I'm going to evolve it from there. 260 00:13:07,040 --> 00:13:09,960 And that's going to require another round of investment. 261 00:13:10,080 --> 00:13:13,080 There's going to be continual investments in this and that. 262 00:13:13,080 --> 00:13:15,400 Business people are not going to love this because that makes 263 00:13:16,000 --> 00:13:19,360 accounting much harder, That makes strategic finance much 264 00:13:19,360 --> 00:13:22,400 harder because they cannot predict or anticipate the costs 265 00:13:22,400 --> 00:13:24,920 that might come in the future. They cannot extrapolate from 266 00:13:24,920 --> 00:13:26,960 today. You know they don't like this 267 00:13:26,960 --> 00:13:29,120 fuzziness of software. It's all risk. 268 00:13:29,240 --> 00:13:31,480 Yes. So and and also like they cannot 269 00:13:31,480 --> 00:13:34,080 calculate like their bottom line or projections for the future, 270 00:13:34,080 --> 00:13:35,920 which are things that are very realistic. 271 00:13:35,920 --> 00:13:39,400 Like public, publicly traded companies want to be able to do 272 00:13:39,400 --> 00:13:41,880 these projections and they want to be able to say that, hey, 273 00:13:41,880 --> 00:13:45,600 we're not going to be spending more here in on evolving our 274 00:13:45,600 --> 00:13:48,040 software, but we're going to make much more revenue and 275 00:13:48,040 --> 00:13:49,440 increase our bottom line and margin. 276 00:13:49,760 --> 00:13:52,760 That's what businesses look for. So it's understandable. 277 00:13:52,760 --> 00:13:55,480 But from a software perspective, there's needs to be regular 278 00:13:55,480 --> 00:13:56,920 investments. And I think the only 279 00:13:56,920 --> 00:13:59,160 approachable way, which is something we do at GitHub, is to 280 00:13:59,160 --> 00:14:04,680 continuously revisit these investments on a quarterly by 281 00:14:04,680 --> 00:14:08,120 quarterly, half a year or a year basis, right? 282 00:14:08,680 --> 00:14:12,200 We can make projections for the next 3-4, five years, but the 283 00:14:12,200 --> 00:14:14,800 confidence in these projections is less and less and less the 284 00:14:14,800 --> 00:14:17,080 more time grows. And I think a lot more companies 285 00:14:17,080 --> 00:14:21,480 need to start doing the same. When you say we will then design 286 00:14:21,480 --> 00:14:25,000 for the next level the order of magnitude for the next level, 287 00:14:25,320 --> 00:14:27,880 how far in the horizon do you look at the with the GitHub 288 00:14:27,880 --> 00:14:30,920 Actions example that you had, you said, OK, five years, but 289 00:14:30,920 --> 00:14:32,520 it's that like an arbitrary thing or how it? 290 00:14:32,520 --> 00:14:34,720 Depends on the curve, right? It depends on the curve like 291 00:14:34,720 --> 00:14:38,320 GitHub Actions has been growing massively over since we, we, we 292 00:14:38,480 --> 00:14:41,920 brought it up at the beginning and we're introducing more and 293 00:14:41,920 --> 00:14:44,680 more features that are increasing the adoption. 294 00:14:45,200 --> 00:14:48,640 So the curve, we can see how it looks like, but it might change 295 00:14:48,640 --> 00:14:51,120 at any point in time, right? It can be disrupted, goes to 0, 296 00:14:51,120 --> 00:14:53,520 or it can continue growing exponentially. 297 00:14:53,960 --> 00:14:58,080 So often the hockey stick that a lot of tech start-ups talk about 298 00:14:58,080 --> 00:15:01,240 like exponential growth, it can appear and you can start seeing 299 00:15:01,240 --> 00:15:02,480 it. And when you start seeing it, 300 00:15:02,720 --> 00:15:05,600 you know, if you have a solution like actions, companies that 301 00:15:05,600 --> 00:15:08,720 migrate to it are not going to flip flop in very short periods 302 00:15:08,720 --> 00:15:10,520 of time. So you can have some confidence 303 00:15:10,520 --> 00:15:14,080 that, OK, this trend is going to last for a year or two or three 304 00:15:14,080 --> 00:15:16,440 or four, right? Nothing lasts forever, 305 00:15:16,440 --> 00:15:19,920 obviously, but you can start thinking in that direction and 306 00:15:19,920 --> 00:15:21,920 then based on that you can make investment decisions. 307 00:15:22,080 --> 00:15:24,440 Got you. I've had many discussions also 308 00:15:24,440 --> 00:15:27,080 in the past when we're talking about our software architecture 309 00:15:27,560 --> 00:15:30,520 in something that can be very specific and also purposeful 310 00:15:30,520 --> 00:15:34,040 built versus setting it up in a generic way potentially towards 311 00:15:34,040 --> 00:15:37,040 the future because we have ambitions and hopes that we have 312 00:15:37,520 --> 00:15:39,160 X amount of solutions that are similar. 313 00:15:39,160 --> 00:15:42,360 So we make a generic right now. What is your perspective on 314 00:15:42,400 --> 00:15:45,240 making something specific versus generic in the first place? 315 00:15:46,120 --> 00:15:48,080 I like solving specific problems. 316 00:15:48,200 --> 00:15:51,640 I don't like solving generic problems because how can you 317 00:15:51,640 --> 00:15:53,560 make trade-offs then, right? What? 318 00:15:53,560 --> 00:15:55,080 What? In software, there's always 319 00:15:55,080 --> 00:15:57,240 trade-offs. So how do you choose these 320 00:15:57,240 --> 00:15:59,240 trade-offs? You can build something super 321 00:15:59,240 --> 00:16:01,920 generic, sure. That basically is what building 322 00:16:01,920 --> 00:16:05,920 a framework that can be a toolbox and give you all sorts 323 00:16:05,920 --> 00:16:09,200 of solutions to all sorts of hypothetical problems that you 324 00:16:09,200 --> 00:16:11,720 might or might not have. That's not the North Star I 325 00:16:11,720 --> 00:16:13,680 follow. When I design software at GitHub 326 00:16:14,080 --> 00:16:18,840 with my team, we are very specific about not over 327 00:16:18,840 --> 00:16:22,320 engineering things and we solve for the problems we have today. 328 00:16:23,040 --> 00:16:25,880 So for example, we'd never introduce caching until we 329 00:16:25,880 --> 00:16:30,600 really need it and we never over optimize until we start seeing 330 00:16:30,600 --> 00:16:34,520 problems sometimes, Sometimes we we know that we're going to hit 331 00:16:34,520 --> 00:16:36,160 this problem in a few months and we're not going to get the 332 00:16:36,160 --> 00:16:37,680 investment. So we solved it right now 333 00:16:37,800 --> 00:16:40,960 because it makes sense. But we don't over engineer 334 00:16:40,960 --> 00:16:42,560 solutions. We don't start jumping into 335 00:16:42,560 --> 00:16:46,200 things, for example, we don't necessarily jump to no SQL at 336 00:16:46,200 --> 00:16:47,760 the beginning. We just start regularly 337 00:16:47,760 --> 00:16:50,120 relational databases. You know, we build regular 338 00:16:50,120 --> 00:16:53,920 tables if we need, if we need actually relational content. 339 00:16:54,080 --> 00:16:57,120 Sometimes relational databases can always get so far. 340 00:16:57,560 --> 00:17:02,040 So we start needing to rethink our solutions here and we need 341 00:17:02,040 --> 00:17:03,480 to start going towards non relational. 342 00:17:03,480 --> 00:17:06,880 Even if we need the relational consistency or the consistency 343 00:17:06,880 --> 00:17:10,240 of relational databases, we need to start thinking about how can 344 00:17:10,240 --> 00:17:13,920 we move that to the application layer and start using other 345 00:17:13,920 --> 00:17:16,800 solutions that persist data that can help us scale. 346 00:17:17,440 --> 00:17:19,720 There are some efforts, for example where we start using 347 00:17:19,720 --> 00:17:25,560 Cosmos or Cosmos DB and things like that, but we never start 348 00:17:25,560 --> 00:17:28,319 exploring these until we hit really massive problems with our 349 00:17:28,319 --> 00:17:30,920 database clusters like our primaries cannot keep up. 350 00:17:31,120 --> 00:17:34,680 The IO is pretty high, write operations are substantially 351 00:17:34,680 --> 00:17:38,200 big. We cannot scale these anymore. 352 00:17:38,440 --> 00:17:41,320 Sharding is not an option. Application layer sharding is 353 00:17:41,320 --> 00:17:44,440 not an option as well. When it becomes not an option, 354 00:17:44,440 --> 00:17:47,680 sometimes it is. So we start thinking about how 355 00:17:47,680 --> 00:17:50,480 can we redesign this and how can we migrate the data. 356 00:17:50,640 --> 00:17:54,000 And migrations, as much as they are painful, they are part of 357 00:17:54,000 --> 00:17:55,640 the job. Yeah, interesting. 358 00:17:55,640 --> 00:17:58,640 And we do go through them. I'm wondering when we're talking 359 00:17:58,640 --> 00:18:01,120 about system design and then specifically practical 360 00:18:01,120 --> 00:18:03,680 experience, what your perspective is on someone to 361 00:18:04,120 --> 00:18:06,120 really get a better understanding of the theory but 362 00:18:06,120 --> 00:18:07,600 also be able to put it in practice. 363 00:18:07,600 --> 00:18:10,720 You you already mentioned that for example, like GitHub, you 364 00:18:10,720 --> 00:18:13,680 need to have a certain level of experience under your belt and 365 00:18:13,680 --> 00:18:16,520 then you can work at GitHub where we have orders of 366 00:18:16,520 --> 00:18:18,960 magnitude with regards to scale. This is the vicious cycle, 367 00:18:18,960 --> 00:18:21,080 right? So do you, how do you, how do 368 00:18:21,080 --> 00:18:23,200 you build experience that is required by this type of 369 00:18:23,200 --> 00:18:26,480 companies, but there's no other type of company that's going to 370 00:18:26,480 --> 00:18:29,400 give you that experience. Unfortunately, there's that's 371 00:18:29,400 --> 00:18:33,120 that's the reason why there is a proliferation of a lot of system 372 00:18:33,120 --> 00:18:35,200 design courses and things online. 373 00:18:35,880 --> 00:18:39,320 And quite honestly, passing that into passing the interview 374 00:18:39,320 --> 00:18:44,000 threshold for companies like GitHub that is achievable by 375 00:18:44,000 --> 00:18:47,000 learning theoretically these concepts OK and not necessarily 376 00:18:47,000 --> 00:18:48,640 having hands on experience with them. 377 00:18:50,240 --> 00:18:56,760 The bar feels high, but right now it's been sort of exploited 378 00:18:56,760 --> 00:19:00,160 to the point where a lot of the tricks and tips and what not 379 00:19:00,160 --> 00:19:02,040 already available very much online. 380 00:19:02,440 --> 00:19:04,760 Like hello interview guys, for example, they have this YouTube 381 00:19:04,760 --> 00:19:06,840 channel. They have pretty much covered a 382 00:19:06,840 --> 00:19:09,640 lot of the topics that you might get asked in a system design 383 00:19:09,640 --> 00:19:12,480 interview and they go deep. Like they explain what Kafka is, 384 00:19:12,480 --> 00:19:14,240 what event streaming is. They explain right as the 385 00:19:14,240 --> 00:19:16,720 internals how it works, when do you use it, when not to use it. 386 00:19:17,000 --> 00:19:19,120 They explain the differences between relational and non 387 00:19:19,120 --> 00:19:21,320 relational databases. They explain caching, how to 388 00:19:21,640 --> 00:19:24,240 implement caching in specific scenarios, and they give 389 00:19:24,240 --> 00:19:27,200 practical hands on problems where you can actually learn how 390 00:19:27,200 --> 00:19:30,480 to effectively utilise all of these different components to 391 00:19:30,480 --> 00:19:33,000 come up with a relatively scalable solution. 392 00:19:33,520 --> 00:19:37,200 And they give you tips also on how to approach the discussion 393 00:19:37,200 --> 00:19:39,480 of scale within a system design interview. 394 00:19:40,040 --> 00:19:41,480 And I think they do a pretty good job at it. 395 00:19:41,640 --> 00:19:44,080 And I think that's enough because a lot of people who go 396 00:19:44,080 --> 00:19:46,480 to big tech will go to Google MO, they don't necessarily have 397 00:19:46,480 --> 00:19:48,760 that hands on experience beforehand, even though the 398 00:19:48,760 --> 00:19:51,000 interview is looking for that hands on experience. 399 00:19:51,640 --> 00:19:55,040 But you know, with these, because we hacked the people 400 00:19:55,040 --> 00:19:58,640 hacked the game. So the signal is given to the 401 00:19:58,640 --> 00:20:01,120 interviewer. And then people when they have 402 00:20:01,120 --> 00:20:04,920 these, this foundation, they can actually do a relatively OK job 403 00:20:04,920 --> 00:20:07,640 on when they join. And they're going to obviously 404 00:20:07,640 --> 00:20:09,760 aren't going to be alone, right? So you're never going to join a 405 00:20:09,760 --> 00:20:12,280 team and start building Greenfield stuff from day zero. 406 00:20:12,520 --> 00:20:15,120 It rarely happens. You're going to join teams that 407 00:20:15,120 --> 00:20:17,080 already established. So there's going to be people 408 00:20:17,080 --> 00:20:19,560 with experience more senior than you were going to give you 409 00:20:19,560 --> 00:20:21,560 guidance and review your solutions, your design. 410 00:20:21,760 --> 00:20:24,200 And so on and so forth. And that's why people make it 411 00:20:24,200 --> 00:20:26,840 right. But if you are interviewed for 412 00:20:26,840 --> 00:20:30,080 experience and you join a Greenfield project, you, you're 413 00:20:30,080 --> 00:20:33,200 going to own your mistakes. And people do make mistakes 414 00:20:33,200 --> 00:20:34,000 often. Yeah. 415 00:20:34,000 --> 00:20:36,200 When it comes to these solutions, not everything big 416 00:20:36,200 --> 00:20:40,720 tech ships is a great feature or operates well in the world. 417 00:20:40,720 --> 00:20:44,960 And often we discover that oh, this was a mistake and it was 418 00:20:44,960 --> 00:20:48,080 actually very costly and some companies fail because of these. 419 00:20:48,320 --> 00:20:51,200 Gotcha, right? Any failures or mistakes that 420 00:20:51,200 --> 00:20:53,400 are top of mind for you that you can share for other people to 421 00:20:53,400 --> 00:20:55,200 learn? Tricky, no? 422 00:20:55,200 --> 00:20:59,600 I want to keep my job so. That's fair, that's fair. 423 00:21:00,120 --> 00:21:04,280 For me, looking at what we do nowadays, I feel with AI tools, 424 00:21:04,280 --> 00:21:06,200 I'm way more productive in actually writing code. 425 00:21:06,760 --> 00:21:09,400 And I feel like when you amplify the amount of code that you 426 00:21:09,400 --> 00:21:13,000 write, you might also write yourself into a, a bottleneck 427 00:21:13,120 --> 00:21:14,560 basically. So I feel like software 428 00:21:14,560 --> 00:21:17,760 architecture and specifically system design from the start, 429 00:21:17,760 --> 00:21:21,560 having a better understanding, especially I feel like like I do 430 00:21:21,560 --> 00:21:24,600 now, I need to grow there. And I feel like it's going to be 431 00:21:24,600 --> 00:21:28,720 a more important skill to indeed figure out what are we designing 432 00:21:28,720 --> 00:21:30,680 for, what makes sense, what would be the next order of 433 00:21:30,680 --> 00:21:34,600 magnitude after and actually make sure to convince people and 434 00:21:34,600 --> 00:21:37,240 have a certain level of buy in. We're always working in teams. 435 00:21:37,400 --> 00:21:40,480 Also from a business standpoint, how would I, for example, say 436 00:21:40,720 --> 00:21:43,000 we're going to design for this until we reach scale and then 437 00:21:43,000 --> 00:21:45,120 we're going to need to revamp. And this is what that's going to 438 00:21:45,320 --> 00:21:47,840 entail for people that don't understand how to build 439 00:21:47,840 --> 00:21:49,480 software. Understand the business 440 00:21:49,480 --> 00:21:51,240 constraints. So you're never going to be able 441 00:21:51,240 --> 00:21:54,840 to convince the business folks about of something technically. 442 00:21:55,440 --> 00:21:57,040 They're just. It's too abstract. 443 00:21:57,880 --> 00:22:01,320 Even if it feels too intuitive for us, for them it's. 444 00:22:01,920 --> 00:22:02,840 Magic. Yeah. 445 00:22:03,440 --> 00:22:06,600 And even if they try to understand how things work, 446 00:22:06,720 --> 00:22:08,600 they're never going to comprehend the magnitude of 447 00:22:08,600 --> 00:22:11,240 problems and they're never going to have have this intuition 448 00:22:11,240 --> 00:22:15,800 about how software is and how not hard, you know how how 449 00:22:15,840 --> 00:22:20,360 evolvable it is. So it's our job to get closer to 450 00:22:20,360 --> 00:22:22,360 their side. Some people say, no, we want the 451 00:22:22,360 --> 00:22:25,920 business to understand they're not gonna it's trickier. 452 00:22:25,920 --> 00:22:29,440 It's easier for you to acquire or assimilate some of the not 453 00:22:29,440 --> 00:22:33,000 everything, some of the business constraints and discuss them 454 00:22:33,000 --> 00:22:35,080 from that perspective. And that's why a lot of 455 00:22:35,080 --> 00:22:38,600 engineers who grow are very good at understanding the business 456 00:22:38,600 --> 00:22:41,720 constraints and then discussing the technical solutions within 457 00:22:41,720 --> 00:22:45,560 those constraints. So for example, I used to work 458 00:22:45,560 --> 00:22:47,520 in the container terminal industry for a while. 459 00:22:47,520 --> 00:22:50,160 We built a huge container terminal. 460 00:22:50,480 --> 00:22:53,040 We furnished everything from the fibre optics layer all the way 461 00:22:53,040 --> 00:22:55,400 to the three tier data centre with all of the enterprise 462 00:22:55,400 --> 00:22:58,400 applications running, running on it and the operating system for 463 00:22:58,400 --> 00:23:00,120 the container terminal. And it's one of the most massive 464 00:23:00,120 --> 00:23:04,440 operations you can ever imagine, one of the most hazardous as 465 00:23:04,440 --> 00:23:07,960 well. So the folks there, they're as 466 00:23:07,960 --> 00:23:11,800 far away from tech as possible. You're not never going to find 467 00:23:11,800 --> 00:23:13,760 the terminal operator who's going to understand what it 468 00:23:13,760 --> 00:23:16,800 means that your database is running hot and you cannot 469 00:23:16,800 --> 00:23:19,040 support their queries. All they care about is I have a 470 00:23:19,040 --> 00:23:23,240 ship here who's docked. There's like 10,000 containers 471 00:23:23,240 --> 00:23:24,920 on it. I need to empty them into my 472 00:23:24,920 --> 00:23:27,000 yard. I have a very fixed window of 473 00:23:27,000 --> 00:23:29,480 time and if I don't do it in that window of time, this is 474 00:23:29,480 --> 00:23:33,840 going to cost me money. We were operating at 12% 475 00:23:33,840 --> 00:23:35,760 capacity. That terminal was generating 476 00:23:35,760 --> 00:23:44,040 about $50,000 per hour, so 12%. So you can imagine if we get 477 00:23:44,040 --> 00:23:47,440 delayed, every minute of delay is actually money that's 478 00:23:47,520 --> 00:23:50,320 disappearing. So this is how you need to 479 00:23:50,320 --> 00:23:53,720 discuss problems with and and investments and solutions. 480 00:23:54,080 --> 00:23:56,680 You need to understand what the impact is, what the impact is on 481 00:23:56,680 --> 00:23:58,400 the operators. And sometimes it's life 482 00:23:58,400 --> 00:24:02,640 threatening impact, right, If your software fails when ASTS, 483 00:24:03,200 --> 00:24:07,400 when the crane is offloading a container, this can be a very 484 00:24:07,640 --> 00:24:11,040 life threatening situation. You cannot really have your 485 00:24:11,040 --> 00:24:12,480 software malfunction at these points. 486 00:24:12,480 --> 00:24:16,600 So snappiness of the software, sub millisecond latencies, all 487 00:24:16,600 --> 00:24:19,440 of these things matter, right? So you need to approach the 488 00:24:19,440 --> 00:24:22,280 discussions with the stakeholders by understanding 489 00:24:22,280 --> 00:24:23,840 them first. So what I've done for example, 490 00:24:23,840 --> 00:24:28,640 in that industry is I've literally sat on a truck and 491 00:24:28,640 --> 00:24:31,200 went there and I sat with every single individual who works in 492 00:24:31,200 --> 00:24:33,080 that terminal to really understand what they go through 493 00:24:33,080 --> 00:24:36,360 on a daily basis. So a truck driver who's driving 494 00:24:36,360 --> 00:24:39,720 a truck for a six 7-8 hours and it was in Saudi Arabia in 495 00:24:39,720 --> 00:24:43,000 scorching heat, it's not going to understand why the button 496 00:24:43,000 --> 00:24:46,640 that they clicked is just is so slow. 497 00:24:46,720 --> 00:24:48,760 Doesn't matter. Doesn't he doesn't care, right? 498 00:24:48,880 --> 00:24:52,280 He just wants it to just work. So you got to understand all of 499 00:24:52,280 --> 00:24:54,400 these perspectives and then when you do, you can start 500 00:24:54,400 --> 00:24:56,560 approaching discussions from that vantage point. 501 00:24:56,720 --> 00:25:00,400 And this applies to banks, this applies to hospitals, to any 502 00:25:00,400 --> 00:25:02,160 other industry. So understand the industry, 503 00:25:02,520 --> 00:25:04,920 understand the business constraints, and then any 504 00:25:04,920 --> 00:25:07,520 technical solution you want to discuss an investment, you can 505 00:25:07,520 --> 00:25:09,520 approach it from that vantage point and you're going to have 506 00:25:09,520 --> 00:25:12,320 much more success in these conversations. 507 00:25:12,680 --> 00:25:14,640 Yeah, interesting. I feel like the the opposite 508 00:25:14,640 --> 00:25:17,040 then also holds true. So if you do understand the 509 00:25:17,040 --> 00:25:20,360 business context and you don't have a case for why you need to 510 00:25:20,480 --> 00:25:22,720 work on tech, that why you need to scale, why you need to fix 511 00:25:22,720 --> 00:25:25,880 some of the issues, then there might not be an actual case. 512 00:25:25,880 --> 00:25:27,880 And right now is not the right time to do so. 513 00:25:28,640 --> 00:25:31,960 I do feel like it's, it is a lot of prep work that you have to 514 00:25:31,960 --> 00:25:33,400 do. It's way easier to talk about 515 00:25:33,400 --> 00:25:35,200 the technical things, right? Because that's what you see, 516 00:25:35,200 --> 00:25:38,400 that's what you perceive latency, numbers, storage, 517 00:25:38,400 --> 00:25:40,760 scalability, that's what you look at. 518 00:25:41,200 --> 00:25:44,040 And then reframing it and saying, OK, what is the the 519 00:25:44,040 --> 00:25:46,040 impact of the business? What is the cost per feature? 520 00:25:46,040 --> 00:25:49,040 And what if we have slower delivery rate compared to a 521 00:25:49,040 --> 00:25:51,920 faster and a new future? Talking that language is very 522 00:25:51,920 --> 00:25:53,360 different from what you're used to. 523 00:25:53,520 --> 00:25:55,360 Absolutely. And the trickiest part in my 524 00:25:55,360 --> 00:25:57,640 opinion, is when the stakeholders are not transparent 525 00:25:57,640 --> 00:26:00,720 about their numbers. So they're never going to tell 526 00:26:00,720 --> 00:26:03,640 you like, oh, we're making this $10 million investment today in 527 00:26:03,640 --> 00:26:06,920 this piece of software. Because the investor, one of the 528 00:26:06,920 --> 00:26:09,480 biggest investors we have, is willing to put that money in 529 00:26:09,480 --> 00:26:13,000 right now, but nobody has the guts to go tell him that, no, we 530 00:26:13,000 --> 00:26:16,000 need another 10 million in 10 years, right? 531 00:26:17,000 --> 00:26:19,160 And nobody's going to come in and tell you that. 532 00:26:19,640 --> 00:26:22,920 But you need to also think about it, try to extract that 533 00:26:22,920 --> 00:26:26,080 information, try to understand who, who's funding this, What is 534 00:26:26,080 --> 00:26:30,280 funding this? What is critical is, is, is the 535 00:26:30,280 --> 00:26:32,840 business in jeopardy? Is it right now under a lot of 536 00:26:32,840 --> 00:26:35,240 scrutiny? Is the bottom line not working? 537 00:26:35,320 --> 00:26:37,720 Is the margin of profit not that high? 538 00:26:38,400 --> 00:26:40,920 What, what is driving this particular investment right now? 539 00:26:41,000 --> 00:26:43,640 Is it more strategic? So I worked in building banks, 540 00:26:43,640 --> 00:26:46,600 for example, in the in the Gulf, I worked as a consultant as 541 00:26:46,600 --> 00:26:50,320 well, right? So there were banks that were 542 00:26:50,320 --> 00:26:53,000 wanted to make a one shot investment into what they 543 00:26:53,000 --> 00:26:56,800 thought it was their future. And they had a lump sum of money 544 00:26:56,800 --> 00:26:59,440 that they wanted to put down once and build software that 545 00:26:59,440 --> 00:27:01,920 will last them for 10 years. They're not going to. 546 00:27:01,920 --> 00:27:05,120 They, nobody has the guts to come in and tell somebody, an 547 00:27:05,120 --> 00:27:08,600 executive who has no time whatsoever that hey, well, this 548 00:27:08,600 --> 00:27:11,520 investment is going to last you maybe like 2-3, four years, but 549 00:27:11,520 --> 00:27:14,080 you need to put in also another million every year to maintain 550 00:27:14,080 --> 00:27:17,040 it and maybe even another 10 million in 5-6 years because you 551 00:27:17,040 --> 00:27:18,680 need to keep up with their new trends. 552 00:27:19,280 --> 00:27:21,520 Nobody has the guts to come in and say that at the beginning 553 00:27:21,520 --> 00:27:25,080 because then the decision maker might say, Oh well this is not 554 00:27:25,080 --> 00:27:27,320 worth it for me anymore. We might just scratch it 555 00:27:27,320 --> 00:27:28,320 completely. Precisely. 556 00:27:28,680 --> 00:27:32,040 What I've also seen is that some organisations operate with a 557 00:27:32,040 --> 00:27:35,520 number of engineers and then from an outside standpoint I 558 00:27:35,520 --> 00:27:37,120 have no clue what those engineers are doing. 559 00:27:37,240 --> 00:27:40,480 Like if I look at a specific e-commerce website, they might 560 00:27:40,480 --> 00:27:43,720 have 2000 engineers where kind of a similar one with a similar 561 00:27:43,720 --> 00:27:45,360 level of skill might have a few 100. 562 00:27:45,920 --> 00:27:48,920 And then I feel like the few 100 engineers, they need to have a 563 00:27:48,920 --> 00:27:52,440 bigger landscape of ownership. Understanding what they do in 564 00:27:52,440 --> 00:27:55,520 the context on day-to-day on a business side is easier for them 565 00:27:55,880 --> 00:27:58,920 than being part of a group of 2000 engineers that kind of does 566 00:27:58,920 --> 00:28:01,480 the same scale. Feel like if you're a cog, it's 567 00:28:01,480 --> 00:28:05,000 very hard to argue what kind of optimizing your little cog is 568 00:28:05,000 --> 00:28:06,280 going to do for the greater good. 569 00:28:06,280 --> 00:28:10,960 One thing I, I one thing a lot of people hate, but I think is 570 00:28:10,960 --> 00:28:15,080 very functional and a lot of the companies that operate based on 571 00:28:15,080 --> 00:28:20,200 the San Francisco Silicon Valley model is the ruthlessness in 572 00:28:20,200 --> 00:28:25,600 terms of optimizing how engineers work and layoffs. 573 00:28:26,000 --> 00:28:31,120 So in Europe, layoffs are not very famous or very well 574 00:28:31,120 --> 00:28:33,960 received and I don't think they are very well received in the US 575 00:28:33,960 --> 00:28:36,760 as well. But they are a if they are an 576 00:28:36,760 --> 00:28:39,720 effective mechanism, even though it's dehumanizing, but it is an 577 00:28:39,720 --> 00:28:44,480 effective mechanism to recalibrate how people or where 578 00:28:44,480 --> 00:28:47,400 people put their attention and what they are focusing on. 579 00:28:47,960 --> 00:28:51,320 So in a lot of situations when layoffs happen, there's a huge 580 00:28:51,400 --> 00:28:54,680 product features that are cut entirely like we don't need this 581 00:28:54,680 --> 00:28:57,440 anymore. And it's it's more expensive to 582 00:28:57,440 --> 00:29:00,080 repurpose the skills of those same engineers in other areas. 583 00:29:00,280 --> 00:29:02,000 So let's just cut it off immediately. 584 00:29:02,640 --> 00:29:05,400 Hire new engineers that are more experienced in that particular 585 00:29:05,400 --> 00:29:07,680 domain, get them to focus on this right away. 586 00:29:08,680 --> 00:29:14,480 So this rapid flexibility and moving rotating resources or 587 00:29:14,560 --> 00:29:18,480 people basically allows these companies to be much more nimble 588 00:29:19,000 --> 00:29:22,760 and effectively or more effectively allocate engineers 589 00:29:22,760 --> 00:29:24,640 to particular problems that matter today. 590 00:29:25,160 --> 00:29:29,800 The second thing I also think is a good that separates a lot of 591 00:29:29,800 --> 00:29:33,560 the big tech companies from other companies is your work or 592 00:29:33,560 --> 00:29:37,840 your reward bonuses, growth, whatever is associated with your 593 00:29:37,840 --> 00:29:40,880 business impact, not your software engineering impact. 594 00:29:41,280 --> 00:29:43,920 So you can come in and say, oh, I built the most, the biggest 595 00:29:43,920 --> 00:29:47,320 Kubernetes cluster you know, known to the planet. 596 00:29:47,520 --> 00:29:48,920 It's beautiful. It's amazing. 597 00:29:49,520 --> 00:29:52,320 You're not going to get any of that or any recognition for it 598 00:29:52,360 --> 00:29:55,200 unless you justify why that was important. 599 00:29:55,560 --> 00:29:58,200 What was the actual landed impact on the business? 600 00:29:58,440 --> 00:30:01,160 So what did it contribute to in terms of our revenue? 601 00:30:01,160 --> 00:30:04,520 Did it help us grow? Did it help us attract more 602 00:30:04,520 --> 00:30:06,760 customers? Did it solve a very hard problem 603 00:30:06,760 --> 00:30:08,480 for us? Did it affect developer 604 00:30:08,480 --> 00:30:11,200 experience, our people more? And you need to have numbers, 605 00:30:11,520 --> 00:30:15,600 not just fluffy words. So I think that's also another 606 00:30:15,600 --> 00:30:19,560 very effective way to reallocate attention of software engineers. 607 00:30:19,760 --> 00:30:22,000 And it's very easy for us, also software engineers, to drift 608 00:30:22,000 --> 00:30:24,600 into the comfort zones. So I'm building something. 609 00:30:24,600 --> 00:30:25,840 I'm comfortable in it. Yeah. 610 00:30:26,600 --> 00:30:27,920 And nobody's questioning me on it. 611 00:30:27,920 --> 00:30:29,200 Nobody understands what I'm doing. 612 00:30:29,400 --> 00:30:31,160 I just keep doing the same thing everyday. 613 00:30:31,680 --> 00:30:34,120 Yeah, I feel like I've also shared this previously on the 614 00:30:34,120 --> 00:30:37,200 podcast, some engineers that I've met and they love the 615 00:30:37,200 --> 00:30:39,840 technical side of things. And when you let them go wild 616 00:30:39,840 --> 00:30:42,720 when there's no business context or direction, they will build 617 00:30:42,720 --> 00:30:45,280 you a rocket ship and they will really enjoy doing it. 618 00:30:46,000 --> 00:30:50,240 There is a crafts, the craftsmanship aspect of software 619 00:30:50,240 --> 00:30:51,720 engineering. It's still there, you know, 620 00:30:51,760 --> 00:30:52,960 there there is an aesthetic to it. 621 00:30:52,960 --> 00:30:55,080 There is like it's fun, it's enjoyable. 622 00:30:55,640 --> 00:30:59,080 But I always in my even my social media stuff like I always 623 00:30:59,240 --> 00:31:03,160 strive to communicate that when you work professionally as a 624 00:31:03,160 --> 00:31:05,240 software engineer, this is not practising a hobby. 625 00:31:05,960 --> 00:31:11,600 And I think a lot of this craftsmanship thinking it comes 626 00:31:11,600 --> 00:31:13,600 from the fact that a lot of people went into software 627 00:31:13,600 --> 00:31:15,920 engineering because programming was a hobby for them, myself 628 00:31:15,920 --> 00:31:17,280 included. I started writing code when I 629 00:31:17,280 --> 00:31:18,880 was 12. I thought that this is amazing 630 00:31:18,880 --> 00:31:22,040 if I can make it my job perfect. But the job is very different 631 00:31:22,840 --> 00:31:25,640 than practicing code for the sake of writing code and the 632 00:31:25,640 --> 00:31:29,200 aesthetics and the fun of it. Sometimes you are lucky to be 633 00:31:29,200 --> 00:31:32,960 able to bring that into your work, but most often you're not 634 00:31:32,960 --> 00:31:34,880 really solving for the aesthetic, you're solving a 635 00:31:35,400 --> 00:31:38,200 business problem. And you need to keep that in 636 00:31:38,200 --> 00:31:41,200 mind always and often. It's not about the beauty of 637 00:31:41,200 --> 00:31:43,840 yourself. You can, if you can build a 638 00:31:43,840 --> 00:31:47,040 beautiful solution and solve the business problem effectively, 639 00:31:47,480 --> 00:31:48,960 fantastic. That's the cherry on top. 640 00:31:49,960 --> 00:31:52,320 But the priority is for the business problem. 641 00:31:52,800 --> 00:31:56,360 And sometimes solving business problems means building software 642 00:31:56,360 --> 00:32:00,040 that is good enough. Good enough for today, right? 643 00:32:00,400 --> 00:32:02,400 Doesn't have to be good enough for tomorrow. 644 00:32:02,400 --> 00:32:05,440 Maybe it's horrible for tomorrow, but it's just keeps on 645 00:32:05,440 --> 00:32:08,440 functioning. And this investment we did and 646 00:32:08,480 --> 00:32:11,400 the good enough, it's going to give us a a certain runway and 647 00:32:11,400 --> 00:32:14,400 we should be OK with that. I think the we should be OK with 648 00:32:14,400 --> 00:32:15,520 that. That's what I've seen where it's 649 00:32:15,520 --> 00:32:18,440 challenging for people where they say, OK, I'm a little bit 650 00:32:18,440 --> 00:32:21,280 of a perfectionist. I value quality in what I do on 651 00:32:21,280 --> 00:32:24,120 a day-to-day. My job is basically part of who 652 00:32:24,120 --> 00:32:26,240 I am. And if I don't deliver the 653 00:32:26,240 --> 00:32:28,640 highest quality that I can in this aspect, like I'm doing 654 00:32:28,640 --> 00:32:31,960 myself with this justice. And it's very like, if I lay it 655 00:32:31,960 --> 00:32:34,560 out like that, it might sound selfish, but those people have 656 00:32:34,560 --> 00:32:36,440 no clue that what they're saying is selfish. 657 00:32:36,440 --> 00:32:38,600 They genuinely think it's best for the organization. 658 00:32:38,920 --> 00:32:41,040 There's just some misinformation and misunderstanding. 659 00:32:41,040 --> 00:32:44,160 Because there's a dogmatic aspect of software engineering 660 00:32:44,160 --> 00:32:47,680 and it was perpetuated in the previous era into two thousands. 661 00:32:47,680 --> 00:32:51,080 2000 I when I ventured and working professionally at 662 00:32:51,080 --> 00:32:54,720 software engineering 2007 8-9, there was a lot of dogma. 663 00:32:54,720 --> 00:32:57,200 Like there's a lot of this is how you do things and this is 664 00:32:57,200 --> 00:32:59,320 how you should do things. And if you do things any other 665 00:32:59,320 --> 00:33:02,480 way, you're wrong. Yeah, and part of that is 666 00:33:03,320 --> 00:33:06,160 elegance of code, code cleanliness, code quality. 667 00:33:06,160 --> 00:33:08,360 We're all raised on this these these concepts, right? 668 00:33:08,360 --> 00:33:11,280 And they're important. And everybody always complained 669 00:33:11,280 --> 00:33:13,600 about bad code and horrible code because it was difficult to 670 00:33:13,600 --> 00:33:15,240 maintain. Nobody enjoys that. 671 00:33:15,280 --> 00:33:17,120 You're going to make it very difficult for the future 672 00:33:17,120 --> 00:33:18,480 engineers to solve these problems. 673 00:33:19,440 --> 00:33:23,520 But sometimes, you know, you don't have future engineers to 674 00:33:23,520 --> 00:33:25,280 solve these problems. Sometimes nobody's going to 675 00:33:25,280 --> 00:33:27,320 touch this code for decades to come. 676 00:33:27,720 --> 00:33:30,280 It's OK if it's just, it just works. 677 00:33:30,960 --> 00:33:33,160 And then we ended up on the complete other end of the 678 00:33:33,160 --> 00:33:36,880 spectrum where we try to clean up everything that we started 679 00:33:36,880 --> 00:33:40,280 adopting all sorts of design overcomplicated abstractions 680 00:33:40,280 --> 00:33:43,920 that are are just horrible to read, horrible to reason about. 681 00:33:44,320 --> 00:33:48,000 It takes you decades to become proficient in just reading that 682 00:33:48,000 --> 00:33:51,120 type of code. And then when you write it, it 683 00:33:51,120 --> 00:33:53,760 gets even more complicated and it's very difficult to maintain. 684 00:33:54,800 --> 00:33:57,120 And big Tech, and I always tell my colleagues and the juniors 685 00:33:57,120 --> 00:34:01,560 that report to me, simple is complicated enough, especially 686 00:34:01,560 --> 00:34:04,640 at scale. So just find it in the dumbest, 687 00:34:04,920 --> 00:34:07,600 most simple way possible. This is why I also love Go, for 688 00:34:07,600 --> 00:34:11,239 example, as a language, right? It's amazing. 689 00:34:11,480 --> 00:34:14,880 It's dumb. You don't have to think too 690 00:34:14,880 --> 00:34:16,480 much. It's just all in your face. 691 00:34:16,800 --> 00:34:19,239 Whenever you want to understand how something is built, just 692 00:34:19,239 --> 00:34:21,199 trace it around. It's there, it's there. 693 00:34:21,719 --> 00:34:23,120 Fantastic. I love that. 694 00:34:24,360 --> 00:34:27,679 And when the situations where we're building at scale, I don't 695 00:34:27,679 --> 00:34:30,560 want to reason about abstractions, I don't want to 696 00:34:30,560 --> 00:34:34,159 think about edge cases, I don't want to think about complicated 697 00:34:34,159 --> 00:34:38,239 memory locations and complicated memory structures. 698 00:34:38,600 --> 00:34:40,199 You know, I just want things to be simple. 699 00:34:40,679 --> 00:34:45,120 Memory leaks happen often and they are very catastrophic at 700 00:34:45,120 --> 00:34:47,159 scale. I don't want to think about 701 00:34:47,159 --> 00:34:48,320 these things. I don't want to think about how 702 00:34:48,320 --> 00:34:50,679 my garbage collector is going to, you know, shut down the 703 00:34:50,679 --> 00:34:55,239 whole world and start causing multi second latency on my API 704 00:34:55,239 --> 00:34:58,440 requests, which at scale again become a gigantic problem for 705 00:34:58,440 --> 00:35:00,120 me. I just want things to be simple, 706 00:35:00,480 --> 00:35:03,600 easy to reason about and that's it. 707 00:35:03,840 --> 00:35:05,520 Yeah, Yeah. Interesting. 708 00:35:06,040 --> 00:35:09,640 I also feel like we've, we are now in a trend where there is 709 00:35:09,640 --> 00:35:13,120 this conversation happening with people that are, first of all, 710 00:35:13,120 --> 00:35:15,640 vibe coding, loving it, being effective in what they do, 711 00:35:15,640 --> 00:35:17,960 solving a problem through software and they don't care how 712 00:35:17,960 --> 00:35:19,880 it looks. And then you have the older 713 00:35:19,880 --> 00:35:21,960 part, let's say existing software engineers that look at 714 00:35:21,960 --> 00:35:25,280 this and say both from a craft perspective and from an 715 00:35:25,280 --> 00:35:27,920 execution perspective, how does this work, right? 716 00:35:27,920 --> 00:35:30,640 This is kind of really coming into my territory. 717 00:35:30,640 --> 00:35:33,000 I feel uncomfortable. Do I jump on this? 718 00:35:33,000 --> 00:35:35,040 Do I actually like it? Or is this going to take away 719 00:35:35,040 --> 00:35:37,280 what I love dearly, what I used to do day-to-day? 720 00:35:37,920 --> 00:35:40,480 I think in essence, things are evolving for me. 721 00:35:40,480 --> 00:35:42,440 That's a fact. The question is, where is it 722 00:35:42,440 --> 00:35:43,680 going? And I'm curious to see your 723 00:35:43,680 --> 00:35:46,360 perspective on that. It's funny it happens in in 724 00:35:46,360 --> 00:35:52,600 every community to be honest. So I'm starting my and 725 00:35:52,600 --> 00:35:57,840 motorcycle riding classes and in in motorcycle riding, a lot of 726 00:35:57,840 --> 00:36:02,160 the more advanced motorcycle motorcyclists and they love 727 00:36:02,280 --> 00:36:04,800 manual, the clutch. They love, you know, changing 728 00:36:04,800 --> 00:36:06,960 gears. They love the, the controlling 729 00:36:06,960 --> 00:36:10,920 the, the, the motorcycle in every single aspect, especially 730 00:36:10,920 --> 00:36:12,600 when they attain that level of proficiency. 731 00:36:13,040 --> 00:36:14,920 So a lot of them are now resisting a lot of the 732 00:36:14,920 --> 00:36:18,480 motorcycle companies introducing E clutches or clutches that just 733 00:36:18,480 --> 00:36:20,320 operate automatically. They hate that. 734 00:36:20,640 --> 00:36:23,960 I don't want this like I want to control every single aspect of 735 00:36:23,960 --> 00:36:25,960 my bike, right? And I feel this is pretty much 736 00:36:25,960 --> 00:36:27,960 the same thing that what's happening in in software. 737 00:36:28,600 --> 00:36:30,720 A lot of the folks who have attained a high level of 738 00:36:30,720 --> 00:36:34,160 proficiency and they enjoy the craftsmanship aspect of software 739 00:36:34,160 --> 00:36:36,720 development. They love the coding part. 740 00:36:36,720 --> 00:36:39,040 They love reasoning about code structure, syntax. 741 00:36:39,040 --> 00:36:43,040 They get a kick out of coming up with a smarter solution where 742 00:36:43,040 --> 00:36:47,680 they utilize A syntactical feature in a programming 743 00:36:47,680 --> 00:36:51,280 language to do something that was not maybe designed for or do 744 00:36:51,280 --> 00:36:54,600 something smart with it. So if you take that away from 745 00:36:54,600 --> 00:36:57,000 them, you're basically introducing, you know, E 746 00:36:57,000 --> 00:36:59,640 clutches to software development and they're not going to react 747 00:36:59,640 --> 00:37:03,680 positively to it, even though it clutches help like when for 748 00:37:03,680 --> 00:37:07,200 example, in when you're stopping at A at the lights signal, you 749 00:37:07,200 --> 00:37:09,360 don't have to worry about stalling and you don't have to 750 00:37:09,360 --> 00:37:10,960 worry about these things. It just makes your life much 751 00:37:10,960 --> 00:37:13,520 easier. It's fun to ride the bicycle, 752 00:37:13,520 --> 00:37:16,640 the motorcycle, and it's just easier to control it and I 753 00:37:16,680 --> 00:37:17,200 think. It's. 754 00:37:17,440 --> 00:37:20,280 Yeah, more accessible. So bike coding is pretty much 755 00:37:20,280 --> 00:37:22,080 the same thing. I hate the term bike coding 756 00:37:22,080 --> 00:37:25,240 because right now at GitHub, for example, I literally, and this 757 00:37:25,240 --> 00:37:28,840 was part of my presentation at Universe, 90% of my code is 758 00:37:28,840 --> 00:37:32,160 written by agents. So I use the VS Code agent mode 759 00:37:32,640 --> 00:37:35,560 all the time and I've been shipping features to production 760 00:37:35,560 --> 00:37:39,960 with it all the time. But that's not software 761 00:37:39,960 --> 00:37:41,520 engineering is not just writing code right. 762 00:37:41,840 --> 00:37:44,360 There's a lot of other stuff that come to it. 763 00:37:44,360 --> 00:37:47,200 And I now shift my focus towards the operational problems. 764 00:37:47,480 --> 00:37:50,160 I shift my focus towards making sure that we never go down. 765 00:37:50,440 --> 00:37:53,080 I shift my focus towards making sure that I don't introduce bugs 766 00:37:53,080 --> 00:37:56,840 that are unnecessary and 'cause people to have because GitHub 767 00:37:56,840 --> 00:37:58,720 has become part of the infrastructure of the Internet 768 00:37:58,720 --> 00:38:02,480 now. So any problem that I cause has 769 00:38:02,480 --> 00:38:05,880 great triple effects. So that's where I put my focus 770 00:38:05,880 --> 00:38:10,120 on right now. Coding fine, let the agent write 771 00:38:10,120 --> 00:38:12,640 it and I will instruct it to write it in a certain way. 772 00:38:12,640 --> 00:38:16,160 And if there's a syntactical approach that I prefer better, I 773 00:38:16,160 --> 00:38:19,560 still push it to to do that. And if something looks funky to 774 00:38:19,560 --> 00:38:23,240 me, and I also prompted to change the direction, right? 775 00:38:23,440 --> 00:38:26,720 But at the same time, one of the problems I was solving was 776 00:38:27,160 --> 00:38:30,120 recently was a caching problem, right? 777 00:38:30,120 --> 00:38:35,400 And I had different ways to implement the cache key and each 778 00:38:35,640 --> 00:38:39,840 way forced a certain data access pattern because of how the key 779 00:38:39,840 --> 00:38:41,960 is structured. And it had a different impact on 780 00:38:41,960 --> 00:38:44,000 Redis based on how the key is structured. 781 00:38:44,320 --> 00:38:47,480 So what I've done with the Escode agent is I prompted it to 782 00:38:47,480 --> 00:38:49,080 write different benchmarks. Yeah. 783 00:38:49,840 --> 00:38:52,200 And I told, hey, this pattern, this pattern and this pattern, 784 00:38:52,200 --> 00:38:54,760 go write 3 distinct benchmarks, run them, give me the results, 785 00:38:54,760 --> 00:38:55,960 analyse them and give me the output. 786 00:38:56,880 --> 00:38:59,400 That's work that could have been done in what, two or three days? 787 00:38:59,400 --> 00:39:01,520 Maybe that was done in 20 minutes. 788 00:39:02,440 --> 00:39:03,880 Why not? Fantastic. 789 00:39:03,880 --> 00:39:04,640 It's amazing. Yeah. 790 00:39:05,000 --> 00:39:06,880 So. You've been programming, you 791 00:39:06,880 --> 00:39:08,880 said hands on coding when you were 12. 792 00:39:09,280 --> 00:39:12,240 Have you always had this mindset to kind of let go of more of the 793 00:39:12,240 --> 00:39:15,400 craft things and look at what it is from an execution standpoint? 794 00:39:15,600 --> 00:39:19,480 Because I hear you from now and it feels like you're very much 795 00:39:19,480 --> 00:39:21,880 on board and making things more effective, understanding the 796 00:39:21,880 --> 00:39:23,640 business context. It's not just the craft. 797 00:39:24,160 --> 00:39:26,920 Because no, I was never like that. 798 00:39:26,920 --> 00:39:29,840 So when I was younger, I was all about the craft. 799 00:39:30,680 --> 00:39:36,800 And in I, my early mentors, I fought with them a lot on this, 800 00:39:37,280 --> 00:39:39,080 right? And I was lucky to have mentors, 801 00:39:39,080 --> 00:39:41,200 right? I was lucky to have great 802 00:39:41,200 --> 00:39:43,440 mentors at the beginning of my career, but they never were able 803 00:39:43,440 --> 00:39:46,360 to explain to me why their perspective of the business 804 00:39:46,360 --> 00:39:47,840 matters. For me, business was too 805 00:39:47,840 --> 00:39:50,000 abstract, like I don't understand the numbers, I don't 806 00:39:50,000 --> 00:39:52,000 understand accounting. I was not accountable for the 807 00:39:52,000 --> 00:39:54,920 business outcomes. I was just asked to solve the 808 00:39:54,920 --> 00:39:57,160 problem. And I thought I had infinite 809 00:39:57,160 --> 00:40:00,640 business resources. But when I realized that my 810 00:40:00,640 --> 00:40:04,320 mentor sometimes. Took an extra mortgage on their 811 00:40:04,320 --> 00:40:06,720 house just to pay the payroll for their employees. 812 00:40:07,520 --> 00:40:09,080 That makes a different problem, right? 813 00:40:09,080 --> 00:40:12,440 That gives perspective to the solutions that you're going to 814 00:40:12,440 --> 00:40:14,320 come up with. These are real people. 815 00:40:14,480 --> 00:40:17,800 Company owners are not just all millionaires and all, you know, 816 00:40:18,520 --> 00:40:20,520 people who are not investing. Some people are investing their 817 00:40:20,520 --> 00:40:22,640 own money in building businesses, right? 818 00:40:23,320 --> 00:40:26,920 So that matters. So when you understand this and 819 00:40:26,920 --> 00:40:30,560 when you become your business owner yourself, you start 820 00:40:30,560 --> 00:40:31,960 thinking about these things more. 821 00:40:32,000 --> 00:40:35,080 And now I approach these problems from that vantage point 822 00:40:35,080 --> 00:40:36,720 as well. That doesn't mean that again, 823 00:40:36,720 --> 00:40:39,120 people might. I always get this argument when 824 00:40:39,120 --> 00:40:41,760 I post about this stuff online. People think, oh, you write 825 00:40:41,760 --> 00:40:43,040 dirty code. No, I don't. 826 00:40:44,080 --> 00:40:48,080 But there's a certain level of the 20% that is required to 827 00:40:48,080 --> 00:40:50,200 reach that highest level of aesthetics. 828 00:40:50,600 --> 00:40:52,360 It's not worth it, no. So I drop that. 829 00:40:52,560 --> 00:40:55,840 Gotcha, As a final thought, there's many people listening 830 00:40:55,840 --> 00:40:58,480 that learn about software engineering and software design 831 00:40:58,480 --> 00:41:01,480 in the first place that either are early in career, mid career, 832 00:41:01,480 --> 00:41:03,760 are really just looking to level up within their career. 833 00:41:04,080 --> 00:41:07,240 What is your advice for people that really want to become great 834 00:41:07,240 --> 00:41:08,880 software engineers? What do they need to do? 835 00:41:10,200 --> 00:41:12,200 Increase your breadth. There's a lot of focus on the 836 00:41:12,200 --> 00:41:15,440 depth early on in your career, which is important. 837 00:41:15,600 --> 00:41:19,360 And there's an advice that perpetuates, which says focus, 838 00:41:20,760 --> 00:41:23,480 true focus. But at the same time, don't 839 00:41:23,480 --> 00:41:25,360 dismiss everything else that's happening. 840 00:41:25,760 --> 00:41:29,440 Increase your breadth. Personally, I optimized one 841 00:41:29,440 --> 00:41:33,120 thing that really got me far, which is having the ability to 842 00:41:33,120 --> 00:41:36,240 learn effectively in very short periods of time. 843 00:41:36,800 --> 00:41:40,040 And that's why whenever I tackle a problem, I don't have a 844 00:41:40,040 --> 00:41:44,760 problem digging really deep into anything you I encounter from 845 00:41:45,560 --> 00:41:50,000 quantum mechanics all the way to any technical problem that I 846 00:41:50,000 --> 00:41:54,200 face on a day-to-day basis. I'm a, you know, I'm a 847 00:41:54,200 --> 00:41:56,720 university drop out. I never finished my computer 848 00:41:56,720 --> 00:41:59,720 science education, but that did not deter me from picking up 849 00:41:59,720 --> 00:42:04,120 that education myself and really digging deep into all sorts of 850 00:42:04,120 --> 00:42:07,280 theoretical topics, but also practical areas and topics. 851 00:42:07,280 --> 00:42:13,040 And I'm a perpetual learner. So in my opinion, the next phase 852 00:42:13,120 --> 00:42:16,040 where we're heading, it's going to require people to be able to 853 00:42:16,360 --> 00:42:19,240 learn really fast, get out of their comfort zone really fast, 854 00:42:19,600 --> 00:42:23,280 dig deep really fast and attain high levels of functional 855 00:42:23,280 --> 00:42:28,720 proficiency in any new area. And then attaining mastery is 856 00:42:28,720 --> 00:42:30,160 not always required in everything. 857 00:42:30,280 --> 00:42:32,960 So just pick a few topics where you attain mastery in, but also 858 00:42:32,960 --> 00:42:34,680 increase your breadth. Got you. 859 00:42:34,680 --> 00:42:36,960 I think this is going to be very important for the next phase. 860 00:42:37,320 --> 00:42:40,640 I love that. How do you get comfortable with 861 00:42:40,840 --> 00:42:43,320 even saying? I've gotten really good at 862 00:42:43,320 --> 00:42:45,520 picking up new things and learning from quantum mechanics 863 00:42:45,520 --> 00:42:47,600 to anything technical or job related, whatever. 864 00:42:48,520 --> 00:42:53,040 I have a lot of interests and I see how fast I can get to a 865 00:42:53,120 --> 00:42:55,880 working proficiency with these interests. 866 00:42:56,160 --> 00:42:58,440 I play music. I'm learning to ride a 867 00:42:58,440 --> 00:43:04,520 motorcycle soon, right? So I never let if I'm curious 868 00:43:04,520 --> 00:43:06,920 about something, I go and pursue it and I explore it. 869 00:43:07,240 --> 00:43:11,920 And I never let how complicated learning it is determine from 870 00:43:11,920 --> 00:43:14,920 pursuing it. And I've become very comfortable 871 00:43:14,920 --> 00:43:17,600 with being uncomfortable learning something new. 872 00:43:18,480 --> 00:43:21,720 And actually that gives me a joy and kick to the point where it 873 00:43:21,720 --> 00:43:25,320 became sort of an addiction. But you know, I keep it under 874 00:43:25,320 --> 00:43:29,440 control sometimes. But I do enjoy the process of 875 00:43:29,440 --> 00:43:32,800 and exploring something entirely different and new. 876 00:43:33,160 --> 00:43:36,680 And in my opinion, that has given me so much breadth and the 877 00:43:36,680 --> 00:43:38,520 ability to talk about all sorts of things. 878 00:43:38,840 --> 00:43:42,920 But what I love the most about it is how I can cross different 879 00:43:42,920 --> 00:43:45,880 ideas together from different disciplines and have a much more 880 00:43:45,880 --> 00:43:49,520 diversified view of the world. And that gives me the ability to 881 00:43:49,520 --> 00:43:51,920 be able to empathize also with all sorts of people and 882 00:43:51,920 --> 00:43:54,520 different people, right, And understand their vantage point. 883 00:43:54,960 --> 00:43:58,120 So when someone's arguing with me, I take a pause and I try to 884 00:43:58,120 --> 00:44:00,080 reason about where they're coming from, what's their 885 00:44:00,080 --> 00:44:02,880 interest, how they got to that idea. 886 00:44:02,880 --> 00:44:05,920 But I draw from my own experiences also and learning 887 00:44:05,920 --> 00:44:09,560 about all sorts of stuff, including business and finance 888 00:44:09,560 --> 00:44:12,440 and investments and all of sorts of all of these things, right? 889 00:44:13,160 --> 00:44:18,120 So I think that's richness and yeah, I would definitely love 890 00:44:18,120 --> 00:44:19,840 for people to be able to have that. 891 00:44:20,160 --> 00:44:22,320 Me too. I think curiosity is a beautiful 892 00:44:22,320 --> 00:44:24,160 thing. When people say I really don't 893 00:44:24,160 --> 00:44:26,520 have a, a drive to learn something or to explore 894 00:44:26,520 --> 00:44:30,720 something, I think it's a shame. And I honestly don't know how to 895 00:44:30,720 --> 00:44:34,640 solve that for people to make sure they have that kind of love 896 00:44:34,640 --> 00:44:36,440 for something or curiosity for something. 897 00:44:36,440 --> 00:44:39,280 Because I feel like that fuels Dr. and that makes you move. 898 00:44:39,800 --> 00:44:42,960 Absolutely. I, I don't know how to, I don't 899 00:44:42,960 --> 00:44:45,040 know if we really should make people do anything. 900 00:44:46,320 --> 00:44:47,680 I would love for people to have it. 901 00:44:48,320 --> 00:44:52,120 If they don't, you can live a pretty, you know, interesting 902 00:44:52,120 --> 00:44:55,240 life. Still, some people have other 903 00:44:55,240 --> 00:44:59,360 commitments as well. Families, kids, less time, 904 00:44:59,760 --> 00:45:01,920 complicated relationships, and life happens. 905 00:45:01,920 --> 00:45:04,000 It's understandable. And that doesn't mean that I'm 906 00:45:04,000 --> 00:45:09,080 also 100% always on the, you know, on the burner, learning 907 00:45:09,120 --> 00:45:11,560 every single minute of the day. No, I have my life as well. 908 00:45:11,560 --> 00:45:16,720 I have the complications of my life too, so balance is 909 00:45:16,720 --> 00:45:20,640 important, but I feel also curiosity is something that you 910 00:45:20,640 --> 00:45:23,080 need to develop. It's like a it's like a muscle 911 00:45:23,080 --> 00:45:26,360 you need to grow as well. And approaching the world from 912 00:45:26,360 --> 00:45:29,640 the curious vantage point is way more interesting and more 913 00:45:29,640 --> 00:45:33,760 effective than being dogmatic or stubborn or hard headed about 914 00:45:34,360 --> 00:45:36,560 certain things. You can have strong opinions, 915 00:45:37,920 --> 00:45:40,320 but not before you actually did your homework. 916 00:45:40,520 --> 00:45:43,320 Yeah, absolutely. Thanks so much for coming on and 917 00:45:43,320 --> 00:45:44,640 sharing. Man, this was a blast. 918 00:45:44,640 --> 00:45:47,000 Absolutely my pleasure making going for hours. 919 00:45:48,240 --> 00:45:49,960 Me too. We're going to round it off 920 00:45:49,960 --> 00:45:52,120 here. If you're still with us, leave a 921 00:45:52,120 --> 00:45:54,080 comment in the comment section. Let us know what you thought of 922 00:45:54,080 --> 00:45:55,800 this episode and we'll see you on the next one.