WEBVTT 1 00:00:05.280 --> 00:00:09.000 Hey, folks, Welcome back to another JavaScript jabber. This week 2 00:00:09.000 --> 00:00:11.199 on our panel, we have Dan Shapeer. 3 00:00:11.800 --> 00:00:14.560 Hello, from what we in Tel Aviv like to call 4 00:00:14.640 --> 00:00:15.000 it winter. 5 00:00:16.839 --> 00:00:19.320 Well, I wish our winters were that warm. I'm Charles 6 00:00:19.320 --> 00:00:21.640 Maxwood from top Endevs, where I think you got below 7 00:00:21.679 --> 00:00:25.760 freezing last night. That zero if you're not in the 8 00:00:25.879 --> 00:00:30.320 US and use something other than fahrenheit, and that's like 9 00:00:30.359 --> 00:00:33.600 thirty two degrees fahrenheit, So got real cold last night. 10 00:00:35.359 --> 00:00:38.200 This week, we're following up on the nine Node Pillars 11 00:00:38.320 --> 00:00:40.159 episode that came out a few weeks ago or a 12 00:00:40.200 --> 00:00:43.679 month ago, so we've got some familiar faces, but we'll 13 00:00:43.679 --> 00:00:46.159 go ahead and let them introduce themselves again. I'm just 14 00:00:46.240 --> 00:00:49.000 going to start at the top of my screen and 15 00:00:49.079 --> 00:00:51.240 we'll just kind of work our way down. We have 16 00:00:51.399 --> 00:00:53.799 Michael Dawson. Michael, do you want to introduce yourself? 17 00:00:54.479 --> 00:00:54.640 Hi? 18 00:00:54.759 --> 00:00:57.240 Michael Dawson on the NODS lead for Rahat and at 19 00:00:57.240 --> 00:00:59.679 GM as well as active in the project from the 20 00:00:59.679 --> 00:01:02.920 Technic Steering Committee and live definitely where it is getting 21 00:01:02.920 --> 00:01:04.519 below zero at nineteen. 22 00:01:05.719 --> 00:01:09.680 Right, practically, neighbors. We also have Matteo Colina. 23 00:01:10.519 --> 00:01:14.079 Hi, everyone, I'm mate Coolina Platmatic co founder and CEO 24 00:01:14.560 --> 00:01:17.079 ps enter on the mat jest I think, a steering committee, 25 00:01:17.359 --> 00:01:20.239 a board member of the Opinion Jazz Foundation. Also of 26 00:01:20.280 --> 00:01:22.799 many modules. You are probably using my software, even if 27 00:01:22.799 --> 00:01:24.319 you don't, even if you want or not. 28 00:01:26.480 --> 00:01:29.400 Probably my tagline awesome. 29 00:01:29.400 --> 00:01:30.799 We also have James Snell. 30 00:01:32.359 --> 00:01:36.120 You know, uh yeah, James del Con from central California 31 00:01:36.920 --> 00:01:44.400 where winter here means just slightly less unshine than I'm 32 00:01:44.400 --> 00:01:46.319 at Claude Flair. I work on their workers run time. 33 00:01:46.359 --> 00:01:48.959 I'm on the Note technical Steering Committee. I've been contributing 34 00:01:49.000 --> 00:01:52.120 to Note for most ten years. We have in March 35 00:01:52.480 --> 00:01:53.920 in just a few months, I'll have been on the 36 00:01:53.959 --> 00:01:56.560 technical Steering committee for Note for ten years old decades, 37 00:01:56.640 --> 00:01:59.560 so which is which is crazy? Yeah, that's. 38 00:02:01.159 --> 00:02:04.200 Awesome. And finally we have Natalia Vendito. 39 00:02:06.079 --> 00:02:08.360 Yeah, thank you for having me. 40 00:02:08.879 --> 00:02:13.039 I am the lead for developer tools and Experiences for 41 00:02:13.199 --> 00:02:17.360 the script on usure and yeah, also participation of the 42 00:02:17.439 --> 00:02:18.800 Open Jes foundations. 43 00:02:18.919 --> 00:02:20.680 We see, that's me. 44 00:02:21.400 --> 00:02:23.840 So yeah. So last time you talked about the nine 45 00:02:23.840 --> 00:02:27.879 node pillars, I think it's worth maybe a five ten 46 00:02:27.919 --> 00:02:30.960 minute review something like that, just trying to get people 47 00:02:31.000 --> 00:02:33.360 back into it. Obviously, folks can go back and listen 48 00:02:33.400 --> 00:02:35.960 to the other episode if they want the in depth discussion, 49 00:02:36.800 --> 00:02:37.759 but then we should. 50 00:02:38.479 --> 00:02:40.919 It was an excellent They definitely should. It was an 51 00:02:40.919 --> 00:02:44.240 excellent conversation, it's an excellent article, and it's an it 52 00:02:44.280 --> 00:02:48.000 was an excellent conversation in my opinion, unbiased opinion. 53 00:02:49.479 --> 00:02:51.960 Well, my point is is then we can get on 54 00:02:52.080 --> 00:02:56.479 with the other you know, four or five pillars, So 55 00:02:56.840 --> 00:02:59.319 really quickly, I'm just gonna pull them out of the article, 56 00:03:00.360 --> 00:03:02.800 and then if whoever wants you can kind of jump 57 00:03:02.800 --> 00:03:05.879 in and just kind of summarize what was discussed. The 58 00:03:05.879 --> 00:03:07.960 first one is do not block the event loop. 59 00:03:11.719 --> 00:03:13.000 Yeah, this one's pretty straightforward. 60 00:03:13.000 --> 00:03:13.159 You know. 61 00:03:13.199 --> 00:03:14.840 It's like, you know, you got to keep in mind 62 00:03:14.840 --> 00:03:18.759 that anytime you're running some bit of jobascripts, you have 63 00:03:18.800 --> 00:03:21.319 some function, nothing else is going to happen on that 64 00:03:21.400 --> 00:03:23.879 event loop. So you need to make sure you're dividing 65 00:03:23.879 --> 00:03:27.439 your work into two very small chunks. Allow the event loop. 66 00:03:27.439 --> 00:03:29.439 It turns you can pick up new requests, you can 67 00:03:29.879 --> 00:03:33.319 process io that that kind of thing. So pay attention 68 00:03:33.759 --> 00:03:37.840 to you know, that event loop delay, event loop utilization. 69 00:03:38.400 --> 00:03:40.120 There's a couple of metrics there. You really want to 70 00:03:40.159 --> 00:03:42.960 watch closely and optimize your applications around that. 71 00:03:44.159 --> 00:03:48.599 Yeah, and also offload if you can lengths casts to 72 00:03:48.680 --> 00:03:50.120 a worker a total post support. 73 00:03:51.080 --> 00:03:54.240 Yeah, and I'm assuming you talked about strategies on how 74 00:03:54.240 --> 00:03:55.680 to do that and what your coach should look like 75 00:03:55.919 --> 00:03:56.800 in the other episode. 76 00:03:56.879 --> 00:03:58.680 So yep, yep. 77 00:03:59.680 --> 00:04:02.840 The next one is monitor node specific metrics and act 78 00:04:02.919 --> 00:04:03.240 on them. 79 00:04:05.360 --> 00:04:05.960 Let me take this. 80 00:04:06.919 --> 00:04:10.639 Most of the things that people do when the plying 81 00:04:10.680 --> 00:04:15.520 no JS is they monitor no JS like it's in 82 00:04:15.560 --> 00:04:19.079 a completely like it's a black box. And this is 83 00:04:19.079 --> 00:04:25.040 a massive it's a massive pain because you because in 84 00:04:25.199 --> 00:04:28.800 most cases no JS has its own quirks and peculiarities, 85 00:04:29.079 --> 00:04:32.319 and monitoring a black box, you are essentially making it 86 00:04:32.319 --> 00:04:37.120 a service. Biggest one being memory. JS will use as 87 00:04:37.240 --> 00:04:39.759 much memory as you make it available to it. And 88 00:04:39.879 --> 00:04:44.519 if you start killing it when it reaches whatever arbitrary threshold, 89 00:04:45.079 --> 00:04:47.720 you know you're killing the process yourself. And and then 90 00:04:47.759 --> 00:04:50.279 you're starting it and complaining that your process is crashing 91 00:04:50.279 --> 00:04:52.199 all the time you're killing it, of course is crashing 92 00:04:52.199 --> 00:04:56.120 all the time. Okay, it's literally like this thing alone 93 00:04:56.199 --> 00:04:59.240 is probably don't know worth a few hours of fright time, 94 00:04:59.680 --> 00:05:02.680 super high end colsantacy. So this is for free, so 95 00:05:02.759 --> 00:05:04.879 you know to take it, take it the way you want. 96 00:05:05.079 --> 00:05:09.240 But this is essentially, you know, very easy fix. But 97 00:05:09.399 --> 00:05:12.240 most people don't Most people monitor assess micos if you 98 00:05:12.399 --> 00:05:16.079 use it, but don't look into what's happening inside the process. 99 00:05:16.160 --> 00:05:17.879 And this is you know, makes all the difference. 100 00:05:18.480 --> 00:05:22.519 One of the key metrics there that was added relatively 101 00:05:22.560 --> 00:05:25.519 recently is the event look utilization. It's going to say 102 00:05:25.519 --> 00:05:28.319 you a whole lot more information than monitoring a CPO. 103 00:05:29.000 --> 00:05:33.879 Yeah, awesome. The next one is use node LTS, which 104 00:05:33.920 --> 00:05:36.399 is long term support versions in production. 105 00:05:38.439 --> 00:05:40.439 I think that one is like, you know, as a project, 106 00:05:40.519 --> 00:05:44.800 we support the long term support streams and the recommendations 107 00:05:44.839 --> 00:05:48.519 really stick with those because in terms of security effects 108 00:05:48.680 --> 00:05:50.439 and stuff like that, that's where you're going to get 109 00:05:50.439 --> 00:05:52.959 those and most people don't want to update when those 110 00:05:53.000 --> 00:05:53.319 come out. 111 00:05:54.639 --> 00:05:58.000 And these are the even numbered versions, right, that's. 112 00:05:57.839 --> 00:06:01.319 Right, and they come out every October and are supported 113 00:06:01.399 --> 00:06:02.480 for thirty months. 114 00:06:03.040 --> 00:06:06.720 They usually say LTS. It's like it's the version number 115 00:06:06.720 --> 00:06:09.480 that says LTS. So if you have a question, just 116 00:06:09.600 --> 00:06:14.040 look for that and you'll know. I think we all 117 00:06:14.120 --> 00:06:15.720 kind of stared at each other on that one, Like 118 00:06:15.759 --> 00:06:21.000 it was pretty clear that that's a good move. The 119 00:06:21.040 --> 00:06:24.000 fourth one is automate testing, code re view and conformance 120 00:06:24.040 --> 00:06:25.079 as much as possible. 121 00:06:25.839 --> 00:06:28.079 Yeah, that one I'll jump in. We talked about last time. 122 00:06:28.759 --> 00:06:31.720 I think like no just is known for being able 123 00:06:31.720 --> 00:06:34.720 to let you move really fast and be productive, but 124 00:06:35.279 --> 00:06:37.680 you need really good testing to be able to move 125 00:06:37.759 --> 00:06:39.720 quickly to make sure you're not going to break things. 126 00:06:39.720 --> 00:06:41.639 And so that's where we last time. We talked about 127 00:06:41.639 --> 00:06:44.199 like how that how it is really your enabler to 128 00:06:44.240 --> 00:06:47.639 take advantage of the sort of speed and agility that 129 00:06:47.720 --> 00:06:48.879 node gives. 130 00:06:49.439 --> 00:06:52.199 We also spoke about the fact that people still use 131 00:06:52.240 --> 00:06:57.240 old testing frameworks which are showing their age, and that 132 00:06:57.399 --> 00:07:00.879 Node now comes with its own built into framework that 133 00:07:00.959 --> 00:07:03.439 you can really easily leverage out of the box. 134 00:07:06.439 --> 00:07:09.240 Good deal. And then it sounded like you got part 135 00:07:09.279 --> 00:07:13.839 way into but didn't completely discuss avoid dependency creep. 136 00:07:18.600 --> 00:07:22.959 Yes, we spoke at length about how NPM it's kind 137 00:07:22.959 --> 00:07:26.399 of like this black hole which sucks the entire universe 138 00:07:26.439 --> 00:07:29.480 into it. So you add one dependency which brings on 139 00:07:29.680 --> 00:07:32.560 another couple for the ride, which bring even more and 140 00:07:32.600 --> 00:07:35.199 more and more. And we talked about the fact that 141 00:07:35.279 --> 00:07:39.279 you need to really be how would I say it, 142 00:07:43.360 --> 00:07:47.800 cognizant of what you're bringing in intentional I think was 143 00:07:47.800 --> 00:07:51.720 the term that we use. Think about what you're bringing 144 00:07:51.759 --> 00:07:53.959 in and why you actually need it, and if there 145 00:07:54.000 --> 00:08:00.120 are lighterweight alternatives, and beware utilizing multiple versions of the 146 00:08:00.240 --> 00:08:06.000 same library. Anything else we mentioned that I'm missing, Yeah, I. 147 00:08:06.000 --> 00:08:08.959 Think that one of the aspects was like within an organization, 148 00:08:09.680 --> 00:08:11.639 the great the good thing about NPM and all the 149 00:08:11.680 --> 00:08:13.879 choices there is there's lots of different choices, but like 150 00:08:13.920 --> 00:08:16.079 in an organization, it would make a lot of sense 151 00:08:16.759 --> 00:08:19.800 to choose a more standardized set of packages as opposed 152 00:08:19.839 --> 00:08:23.720 to having five copies of something which does the same 153 00:08:23.759 --> 00:08:26.199 thing but are actually slightly different. Because when it comes 154 00:08:26.279 --> 00:08:29.680 to helping each other or to debug issues or to 155 00:08:29.720 --> 00:08:32.440 be able to support them, that can be an advantage. 156 00:08:32.440 --> 00:08:34.519 Of course, you know, there's always cases where you want 157 00:08:34.559 --> 00:08:37.879 to use something special to your particular effort, but like 158 00:08:37.960 --> 00:08:40.840 that's probably the twenty percent case versus the eighty percent. 159 00:08:42.600 --> 00:08:45.120 By the way, with regard to that one thing that 160 00:08:45.200 --> 00:08:47.840 I'm thought of and I don't think I mentioned the 161 00:08:47.919 --> 00:08:51.919 last time we spoke about this, is the fact that 162 00:08:52.000 --> 00:08:57.559 I know some organizations that intentionally take call it micro 163 00:08:57.639 --> 00:09:01.559 front ends micro services type approach of trying to create 164 00:09:01.559 --> 00:09:05.759 as much segregation as possible between various teams and reduce 165 00:09:05.840 --> 00:09:10.519 teams dependencies or dependency on each other. And that means 166 00:09:10.559 --> 00:09:15.240 that for example, one team might choose to use one 167 00:09:16.799 --> 00:09:20.000 package or library and another team should be free to 168 00:09:20.120 --> 00:09:24.039 choose something else, or that they don't need to move 169 00:09:24.080 --> 00:09:27.600 at the same rate with regard to version ing and 170 00:09:28.000 --> 00:09:31.000 stuff like that. Now, obviously they if they go the 171 00:09:31.039 --> 00:09:34.559 way or the whole way with microservices, then they're probably 172 00:09:34.600 --> 00:09:38.600 also running separate node instances, which might reduce the impact, 173 00:09:38.759 --> 00:09:41.559 but they might be running within the same note instance, 174 00:09:42.200 --> 00:09:46.559 and then they're kind of working in contradiction to this recommendation. 175 00:09:48.600 --> 00:09:50.600 I think, like if you look at it, like maybe 176 00:09:51.000 --> 00:09:54.679 that plays into not using like not forcing people to 177 00:09:54.679 --> 00:09:56.799 be using the same version. But I still think even 178 00:09:56.799 --> 00:10:00.279 in that case, there's value to say, like let's all 179 00:10:00.399 --> 00:10:02.600 choose the same loger, right, Like we don't need to 180 00:10:02.679 --> 00:10:06.000 use ten different bloggers. So for example, if somebody moves 181 00:10:06.000 --> 00:10:08.519 from one team to the other, they they already know 182 00:10:08.679 --> 00:10:10.799 the log or in the patterns and so forth they're 183 00:10:10.919 --> 00:10:15.600 used and breaking it up into micro services like that's 184 00:10:15.600 --> 00:10:17.720 sort of a different kind of dependency in my mind. 185 00:10:17.799 --> 00:10:21.320 Anyway, Yeah, I agree. I've worked on a number of 186 00:10:21.360 --> 00:10:23.720 projects where we you know, we try to segregate things 187 00:10:23.720 --> 00:10:26.480 out this way, and what I found is that sometimes 188 00:10:26.480 --> 00:10:28.720 there are good reasons for deviating from what the other 189 00:10:28.720 --> 00:10:31.600 teams are doing, and sometimes there really aren't. And so 190 00:10:32.480 --> 00:10:35.240 a lot of this, you know, they try and segregate 191 00:10:35.320 --> 00:10:39.080 it so the teams don't have to spend as much time, 192 00:10:39.159 --> 00:10:43.519 you know, coming together and collaborating. But this is more 193 00:10:43.519 --> 00:10:47.200 of an organizational issue, I think, than than a code issue, 194 00:10:47.200 --> 00:10:49.720 in the sense that you should still be talking and 195 00:10:49.759 --> 00:10:52.039 you can still leverage the expertise of the other team 196 00:10:52.080 --> 00:10:54.919 where appropriate and say, all right, we've got to solve 197 00:10:54.960 --> 00:10:57.960 this problem. We know you have this same problem. What 198 00:10:58.000 --> 00:10:59.919 are you using And then you can have the discussion 199 00:11:00.039 --> 00:11:03.600 about what and where and why. And then when we 200 00:11:03.639 --> 00:11:06.440 look at it from our problem perspective, right, because we're 201 00:11:06.440 --> 00:11:08.440 working on a different part of the app, then we 202 00:11:08.519 --> 00:11:11.639 may say that all makes sense, and we tried to 203 00:11:11.639 --> 00:11:14.159 put it in, but it turned out these concerns lead 204 00:11:14.240 --> 00:11:16.360 us to a different solution. But then you have a 205 00:11:16.399 --> 00:11:18.440 good reason for saying this is why we're doing it 206 00:11:18.480 --> 00:11:21.639 different as opposed to the other thing. But it also 207 00:11:21.759 --> 00:11:24.279 then makes people more mobile between the teams. It makes 208 00:11:24.279 --> 00:11:26.799 it easier to talk about some of the similar issues. 209 00:11:27.159 --> 00:11:30.039 And so I think there's some nuance here, but I 210 00:11:30.200 --> 00:11:33.360 like the direction of saying, hey, at least consider what 211 00:11:33.399 --> 00:11:35.159 everybody else is doing in your organization. 212 00:11:35.559 --> 00:11:39.279 And part of my part of the concerns here is 213 00:11:39.840 --> 00:11:45.480 you really want to to even say okay. So we 214 00:11:45.559 --> 00:11:50.200 have created a way to a little module to call 215 00:11:50.399 --> 00:11:54.080 this micro service okay that is consumed by everybody okay, 216 00:11:54.600 --> 00:11:57.120 and I want to take that code and publish it 217 00:11:57.200 --> 00:12:02.879 on my internal registry because otherwise each other team is 218 00:12:02.879 --> 00:12:05.399 going to redew it, and each other team is going 219 00:12:05.399 --> 00:12:11.480 to use a different HDP library for calling it okay, 220 00:12:12.120 --> 00:12:16.720 which is bananas. I've seen this happening over and over again. Okay, 221 00:12:16.840 --> 00:12:21.120 literally time wasted due to writing API clients. But now 222 00:12:21.120 --> 00:12:24.240 we have a point there for top creating API clients. 223 00:12:24.360 --> 00:12:28.679 But this is essentially this is part of the problem. 224 00:12:29.360 --> 00:12:31.799 This is one of the problems. This happens to all 225 00:12:31.799 --> 00:12:32.720 the things okay. 226 00:12:33.240 --> 00:12:38.120 It is I need a library to validate that. 227 00:12:38.000 --> 00:12:44.480 My custom field is correct, right, and then I need 228 00:12:44.519 --> 00:12:47.919 this custom data. Well, let's put it somewhere so that 229 00:12:48.000 --> 00:12:50.840 I don't need to implement it all every every single time. 230 00:12:51.799 --> 00:12:56.279 So yeah, it just comes out of being intentional. You 231 00:12:56.320 --> 00:12:59.200 need to be more intentional than your opinion. Like engineers 232 00:12:59.240 --> 00:13:01.399 are going to have opinions. You know, I don't agree 233 00:13:01.399 --> 00:13:03.240 with the displiment right into the library. Does it a 234 00:13:03.279 --> 00:13:06.240 different way, And it's like in an organization, that's just 235 00:13:06.279 --> 00:13:09.440 not our work. You can get so far with it. 236 00:13:10.240 --> 00:13:14.159 Let's just cause more headaches and overhead. So do it once, 237 00:13:14.240 --> 00:13:16.279 publish it for everyone to use. And you know what 238 00:13:16.320 --> 00:13:17.840 if you don't agree with that one hundred percent, so 239 00:13:17.879 --> 00:13:18.639 what use it anyway? 240 00:13:19.480 --> 00:13:25.960 M Yeah, enterprise I agree, go ahead, Natalia sorry, yeah. 241 00:13:26.360 --> 00:13:29.000 Yeah, in enterprise development, I think many. 242 00:13:28.759 --> 00:13:32.440 People forget there is this intermediately year like everybody can 243 00:13:32.480 --> 00:13:34.200 consume from upstream. 244 00:13:33.799 --> 00:13:35.039 Whatever module they want. 245 00:13:35.200 --> 00:13:40.120 But again, like Matteo and James uh stay that, you 246 00:13:40.320 --> 00:13:43.080 need to be conscious of what you're building yourself and 247 00:13:43.159 --> 00:13:45.519 make it available to others. In the end, you have 248 00:13:45.600 --> 00:13:50.120 a smaller ecosystem with that within your company, your organization 249 00:13:50.519 --> 00:13:55.759 that allows you to publish to any private registry and 250 00:13:55.879 --> 00:13:59.919 also function in the same way as open source by 251 00:14:00.200 --> 00:14:02.200 within the boundaries of your organization. 252 00:14:02.320 --> 00:14:03.279 And by the way, this is. 253 00:14:04.919 --> 00:14:10.120 Definitely an organizational convenience, not so much at a metal one. 254 00:14:10.159 --> 00:14:13.279 I think in the front end, definitely try to keep 255 00:14:14.639 --> 00:14:18.480 dependencies that you're probably shipping over the wire minimum. But 256 00:14:18.559 --> 00:14:20.360 in the back end, what you want to do is 257 00:14:20.399 --> 00:14:25.559 to make sure that you have a lower maintenance requirement. 258 00:14:27.000 --> 00:14:30.279 Than when you have a lot of modules to maintain. 259 00:14:32.000 --> 00:14:36.879 One thing that I encountered with organizations thinking about reusing 260 00:14:37.120 --> 00:14:40.679 their own components within the organization. So sometimes they're very 261 00:14:40.720 --> 00:14:43.480 explicit about it. So for example, if an organization in 262 00:14:43.559 --> 00:14:47.080 the context of front and development, an organization decides they're 263 00:14:47.120 --> 00:14:50.480 going to have a design system and the implement some 264 00:14:50.519 --> 00:14:56.440 sort of a front end library that's pretty typical but working, 265 00:14:56.480 --> 00:14:59.480 and let's say in a certain project, and then coming 266 00:14:59.519 --> 00:15:02.279 to a conclude and hey, this bit of code that 267 00:15:02.360 --> 00:15:05.840 I wrote seems to be something that will be generally 268 00:15:06.000 --> 00:15:11.480 useful across the entire organizations. People have that a harm moment, 269 00:15:11.919 --> 00:15:17.480 but are sometimes hesitant to act on it because you're 270 00:15:17.519 --> 00:15:21.720 assuming a lot more responsibility than you originally had. Like 271 00:15:21.799 --> 00:15:25.240 if you're just writing something for your own use within 272 00:15:25.279 --> 00:15:28.639 your own team, that's one thing, but committing to support 273 00:15:28.720 --> 00:15:32.320 every use case within the larger organization. That's a different 274 00:15:32.360 --> 00:15:37.039 type level of commitment altogether, and making that jump can 275 00:15:37.080 --> 00:15:39.080 be you know significant. 276 00:15:40.919 --> 00:15:42.399 Yeah, that's true. 277 00:15:42.480 --> 00:15:47.679 I have sorry, go ahead, go ahead, Michael, I said. 278 00:15:47.639 --> 00:15:49.320 That seems to be the thing in life. The more 279 00:15:49.399 --> 00:15:51.320 you do, the more you pick up in terms of 280 00:15:51.360 --> 00:15:54.360 responsibility of keeping things going. So I can totally see 281 00:15:54.360 --> 00:15:56.120 people worrying about that. 282 00:15:56.679 --> 00:16:02.039 Now I have an absolute counter argument to okay, and 283 00:16:03.320 --> 00:16:05.919 I want to flag out this functional and why you 284 00:16:06.000 --> 00:16:10.440 need to be intentional when creating this kind of software, 285 00:16:10.480 --> 00:16:14.080 when when thinking about dependencies and software usability within your 286 00:16:14.120 --> 00:16:19.080 organization and enterprise and also our enterprise about absolutely sabotage 287 00:16:19.120 --> 00:16:24.159 themselves while doing so. Okay, so imagine that each team 288 00:16:24.399 --> 00:16:27.679 needs to, you know, implement a piece of functionality. Okay, 289 00:16:28.159 --> 00:16:31.639 Now one of the teams that they discuss, one of 290 00:16:31.720 --> 00:16:34.159 the teams is the first one, and they created their 291 00:16:34.159 --> 00:16:36.600 own little module to do this, and this is well 292 00:16:36.639 --> 00:16:40.879 it it is. I'm publishing it on my NPM internal 293 00:16:40.960 --> 00:16:44.639 MPM rights. Great, everybody is happy, the management is very happy. 294 00:16:44.679 --> 00:16:46.320 We saved a maunch of money, so we need to 295 00:16:46.440 --> 00:16:48.120 can reuse all these things. 296 00:16:48.159 --> 00:16:49.840 Fantastic okay. 297 00:16:50.480 --> 00:16:54.600 Now, however, a moment after that's happened, the team that 298 00:16:54.679 --> 00:17:00.320 created that module completely drops the ball on it because nope, 299 00:17:00.440 --> 00:17:03.279 it's not part of my OKR anymore. The quarter has changed, 300 00:17:03.320 --> 00:17:07.240 so I'm not maintaining this anymore. And this is the 301 00:17:07.279 --> 00:17:10.680 typical thing that happens with okay, are okay? If what 302 00:17:10.720 --> 00:17:13.759 you're doing is not part of of your okay of 303 00:17:13.920 --> 00:17:17.599 of your does not help you achieve your key results, 304 00:17:17.599 --> 00:17:20.519 you are absolute that thing it needs to be dropped, okay, 305 00:17:20.799 --> 00:17:23.119 even though it's important and you know you're saving the 306 00:17:23.160 --> 00:17:27.680 compliant of money by avoiding duplications. So, in reality, a 307 00:17:27.759 --> 00:17:32.440 lot of teams in some enterprise works a little bit 308 00:17:32.480 --> 00:17:34.279 like silos. 309 00:17:34.119 --> 00:17:35.440 And they are a little bit. 310 00:17:36.880 --> 00:17:40.319 Yeah I have Yeah, I think Natali has a few 311 00:17:40.359 --> 00:17:42.960 stories on on that, so I don't know it's. 312 00:17:44.039 --> 00:17:47.599 But yeah, after a decad as an enterprise developer, I 313 00:17:47.640 --> 00:17:51.720 have many stories. Yes, there are silos, and I do agree, mate, 314 00:17:52.200 --> 00:17:56.920 But typically enterprise projects do not work under KPIs. The 315 00:17:57.000 --> 00:18:01.759 KPI is delivering your project's a little bit different than product. 316 00:18:03.200 --> 00:18:05.119 And another thing to your. 317 00:18:05.039 --> 00:18:08.880 Favor is that if you are building something that you 318 00:18:09.039 --> 00:18:13.559 publish to a private registry and you move to another project, 319 00:18:13.680 --> 00:18:16.599 which is usually the case of developers in the context 320 00:18:16.680 --> 00:18:17.400 of enterprise. 321 00:18:17.799 --> 00:18:20.400 You are rotating, you're going to a different project. 322 00:18:20.440 --> 00:18:22.920 You can reuse it, right, you have it, you have 323 00:18:23.000 --> 00:18:26.799 it available to your new project, whereas if it's part 324 00:18:26.839 --> 00:18:29.839 of a private code base, you don't have access to 325 00:18:29.880 --> 00:18:30.440 it anymore. 326 00:18:30.920 --> 00:18:34.400 Right, And I think that there's I'm gonna sorry, sorry 327 00:18:34.400 --> 00:18:36.920 for the dogs here, but only another aspect of this 328 00:18:37.119 --> 00:18:41.319 that's completely overlooked is a lot of times these internal 329 00:18:41.359 --> 00:18:44.319 teams will look at, hey, this other team created this, 330 00:18:44.319 --> 00:18:47.039 this package that I want to use, it's their responsibility 331 00:18:47.079 --> 00:18:49.319 to maintain it so I can get the benefit from it. 332 00:18:49.880 --> 00:18:54.119 That's internally the wrong calculus. It's if if if I'm 333 00:18:54.559 --> 00:18:57.119 up to use it in my project, I'm also picking 334 00:18:57.200 --> 00:18:58.759 up the burden to help maintain it. 335 00:18:59.720 --> 00:19:00.000 Uh. 336 00:19:00.119 --> 00:19:03.319 So you know, we can't have this idea that it's like, oh, 337 00:19:03.519 --> 00:19:06.039 that other team's responsible for it. No, no, no, all 338 00:19:06.079 --> 00:19:09.519 the same company, all the same team is equally my 339 00:19:09.599 --> 00:19:10.839 responsibility to anyone else. 340 00:19:11.640 --> 00:19:15.680 Let me be plunned if your assumption is that if 341 00:19:15.720 --> 00:19:19.559 you run into a problem because your needs change and 342 00:19:19.599 --> 00:19:23.839 the current and the package doesn't properly or adequately support it, 343 00:19:23.920 --> 00:19:27.039 and you're dependent on somebody from some other team who, 344 00:19:27.160 --> 00:19:31.000 as we said, may have different OKRs, different priorities, you're 345 00:19:31.039 --> 00:19:34.720 literally screwed. I mean, you have to take the attitude 346 00:19:34.759 --> 00:19:37.599 and the approach that if you're using it, you're assuming 347 00:19:37.640 --> 00:19:38.960 responsibility for it. 348 00:19:40.119 --> 00:19:43.759 That can almost still be totally extended to every module 349 00:19:43.799 --> 00:19:47.839 you use from MPM, because in that case, the people 350 00:19:47.839 --> 00:19:51.079 who who may be maintaining it are even further away 351 00:19:51.079 --> 00:19:55.039 from you and even have less reason to necessarily prioritize 352 00:19:54.400 --> 00:19:56.640 your your requirements. 353 00:19:58.319 --> 00:20:00.079 And I a hundred percent agree with that. I'm and 354 00:20:00.160 --> 00:20:04.279 I've said before many times. Where you know, especially companies, 355 00:20:04.279 --> 00:20:07.480 if you are making use of open source, then you 356 00:20:07.519 --> 00:20:09.960 as a company have an obligation helped support that open 357 00:20:09.960 --> 00:20:15.839 source that that you're using. That includes contributing back bug fixes, 358 00:20:16.000 --> 00:20:19.519 changes or whatever, and working with those maintainers. Don't put 359 00:20:19.559 --> 00:20:22.119 that burden on them, especially if you're not paying them. 360 00:20:22.759 --> 00:20:25.640 By the way, an interesting aspect that I've seen is 361 00:20:25.640 --> 00:20:29.799 that at least for some organization, when they decided to 362 00:20:29.920 --> 00:20:34.640 share some resource across the entire organization, it was actually 363 00:20:34.759 --> 00:20:39.640 easier from the organizational perspective to turn it into an 364 00:20:39.680 --> 00:20:44.839 actual open source project. Then to try to maintain it 365 00:20:44.920 --> 00:20:49.480 as an internally shared resource, because once it was declared 366 00:20:49.480 --> 00:20:53.960 an actual open source project, it was actually allocated resources 367 00:20:54.640 --> 00:20:57.880 versus when it was just an internal thing that's shared, 368 00:20:58.359 --> 00:21:02.680 you know, ownership was met. 369 00:21:03.599 --> 00:21:06.960 Yeah. One thing that I wanted to piggyback off of 370 00:21:07.240 --> 00:21:10.640 what Matteo was talking about a little bit earlier is that, 371 00:21:10.799 --> 00:21:13.079 and this is coming from when I was working on 372 00:21:13.160 --> 00:21:17.160 integrations and it was mostly third party integrations within an 373 00:21:17.160 --> 00:21:21.200 application that I was helping maintain. But also, you know, 374 00:21:21.240 --> 00:21:24.759 between micro services, is that if you can structure your 375 00:21:25.039 --> 00:21:27.119 because he was saying, you know, if you're writing the 376 00:21:27.240 --> 00:21:29.160 micro service, you ought to be writing the library that 377 00:21:29.200 --> 00:21:32.559 consumes it and giving everybody a standard way of accessing it. 378 00:21:33.039 --> 00:21:36.880 And for me, if you can structure all of those 379 00:21:37.039 --> 00:21:39.680 the same way and make sure that they all kind 380 00:21:39.720 --> 00:21:43.480 of look and feel and are built in the same manner, again, 381 00:21:43.519 --> 00:21:46.359 it makes it easier for people across the organization to 382 00:21:46.359 --> 00:21:48.519 be able to come in and do that maintenance for 383 00:21:48.559 --> 00:21:51.839 you so that they can you know, you can move ahead. 384 00:21:51.880 --> 00:21:54.440 So then it's hey, this micro service has this feature 385 00:21:54.440 --> 00:21:56.160 that they built in, but they have an updated the 386 00:21:57.039 --> 00:22:00.559 library for it, or maybe I need to make pull 387 00:22:00.599 --> 00:22:02.119 the data in, but I need to do something a 388 00:22:02.119 --> 00:22:04.839 little bit different with it before I consume it in 389 00:22:05.039 --> 00:22:08.920 my service. You know, if it's all structured in a 390 00:22:08.960 --> 00:22:11.000 similar manner, then I know where to go to go 391 00:22:11.000 --> 00:22:14.200 ahead and add that in and then everybody else benefits 392 00:22:14.200 --> 00:22:15.759 from it and I don't have to go in and 393 00:22:15.799 --> 00:22:20.359 reverse engineer this driver or that driver, or this integration 394 00:22:20.440 --> 00:22:21.920 library and that integration library. 395 00:22:22.279 --> 00:22:27.400 I do want to I do want to. Sorry, I 396 00:22:27.440 --> 00:22:29.880 do want to push us along a little bit because 397 00:22:29.920 --> 00:22:32.279 we are We're never going to finish the pillars. 398 00:22:31.960 --> 00:22:36.000 Otherwise I want I do want them today. 399 00:22:36.400 --> 00:22:38.599 Yeah, I do want to touch on two things that 400 00:22:38.640 --> 00:22:41.640 were mentioned in the article in this context, at least briefly. 401 00:22:42.240 --> 00:22:46.880