WEBVTT 00:00:12.040 --> 00:00:15.620 Welcome to the Bikeshed podcast, where we talk about all things software engineering, 00:00:16.260 --> 00:00:20.060 Dunkin' versus Starbucks coffee, and which AI company will go public first. 00:00:20.840 --> 00:00:24.940 I'm your co-host, religious Raycast Reddit poster, Scott K. 00:00:25.630 --> 00:00:27.580 And alongside with me are my co-hosts. 00:00:27.940 --> 00:00:32.099 He took the application code you shipped yesterday and already refactored it. 00:00:32.840 --> 00:00:35.040 Matt, one version ahead, Hamlin. 00:00:35.810 --> 00:00:36.740 And my other co-host. 00:00:37.460 --> 00:00:41.660 He's hot like sriracha, dropping fervent takes that sting like Szechuan. 00:00:42.240 --> 00:00:44.840 Dillon, spicy take curry. 00:00:45.960 --> 00:00:47.760 Fellas, what are we up to today? 00:00:48.880 --> 00:00:50.960 Today we're going to talk about internal tooling. 00:00:51.720 --> 00:00:53.780 Specifically, why internal tooling sucks. 00:00:53.870 --> 00:00:55.460 Or at least that's my take. 00:00:56.440 --> 00:00:59.260 Maybe Dillon and Scott have alternative takes. 00:01:01.200 --> 00:01:08.140 But yeah, we want to dig into what is internal tooling and why it's usually bad. 00:01:08.660 --> 00:01:11.640 Or maybe what are the pros and cons of it? 00:01:12.220 --> 00:01:13.340 It's always good, Matt. 00:01:14.500 --> 00:01:17.840 There's never a bad internal tooling code. 00:01:19.800 --> 00:01:20.180 Yeah, maybe. 00:01:20.960 --> 00:01:21.820 I haven't seen that. 00:01:22.920 --> 00:01:23.860 But maybe. 00:01:26.140 --> 00:01:30.120 um maybe yeah maybe it's all bad that's how i feel but we'll get to that 00:01:32.280 --> 00:01:35.880 Dillon do you want to define what we mean when we say internal tooling 00:01:37.170 --> 00:01:40.600 uh to me it's something that's owned by the company you work for 00:01:42.200 --> 00:01:45.620 maybe your team owns it maybe some other team within your company owns it 00:01:47.280 --> 00:01:53.080 um but what what does own it even mean like what is the internal tool that we're talking about i 00:01:53.080 --> 00:01:58.800 think like giving specific examples here would be helpful like is it is it a spreadsheet we put 00:01:58.940 --> 00:02:06.240 things into and then people look at it later or is it like some website that we built that people 00:02:06.410 --> 00:02:11.620 insert data into and then it's like it's a custom cms and that's like shown onto a site like there's 00:02:11.700 --> 00:02:15.960 so many different versions of what an internal tool could be i feel like even the examples i gave 00:02:16.180 --> 00:02:16.180 were kind of bad 00:02:16.181 --> 00:02:16.181 well i think it's also like just intrinsically difficult to give examples of 00:02:21.100 --> 00:02:25.320 internal tool, right? Because like an internal tool at HubSpot is going to be different from one at 00:02:25.460 --> 00:02:30.580 Whoop, from one at Airbnb, etc. Like maybe some of them are going to overlap in terms of solving 00:02:30.760 --> 00:02:36.480 a similar problem. But yeah, it's not like I can rattle off a name, for example, and people 00:02:36.800 --> 00:02:39.820 listening to the pod will immediately understand like what we're talking about. 00:02:40.300 --> 00:02:45.020 I think it's easier, and I think you're going to get there, is like talk about an external tool 00:02:45.840 --> 00:02:50.860 that maybe your company or other companies build internal versions of or something similar. 00:02:52.180 --> 00:02:52.880 or wrappers around? 00:02:54.600 --> 00:02:57.420 Yeah, one example for HubSpot that came to mind 00:02:57.510 --> 00:02:58.500 as I was thinking of this topic 00:02:59.940 --> 00:03:01.760 is we have this tool called GitHub Manager, 00:03:02.280 --> 00:03:07.960 which is a internal website UI for managing settings 00:03:08.340 --> 00:03:10.580 across the repos that your team owns. 00:03:12.240 --> 00:03:14.720 So traditionally, if you wanted to change a setting 00:03:14.920 --> 00:03:17.940 for a repository in GitHub, you would go to that repo 00:03:18.220 --> 00:03:19.699 and then go into the settings tab 00:03:19.720 --> 00:03:22.540 and then tinker with the settings that you wanted to change. 00:03:23.980 --> 00:03:28.380 This is like a custom UI that we like visit and like opens a drawer 00:03:28.640 --> 00:03:32.960 and for each repo that you want to edit and you can like change different default settings 00:03:33.100 --> 00:03:38.560 or like, you know, things like apply, you know, or require specific checks to pass 00:03:38.620 --> 00:03:44.420 before PRs can be merged, opting into auto merge, configuring code owners, 00:03:45.320 --> 00:03:45.920 stuff like that. 00:03:46.000 --> 00:03:51.900 it's like manage this internal tool instead of going to github itself uh to manage those settings 00:03:52.380 --> 00:03:58.040 so that's one example from hubspot um i don't know Scott do you have a like an example in mind for 00:03:58.360 --> 00:03:58.360 airbnb that you can share without bleeping too much 00:03:58.361 --> 00:03:58.361 i literally work on an internal tool which 00:04:05.160 --> 00:04:10.180 we've talked about before yeah so i work on something called flow builder for like the next 00:04:10.160 --> 00:04:15.980 week or two before I switch over to a different internal tool. And basically that tool allows 00:04:16.600 --> 00:04:24.860 engineers to format JSON in a workflow tool for what AI output might occur for UI on site, 00:04:25.180 --> 00:04:31.680 mostly like chatbots. I guess like the value of that and probably what I will argue as the best 00:04:31.840 --> 00:04:40.120 values of internal tools are things like security and maybe some customizations. So you can have all 00:04:40.660 --> 00:04:47.500 internal data or sensitive data in this tool very easily. Now, it might not always want to be 00:04:47.700 --> 00:04:52.480 intertwined with the tool, especially if you're open sourcing it. We definitely use third parties 00:04:53.020 --> 00:04:59.500 libraries as part of this tool, but one could argue a tool like this could be built and then 00:05:00.040 --> 00:05:05.180 teams could put their data into it. But it does allow you to easily marry your data into your 00:05:05.200 --> 00:05:07.900 application and it gives you some security. 00:05:08.420 --> 00:05:12.620 Yeah, that's something actually like you saying that you work on the internal tools didn't 00:05:12.800 --> 00:05:17.860 like didn't click for me with this topic until just now in the sense of like, I don't intend 00:05:17.900 --> 00:05:21.220 to say that your job is not delivering value. 00:05:21.860 --> 00:05:25.200 But but I think with my premise, the internal tools suck. 00:05:25.200 --> 00:05:31.080 I think it's maybe we'll we'll have some interesting maybe points to dig into there. 00:05:32.000 --> 00:05:33.800 I feel like what we're going to get to, 00:05:33.810 --> 00:05:35.040 and maybe this is just my take, 00:05:35.070 --> 00:05:37.560 is we all work on internal tools. 00:05:38.800 --> 00:05:39.640 Maybe that's a weird take. 00:05:40.480 --> 00:05:42.760 Maybe Matt's going to burst into flames. 00:05:44.780 --> 00:05:45.980 The difference is the way, 00:05:46.540 --> 00:05:48.460 the perspective of the internal tool 00:05:48.860 --> 00:05:49.760 and the audience, 00:05:50.410 --> 00:05:52.640 whereas the internal tools Matt works on 00:05:53.300 --> 00:05:57.740 are kind of like external third-party tools 00:05:58.000 --> 00:05:59.560 that all teams need to consume, 00:06:00.100 --> 00:06:04.920 Whereas the tool I work on, it's a smaller subset of people who need to consume it. 00:06:06.000 --> 00:06:07.520 And it may just be a different audience. 00:06:09.060 --> 00:06:14.040 So like, yeah, we'll get, we'll dig into this more, but there isn't, well, there are probably 00:06:14.340 --> 00:06:19.860 now open source tools that are like Flow Builder, but when it was built, there weren't, right? 00:06:20.260 --> 00:06:26.220 So there wasn't like a clear common solution that companies were running with. 00:06:26.740 --> 00:06:34.520 So one could make an argue that we want to build this tool and we don't want to put the effort in to being the owners and open sourcing it. 00:06:34.730 --> 00:06:50.460 But rather, let's just build it and solve the problem we have at hand because that's the main goal versus like we need to support 20,000 engineers or sorry, 2,000 engineers or something versus I probably support maybe like maybe like 100. 00:06:50.500 --> 00:06:55.840 and we replace writing code with UI 00:06:56.460 --> 00:06:58.900 to streamline the speed of what we're doing. 00:06:59.040 --> 00:06:59.960 So it is a little different. 00:07:01.920 --> 00:07:03.700 So audience is a big key factor here. 00:07:04.920 --> 00:07:08.280 Yeah, I think not necessarily to pivot us away from that. 00:07:08.280 --> 00:07:10.060 I think that's an interesting topic also. 00:07:10.320 --> 00:07:13.440 But I also wanted to like some framing 00:07:13.680 --> 00:07:17.220 that I had thought of while thinking of this topic 00:07:17.860 --> 00:07:19.920 was generally from what I've seen, 00:07:20.060 --> 00:07:22.380 there's sort of like two different kinds of internal tools. 00:07:24.220 --> 00:07:27.080 One is like a tool that wraps an existing tool. 00:07:27.240 --> 00:07:28.400 So the example I provided earlier 00:07:28.520 --> 00:07:29.520 of like this GitHub manager, 00:07:29.600 --> 00:07:31.620 it's like sort of wraps the functionality 00:07:31.840 --> 00:07:32.960 that GitHub already provides, 00:07:34.020 --> 00:07:35.420 just in maybe a nicer interface 00:07:35.820 --> 00:07:39.180 or something that can be, you know, 00:07:39.260 --> 00:07:41.680 provide additional context for internal tools 00:07:42.080 --> 00:07:44.040 and or internal users 00:07:46.020 --> 00:07:47.900 and maybe provides additional functionality. 00:07:49.580 --> 00:07:51.040 But then I think that there's like another bucket 00:07:51.300 --> 00:07:54.380 that's like internal tools that are effectively 00:07:54.960 --> 00:07:59.360 complete alternatives to existing external tools 00:07:59.400 --> 00:08:00.360 for lack of a better term, 00:08:00.880 --> 00:08:02.020 tools that are common in an industry. 00:08:03.440 --> 00:08:05.460 These are probably ones that are even harder 00:08:05.600 --> 00:08:08.100 for us to give examples to, I think. 00:08:09.540 --> 00:08:10.980 You guys feel free to correct me if I'm wrong here, 00:08:11.040 --> 00:08:13.100 but one example that comes to mind with HubSpot 00:08:13.100 --> 00:08:16.919 is we have an internal dependency manager 00:08:16.940 --> 00:08:19.720 for our front end packages at HubSpot, 00:08:20.250 --> 00:08:25.960 which is basically an alternative to NPM, YARN, PMPM, et cetera. 00:08:27.780 --> 00:08:30.300 And it's not built on top of those things. 00:08:30.460 --> 00:08:32.340 It's a completely different custom system 00:08:33.039 --> 00:08:36.039 that manages our dependencies and manages installing dependencies 00:08:36.240 --> 00:08:37.479 and resolving them. 00:08:38.800 --> 00:08:40.719 And so that's an example in my mind 00:08:40.719 --> 00:08:42.300 that falls in the second bucket. 00:08:43.510 --> 00:08:45.919 I don't know if you guys have better examples 00:08:45.940 --> 00:08:47.260 or more clear examples? 00:08:48.000 --> 00:08:49.020 I can get one. 00:08:50.280 --> 00:08:51.460 Whoop is a smaller company. 00:08:51.760 --> 00:08:52.240 That's where I work. 00:08:53.999 --> 00:08:57.320 So honestly, mostly what we use is external tooling. 00:08:58.420 --> 00:09:00.320 It's just that's the way-- 00:09:00.580 --> 00:09:02.080 we're a late-stage startup, so we're just 00:09:02.560 --> 00:09:04.140 grabbing random third-party things 00:09:04.340 --> 00:09:06.840 and trying to get things working as quickly as we can. 00:09:07.840 --> 00:09:10.160 But they do have a tool internally called Easy Deploy, 00:09:10.410 --> 00:09:13.000 which is sort of like Backstage that's fully homegrown. 00:09:14.000 --> 00:09:15.580 and the infra team owns it. 00:09:16.210 --> 00:09:17.280 But it's kind of like service. 00:09:19.260 --> 00:09:19.700 Discoverability 00:09:20.430 --> 00:09:21.260 is all in one place, 00:09:21.940 --> 00:09:23.760 and then you can manage deploys and roll 00:09:24.030 --> 00:09:24.840 pods and 00:09:25.720 --> 00:09:27.420 discover tech docs for all the different 00:09:27.760 --> 00:09:28.720 Java services they own. 00:09:30.500 --> 00:09:31.460 But it has its own issues. 00:09:32.260 --> 00:09:33.440 I could complain about it 00:09:33.570 --> 00:09:33.940 all day, 00:09:35.820 --> 00:09:37.580 but I won't because I'm a good 00:09:37.740 --> 00:09:37.920 employee. 00:09:40.480 --> 00:09:41.280 No, but 00:09:42.000 --> 00:09:43.160 it's actually kind of good. 00:09:43.640 --> 00:09:50.780 maybe we'll get to like why companies end up building internal tools i think what ends up 00:09:51.000 --> 00:09:57.400 happening is the bigger you get the the less like that external tool like is a one-size-fits-all for 00:09:57.400 --> 00:10:02.800 your company and then you start to discover that you need like specific support for very specific 00:10:02.960 --> 00:10:07.780 things and then you try to get that company to do it for you and they're too slow and they're too 00:10:07.980 --> 00:10:12.259 expensive so you just eventually you cave and you say all right we're going to hire some people to 00:10:12.240 --> 00:10:17.560 just build an internal tool to do that thing for us. I feel like that's kind of why this happens, 00:10:17.860 --> 00:10:17.860 but curious on y'all's takes. 00:10:17.861 --> 00:10:17.861 One other aspect besides just growing large is just that the 00:10:25.340 --> 00:10:30.920 existing tooling doesn't solve your current day needs as well. So I think you can definitely grow 00:10:31.140 --> 00:10:35.380 that the gap between the problem you need to be solved versus what the external tool solves 00:10:35.700 --> 00:10:39.979 definitely grows over time as your company grows. But I think also you can start from a point where 00:10:40.900 --> 00:10:45.300 you have a specific problem you need to solve and none of the external tooling available already 00:10:45.800 --> 00:10:51.080 solves it and so then you like basically from the get-go you decide to go in a different path 00:10:52.160 --> 00:10:57.660 that's exactly what i was going to say uh there's a few examples of like sometimes we build this 00:10:57.860 --> 00:11:01.940 internal tool because there isn't a third-party solution there yet that's basically what i was 00:11:02.020 --> 00:11:08.360 talking about with flow builder and maybe some of the tools that you deal with also yeah you have a 00:11:08.320 --> 00:11:15.520 unique problem that the external tool can't solve, or it doesn't have a part of exactly 00:11:15.690 --> 00:11:20.300 the solution you need, which could be the difference between creating your own tool 00:11:22.180 --> 00:11:26.000 or just wrapping the tool and adding some layer on top of it. 00:11:26.620 --> 00:11:31.260 So there might be some layer of, again, sensitive data that you need to add, or it just doesn't 00:11:31.340 --> 00:11:31.880 do something. 00:11:34.180 --> 00:11:47.940 Yeah, so basically it usually comes down to the use case you're describing, Matt, where it's like there's some unique thing about what we're doing or the vision is like, oh, we're different and we need to make this change to support. 00:11:49.600 --> 00:12:00.140 Yeah, I think there's like a very small percentage chance where it's like the internal tool sort of predates the external tool also. 00:12:00.780 --> 00:12:09.740 Like in a sense where like the path was proven right of like the company went down a different path than what maybe other companies are doing for solving a specific use case. 00:12:10.540 --> 00:12:15.560 And then maybe reach the stage where it's like actually more like general enough that any other company could adopt it. 00:12:16.420 --> 00:12:22.500 And, you know, like maybe a good example here is like Borg from within Google, which is like a pre-Kubernetes concept. 00:12:22.630 --> 00:12:26.340 Like that's how Google deploys things, as my understanding is Borg. 00:12:26.460 --> 00:12:33.600 And they basically took maybe the good parts, I don't know, maybe some parts of it and extracted it out as Kubernetes and open source. 00:12:33.610 --> 00:12:34.040 It is minor. 00:12:34.310 --> 00:12:37.680 Like I could be getting that completely wrong, but that's my loose understanding of it. 00:12:38.010 --> 00:12:44.940 So that's maybe a good example where, you know, a company went and built an internal tool to solve a use case they had that was different from the existing solutions. 00:12:45.820 --> 00:12:51.820 And then ultimately it became popular enough that, you know, other companies started to adopt it as the standard as well. 00:12:53.020 --> 00:12:55.200 But I think that's generally a pretty rare case. 00:12:56.620 --> 00:13:01.100 And I would say like, maybe this is getting a little bit to my core thesis, maybe too early. 00:13:01.320 --> 00:13:10.280 But I think generally speaking, like that case where a company decides that an external tool just doesn't meet the use cases and they start building from scratch a new thing. 00:13:11.140 --> 00:13:13.940 I think 90% of the time that's like maybe the wrong decision. 00:13:15.480 --> 00:13:18.920 Yeah, maybe that's the hot take is maybe 90% feels too strong. 00:13:20.260 --> 00:13:30.420 One thing that I was thinking of, and maybe this is weird approach to this conversation is sometimes you just have somebody in your company who's like a subject matter expert. 00:13:31.560 --> 00:13:36.520 Maybe they've like written, maybe they work like on the React core team or something. 00:13:37.460 --> 00:13:39.700 And then they're just like, you know what, we could do this ourselves. 00:13:40.180 --> 00:13:40.920 I've already done it before. 00:13:42.660 --> 00:13:44.080 Let's just like spin up our own version of this. 00:13:44.260 --> 00:13:45.380 We'll have full control over it. 00:13:46.860 --> 00:13:48.500 I think there are cases like this. 00:13:48.740 --> 00:13:51.200 I've worked with, both of us have probably worked with people 00:13:51.870 --> 00:13:52.880 that can do this kind of stuff. 00:13:53.510 --> 00:13:57.640 I think of like Arty in one case where she has like a deep understanding 00:13:58.150 --> 00:14:02.540 of JavaScript and able to like create libraries that solve problems 00:14:02.840 --> 00:14:06.620 that maybe aren't even like open sourced specifically. 00:14:09.040 --> 00:14:13.099 Something called Jambox that we used in the past that could like snapshot 00:14:13.120 --> 00:14:14.700 got server requests for end-to-end tests. 00:14:16.240 --> 00:14:19.560 It was kind of clunky, but there wasn't really anything else out there 00:14:20.040 --> 00:14:22.020 that was off the shelf and easy to use. 00:14:22.490 --> 00:14:25.140 And maybe Mac can tell me I'm wrong and we should have been using something else. 00:14:25.670 --> 00:14:27.460 And I'll be like, that's great, I'm going to use that at Whoop. 00:14:29.360 --> 00:14:35.100 But I think there's special cases where you have people that are just really smart 00:14:35.480 --> 00:14:39.920 and there's a specific problem that you can't solve or you're having trouble solving. 00:14:40.840 --> 00:14:44.300 And it's like a really good opportunity to build something in internal. 00:14:45.700 --> 00:14:48.940 Yeah, I think that's a really good example of it could be good. 00:14:48.960 --> 00:14:49.760 It could be bad. 00:14:50.300 --> 00:14:54.900 It defends like totally because I think I immediately thought of Tungsten, which was 00:14:55.400 --> 00:14:57.560 Wayfair is basically React substitute. 00:14:57.720 --> 00:15:04.600 They wanted to try to keep the platform they had and go down with this MVC framework that 00:15:04.600 --> 00:15:08.420 they had and try to build a solution that worked for them where they had one person who 00:15:08.420 --> 00:15:09.220 knew it really well. 00:15:09.720 --> 00:15:11.460 And I'm not saying like this is wrong. 00:15:11.490 --> 00:15:16.340 Like Jambox actually probably could have been the right solution for the problem at the time. 00:15:16.660 --> 00:15:18.440 There just wasn't enough buy-in for that. 00:15:18.490 --> 00:15:21.320 It's a different example that we were talking about. 00:15:21.560 --> 00:15:26.780 But I think the things, the overarching concepts here is like cost first. 00:15:27.300 --> 00:15:32.240 Like it takes a big cost to support these things. 00:15:32.290 --> 00:15:35.560 If you have one engineer that knows how to do this, that's not ideal. 00:15:35.700 --> 00:15:40.420 Just because one engineer is really smart and can bang something out, that's not going to help with the cost. 00:15:40.880 --> 00:15:42.320 Everyone needs to learn about it. 00:15:43.180 --> 00:15:49.720 Anyone who comes in now needs to learn how this tool might work, depending on how important it is to the overall structure of what they're building. 00:15:50.900 --> 00:15:53.060 And then it needs support, right? 00:15:53.340 --> 00:15:56.300 Like you need to work on it all the time or you need to document it well. 00:15:57.090 --> 00:15:59.760 And then the usability of it has to be really good. 00:15:59.850 --> 00:16:02.940 So there needs to be not just engineers on it. 00:16:03.200 --> 00:16:09.400 There needs to be people who are designers or understand how the workflow should work. 00:16:09.920 --> 00:16:12.980 It's great that we can build something, but if the patterns aren't great. 00:16:13.380 --> 00:16:21.700 One of the reasons React is so used is I think the patterns are fairly easy to understand once you get them. 00:16:21.880 --> 00:16:28.080 I'm not saying all the hooks, but just the concept of you build something once and then you reuse it is kind of a simple pattern. 00:16:28.640 --> 00:16:31.060 And I think that really helped a lot. 00:16:31.500 --> 00:16:33.960 And obviously there's a huge community of support there. 00:16:34.480 --> 00:16:39.100 And because it's an external tool, you have support, which is a pro of external tools, right? 00:16:39.600 --> 00:16:41.780 And people can come in and know how this thing works. 00:16:42.340 --> 00:16:46.740 So it's kind of a double-edged sword depending on what you're building. 00:16:47.000 --> 00:16:49.520 And you really have to really think these things through. 00:16:50.360 --> 00:16:57.860 Smaller things maybe make sense for someone who's really intelligent to just build if it can be documented well and the cost isn't that high. 00:16:58.240 --> 00:17:02.440 But the tools like Matt's talking about, like bun, NPM, yarn replacements. 00:17:02.550 --> 00:17:10.420 And I know I said I'd try to argue for internal tools, but I don't know if I could argue for that one specifically. 00:17:10.620 --> 00:17:15.319 It just seems redundant and now difficult. 00:17:15.770 --> 00:17:18.040 Your whole architecture relies on something like that. 00:17:18.350 --> 00:17:20.880 The cost of that is absolutely massive. 00:17:21.189 --> 00:17:23.660 And I think that's the number one factor to weigh here. 00:17:25.860 --> 00:17:54.780 Yeah, I kind of like the concept you're maybe talking about there's kind of like there's like so many sharp edges with building an internal tool. And especially on onboarding, which is like something I've been feeling sort of acutely. I mean, I've been here almost a year now, but it's still like kind of crazy that there's like things I don't know that I should maybe know that are like basically like sort of maybe not in a daily, but like weekly used internal tools. 00:17:56.340 --> 00:18:03.540 weekly in the sense of like someone might use this once a week at least and yeah I don't know there's 00:18:03.580 --> 00:18:11.380 just like so many like places where you need added polish and added quality in order to make it easy 00:18:11.380 --> 00:18:16.720 to use whereas like if it's an external tool that you've adopted then it's like you kind of get to 00:18:16.770 --> 00:18:22.160 lean on the fact that maybe someone joining a company is like has experience with using that 00:18:22.200 --> 00:18:26.020 tool at the previous company, right? Like GitHub is a good example as like sort of a standard, 00:18:26.710 --> 00:18:33.160 um, I think like get forge or get backend, um, that, uh, most engineers will know and recognize, 00:18:33.740 --> 00:18:37.700 right. And so they'll know how to use it when they join sort of day one versus having to learn, 00:18:38.470 --> 00:18:42.440 you know, something completely custom, uh, like as they onboard. 00:18:43.980 --> 00:18:48.340 You know, one thing that scares me about internal tools, especially like when you join a company, 00:18:48.400 --> 00:18:54.860 like maybe I'm just going off of what Matt just said is when like you're not sure if the person 00:18:54.890 --> 00:19:00.240 that created it or the people that maintain it are even still at the company sometimes and then 00:19:00.340 --> 00:19:05.100 maybe there's somebody who's like contributed to it but they all they've done is like make a one 00:19:05.240 --> 00:19:10.620 line change they don't even know it so then like when you go to look for somebody for help on that 00:19:10.820 --> 00:19:14.599 tool you're like oh let's go look at the contributors list and it's just people that 00:19:14.740 --> 00:19:20.220 have tweaked it and know nothing about it um and eventually it's yeah it just becomes like 00:19:21.320 --> 00:19:27.560 this lone project that everyone's scared of um yeah i don't know what else nowhere else to go 00:19:27.570 --> 00:19:32.360 with that but yeah that's that i can that's a big argument against internal tools is if they're not 00:19:32.460 --> 00:19:39.579 properly owned and continue to be owned and like um taken care of then they turn into a big issue 00:19:39.600 --> 00:19:39.600 for your company. 00:19:39.601 --> 00:19:39.601 There's also like kind of along that same line of thinking is like, 00:19:45.820 --> 00:19:51.000 there's also decisions that are lost to time for internal tools. Like it's like, you know, 00:19:51.080 --> 00:19:57.000 it's like hard to tell if like, is this a feature or is this a bug or is this just like unknown, 00:19:57.210 --> 00:20:01.660 like undefined behavior of this internal tool? Like, you know, the person implemented it 10 years 00:20:01.690 --> 00:20:07.600 ago, did they think about this use case or did they not? And it's like hard to say because yeah, 00:20:07.780 --> 00:20:12.340 the person might not be at the company anymore or uh or if they are they've moved completely away 00:20:12.440 --> 00:20:16.700 from it or like or even even if they are and they're working on the same team they probably 00:20:16.880 --> 00:20:20.060 can't remember what they thought about 10 years ago right because it probably wasn't documented 00:20:20.460 --> 00:20:24.040 so i think there's like you know you could see that the same with external tooling but i feel 00:20:24.040 --> 00:20:29.340 like with external tooling it like usually there's more care and polish put into it than with internal 00:20:29.600 --> 00:20:29.600 tooling 00:20:29.601 --> 00:20:29.601 yeah with external tooling there's like there's so many more stakeholders and there's more 00:20:35.640 --> 00:20:41.460 like a larger expectation from those people that you like you you write out your architecture 00:20:41.860 --> 00:20:45.800 decision record or whatever i don't know if you guys use those but i've been thinking about that 00:20:46.040 --> 00:20:51.280 recently i've been making a lot of decisions within my company and i don't document it properly 00:20:51.840 --> 00:20:55.920 and then somebody comes to me like months later and they're like why did we do this and i'm like 00:20:56.320 --> 00:20:59.680 well it's in my head let me just tell you and they're like why isn't it written down 00:21:00.540 --> 00:21:05.520 and that's probably a common problem with internal tooling and and i think with external it's like 00:21:05.540 --> 00:21:11.980 or pressure from the public to sort of fill in that documentation over time and keep it up to date. 00:21:13.160 --> 00:21:17.140 I feel like it's hard to write everything down on why you make a decision on something. 00:21:17.260 --> 00:21:18.760 You could be doing docs for months. 00:21:18.820 --> 00:21:20.300 You have to execute at some point. 00:21:20.460 --> 00:21:25.600 We do docs, but we try to really emphasize don't put too much time into them. 00:21:27.059 --> 00:21:28.680 We can do more and more docs. 00:21:29.060 --> 00:21:31.820 Let's just make sure we're all on the same page. 00:21:32.380 --> 00:21:33.620 Sorry, that's just an aside comment. 00:21:34.160 --> 00:21:37.460 But I think it comes back to what folks have been talking about is buy-in. 00:21:38.110 --> 00:21:44.300 You need all the buy-in for these tools, and everyone needs to be on board and agreed to that we're going to use them. 00:21:44.530 --> 00:21:58.080 I think a lot of the tools we talk about not being successful as well are actually tools that engineers need to extend and not the end tools that Flow Builder is where the audience happens to be engineers. 00:21:58.560 --> 00:22:09.140 Like tools where the audience is like people who work internally or partners, suppliers, where they just need to see data, like user data or numbers. 00:22:09.640 --> 00:22:25.960 Like those kinds of tools are often built in-house, but they work versus it's really like these framework level tools almost where it's something that the engineering system might rely on heavily. 00:22:26.980 --> 00:22:38.020 And then that needs to be carried forward for the rest of the company's existence, or it could be really difficult to migrate off of it. 00:22:38.020 --> 00:22:52.380 So when knowledge transfer occurs or doesn't occur, it creates these situations where people are afraid of it, a la Bagel at Wayfair or, yeah, Tungsten. 00:22:52.500 --> 00:22:58.860 And like, um, I think that actually Jambox was a good example of a tool that could work. 00:22:59.280 --> 00:23:01.180 I do think there are probably solutions now. 00:23:01.820 --> 00:23:04.980 Um, but it was a tool that could work. 00:23:05.040 --> 00:23:11.660 It just needed the buy-in that we, that it didn't have where someone, an engineer really 00:23:11.860 --> 00:23:15.820 built like a, a problem, a solution, and we were not dedicating time to it. 00:23:15.820 --> 00:23:19.440 We're dedicating time to other things and there should have been parallel tracks there 00:23:19.920 --> 00:23:21.460 and leadership needs to sell. 00:23:21.620 --> 00:23:25.880 This is a solution to solve this large problem engineers are facing. 00:23:26.460 --> 00:23:28.640 So part of it could be that. 00:23:28.730 --> 00:23:30.280 I think it is replaced now. 00:23:30.280 --> 00:23:34.480 I think Yair said by playwright testing, which I guess makes sense. 00:23:35.080 --> 00:23:41.660 But the point is, even if you do that, that's still a smaller subset problem that is easy to replace. 00:23:42.030 --> 00:23:51.180 Whereas, again, if your package manager that manages hundreds of packages or thousands of packages in your org needs to be replaced, 00:23:51.580 --> 00:23:54.280 I could see that being a really big rewrite. 00:23:57.540 --> 00:24:00.420 Kind of dovetailing into what you were saying there, Scott, 00:24:00.420 --> 00:24:05.220 I think maybe the core realization that I'm having also is like, 00:24:06.380 --> 00:24:11.100 even if you have an internal sort of maybe developer tooling team 00:24:11.300 --> 00:24:16.440 or organization or like sort of an org focused on building 00:24:16.560 --> 00:24:17.820 and maintaining these internal tools, 00:24:17.920 --> 00:24:25.060 I think it'll always be second to whatever your company is solving, right? 00:24:25.140 --> 00:24:28.860 Like what is your core value that your company provides? 00:24:29.420 --> 00:24:35.320 Even if you have an org focused on this, it's still like, yes, that org will be their primary focus. 00:24:35.660 --> 00:24:43.220 But that org, the value to the company is maybe second to sales or whatever, right? 00:24:43.380 --> 00:24:46.500 Second to a customer-facing part of the company. 00:24:46.980 --> 00:24:50.200 So I think it's really just like, yeah, it comes down to investment. 00:24:50.490 --> 00:25:03.280 And I think it's almost impossible to find a company that will give the right amount of investment into internal tooling to make sure it is well-maintained and well-supported. 00:25:04.820 --> 00:25:09.560 And it continues to solve the needs and stays up to date and things like that. 00:25:11.700 --> 00:25:29.960 So I guess we're now like kind of in a place where it's like, when do you pick one or the other? And like, what are the pros and cons? Like, I keep bashing on this example, but a package manager is probably not a good place to, or a good hill to die on for, we're going to build a custom tool that we'll need to support forever. 00:25:30.660 --> 00:25:39.060 But I think some of the things we've brought up are, I mean, we built internal tracking mechanisms, which maybe that's not even the best use case. 00:25:39.130 --> 00:25:45.940 You could probably use one, but maybe the system you're working within already has constraints where you can't use a third party. 00:25:46.580 --> 00:25:57.880 So it's like, look at cost, look at the support it's going to take, how many people that does it impact, how does it hurt security, and how much customization do you really need? 00:25:59.300 --> 00:26:03.320 And how much effort is it going to be to scale what you're building? 00:26:03.960 --> 00:26:08.920 So these are just like kind of some rules of thumb before you do it. 00:26:09.780 --> 00:26:19.380 But we didn't really talk about like why you might need to wrap a third party in something like all of the things we do here. 00:26:19.780 --> 00:26:38.100 I think I brought it up briefly, but I might wrap something when you get maybe, let's just say, some percentage of all the things from an open source tool, but you need to either wrap sensitive data or some sort of other features you need to roll with it. 00:26:39.180 --> 00:26:41.880 You could also fork something if things don't work. 00:26:42.380 --> 00:26:50.920 Well, I would actually say that that's likely dangerous unless you can avoid it or you know that it's going to come soon with that package. 00:26:51.800 --> 00:26:57.860 But we've gotten, I've seen, well, bagel is an example of forked and then changed so much. 00:26:58.520 --> 00:27:16.200 You're almost, I don't want to say you're always better off building your own thing, but maybe you're better off like solving the problem in a separate space and then marrying two items before you just go rogue or maybe building your own if you can support the cost. 00:27:18.000 --> 00:27:22.800 Like one thought comes to mind is like, it's interesting, at least so far from my experience, 00:27:23.060 --> 00:27:28.780 it's interesting that there's always like, like most tools solve a 90% use case, at least maybe, 00:27:29.280 --> 00:27:33.380 like maybe that's a sweet spot. And, you know, sometimes they solve less of a use case for a 00:27:33.560 --> 00:27:40.240 company, sometimes a little bit more, but it's, I found it pretty difficult to find examples where 00:27:40.290 --> 00:27:47.240 an external tool 100% meets the internal use case. Which makes me wonder, like, you know, 00:27:47.380 --> 00:27:51.280 obviously a company is making a tool and produce like selling the tool, right? 00:27:51.380 --> 00:27:55.460 Like GitHub and Microsoft now is like selling GitHub as a tool. 00:27:56.820 --> 00:28:00.840 Why would they settle for selling a tool that's 90% use case? Right. 00:28:00.880 --> 00:28:04.080 And so like, it makes me wonder, like, maybe that's not the case, right? 00:28:04.100 --> 00:28:07.160 Like, but like, how did we get here in the first place? Right? 00:28:07.340 --> 00:28:11.780 Like how is it possible that it just seems that most places 00:28:13.020 --> 00:28:14.580 maybe, you know, 00:28:14.640 --> 00:28:17.340 don't have a hundred percent overlap with the tools that are available in the 00:28:17.450 --> 00:28:20.580 market. Basically. Um, you know, 00:28:20.580 --> 00:28:23.920 I guess you could boil it down to like companies are different and unique. Um, 00:28:24.320 --> 00:28:27.400 yeah. I'm like, I feel like you're about to get into like philosophy. 00:28:27.820 --> 00:28:31.160 I just think it's impossible for a tool to solve every use case, 00:28:32.120 --> 00:28:34.700 like for your company or your code base, you're in, 00:28:34.920 --> 00:28:39.000 you're always going to have like 150 tools sort of working together to solve 00:28:39.070 --> 00:28:41.920 your problems. And then it's going to be a tons of overlap. 00:28:42.780 --> 00:28:48.180 This kind of reminds me of the product card at Wayfair where they wanted to build one that could be used for any use case. 00:28:48.440 --> 00:28:50.900 And then the answer was like, okay, it's too hard to use. 00:28:51.660 --> 00:28:55.800 Like you can't solve problems for use cases you can't see coming. 00:28:55.970 --> 00:29:02.320 Like maybe some of them, but like if you have to outline as much of the use cases as possible. 00:29:02.500 --> 00:29:08.100 That's why like maybe this isn't the best example, but like Next, for example, 00:29:09.100 --> 00:29:16.640 it has multiple third-party plugins that that also support it because not every website needs login 00:29:16.960 --> 00:29:22.700 not every website needs all the features that will come with it out of the box so it's like we build 00:29:22.780 --> 00:29:29.640 a basic thing and then we provide more and more features as we see fit or as other companies see 00:29:29.780 --> 00:29:29.780 fit or need 00:29:29.781 --> 00:29:29.781 yeah i think that's a good summary um i'm curious like i guess maybe to get us back on 00:29:36.140 --> 00:29:42.960 on topic here. It sounds like we're maybe landing on the classic Scottism of it depends, 00:29:43.860 --> 00:29:49.680 in terms of like whether to build internal tooling or not. I think I like entered this 00:29:50.040 --> 00:29:56.280 conversation thinking like a strong like, don't build internal tools, basically as like the default 00:29:56.520 --> 00:30:01.940 state. But but maybe I'm getting more swayed towards like, yeah, the it depends case where 00:30:01.820 --> 00:30:03.180 where it's like a little bit closer to a, 00:30:03.600 --> 00:30:05.500 not necessarily 50-50, but like closer to it. 00:30:06.030 --> 00:30:06.960 You have more of a, like, 00:30:07.540 --> 00:30:09.300 maybe there's more opportunities 00:30:09.640 --> 00:30:10.720 to reach for internal tooling 00:30:10.930 --> 00:30:12.860 versus always adopting external tooling. 00:30:14.020 --> 00:30:16.660 I feel like we're landing on more of like, 00:30:17.120 --> 00:30:20.040 don't build internal tools that already exist 00:30:20.300 --> 00:30:22.380 for like 90% of your use case. 00:30:22.690 --> 00:30:25.960 Like that is a foolish or fool's errand, right? 00:30:26.180 --> 00:30:29.700 Because why would I want to rebuild a thing? 00:30:29.880 --> 00:30:39.260 Like just because it doesn't support 10% of the use case, we can build on top of it or we can build a secondary thing that works with it. 00:30:39.660 --> 00:30:45.860 Let's not just frivolously build something to say we did it. 00:30:47.200 --> 00:30:48.520 And then look at the cost. 00:30:48.580 --> 00:30:52.600 Like how foundational to your entire organization is what you're building? 00:30:53.040 --> 00:30:56.980 Are you building something that like could be replaced in a few days? 00:30:57.080 --> 00:30:58.960 Like what is the impact that it will have? 00:30:59.720 --> 00:31:07.960 Just asking the right questions before you do something other than just being a gung-ho engineer that can't wait to build something that doesn't exist. 00:31:09.480 --> 00:31:13.580 There's just like a lot more factors, and it requires some diligent attention. 00:31:13.690 --> 00:31:21.580 I almost feel like we should maybe with this episode or come up with like what we see as a guide to like when would you do one versus the other. 00:31:21.770 --> 00:31:25.720 Maybe it could be a Venn diagram or a web diagram. 00:31:25.770 --> 00:31:26.120 I don't know. 00:31:26.170 --> 00:31:26.960 Some sort of diagram. 00:31:28.100 --> 00:31:29.560 I just thought of Venn diagram. 00:31:29.620 --> 00:31:34.760 sounded cool even though uh probably doesn't solve the problem at all but basically there 00:31:35.180 --> 00:31:40.280 it's like very situational and you should really think through the investment that it'll take 00:31:41.919 --> 00:31:46.960 yeah and it seems like like we sort of at the outset we sort of laid this framing of like 00:31:47.620 --> 00:31:50.960 there's internal tools that wrap external tools and then there's internal tools that are like 00:31:51.360 --> 00:31:55.980 completely different or you know replicate an external tool versus like wrapping it and it 00:31:55.880 --> 00:31:59.880 seems like the first bucket of wrapping an external tool 00:32:00.640 --> 00:32:07.280 can be completely reasonable or is easier to validate or to 00:32:08.870 --> 00:32:12.120 reason about and adopt versus the one that-- 00:32:12.540 --> 00:32:17.940 like the second bucket is maybe there's a higher impedance 00:32:18.010 --> 00:32:20.900 curve that you need to meet before you make the decision 00:32:21.140 --> 00:32:23.280 to replicate an external tool. 00:32:24.340 --> 00:32:31.500 Yeah, we're getting to every engineer's favorite topic, which is a long-term cost analysis of the decisions you make. 00:32:33.020 --> 00:32:35.080 That's your favorite thing that your manager can ask you. 00:32:35.240 --> 00:32:36.420 How much is this going to cost us? 00:32:38.220 --> 00:32:45.140 When Scott was having that example, all I could think of is a company deciding that Cursor is just not good or something. 00:32:45.980 --> 00:32:50.820 And so they're like, oh, well, VS Code is open source, so we're just going to build our own version of this. 00:32:50.900 --> 00:32:53.120 And I bet you there's companies out there that are doing this. 00:32:53.700 --> 00:32:58.820 And they just have like five engineers wasting away their time trying to like build a cursor 00:32:58.980 --> 00:32:59.520 clone internally. 00:33:01.280 --> 00:33:02.640 And maybe that was a hot take. 00:33:02.740 --> 00:33:04.600 And maybe Airbnb is already doing that. 00:33:05.760 --> 00:33:06.880 We use the appropriate plugins. 00:33:07.140 --> 00:33:08.580 We trialed cursor. 00:33:09.180 --> 00:33:10.500 It was just not that popular. 00:33:10.680 --> 00:33:14.920 I guess like there's a lot of plugins with VS Code now that you can just basically do 00:33:14.920 --> 00:33:15.820 the exact same thing. 00:33:16.460 --> 00:33:19.140 So yeah, I agree with you, though. 00:33:19.260 --> 00:33:20.240 Someone's probably building that. 00:33:20.400 --> 00:33:26.460 They're probably like, well, we could do AI in our code editor faster. 00:33:27.120 --> 00:33:30.380 Honestly, they're probably not wrong. 00:33:31.300 --> 00:33:33.800 It's just, is it going to be worth the investment long term? 00:33:33.960 --> 00:33:36.060 Do they do that homework up front? 00:33:36.160 --> 00:33:37.480 Or also, are you going to sell it? 00:33:37.960 --> 00:33:42.700 What's the point of making your workflow faster if you're not like, I don't know. 00:33:44.240 --> 00:33:48.980 Maybe it's like five cents less per token because they did it themselves or something. 00:33:49.280 --> 00:33:51.560 They're going direct to the open API. 00:33:52.080 --> 00:33:52.500 Yeah. 00:33:53.480 --> 00:33:54.040 Oh, my God. 00:33:54.460 --> 00:34:02.040 Now you're reminding me of a certain job Matt and I had where it's like, let's just build everything ourselves because it costs less. 00:34:02.660 --> 00:34:03.900 And it's easy, right? 00:34:04.420 --> 00:34:07.460 That's another thing you're making me think of. 00:34:07.560 --> 00:34:10.820 Like when we built our own dev key setup and we were like. 00:34:10.889 --> 00:34:13.659 Is this when you were at your like for that smaller startup? 00:34:14.560 --> 00:34:16.020 Yeah, when we were working at Fireworks. 00:34:17.399 --> 00:34:22.940 We basically, it was really expensive to store our API keys through Google, if I remember correctly. 00:34:23.600 --> 00:34:27.899 And we found a smaller place, but we had to build out essentially a middleware for it. 00:34:28.860 --> 00:34:35.260 And that was like, oh, it's just like this simple middleware that will take like a month maybe. 00:34:35.780 --> 00:34:42.500 It was like a painstaking three to six month process for folks with only like two engineers working on it. 00:34:42.790 --> 00:34:45.320 And yeah, it's saved and it was probably worth it. 00:34:45.480 --> 00:34:52.440 But like sometimes you have to look at like, does it, should we pay more now? 00:34:52.700 --> 00:34:59.460 So, or, or hire more people to do something before, like it may be, I don't know the state 00:34:59.460 --> 00:35:04.020 of the company more if it was the right call or not, but like, what is the amount that it 00:35:04.160 --> 00:35:07.940 costs and what would be the amount of a couple of engineers who need to work on it? 00:35:08.420 --> 00:35:12.040 And like, how can we factor that in versus just saying, oh, it's easy. 00:35:12.160 --> 00:35:13.000 It'll take a month. 00:35:13.400 --> 00:35:22.060 Always, I mean, I've been guilty of this lately, but always just assume it takes long, like at least one third plus longer than you think it's going to take with good intentions. 00:35:24.200 --> 00:35:31.620 One thing you made me think of when you were saying that is, is if a company decides like, oh, we're going to take on this internal tool, it's going to take us two months. 00:35:32.600 --> 00:35:37.040 Can they halfway through decide like, oh, we didn't do enough research. 00:35:37.460 --> 00:35:38.360 There's actually something better. 00:35:38.600 --> 00:35:43.760 Can they just stop themselves and cancel the project and pivot? 00:35:45.500 --> 00:35:47.620 Yes, Arlo at Wayfair. 00:35:48.300 --> 00:35:53.260 We spent an entire year building an interior design project to catch up to another project. 00:35:53.480 --> 00:36:00.480 This is another example where, and sorry, I'll try to be quick here, but basically I had been thinking about this example. 00:36:01.380 --> 00:36:06.980 We wanted to build an interior design app to catch up to this competitor that was one year ahead of us. 00:36:07.480 --> 00:36:15.100 And when we started the backend engineer, Ross kept asking, like, are you sure we need to do this with no Wayfair related things? 00:36:15.210 --> 00:36:17.760 Like Wayfair, people can't know it's related to Wayfair. 00:36:17.790 --> 00:36:19.620 Like we had to build everything from scratch. 00:36:19.960 --> 00:36:24.240 So we, we created like a three to six month hole, like building from scratch. 00:36:25.040 --> 00:36:32.360 And then a year later, after we built and launched the product, they were like, oh, well, the product we were working against also spent a year. 00:36:32.900 --> 00:36:40.460 And about as many people, there were 17 people working on this project, engineers, and they were still a year ahead of us. 00:36:40.510 --> 00:36:43.320 So they just deemed it like, oh, we can't possibly beat them. 00:36:43.350 --> 00:36:54.180 And instead of rolling it out with like keep the lights on and try to get some users, they just folded one of the two of the features that we built into like the lists on Wayfair. 00:36:54.440 --> 00:36:57.280 I don't know if that still exists, but I remember being really disappointed. 00:36:57.370 --> 00:37:03.340 It's like, why not just put it out there and then give it to a team to own bugs and have one or two engineers use it? 00:37:03.390 --> 00:37:08.280 You just invested millions of dollars on a product that you're not even going to launch. 00:37:10.020 --> 00:37:11.100 Dang, that sucks. 00:37:13.420 --> 00:37:18.640 Yeah, I mean, at the end of the day, I don't care, but they could have made money off of it. 00:37:19.440 --> 00:37:20.300 I feel the same way. 00:37:20.450 --> 00:37:23.140 All right, I'm going rabbit holing, but I feel the same way about the registry. 00:37:23.700 --> 00:37:26.880 if they just kept it, it's money you're gonna make. 00:37:28.140 --> 00:37:28.420 All right. 00:37:28.890 --> 00:37:30.700 Before we move on, I had a couple hot takes 00:37:31.320 --> 00:37:33.500 because my takes aren't spicy enough, 00:37:35.430 --> 00:37:36.100 is what I was told. 00:37:37.460 --> 00:37:39.320 But these are more against external tooling. 00:37:41.360 --> 00:37:43.820 I feel like maybe we didn't talk about this much, 00:37:44.000 --> 00:37:45.700 but I think external tooling kind of sucks. 00:37:46.260 --> 00:37:49.580 And the reason is whoever owns it, 00:37:49.690 --> 00:37:50.760 it could be privately owned, 00:37:51.300 --> 00:37:52.620 maybe open source is a little bit better, 00:37:53.020 --> 00:37:55.220 But at some point in time, it can just stop being maintained. 00:37:55.980 --> 00:37:56.720 And then what do you do? 00:37:56.940 --> 00:37:59.260 You fork it or you move on, you find something new. 00:37:59.720 --> 00:38:01.500 That can be really disruptive for your company. 00:38:02.960 --> 00:38:08.860 Another thing is new versions will come out that feel almost impossible to migrate to. 00:38:08.860 --> 00:38:10.020 You just don't have time to do it. 00:38:10.540 --> 00:38:19.200 Or they change the feature of that tool or the features for that tool in a way that just don't align with your company at all. 00:38:20.180 --> 00:38:23.840 And now you're like stuck in a weird spot where you're like, I guess we'll just stay on version 8 forever. 00:38:25.400 --> 00:38:28.100 Or we have to build something ourselves or move on to something new. 00:38:28.680 --> 00:38:33.340 So in that sense, and it makes me think a lot of like Next.js, it just like morphs over time. 00:38:33.900 --> 00:38:42.020 And it feels like every time they release a new version, it's something to like push you closer to Vercel or like push you to use Vercel. 00:38:42.600 --> 00:38:45.220 It's always some new feature that's only supported on their services. 00:38:45.760 --> 00:38:50.200 Then they give some blog post that's like, hey, you can self-host this. 00:38:51.370 --> 00:38:53.380 And we promise it's easy, but they're lying. 00:38:54.560 --> 00:38:56.460 But really what I'm saying is Vercel kind of sucks. 00:38:57.660 --> 00:38:58.060 There you go. 00:38:58.160 --> 00:38:58.760 There's my hot take. 00:39:00.420 --> 00:39:01.200 Vercel, hire me. 00:39:02.020 --> 00:39:03.520 Damn, that was spicy from you. 00:39:07.880 --> 00:39:09.580 I just had to let it boil up. 00:39:10.380 --> 00:39:14.020 It took 15 episodes for your first spicy take. 00:39:15.400 --> 00:39:15.400 takes a long time to boil water you know 00:39:15.401 --> 00:39:15.401 you got two coffees today didn't you 00:39:24.080 --> 00:39:28.680 yeah yeah so by this time next year we'll have the second hot take from Dillon 00:39:33.420 --> 00:39:37.420 all right um i think we've been talking a decent amount of this stuff i think i feel like we 00:39:37.480 --> 00:39:42.719 covered this topic pretty well um curious if anyone has any last points otherwise do we want to 00:39:43.400 --> 00:39:44.920 transition into a standup. 00:39:48.020 --> 00:39:49.940 All right, Scott, what's up with you? 00:39:51.060 --> 00:39:51.800 Oh, geez. 00:39:53.200 --> 00:39:55.120 Okay, well, I kind of finally 00:39:57.260 --> 00:39:59.580 made the feature I was working on forever 00:40:00.560 --> 00:40:01.240 quite resilient. 00:40:01.560 --> 00:40:04.960 I'm building like one more feature on top of it. 00:40:05.220 --> 00:40:07.460 I was able to, in the last two days, 00:40:07.520 --> 00:40:09.020 get back to the feature I was working on before, 00:40:09.200 --> 00:40:10.420 which was like a search palette. 00:40:11.060 --> 00:40:12.440 I'm finalizing that. 00:40:12.880 --> 00:40:16.820 And then my team is switching over to a different project. 00:40:18.000 --> 00:40:25.760 Essentially, they took the two most senior folks on the team who were working on a new version of what we build. 00:40:26.800 --> 00:40:29.520 Basically, just like AI backend. 00:40:30.860 --> 00:40:33.320 And they decided to form a team around that. 00:40:35.420 --> 00:40:41.640 So now there is a new version of that team that's just going to be a backend team for now. 00:40:42.160 --> 00:40:45.200 And we're taking over like another tool, another internal tool. 00:40:45.680 --> 00:40:46.340 So that's exciting. 00:40:46.580 --> 00:40:48.320 Going to Rhode Island this weekend with Brittney. 00:40:49.220 --> 00:40:49.820 That's exciting. 00:40:52.740 --> 00:41:02.100 Fixed siding, the siding, or sorry, I fixed the side door on my house with my friend Scott, Scott and Scott Incorporated. 00:41:03.140 --> 00:41:05.260 Basically put some new trim up. 00:41:05.920 --> 00:41:14.640 And then we had to deal with a can of worms, which is like every time we open something up here, there's like concrete poured right up against wood. 00:41:15.180 --> 00:41:16.420 And it's an absolute nightmare. 00:41:16.680 --> 00:41:17.520 And it's a can of worms. 00:41:17.780 --> 00:41:19.120 But we got the work done. 00:41:19.660 --> 00:41:21.080 We got the screen door back on. 00:41:21.640 --> 00:41:23.380 The screen door is kind of a POS. 00:41:23.980 --> 00:41:27.540 And I realize I'm going to paint it and see if I can make it look nice. 00:41:27.740 --> 00:41:29.340 So happy to get that done. 00:41:32.460 --> 00:41:35.600 And then I'm not sure if I'm supposed to mention this, 00:41:35.680 --> 00:41:40.140 but I had dinner with you and Dillon, Matt. 00:41:42.160 --> 00:41:43.280 I don't know if that's like a secret. 00:41:44.000 --> 00:41:45.520 We're supposed to be talking about that, 00:41:45.660 --> 00:41:47.960 but we had dinner recently and it was nice. 00:41:48.380 --> 00:41:49.900 Yeah, we know each other in real life. Crazy 00:41:50.300 --> 00:41:51.860 We almost recorded a live episode. 00:41:52.520 --> 00:41:52.720 Yeah. 00:41:54.320 --> 00:41:56.100 We should have done some sort of like live, 00:41:56.460 --> 00:41:58.680 just like a 10 second clip or something 00:41:58.740 --> 00:42:00.000 and added it into the episode. 00:42:01.460 --> 00:42:03.120 Alright, I'll give my home remodeling update. 00:42:06.900 --> 00:42:08.040 Recently got mini splits. 00:42:09.420 --> 00:42:10.540 Getting new doors soon. 00:42:11.770 --> 00:42:14.540 So this is all very, very expensive. 00:42:15.380 --> 00:42:17.640 Next thing in my mind is, oh, now I need solar panels 00:42:17.880 --> 00:42:20.620 because I'm powering these mini splits with electricity. 00:42:20.960 --> 00:42:22.480 So maybe next year I'm going to get solar panels. 00:42:23.360 --> 00:42:25.320 So maybe we'll have a whole episode on solar panels 00:42:26.210 --> 00:42:28.260 because that's really relevant to our work experience. 00:42:30.860 --> 00:42:32.160 And then what else is going on? 00:42:33.720 --> 00:42:34.120 I don't know. 00:42:34.240 --> 00:42:35.220 Got a couple trips coming up. 00:42:36.080 --> 00:42:36.980 Got like a wedding this weekend. 00:42:38.380 --> 00:42:44.960 Going to go to Louisiana down in the Cajun South and hang out at my mom's house that I've never been to. 00:42:45.100 --> 00:42:45.780 So that should be cool. 00:42:47.120 --> 00:42:49.520 And then going to have a pretty chill Christmas this year. 00:42:51.920 --> 00:42:52.640 That's pretty much it. 00:42:53.160 --> 00:42:54.040 Work's been going pretty good. 00:42:54.100 --> 00:43:10.260 I've been doing this thing called Web Guild, sort of like at other companies that have like chapters or whatever you want to call them, or like groups of engineers and specific fields will get together and try to solve like problems. 00:43:10.950 --> 00:43:12.560 So I've been like leading that at Whoop. 00:43:13.390 --> 00:43:17.740 I was kind of like hating it, but I slowly started to like enjoy it. 00:43:17.990 --> 00:43:20.380 And now it's almost over and I got to find somebody else to take over. 00:43:20.500 --> 00:43:25.080 So it's been like a really interesting learning experience and maybe an opportunity for growth. 00:43:25.120 --> 00:43:26.200 So that's been pretty cool. 00:43:27.160 --> 00:43:30.100 Like if you asked me last week, I'd be like, this is the worst thing ever. 00:43:30.400 --> 00:43:34.560 But I've had like some pretty good experiences with it more recently. 00:43:34.800 --> 00:43:36.880 So I'm a little bit more optimistic about it. 00:43:37.020 --> 00:43:42.520 I feel like if you aren't in the industry, the way you described it, Dillon, almost makes it sound like it's a cult. 00:43:44.820 --> 00:43:45.680 It kind of is. 00:43:46.500 --> 00:43:49.540 To me, it's actually more like an unofficial union. 00:43:50.860 --> 00:43:51.260 or something. 00:43:51.860 --> 00:43:53.640 It's like you kind of get together 00:43:53.880 --> 00:43:55.500 with like-minded people within your company 00:43:55.740 --> 00:43:57.680 and you share problems 00:43:57.920 --> 00:43:59.620 that you're having. It's like group therapy 00:43:59.890 --> 00:44:01.720 for front-end engineers is really 00:44:01.750 --> 00:44:02.180 what it is. 00:44:07.060 --> 00:44:07.460 Let's see. 00:44:08.380 --> 00:44:09.560 Yeah. What's up with you, Matt? 00:44:10.820 --> 00:44:11.680 I feel like I actually 00:44:11.840 --> 00:44:13.400 wasn't prepared for staying up today. 00:44:13.660 --> 00:44:15.500 I've been churning out a ton of build 00:44:15.700 --> 00:44:17.720 performance changes to an internal 00:44:17.920 --> 00:44:18.660 tool at work. 00:44:20.520 --> 00:44:20.680 although 00:44:21.640 --> 00:44:23.500 ironically some of those are actually maybe regressing 00:44:23.800 --> 00:44:25.360 performance so I need to look into that 00:44:26.040 --> 00:44:27.600 we're just trying to like parallelize 00:44:27.640 --> 00:44:28.700 more things in our build tool 00:44:29.800 --> 00:44:30.460 which is 00:44:31.500 --> 00:44:33.140 there's limits in which you can actually 00:44:33.800 --> 00:44:35.200 get benefits out of doing that change 00:44:35.740 --> 00:44:37.340 so that's a little unfortunate 00:44:39.480 --> 00:44:40.300 outside of that 00:44:42.680 --> 00:44:43.260 yeah I don't know 00:44:43.620 --> 00:44:44.160 I've just been chilling 00:44:45.180 --> 00:44:46.360 I'm contemplating getting arc raiders 00:44:46.460 --> 00:44:48.259 we talked a little bit about arc raiders in the last episode 00:44:48.940 --> 00:44:51.300 Dillon's been convincing me more and more 00:44:51.720 --> 00:44:53.280 I found some like old unused 00:44:53.570 --> 00:44:54.040 gift cards 00:44:55.270 --> 00:44:57.120 and so I redeemed those and now I have like $100 00:44:57.310 --> 00:44:58.640 I can spend on games so 00:44:58.900 --> 00:45:00.520 I need to use those 00:45:00.880 --> 00:45:01.020 yeah 00:45:02.280 --> 00:45:04.060 I think people should try it it's fun 00:45:04.520 --> 00:45:06.780 I know people get like really turned off 00:45:07.000 --> 00:45:08.820 by the idea that you die and then you lose 00:45:09.020 --> 00:45:10.040 everything but the game's 00:45:10.800 --> 00:45:11.220 pretty 00:45:12.180 --> 00:45:14.940 it's like pretty casual in a sense that it gives you a lot 00:45:15.280 --> 00:45:16.520 even when you die so 00:45:16.810 --> 00:45:17.659 it makes it pretty easy 00:45:18.500 --> 00:45:24.740 and then just the game world and the like sound and the enemies and everything in it are just 00:45:24.740 --> 00:45:24.740 like really well polished so it's it's a fun experience 00:45:24.741 --> 00:45:24.741 yeah and then let's see not this 00:45:29.840 --> 00:45:36.160 weekend but next weekend we're planning like sort of another physical in in-person meetup uh with 00:45:36.160 --> 00:45:41.020 with another friend so that should be fun hopefully the three of us three of us can actually hang out 00:45:41.320 --> 00:45:47.640 instead of uh instead of scott needing to continue to paint his house or do something around his house 00:45:48.000 --> 00:45:48.300 We'll see. 00:45:48.460 --> 00:45:49.340 It'll probably happen. 00:45:52.960 --> 00:45:53.200 Yeah. 00:45:53.600 --> 00:45:54.600 I think that's about it. 00:45:55.130 --> 00:45:55.740 Yeah, it depends. 00:45:58.700 --> 00:45:58.940 All right. 00:45:59.350 --> 00:46:00.900 Yeah, I think that about ends it. 00:46:02.280 --> 00:46:02.920 Thanks to the listener. 00:46:03.570 --> 00:46:04.680 If you listened all this way, 00:46:05.570 --> 00:46:06.180 leave us a review. 00:46:06.760 --> 00:46:07.480 We appreciate it. 00:46:08.680 --> 00:46:09.340 Share it with a friend. 00:46:11.220 --> 00:46:11.400 Yeah. 00:46:13.380 --> 00:46:13.460 Yeah. 00:46:13.790 --> 00:46:16.180 Give us at least five stars out of ten stars, 00:46:16.880 --> 00:46:17.640 And that would be pretty good. 00:46:18.160 --> 00:46:19.220 I think there's only five stars. 00:46:20.720 --> 00:46:22.360 Make sure you give us seven stars out of five. 00:46:22.800 --> 00:46:24.000 That way we get boosted. 00:46:28.140 --> 00:46:29.840 Rate, review, like, and subscribe. 00:46:30.920 --> 00:46:31.120 Yeah. 00:46:32.760 --> 00:46:33.880 Smash that subscribe button. 00:46:34.220 --> 00:46:34.320 Later. 00:46:34.780 --> 00:46:35.000 All right. 00:46:35.900 --> 00:46:36.080 See you.