WEBVTT 00:00:12.540 --> 00:00:15.940 Scott: Welcome to the Bikeshed podcast where we talk about all things software engineering, 00:00:16.360 --> 00:00:22.020 Scott: how to behave at your job, and how not to. I'm your co-host, keyboard shortcut hotshot, 00:00:22.540 --> 00:00:28.800 Scott: command line kingpin, and world traveler, Scott Kaye. And alongside with me today are my co-hosts. 00:00:29.240 --> 00:00:32.180 Scott: He built a CLI tool to generate our monologues. 00:00:33.020 --> 00:00:35.340 Scott: Coffee is incapable of crashing his motivation. 00:00:36.300 --> 00:00:38.220 Scott: His blog posts are the documentation. 00:00:39.260 --> 00:00:39.840 Scott: Matt Hamlin. 00:00:40.880 --> 00:00:44.540 Scott: And to my other side, cooking up takes hotter than your air fryer. 00:00:45.280 --> 00:00:47.460 Scott: Dillon, spicy, take, curry. 00:00:48.239 --> 00:00:49.780 Scott: Fellas, what are we 00:00:49.780 --> 00:00:50.560 Scott: up to today? 00:00:52.120 --> 00:00:54.220 Dillon: We're going to try to record a podcast, Scott. 00:00:55.920 --> 00:00:56.580 Dillon: It's going to be sick. 00:00:57.540 --> 00:00:59.100 Scott: Now I'm all out of intros, boys. 00:00:59.260 --> 00:01:00.320 Scott: I'll have to cook up another. 00:01:00.900 --> 00:01:02.720 Scott: I get spicy take to do it for me. 00:01:05.840 --> 00:01:08.400 Matt: I mean, we've had a fairly long hiatus for recording, 00:01:08.500 --> 00:01:10.100 Matt: so I'm surprised that we didn't have a monologue, 00:01:10.400 --> 00:01:12.120 Matt: sort of, or multiple monologues built up. 00:01:12.860 --> 00:01:13.640 Scott: We'll create a backlog. 00:01:14.020 --> 00:01:16.020 Scott: Just assign me the Jira task, Captain. 00:01:19.620 --> 00:01:20.140 Matt: an ice box? 00:01:20.780 --> 00:01:21.120 Scott: That's right. 00:01:24.920 --> 00:01:25.140 Matt: All right. 00:01:25.320 --> 00:01:28.540 Matt: Today, first, we want to start off with our stand-up segment. 00:01:29.520 --> 00:01:32.780 Matt: And then the sort of main topic that we want to dig into is about monorepos. 00:01:33.680 --> 00:01:34.840 Matt: Should you use a monorepo? 00:01:35.390 --> 00:01:35.880 Matt: Are they good? 00:01:36.010 --> 00:01:36.580 Matt: Are they bad? 00:01:37.520 --> 00:01:40.680 Matt: And maybe also we'll talk a little bit about our experience working with a monorepo at 00:01:40.700 --> 00:01:43.600 Matt: Wayfair and maybe also at other companies since then. 00:01:44.980 --> 00:01:47.480 Matt: But yeah, Dillon, do you want to kick us off with your stand-up update? 00:01:47.620 --> 00:01:47.760 Dillon: Sure. 00:01:48.240 --> 00:01:51.760 Dillon: There's construction beneath me on the first floor of my house right now. 00:01:52.470 --> 00:01:54.420 Dillon: And it's making it impossible to focus. 00:01:54.820 --> 00:01:57.960 Dillon: but I'm here and I'm going to be focused guys. 00:01:58.920 --> 00:02:00.700 Dillon: I'm also taking a few days off of work. 00:02:00.700 --> 00:02:01.720 Dillon: I just feel a little burned out. 00:02:02.020 --> 00:02:04.080 Dillon: We had like a big launch come up. 00:02:05.120 --> 00:02:06.840 Dillon: Some of you, if you know where I work, 00:02:07.080 --> 00:02:09.259 Dillon: you may have seen the outburst online. 00:02:09.800 --> 00:02:11.700 Dillon: So it's been fun watching that happen 00:02:12.120 --> 00:02:14.200 Dillon: and seeing how the company sort of adapts to that. 00:02:15.300 --> 00:02:16.560 Dillon: And then what else? 00:02:16.940 --> 00:02:19.660 Dillon: At work, I volunteered to be the guild lead of web, 00:02:20.780 --> 00:02:28.420 Dillon: which really means I get to help push larger initiatives for the web framework, I guess, 00:02:29.240 --> 00:02:30.120 Dillon: like the web teams. 00:02:30.900 --> 00:02:35.260 Dillon: But it's really like do all the work that no one wants to do is what it turns out to be. 00:02:35.860 --> 00:02:38.440 Dillon: It's really hard to get people interested in any of it. 00:02:40.239 --> 00:02:48.700 Dillon: So I'm hoping to get that put together in a way that can help push the web further at Woot. 00:02:48.720 --> 00:02:53.840 Dillon: So kind of excited, kind of like dreading it because I have a lot of other work to do. 00:02:54.280 --> 00:02:56.720 Dillon: Yeah, that's where I'm at right now. 00:02:57.260 --> 00:02:58.240 Dillon: What about you, Scott? 00:03:00.720 --> 00:03:00.940 Scott: All right. 00:03:00.990 --> 00:03:04.480 Scott: So this is the one segment that's easiest that I didn't prepare for at all. 00:03:05.540 --> 00:03:06.800 Scott: So a few things, a few things. 00:03:07.280 --> 00:03:10.100 Scott: Starting off, I just got back from Italy like a week and a half ago. 00:03:10.260 --> 00:03:15.560 Scott: This is like not, I mean, it's old news now, but we haven't recorded in a while. 00:03:16.140 --> 00:03:16.640 Scott: It was great. 00:03:16.720 --> 00:03:23.400 Scott: We went to Rome, got to help elect the new Pope while we were there, went to Florence. 00:03:23.610 --> 00:03:24.420 Matt: You contributed to that? 00:03:24.940 --> 00:03:26.640 Scott: Yeah, actually, I okayed it. 00:03:26.800 --> 00:03:29.180 Scott: I really pushed for the American Pope. 00:03:30.500 --> 00:03:31.880 Scott: Yeah, went to Florence after that. 00:03:32.090 --> 00:03:33.120 Scott: Florence was probably my favorite. 00:03:34.740 --> 00:03:35.440 Scott: Also went to Venice. 00:03:36.190 --> 00:03:41.800 Scott: It was really cool to see that infrastructure and architecture and just the fact that it's 00:03:41.870 --> 00:03:45.120 Scott: built on basically wooden stilts and concrete is unbelievable. 00:03:45.940 --> 00:03:51.400 Scott: Also went to Milan, like a small Italy's version of New York. 00:03:52.140 --> 00:03:53.100 Scott: Not as crazy at all. 00:03:53.470 --> 00:03:57.360 Scott: But then we went up to Lake Como, which is like borders Switzerland. 00:03:57.490 --> 00:03:59.000 Scott: And you can kind of see the Alps in the distance. 00:03:59.500 --> 00:04:00.300 Scott: Absolutely phenomenal. 00:04:01.180 --> 00:04:02.200 Scott: Best trip of my life. 00:04:02.840 --> 00:04:04.180 Scott: Maybe a little recency bias. 00:04:04.740 --> 00:04:06.760 Scott: Kenya was also unbelievably amazing. 00:04:07.480 --> 00:04:08.360 Scott: I'm back at work. 00:04:09.180 --> 00:04:11.660 Scott: I think the last time we recorded, I was really new. 00:04:11.960 --> 00:04:13.000 Scott: I'm still really new. 00:04:13.220 --> 00:04:18.160 Scott: I'm still technically in like a onboarding period for the company, 00:04:18.760 --> 00:04:19.440 Scott: but I basically, 00:04:20.160 --> 00:04:23.480 Scott: I got my first big project and I'm just rebuilding GitHub. 00:04:25.120 --> 00:04:25.620 Scott: Not really, 00:04:25.840 --> 00:04:26.020 Scott: honestly, 00:04:26.180 --> 00:04:28.000 Scott: but basically we have a 00:04:28.000 --> 00:04:28.520 Scott: situation 00:04:28.520 --> 00:04:31.760 Scott: where teams are building workflows 00:04:32.240 --> 00:04:34.800 Scott: visually and they, 00:04:35.480 --> 00:04:39.920 Scott: two people could be working on the same live version at once in isolation. 00:04:40.500 --> 00:04:43.240 Scott: And we never really solved concurrency for this project. 00:04:43.370 --> 00:04:51.060 Scott: So we need a way for teams to be able to visually see the changes that occurred when someone pushes to live. 00:04:51.880 --> 00:04:53.500 Scott: And how do they consume those changes? 00:04:54.580 --> 00:04:58.380 Scott: Not sure exactly what approach we're going to take, but that's as much as I'm going to talk about it, really. 00:04:59.200 --> 00:05:01.560 Scott: So really actually exciting problem to try to solve. 00:05:02.120 --> 00:05:05.300 Scott: And I've done a lot of digging into how we would merge things. 00:05:05.540 --> 00:05:10.320 Scott: But it sounds like our focus is really going to be on presenting a visual diff. 00:05:10.500 --> 00:05:17.340 Scott: not a visual code diff exclusively, but rather a like graphical diff in the UI, which is pretty, 00:05:17.590 --> 00:05:22.520 Scott: pretty freaking cool. So excited to execute on that, building some POCs on that right now. 00:05:23.240 --> 00:05:31.780 Scott: I also rebuilt some code that I open sourced about a few years ago with help from actually 00:05:32.100 --> 00:05:38.240 Scott: both of you guys. It was my like use keyboard navigation. We, we kind of like worked through 00:05:38.260 --> 00:05:46.140 Scott: workshop through this together and i rebuilt it using like use sync external store and just made 00:05:46.140 --> 00:05:55.200 Scott: it more modernized and i also added some use cases for it where um i was creating like a command k 00:05:55.400 --> 00:06:01.400 Scott: search palette and if you look at spotify's in the app i was using that as my reference uh you'll 00:06:01.520 --> 00:06:06.779 Scott: notice that when you cycle through items that like the focus is still on the input so it's like a uh 00:06:06.840 --> 00:06:13.540 Scott: what is that called like not an autocomplete but a combo box style um you can still be focused in 00:06:13.540 --> 00:06:20.080 Scott: the input and you can still cycle through all the options so you're not actually moving the focus 00:06:20.780 --> 00:06:26.040 Scott: so i'm working on adding that to the one i've created and hopefully reopen sourcing my project 00:06:26.600 --> 00:06:32.940 Scott: with these changes uh sometime in june if possible and that was a lot i said i didn't 00:06:32.800 --> 00:06:38.260 Scott: have anything prepared but i just fired stuff off at you i can spit verbal diarrhea boys matt what's 00:06:38.340 --> 00:06:38.680 Scott: up with you 00:06:38.680 --> 00:06:46.920 Matt: well first i'm curious if you uh uh if you're using like the command k library from uh 00:06:48.060 --> 00:06:54.100 Matt: paco and and company um that i think shadcn builds on top of it for their command menu 00:06:54.300 --> 00:06:54.920 Scott: no so the 00:06:54.920 --> 00:07:00.240 Scott: command k ballot stuff is actually something we identified well uh at work uh in the 00:07:00.080 --> 00:07:04.800 Scott: the UI, there are a lot of nodes and it's hard to navigate. So I've been working on navigation tools. 00:07:05.400 --> 00:07:11.700 Scott: So I started with a basic command K palette that I actually built a dialogue modal with. So I took 00:07:12.440 --> 00:07:16.720 Scott: my concept. I think I learned this from actually Adam Argyle, shout out Google, how to use the 00:07:16.830 --> 00:07:23.740 Scott: actual dialogue modal in React, or sorry, the HTML5 tag dialogue correctly in React. I basically 00:07:24.130 --> 00:07:28.440 Scott: bare bones built something like that. And for now, all you can do is search through modals, but 00:07:28.400 --> 00:07:33.080 Scott: I'm talking about doing some crazy stuff in here that hopefully you can use this command K palette 00:07:33.660 --> 00:07:40.500 Scott: as a way to ask AI to build your nodes in the future and a really ambitious thing, but 00:07:40.920 --> 00:07:47.560 Scott: something I wanted to consider for this project in the long term. But really this is, so my work, 00:07:48.560 --> 00:07:53.380 Scott: my project is part of a larger set of applications. So essentially I built a, 00:07:54.180 --> 00:08:01.780 Scott: what I'm calling a search palette, but just command K as a UI that can be consumed by multiple tool applications that I work with. 00:08:03.840 --> 00:08:04.080 Matt: Nice. 00:08:06.640 --> 00:08:06.800 Matt: Cool. 00:08:07.320 --> 00:08:07.940 Matt: Let's see, my update. 00:08:09.000 --> 00:08:14.460 Matt: Just like a sort of, I feel like I'm always like this at a normal standup where I just don't know what to say. 00:08:15.780 --> 00:08:16.060 Matt: Let's see. 00:08:16.080 --> 00:08:16.760 Matt: Yeah, it's been a while. 00:08:18.700 --> 00:08:21.940 Matt: At work, I've been working on like sort of rolling out this migration. 00:08:23.160 --> 00:08:29.360 Matt: We have this crazy, multi-variant way that we handle translations in our Webpack apps. 00:08:30.320 --> 00:08:34.240 Matt: We literally have a field in our Webpack that's like useModernLyaml and it can be the value 00:08:34.280 --> 00:08:38.719 Matt: of false or undefined true the string modern or the string postmodern. 00:08:40.020 --> 00:08:44.159 Matt: And so we're trying to migrate everyone to the string of postmodern variant, which changes 00:08:44.300 --> 00:08:48.240 Matt: like how the translations are loaded and generated during build times. 00:08:49.660 --> 00:08:51.000 Matt: So that's been a fun migration to work through. 00:08:53.140 --> 00:08:56.120 Matt: Outside of work, I think in between episodes, 00:08:56.290 --> 00:08:59.960 Matt: I sort of re-built, rewrote my website. 00:09:01.180 --> 00:09:03.500 Matt: Before I was using Next.js, now it's using Waku, 00:09:04.380 --> 00:09:07.100 Matt: which is pretty exciting, although it was really slow. 00:09:07.480 --> 00:09:10.200 Matt: I had a lot of delayed cold starts 00:09:10.640 --> 00:09:11.780 Matt: when I deployed on Cloudflare. 00:09:13.140 --> 00:09:16.639 Matt: So yeah, I've been trying to dig into why that's happening 00:09:16.660 --> 00:09:18.680 Matt: and found like a few bugs in the library along the way. 00:09:20.040 --> 00:09:22.020 Matt: Also, I think since we last recorded, 00:09:23.140 --> 00:09:24.500 Matt: I got my new keyboard. 00:09:25.080 --> 00:09:25.860 Matt: I can show you guys. 00:09:26.920 --> 00:09:27.280 Matt: There we go. 00:09:27.880 --> 00:09:29.100 Matt: People listening won't see, 00:09:29.360 --> 00:09:34.340 Matt: but it's the Nuphy Air V2 75, I think. 00:09:35.780 --> 00:09:37.520 Matt: And of course, like a week after I got my keyboard, 00:09:37.820 --> 00:09:40.200 Matt: they announced that they have the V3 model coming out. 00:09:40.460 --> 00:09:41.720 Matt: So we'll have to see. 00:09:41.900 --> 00:09:44.740 Matt: I think it's like, it'll probably be better obviously, 00:09:45.020 --> 00:09:48.300 Matt: But I think it'll be slimmer, which I'm excited for. 00:09:48.800 --> 00:09:50.120 Matt: So I might have to make that upgrade also. 00:09:51.540 --> 00:09:55.020 Dillon: Can you still return it in the return window? 00:09:55.980 --> 00:09:56.840 Matt: That's a good question. 00:09:57.560 --> 00:09:58.360 Matt: Yeah, that's a good question. 00:09:58.520 --> 00:09:59.440 Matt: Maybe I should look at that. 00:10:00.580 --> 00:10:02.760 Matt: I signed up for their pre-order notifications. 00:10:03.180 --> 00:10:04.900 Matt: So we'll see what happens. 00:10:06.060 --> 00:10:08.360 Matt: I think I get a discount because I bought this one also. 00:10:09.060 --> 00:10:13.860 Matt: But yeah, I wonder if I can just return this and get the discount. 00:10:17.400 --> 00:10:17.480 Matt: yeah 00:10:18.470 --> 00:10:19.780 Matt: I think that's about it for my update 00:10:20.779 --> 00:10:22.600 Scott: Dillon you didn't talk about your keyboard 00:10:22.830 --> 00:10:23.940 Scott: you got a Nuphy right 00:10:24.480 --> 00:10:26.760 Scott: I got two keyboards here I can hold them up too 00:10:26.900 --> 00:10:28.920 Scott: you guys can't see them maybe we'll take pictures 00:10:29.170 --> 00:10:30.880 Scott: for the website 00:10:31.260 --> 00:10:32.680 Scott: Matt what do you think about that 00:10:34.200 --> 00:10:35.000 Matt: oh it looks like 00:10:35.000 --> 00:10:35.220 Matt: trash 00:10:36.220 --> 00:10:37.240 Scott: that's straight up rude 00:10:37.620 --> 00:10:39.080 Dillon: I bet you Scott's keyboards 00:10:39.400 --> 00:10:40.960 Dillon: Scott's keyboards probably cost like 00:10:41.070 --> 00:10:42.259 Dillon: three times our keyboards 00:10:43.080 --> 00:10:45.940 Scott: my keyboards are worth more than matt's life and 00:10:45.940 --> 00:10:47.720 Scott: he's over here nuking 00:10:47.720 --> 00:10:47.820 Scott: them 00:10:49.660 --> 00:10:54.120 Dillon: scott's keyboard he's like holding up gold bars compared to what we have 00:10:55.700 --> 00:10:56.400 Scott: this is uh 00:10:56.400 --> 00:10:57.660 Scott: wayfair stock put 00:10:57.660 --> 00:10:58.720 Scott: to use right here boys 00:11:04.680 --> 00:11:08.939 Matt: yeah Dillon how have you uh have you been enjoying your keyboard you i mean you've used 00:11:09.000 --> 00:11:12.080 Matt: mechanical keyboards in the past right like you've had yeah i 00:11:12.080 --> 00:11:14.320 Dillon: use them usually when i'm like gaming 00:11:15.060 --> 00:11:15.240 Dillon: not 00:11:15.240 --> 00:11:16.020 Dillon: usually when i'm working 00:11:16.020 --> 00:11:22.920 Dillon: i got so used to using the laptop keyboard and then i don't know 00:11:23.240 --> 00:11:28.700 Dillon: i've just gotten sort of tired over tired of it over time and everyone at my job has a mechanical 00:11:28.900 --> 00:11:34.640 Dillon: it's like i'll just join the club and i've been really really happy with it like i love i love the 00:11:34.560 --> 00:11:38.820 Dillon: the feel of it it's been much more enjoyable 00:11:34.560 --> 00:11:38.820 Scott: honestly 00:11:38.820 --> 00:11:40.460 Scott: i used to be fine with just using the 00:11:40.530 --> 00:11:44.960 Scott: laptop keyboard too but until i had like covid work from home where i have the world's biggest 00:11:45.320 --> 00:11:51.200 Scott: monitor um situation basically i i just more comfortable with having the keyboard but like 00:11:51.820 --> 00:11:57.119 Scott: i'm able to kind of switch back and forth like if i'm going to do a job remote uh or go to like 00:11:57.639 --> 00:12:05.300 Scott: california for a job or something which seems to be where i go um i can deal with using the laptop 00:12:05.540 --> 00:12:11.720 Scott: keyboard i usually just bring a keyboard at this point but i kind of like the challenge of using 00:12:11.880 --> 00:12:14.880 Scott: different keyboards sometimes maybe i'm a masochist 00:12:14.880 --> 00:12:19.100 Matt: yeah i've been for the longest time i was a uh 00:12:19.300 --> 00:12:25.680 Matt: hardcore mac like a laptop keyboard user so like even if i had an extra monitor i would still have 00:12:25.680 --> 00:12:30.660 Matt: my laptop in front of me and using that keyboard i still prefer it i think but yeah this Nuphy's 00:12:30.660 --> 00:12:35.880 Matt: been growing on me um not too bad that's my review not too bad 00:12:35.880 --> 00:12:40.080 Dillon: you were complaining that 00:12:40.300 --> 00:12:45.180 Dillon: the battery of life is like not great right yeah 00:12:45.180 --> 00:12:47.140 Matt: i mean yeah i mean like i have it plugged in right 00:12:47.140 --> 00:12:51.760 Matt: now too because i swear i charged this like three days ago and then this morning it's like oh it's 00:12:51.780 --> 00:12:53.640 Matt: like 15%. 00:12:53.820 --> 00:12:55.020 Dillon: You just got a tight mask. 00:12:57.800 --> 00:12:58.200 Matt: Yeah, maybe. 00:12:58.330 --> 00:13:00.100 Matt: I think maybe sometimes 00:13:00.250 --> 00:13:01.600 Matt: I'll get away from my laptop for 00:13:02.290 --> 00:13:04.260 Matt: maybe an hour or something and I forget to turn it off 00:13:04.360 --> 00:13:05.580 Matt: and so it's just sitting there on. 00:13:06.320 --> 00:13:08.300 Matt: But yeah, I feel like the keyboard battery 00:13:08.390 --> 00:13:10.320 Matt: should last a little bit longer. Hopefully the new 00:13:10.460 --> 00:13:12.200 Matt: version's a little bit larger battery 00:13:12.460 --> 00:13:13.620 Matt: but we'll see. 00:13:15.580 --> 00:13:15.780 Dillon: Cool. 00:13:16.320 --> 00:13:18.320 Dillon: I just keep mine plugged in. No issues here. 00:13:19.760 --> 00:13:20.480 Scott: You know what? I was just 00:13:20.480 --> 00:13:26.420 Scott: thinking we need like a spicy take police or a hot take police siren that we play when any of us 00:13:26.560 --> 00:13:28.620 Scott: have a hot take why don't we have that 00:13:28.620 --> 00:13:31.000 Dillon: and then we don't need the segment well 00:13:31.000 --> 00:13:31.740 Scott: no we'll keep the 00:13:31.910 --> 00:13:36.960 Scott: segment i was thinking like a legitimate police siren you're getting arrested for this take it's 00:13:36.960 --> 00:13:44.360 Scott: so hot maybe maybe an ice siren okay that's enough matt introduce our topic 00:13:36.960 --> 00:13:44.360 Matt: yeah 00:13:44.360 --> 00:13:45.020 Matt: let's get into a 00:13:45.020 --> 00:13:49.599 Matt: main topic so uh i think for people that have been doing software development over the past 00:13:49.620 --> 00:13:52.240 Matt: maybe within the past five years or longer for sure, 00:13:52.500 --> 00:13:56.300 Matt: but has certainly come to face the concept of monorepo. 00:13:56.360 --> 00:13:59.600 Matt: So the concept of monorepo is just like you have like a single repo 00:13:59.780 --> 00:14:02.440 Matt: of multiple different projects or packages or workspaces 00:14:03.020 --> 00:14:05.260 Matt: usually that contribute to like the same end result. 00:14:06.540 --> 00:14:09.060 Matt: They're fairly popular at very large companies. 00:14:09.320 --> 00:14:12.700 Matt: So like Google is probably famously known for having a very large monorepo 00:14:12.880 --> 00:14:15.020 Matt: where like everything basically lives in the same monorepo. 00:14:15.540 --> 00:14:17.920 Matt: I think Facebook or Meta is like in the same bucket. 00:14:18.760 --> 00:14:27.140 Matt: But I think over the past maybe five years or so, they've really started to catch on at almost every other company of maybe of any size. 00:14:28.920 --> 00:14:32.440 Matt: Yeah, there's been a lot of tooling that's come around for it. 00:14:34.040 --> 00:14:36.180 Matt: And we can probably dig into some of those tools. 00:14:37.200 --> 00:14:43.259 Matt: But yeah, I'm just curious from your guys' take, working in a monorepo versus working across multiple distributed repos. 00:14:44.600 --> 00:14:47.480 Matt: I'm curious if you guys have any early takes on, like, 00:14:48.700 --> 00:14:50.580 Matt: have you enjoyed working with monorepos? 00:14:51.120 --> 00:14:51.700 Matt: Do you hate them? 00:14:53.220 --> 00:14:54.660 Matt: Are you ambivalent to them? 00:14:56.000 --> 00:14:56.560 Dillon: I'll jump in. 00:14:56.900 --> 00:15:00.780 Dillon: I've had exposure to monorepos in two places, or maybe three. 00:15:02.080 --> 00:15:04.680 Dillon: I feel like when we were at Wayfair, we had the home... 00:15:04.720 --> 00:15:07.440 Dillon: I had our design system, which basically had its own, 00:15:08.520 --> 00:15:09.880 Dillon: I guess, sort of monorepo. 00:15:11.060 --> 00:15:13.220 Dillon: I can't even think back that far at this point. 00:15:13.280 --> 00:15:22.520 Dillon: But I will say more recently, we have a monorepo, which is like all of our more recent next apps are in there. 00:15:22.610 --> 00:15:35.380 Dillon: And then all of the like internationalization packages and authorization packages that we have that are shared across those apps are like seated within their own like packages folder, which is like a sibling folder to the apps folder. 00:15:36.380 --> 00:15:42.460 Dillon: And that's kind of I don't like have a ton of strong opinions about how that works. 00:15:43.160 --> 00:15:45.680 Dillon: I think I get a little bit more confused on like. 00:15:47.359 --> 00:15:51.040 Dillon: How how you should decide when you need a monorepo and like 00:15:51.720 --> 00:15:53.540 Dillon: when you should decide you need a shared package. 00:15:55.300 --> 00:15:58.040 Dillon: I think those sorts of things get a little bit dicey. 00:15:58.540 --> 00:16:01.200 Dillon: And like when when does it make sense that like you need a separate repo 00:16:01.440 --> 00:16:02.560 Dillon: and that needs to be its own monorepo. 00:16:03.580 --> 00:16:06.860 Dillon: So maybe like getting into further questions we can get into later. 00:16:07.000 --> 00:16:08.560 Dillon: But yeah, that's where I'm at. 00:16:09.560 --> 00:16:09.960 Scott: That's awesome. 00:16:10.920 --> 00:16:11.540 Scott: It's a good question. 00:16:11.660 --> 00:16:18.320 Scott: like so i'm assuming like if you don't do a mono repo you're talking about having like all uh i 00:16:18.440 --> 00:16:25.360 Scott: guess would that be a poly repo or just like every uh service or tooling or application just has its 00:16:25.520 --> 00:16:32.180 Scott: own standalone repo i don't know if it needs to be that um isolated however i think like the reason 00:16:32.480 --> 00:16:39.740 Scott: just to the wayfair example is like why we we went so heavily on um a monorepo is like if we if we 00:16:39.580 --> 00:16:46.400 Scott: take a step back. We used to have rapid development with our monolithic app, which I guess is very 00:16:46.490 --> 00:16:52.140 Scott: different than a monorepo because that's every single app living in one space. I think technically 00:16:52.440 --> 00:16:56.600 Scott: it's usually like front end and back end lives in the same space, but we didn't do that. But we had 00:16:56.740 --> 00:17:03.600 Scott: every single app living in one space. So it might not have been a true monolithic app, but whatever, 00:17:03.800 --> 00:17:10.300 Scott: was close enough. So let's just say the monorepo structure came from, we're not moving fast enough, 00:17:10.480 --> 00:17:15.459 Scott: everything is so far distributed. And I think there was a school of thought there that 00:17:16.319 --> 00:17:22.180 Scott: folks were used to reaching across the aisle by being in one repo and seeing all of the work 00:17:22.319 --> 00:17:30.839 Scott: that's available. And we're then more likely to make changes across spaces. So creating a more 00:17:30.860 --> 00:17:36.980 Scott: collaborative environment of and making it more easily easy and discoverable on how you make 00:17:38.000 --> 00:17:42.320 Scott: changes so i think there was necessarily more of like a culture thing going on here that when we 00:17:42.610 --> 00:17:49.440 Scott: moved towards a microsoft uh microservice architecture and we decided like everything 00:17:49.470 --> 00:17:57.759 Scott: would just have its own repo maybe almost to a fault there is some sort of maybe fine line or or 00:17:57.780 --> 00:18:02.880 Scott: you need to create some sort of set of rules as to how many or like when you make this decision. 00:18:03.880 --> 00:18:08.300 Scott: But as things kind of stretch out into multiple repos, you can create this 00:18:09.600 --> 00:18:15.860 Scott: knowledge gap or make it easier to introduce knowledge gaps. And I think it has a lot of 00:18:16.060 --> 00:18:21.680 Scott: factors that it depends on. So I didn't want to just say it depends, but it's more of like, 00:18:22.220 --> 00:18:25.359 Scott: how big is the company? How many people are contributing to the thing that 00:18:25.380 --> 00:18:29.260 Scott: that you're trying to create a repo for, 00:18:30.040 --> 00:18:31.740 Scott: how fast do you need to deploy things, 00:18:32.340 --> 00:18:33.380 Scott: what's more important, 00:18:33.900 --> 00:18:35.680 Scott: rapidly deploying new features for you, 00:18:36.160 --> 00:18:38.200 Scott: or stability. 00:18:38.760 --> 00:18:41.060 Scott: This gets into something I was talking about 00:18:41.110 --> 00:18:42.340 Scott: in our Discord group. 00:18:44.440 --> 00:18:46.060 Scott: Deployment for us is really long, 00:18:46.970 --> 00:18:48.800 Scott: whereas at Wayfair, as an example, 00:18:49.080 --> 00:18:50.700 Scott: it's like how fast can you get something out? 00:18:51.660 --> 00:18:53.740 Scott: And I think there are different schools of thought 00:18:53.750 --> 00:18:54.480 Scott: on that as well. 00:18:54.900 --> 00:19:04.700 Scott: But it's really my general point here in this rant that I will end is it matters a lot to how the culture and what your expectations are. 00:19:05.380 --> 00:19:09.800 Scott: But also, like, what are you proposing to benefit and gain from? 00:19:09.910 --> 00:19:14.140 Scott: Do you expect multiple teams to work across problem spaces? 00:19:14.830 --> 00:19:20.220 Scott: Or can you just isolate and silo things off more into their own repos? 00:19:20.620 --> 00:19:24.640 Scott: or do you have like a really good structure for people to get introduced to a new repo and 00:19:24.880 --> 00:19:30.520 Scott: documentation and whatnot i mean ai is a great way to solve documentation but um what what is your 00:19:31.140 --> 00:19:37.140 Scott: path i guess i want to say is my last point like occam's razor like what is the simplest 00:19:38.360 --> 00:19:43.660 Scott: explanation and or solution in this case for what you're trying to do based on your needs 00:19:44.780 --> 00:19:47.079 Scott: and that's all my thoughts on mono repos we're done 00:19:50.580 --> 00:19:51.800 Matt: all right we're gonna end the podcast there 00:19:53.860 --> 00:19:59.520 Matt: I think um you kind of brought up some uh interesting thoughts there Scott and Dillon 00:19:59.840 --> 00:20:05.340 Matt: also I think maybe it's worth I just because we have like maybe the most shared experience of 00:20:05.440 --> 00:20:08.780 Matt: Wayfarer's like code base and setup maybe it's worth us talking a little bit about that because 00:20:08.820 --> 00:20:13.839 Matt: I think that was an interesting journey Scott you kind of covered it right we when I joined Wayfarer 00:20:13.940 --> 00:20:21.200 Matt: at least, you know, we had effectively two large monorepos, or not even monorepos, two large repos, 00:20:21.400 --> 00:20:25.540 Matt: right? Like there was no concept of separate workspaces or packages internally. There wasn't 00:20:25.620 --> 00:20:29.920 Matt: really a concept of like, this code only serves this specific use case. It was like basically 00:20:30.100 --> 00:20:31.460 Matt: just a jumble of code. 00:20:32.440 --> 00:20:35.900 Scott: Well, just that they technically were monorepos, but we always called 00:20:35.900 --> 00:20:40.559 Scott: them monoliths. Like in theory, a monolith would be the backend, frontend, and everything is coupled 00:20:40.580 --> 00:20:46.780 Scott: together but it at least had that deviation so sorry go go ahead oh 00:20:46.780 --> 00:20:47.820 Matt: yeah i mean i think 00:20:48.780 --> 00:20:52.220 Matt: yeah i don't know like in my mind yeah maybe that's something we should get to first is like 00:20:52.400 --> 00:20:55.760 Matt: how do you define a monorepo i think in my mind that like a monorepo is usually 00:20:56.560 --> 00:21:00.900 Matt: it's like a large it's like a single repo with a large collection of code but that code is 00:21:02.040 --> 00:21:07.220 Matt: um you know structured in a way that it's uh you know put together at pieces and it's not 00:21:07.180 --> 00:21:08.740 Matt: necessarily just a big jumble of mess, right? 00:21:08.900 --> 00:21:12.140 Matt: Like you could take a large code base that just has, you know, for example, 00:21:12.260 --> 00:21:12.880 Matt: if we're working on the front end, 00:21:12.920 --> 00:21:15.960 Matt: like maybe only has a single package JSON and like manages all its 00:21:16.080 --> 00:21:19.220 Matt: dependencies there. And like, there's no, you know, 00:21:19.320 --> 00:21:23.220 Matt: you could reach from deep folder A to deep folder Z and like share code that 00:21:23.320 --> 00:21:25.860 Matt: way. It's like that, that, that necessarily, you know, 00:21:26.020 --> 00:21:29.260 Matt: at least in my definition wouldn't actually like meet the criteria of a 00:21:29.300 --> 00:21:30.180 Matt: monorepo in my mind, a 00:21:30.180 --> 00:21:31.280 Matt: monorepo is like more 00:21:31.280 --> 00:21:33.000 Matt: structured of individual 00:21:33.200 --> 00:21:34.340 Matt: packages. Yeah. Yeah. 00:21:34.420 --> 00:21:39.420 Matt: multiple individual packages that can be, you know, you can sort of depend on each other, but 00:21:40.000 --> 00:21:45.140 Matt: they're relatively isolated and sort of in their own space, I guess, within the repo. 00:21:46.130 --> 00:21:50.400 Matt: So yeah, like Wayfair, when I joined, is like effectively two large repos that didn't have 00:21:50.510 --> 00:21:56.860 Matt: that concept of workspaces or packages. It was just like code being shared. Our PHP side was maybe 00:21:56.860 --> 00:22:01.319 Matt: a little bit more structured that way. Like we had sort of separate deployables and the code 00:22:02.060 --> 00:22:07.480 Matt: It was kind of within those deployables inside the repo, but our resources side was a little bit more jumbled up. 00:22:10.399 --> 00:22:15.320 Matt: And so what we did is we went through this phase at Wayfair where we started what we call decoupling, 00:22:15.420 --> 00:22:19.860 Matt: where we just said, okay, these big, huge repos are not helping us move fast enough, 00:22:19.980 --> 00:22:24.420 Matt: so applications could split out to their own repo, deploy independently, and whatnot. 00:22:24.540 --> 00:22:28.400 Matt: And then we ended up in a state where we had thousands of repos for individual applications and pages, 00:22:28.700 --> 00:22:31.200 Matt: and it was just hard to maintain consistency across them. 00:22:31.380 --> 00:22:41.100 Matt: And so then we, at least on the storefront side of things, opted for a monorepo to manage sort of a more consistent baseline across our storefront experiences. 00:22:42.120 --> 00:22:46.220 Matt: So that was like a five second TLDR of like the journey of repos at Wayfair. 00:22:47.710 --> 00:22:49.880 Matt: But I think it's a, yeah, I don't know, like. 00:22:51.340 --> 00:22:55.800 Matt: As I was like thinking about it, as you guys were talking, it's like there's multiple different ways for us to adopt monorepos. 00:22:55.900 --> 00:23:00.400 Matt: like the way that Wayfair adopted a monorepo doesn't necessarily mean it's the same way that 00:23:01.080 --> 00:23:06.660 Matt: you know I don't know Airbnb might adopt monorepo or Whoop or HubSpot or whatnot like I think there's 00:23:06.800 --> 00:23:11.180 Matt: multiple different strategies kind of like what Dillon was saying like homebase had a monorepo 00:23:11.780 --> 00:23:17.200 Matt: for a while while we were doing that decoupling effort but it was decoupled from the rest of the 00:23:17.280 --> 00:23:22.299 Matt: code base also so you could still have a strategy where you have like multiple different monorepos 00:23:22.880 --> 00:23:25.560 Matt: that still sort of contribute to the same sort of state of things. 00:23:27.680 --> 00:23:29.960 Matt: I think we tried to do monorepos at a time 00:23:29.970 --> 00:23:32.060 Matt: where the tooling was just not that great 00:23:32.500 --> 00:23:33.860 Matt: for at least Homebase's use case. 00:23:34.640 --> 00:23:36.720 Matt: I think back then it was like Lerna was the state-of-the-art 00:23:36.860 --> 00:23:40.200 Matt: for managing workspaces and we're using Yarn Classic. 00:23:40.450 --> 00:23:46.480 Matt: And yeah, a lot of things sort of jumbled together to make it work. 00:23:49.120 --> 00:23:51.540 Matt: Nowadays, we have better tooling for monorepos. 00:23:51.740 --> 00:23:51.880 Matt: I think 00:23:51.880 --> 00:23:53.580 Matt: probably because more and more companies realized 00:23:53.860 --> 00:23:55.800 Matt: that they could probably get benefit 00:23:56.080 --> 00:23:58.400 Matt: out of sharing code in the same repo. 00:24:00.040 --> 00:24:01.460 Matt: And so we have tools like Turborepo 00:24:01.740 --> 00:24:05.320 Matt: and a variety of other tools that have sort of built up 00:24:05.640 --> 00:24:08.860 Matt: support for monorepos to be better than where they were. 00:24:08.940 --> 00:24:10.840 Matt: So like PMPM is a classic example of like, 00:24:11.660 --> 00:24:14.640 Matt: it's like really helped support the concept of monorepos 00:24:14.880 --> 00:24:16.480 Matt: with their like catalog features and workspaces 00:24:16.800 --> 00:24:18.040 Matt: and things like that. 00:24:18.940 --> 00:24:20.919 Dillon: - Basically, I think that one of the reasons 00:24:20.940 --> 00:24:25.240 Dillon: don't have really strong opinions with monorepos right now is I'm at a company which is like I 00:24:25.240 --> 00:24:32.600 Dillon: would say mid startup stage where we don't have the resources for like a team that just focuses on 00:24:32.860 --> 00:24:38.960 Dillon: like the infrastructure of our code in a sense I feel like at larger companies I've worked at 00:24:39.520 --> 00:24:43.500 Dillon: there's there's like usually a dedicated team that's thinking about that and thinking about 00:24:43.540 --> 00:24:48.720 Dillon: how we can like make sure our code is being shared properly and it and when you're at a 00:24:48.560 --> 00:24:53.300 Dillon: smaller company it just comes down to like someone having that interest and putting in this extra 00:24:53.480 --> 00:24:59.440 Dillon: effort that's like outside the work that you're typically doing so it's like it's hard for me in 00:24:59.440 --> 00:25:05.280 Dillon: my current work right now where I'm like so feature focused on building features that like 00:25:05.540 --> 00:25:11.820 Dillon: as long as I can ship the code I just don't really care about the surrounding pieces not to say that 00:25:11.900 --> 00:25:18.520 Dillon: like monorepos doesn't matter but it's definitely helping me because I'm we have it but like I 00:25:18.540 --> 00:25:24.960 Dillon: I haven't had much of a chance in my current role to reflect on whether or not what we're using is even good. 00:25:26.180 --> 00:25:31.880 Scott: Yeah, I still think it's really important to be constantly looking at the shape and needs of your company. 00:25:32.010 --> 00:25:36.700 Scott: Like you're saying, having a team that's constantly thinking about these things is very important. 00:25:38.399 --> 00:25:45.680 Scott: But I feel like whatever solution you pick, once it becomes mature, you usually start to see the faults. 00:25:46.530 --> 00:25:47.880 Scott: And that might take some time. 00:25:48.680 --> 00:25:53.320 Scott: and this like whole thing can be a vicious cycle like kind of a grass is always greener problem 00:25:53.920 --> 00:26:01.760 Scott: that occurs where you know if you have a monorepo and one of the faults is being like how do we keep 00:26:01.880 --> 00:26:06.920 Scott: pipelines super fast we have all this tooling it starts to get slow and then it's like oh should we 00:26:07.020 --> 00:26:13.820 Scott: just have multiple monorepos should we have just repos per project things will be faster that way 00:26:14.100 --> 00:26:22.360 Scott: But then if one of your needs is like, no, we need people to be more collaborative and be able to discover things, like how do you balance those two things? 00:26:22.860 --> 00:26:31.680 Scott: And just understanding the shape of your teams and your makeup and how they work has a lot to do with like what path we're going to choose here. 00:26:34.200 --> 00:26:43.120 Matt: Yeah, I think, you know, kind of reaching back into history a little bit, like I think that's 100% the tradeoff that Wayfair made when we opted to go down the road on monorepos. 00:26:43.140 --> 00:26:46.980 Matt: is like we, at the time, we wanted to value consistency 00:26:47.420 --> 00:26:49.640 Matt: and sort of a baseline standards 00:26:50.020 --> 00:26:51.600 Matt: across our storefront experiences 00:26:52.000 --> 00:26:53.720 Matt: that were in multiple to separate repos. 00:26:53.720 --> 00:26:54.740 Matt: And it was very difficult for us 00:26:54.740 --> 00:26:56.800 Matt: to maintain that consistency across those repos. 00:26:57.320 --> 00:26:58.860 Matt: And so we opted for a monorepo to solve that. 00:26:59.520 --> 00:27:01.100 Matt: And we sort of traded off at the time, 00:27:01.880 --> 00:27:03.000 Matt: you know, whether or not we knew it, 00:27:03.820 --> 00:27:05.600 Matt: the like the pain points that come 00:27:05.700 --> 00:27:07.020 Matt: with managing code in a single repo, right? 00:27:07.140 --> 00:27:10.420 Matt: Like the fact that you have 100 plus contributors 00:27:10.780 --> 00:27:13.100 Matt: all pushing changes to the same repo 00:27:13.120 --> 00:27:15.480 Matt: and managing pipelines and managing merge conflicts 00:27:15.760 --> 00:27:18.580 Matt: and deployments from there is like, that's a pain, right? 00:27:18.740 --> 00:27:20.240 Matt: And so we sort of traded that off and said, 00:27:20.840 --> 00:27:22.260 Matt: we'll just put our effort into solving that problem 00:27:22.420 --> 00:27:24.980 Matt: versus solving the like, how do you have consistency 00:27:25.220 --> 00:27:26.500 Matt: across a distributed architecture? 00:27:28.400 --> 00:27:29.920 Matt: And yeah, I think it's interesting. 00:27:29.980 --> 00:27:30.980 Matt: It's like we-- 00:27:31.040 --> 00:27:34.240 Matt: I think there was some early on discussion of like, 00:27:34.900 --> 00:27:36.060 Matt: we just build-- 00:27:36.320 --> 00:27:38.380 Matt: instead of doing that trade off, try 00:27:38.380 --> 00:27:42.020 Matt: to build the tooling to make a distributed architecture work 00:27:42.060 --> 00:27:44.280 Matt: or, you know, distributed repo architecture work. 00:27:45.780 --> 00:27:47.540 Matt: And, you know, at the time it just seemed like, all right, 00:27:47.660 --> 00:27:50.380 Matt: let's just use open source schools to help, you know, manage monorepos. 00:27:50.580 --> 00:27:53.640 Matt: And it's like, I think those did most of the work, 00:27:53.880 --> 00:27:56.740 Matt: but didn't solve like the 100% use case that we needed. 00:27:56.860 --> 00:27:59.460 Matt: And so it was like still a complex problem to solve, 00:28:00.320 --> 00:28:03.800 Matt: like ensuring that you have, you know, fast iteration velocity 00:28:04.140 --> 00:28:08.140 Matt: and also consistency and safety across the board is, 00:28:08.440 --> 00:28:11.680 Matt: I think it's just like a, you know, it's like pick two sort of thing. 00:28:12.140 --> 00:28:16.320 Matt: of like consistency, speed, and yeah, I don't know. 00:28:17.240 --> 00:28:18.940 Matt: Or pick one maybe out of those two. 00:28:19.380 --> 00:28:21.300 Matt: Can't think of the third pillar there. 00:28:21.570 --> 00:28:22.120 Scott: I agree with that. 00:28:22.130 --> 00:28:23.920 Scott: But I also think that like consistency itself 00:28:25.590 --> 00:28:26.180 Scott: can be difficult. 00:28:26.390 --> 00:28:28.800 Scott: Like you can get consistency in some senses of it. 00:28:28.940 --> 00:28:31.920 Scott: Like we're all using the same shared like template 00:28:32.300 --> 00:28:34.820 Scott: or layout, but like teams are going to deviate. 00:28:35.100 --> 00:28:35.660 Scott: They always do. 00:28:35.760 --> 00:28:37.620 Scott: Like one of the biggest things we were picked 00:28:37.880 --> 00:28:40.240 Scott: monorepos for are consistency. 00:28:40.680 --> 00:28:44.360 Scott: but there's when, when like using homebase, 00:28:44.480 --> 00:28:46.600 Scott: using the design system as like an example, 00:28:47.500 --> 00:28:48.880 Scott: our, if a team was like, 00:28:48.880 --> 00:28:50.420 Scott: we want the component to do this, 00:28:50.460 --> 00:28:52.320 Scott: it was always, oh, create your own version of it. 00:28:52.740 --> 00:28:54.060 Scott: And when that becomes like a norm 00:28:54.800 --> 00:28:56.000 Scott: and we have this mono repo 00:28:56.260 --> 00:28:58.480 Scott: and people are like kind of recreating something 00:28:58.700 --> 00:28:59.480 Scott: with one little difference, 00:29:00.440 --> 00:29:02.200 Scott: you're still going to lose some of that consistency. 00:29:02.400 --> 00:29:03.860 Scott: So there are trade-offs with that one too, 00:29:04.220 --> 00:29:05.800 Scott: but I do agree with like your overall premise 00:29:05.980 --> 00:29:06.660 Scott: is absolutely correct. 00:29:06.900 --> 00:29:09.180 Scott: Like we're going to get more consistency for sure. 00:29:09.400 --> 00:29:14.340 Scott: And we're going to hopefully get speed or like awareness or discoverability. 00:29:14.940 --> 00:29:19.760 Scott: But like getting all of it at 100% is really tough. 00:29:19.920 --> 00:29:24.680 Scott: It's like that classic 80-20 where it's like, yeah, we might get 80% more of it. 00:29:25.040 --> 00:29:27.380 Scott: But getting that last 20 is next to impossible. 00:29:28.120 --> 00:29:33.660 Scott: And that concept creeps all the time because like just moving to that monorepo, 00:29:33.820 --> 00:29:38.700 Scott: we still have that classic 80-20 of two different large infrastructure changes. 00:29:39.040 --> 00:29:47.320 Scott: So sometimes like it's very complex to weigh how to all those things kind of work together. 00:29:47.640 --> 00:29:52.460 Scott: And do we still get the results we're looking for or enough of the results we're looking for? 00:29:53.420 --> 00:29:59.680 Matt: Yeah, I have like maybe a tangential thought, but I don't know, Dillon, if you wanted to talk a little bit about that sort of speed. 00:30:00.260 --> 00:30:06.640 Dillon: I sort of thought about it while Scott was talking is whether or not like Monorepos slow you down or speed you up. 00:30:07.120 --> 00:30:14.880 Dillon: And I think if you have good tooling and you're using the tooling exactly the way it's in the documentation, 00:30:15.630 --> 00:30:17.100 Dillon: for the most part, it's going to speed you up. 00:30:17.710 --> 00:30:19.960 Dillon: But I've seen cases where it will slow you down. 00:30:20.150 --> 00:30:26.080 Dillon: And that can come down to how your continuous integration is set up. 00:30:26.820 --> 00:30:28.100 Dillon: It's the first thing that comes to mind. 00:30:29.740 --> 00:30:35.700 Dillon: And maybe you guys have seen situations where you make a change to one package and then everything depends on it. 00:30:35.840 --> 00:30:38.820 Dillon: So then you end up having to like rebuild and redeploy everything. 00:30:39.000 --> 00:30:41.720 Dillon: And next thing you know, like your builds taking 30, 45 minutes, 00:30:42.740 --> 00:30:44.720 Dillon: maybe not, hopefully not that long, but it's possible. 00:30:45.820 --> 00:30:49.100 Dillon: And it just starts to feel like, why am I redeploying this other app 00:30:49.180 --> 00:30:51.420 Dillon: that I just didn't care about or touch? 00:30:53.140 --> 00:30:55.460 Dillon: So yeah, I'm just wondering, like, how do you guys feel about that? 00:30:56.540 --> 00:30:57.540 Dillon: And like, how are you? 00:30:57.930 --> 00:31:00.680 Dillon: Are there like ways that you're solving it that 00:31:01.640 --> 00:31:05.120 Dillon: like maybe it's like only redeploy the things 00:31:05.560 --> 00:31:07.740 Dillon: that I'm trying to make changes for? 00:31:08.230 --> 00:31:11.660 Dillon: In some sense, is there some better way to do that 00:31:12.420 --> 00:31:13.720 Dillon: that I just don't know about? 00:31:14.420 --> 00:31:17.700 Matt: Yeah, I mean, I haven't found a solution to that problem. 00:31:17.790 --> 00:31:20.600 Matt: I think it's like a part of me thinks that 00:31:21.580 --> 00:31:23.660 Matt: one of the core contributors to that pain point 00:31:23.860 --> 00:31:26.540 Matt: is that so many developers are sort of brought up 00:31:26.540 --> 00:31:29.540 Matt: on the don't repeat yourself sort of concept. 00:31:29.750 --> 00:31:32.980 Matt: And so you end up creating a library that solves a need 00:31:33.470 --> 00:31:34.620 Matt: and then someone else sees like, 00:31:34.760 --> 00:31:35.740 Matt: all right, I need 90% of that. 00:31:35.900 --> 00:31:38.220 Matt: And so they go to abstract that shared library 00:31:38.600 --> 00:31:40.140 Matt: and now two things are dependent on it. 00:31:40.220 --> 00:31:41.140 Matt: And they just keep kind of like 00:31:41.540 --> 00:31:42.480 Matt: building up this chain of dependencies 00:31:42.940 --> 00:31:45.980 Matt: instead of opting to like in the short term, 00:31:46.180 --> 00:31:48.160 Matt: maybe copying and reusing the code 00:31:48.680 --> 00:31:50.580 Matt: instead of like building up a, you know, 00:31:50.600 --> 00:31:52.380 Matt: an actual like package dependency upon it. 00:31:53.040 --> 00:31:54.320 Matt: You know, I think obviously you don't want to like 00:31:54.500 --> 00:31:56.420 Matt: always copy all code, right? 00:31:56.560 --> 00:31:58.120 Matt: Like you can't always, you can't aim for, 00:31:58.240 --> 00:31:59.940 Matt: like I don't think, I don't think it's reasonable 00:32:00.120 --> 00:32:02.140 Matt: to reach a point where you have no dependencies 00:32:02.820 --> 00:32:04.040 Matt: and you manage all your own code. 00:32:04.200 --> 00:32:07.980 Matt: But I think that's-- it just like sort of feeds into this 00:32:08.090 --> 00:32:11.140 Matt: like sort of thing of like, oh, this code exists, 00:32:11.340 --> 00:32:13.220 Matt: so I'll just like keep-- build a dependency on it 00:32:13.330 --> 00:32:16.680 Matt: instead of like pull in the parts I need or whatever. 00:32:18.300 --> 00:32:20.540 Matt: I think that's just like a main contributor to that kind of like-- 00:32:20.800 --> 00:32:22.540 Matt: you start building up this like web of things 00:32:22.840 --> 00:32:27.660 Matt: that everything basically invalidates the rest of it 00:32:27.800 --> 00:32:29.120 Matt: when you go to make that change. 00:32:31.860 --> 00:32:34.840 Matt: Yeah, I mean, it is interesting also that like, 00:32:35.880 --> 00:32:36.940 Matt: even if you don't have a monorepo, 00:32:37.340 --> 00:32:39.220 Matt: if you have like a more of a monolithic code base, 00:32:39.450 --> 00:32:40.980 Matt: like making a change like that 00:32:41.250 --> 00:32:43.460 Matt: probably also results in deploying everything anyway. 00:32:43.600 --> 00:32:44.960 Matt: So you're kind of like back at that state, 00:32:45.460 --> 00:32:46.660 Matt: even if you move to a monorepo, 00:32:46.840 --> 00:32:48.260 Matt: like you're still back, maybe back to that state 00:32:48.340 --> 00:32:50.800 Matt: where it's like one small change redeploys the whole world. 00:32:52.280 --> 00:32:53.900 Matt: Yeah, I don't know if, yeah, maybe Scott, 00:32:54.060 --> 00:32:57.040 Matt: you have some thoughts on like ways to optimize that 00:32:57.400 --> 00:32:58.040 Matt: or whatnot. 00:32:59.080 --> 00:32:59.980 Dillon: I'll jump in real quick, Matt. 00:33:00.540 --> 00:33:04.640 Dillon: You made me think of something at Wayfair, like monolith versus monorepo, 00:33:05.900 --> 00:33:09.240 Dillon: and how we're talking about with a monorepo, 00:33:09.340 --> 00:33:11.680 Dillon: there's a con of you change your dependency, 00:33:11.930 --> 00:33:13.580 Dillon: and everything needs to be rebuilt and redeployed. 00:33:13.980 --> 00:33:17.520 Dillon: But the nice thing in the monorepo is that it's all clearly connected, 00:33:18.600 --> 00:33:19.720 Dillon: and that can work. 00:33:20.420 --> 00:33:23.560 Dillon: But in a monolith situation, we have an example of, 00:33:23.920 --> 00:33:26.880 Dillon: we upgrade a major version of the design system, 00:33:27.700 --> 00:33:32.180 Dillon: And now there's no connection between the other things that depend on this package. 00:33:33.200 --> 00:33:40.580 Dillon: So when we make that change, we have to like just tell people to go upgrade or like automate a PR and have them merge it. 00:33:40.580 --> 00:33:43.500 Dillon: And like it's just so much. 00:33:43.830 --> 00:33:49.660 Dillon: It can be like the tradeoff of the extra time and CI and dealing with that. 00:33:50.140 --> 00:33:55.740 Dillon: It seems kind of worth it when you look back and think about how disconnected that was or can be. 00:33:56.560 --> 00:34:10.740 Matt: Yeah, this gets me to, yeah, back to kind of the tangent that I was thinking about heading down a little bit, is that I think in many ways, adopting a monorepo is like adopting a technical solution to an organizational problem. 00:34:12.720 --> 00:34:15.960 Matt: you could say that there's technical problems underneath that you're solving for but really 00:34:16.139 --> 00:34:19.520 Matt: you're like especially at Wayfair we were adopting it to solve the problem of like 00:34:20.460 --> 00:34:25.320 Matt: keeping teams aligned on coding you know coding patterns or like themes or like you know like the 00:34:25.520 --> 00:34:31.100 Matt: actual version of a you know the design tokens that they're using for example but and like you 00:34:31.100 --> 00:34:35.379 Matt: know we could have solved that with you know maybe a single team maintaining all of that and like 00:34:35.540 --> 00:34:38.799 Matt: it's like okay they just need to push across multiple repos or something you know you could 00:34:38.820 --> 00:34:42.800 Matt: have solved it via other solutions, but instead reached for a technical solution. 00:34:43.000 --> 00:34:43.639 Matt: I think in 00:34:43.860 --> 00:34:50.040 Matt: general, and maybe this is a topic that we need to cover, but I think most technical solutions 00:34:50.149 --> 00:34:54.960 Matt: that are adopted are usually solving for organizational problems rather than technical 00:34:55.179 --> 00:35:02.060 Matt: issues. I think Monorepos is just a very good example of that. It makes solving that organizational 00:35:02.230 --> 00:35:03.060 Matt: problem far easier. 00:35:03.180 --> 00:35:07.079 Scott: Yeah, I think that's exactly why we did it, right? I think the problem was 00:35:07.100 --> 00:35:14.220 Scott: Like we moved to a microservice architecture at Wayfair and then it felt like people couldn't get anything done. 00:35:15.010 --> 00:35:23.000 Scott: But then when we moved back to a monorepo, like ironically, people still had a lot of reasons why we couldn't get things done. 00:35:23.180 --> 00:35:31.020 Scott: We focused so much on just like, I hate this term, but lift and shift. 00:35:31.140 --> 00:35:36.080 Scott: Like the concept of like, how can we throw everything in a new space, but avoided the 00:35:36.280 --> 00:35:40.220 Scott: hard problems of like, how do we make it so we can actually do this fast? 00:35:42.060 --> 00:35:42.940 Matt: Yeah, 100%. 00:35:44.420 --> 00:35:49.260 Matt: Obviously, I think if you're in leadership, you never really want to say, yeah, let's spend 00:35:49.380 --> 00:35:52.780 Matt: the nine months rewriting stuff. 00:35:53.480 --> 00:35:56.360 Matt: It's like you never want to say that you're throwing away all that stuff. 00:35:56.570 --> 00:36:00.680 Matt: I think it's just like the common like sort of sunk cost fallacy of like, I feel like 00:36:00.680 --> 00:36:04.660 Matt: if you're in leadership, you don't see it as a sunk cost, you see it as an investment. 00:36:05.600 --> 00:36:09.700 Matt: It's like the flip side of sunk cost, just an investment in something and like, don't 00:36:09.700 --> 00:36:13.220 Matt: throw away your investment, keep it, but like move it to something new. 00:36:14.400 --> 00:36:18.000 Matt: I think that's like a, just a common mindset, right? 00:36:19.280 --> 00:36:22.940 Matt: I think that was especially common at Wayfair, for sure. 00:36:28.680 --> 00:36:31.760 Matt: I'm trying to think if I had any other thoughts on Monorepos. 00:36:31.860 --> 00:36:35.220 Matt: I think maybe they were jumping the gun a little bit, the spicy takes. 00:36:35.260 --> 00:36:42.240 Matt: I think at this point in time, now that I've seen sort of contributed to us adopting a 00:36:42.340 --> 00:36:48.760 Matt: Monorepo at Wayfair and then sort of seen maybe the opposite of it at HubSpot, where 00:36:48.700 --> 00:36:54.020 Matt: it's very distributed. And instead, HubSpot leaned a lot into building the tooling to help 00:36:55.260 --> 00:37:01.080 Matt: manage many, many repos. I think at this point, my spicy take is I think monorepos are 00:37:03.780 --> 00:37:09.520 Matt: maybe over... What's the word I'm looking for? Sort of overvalued across multiple different 00:37:09.780 --> 00:37:14.040 Matt: companies. I think it's something that people say, oh, that's going to be our silver bullet. 00:37:14.140 --> 00:37:18.580 Matt: and they adopt it and then realize that they still have many of the same pain points or, 00:37:18.980 --> 00:37:23.700 Matt: you know, slightly different pain points, but, you know, things that they probably could have 00:37:23.760 --> 00:37:27.860 Matt: solved in a different way. I don't know. Yeah. I feel like the spicy take is that 00:37:28.100 --> 00:37:30.200 Matt: monorepos are overhyped. 00:37:30.440 --> 00:37:31.840 Scott: So I got a question to that, but 00:37:34.200 --> 00:37:40.599 Scott: how does cross repo collaboration work there? Is it more so like maybe because Wayfair folks 00:37:40.660 --> 00:37:48.960 Scott: weren't trained to reach across the aisle or they it was like a not a norm whereas hubspot and maybe 00:37:49.300 --> 00:37:55.900 Scott: ingrained that as a norm from the beginning and it's not a problem or um how does that work there 00:37:55.910 --> 00:38:02.260 Scott: give us a little context a little insight as to how things how you see that working or maybe the 00:38:02.420 --> 00:38:07.859 Scott: engineers are just really good in that space and they understand across team collaboration 00:38:08.660 --> 00:38:10.180 Matt: No, yeah, that's a really good point. 00:38:11.960 --> 00:38:23.580 Matt: Yeah, I think for people that have been here a while, I think it's like that norm is still there or that culture of just find a problem and solve it in someone else's code base, go for it kind of mindset. 00:38:23.780 --> 00:38:26.120 Matt: I think that's present for the people that have been here for a while. 00:38:26.280 --> 00:38:28.020 Matt: But for the newer people, I think that's not the case. 00:38:28.760 --> 00:38:36.859 Matt: And I think we've gotten to a point where teams are very siloed and isolated, which is like, it's an interesting sort of... 00:38:37.860 --> 00:38:41.780 Matt: You know, my initial take was like, okay, that's not good that teams are so isolated and siloed. 00:38:42.030 --> 00:38:46.860 Matt: But actually those teams have full control over how they deliver on the results. 00:38:47.280 --> 00:38:49.980 Matt: And it works out for us so far from what I've seen. 00:38:50.370 --> 00:38:50.520 Matt: Right? 00:38:50.590 --> 00:38:55.000 Matt: Like those teams are, you know, I don't know, like four engineers or something for a specific feature. 00:38:55.640 --> 00:38:56.700 Matt: And they just own it wholly. 00:38:57.910 --> 00:39:03.500 Matt: And there's not that much that contributes across, like, that they need to touch in terms of, like, things outside of that feature. 00:39:06.020 --> 00:39:06.140 Matt: Yeah. 00:39:06.440 --> 00:39:11.860 Matt: Like on the face of it, it seems bad, but it actually works out pretty well is what I've found so far. 00:39:12.720 --> 00:39:28.800 Dillon: I have a lot of thoughts in terms of just like what sort of leads to monorepos or like what sort of leads to the separation of repos and like why we've led, like why we've gone to monorepos over time. 00:39:30.060 --> 00:39:36.920 Dillon: And I think it's like sort of adding on to something Scott said earlier about like discoverability. 00:39:38.080 --> 00:39:42.720 Dillon: And one of the things I've seen where I am now is like over the last eight years or so, 00:39:43.400 --> 00:39:49.460 Dillon: it was more of like a monolithic multi-repo setup where like different services are in different repos. 00:39:50.120 --> 00:39:53.560 Dillon: And I haven't even actually haven't even seen them in the Java side go into a monorepo setup. 00:39:53.700 --> 00:39:55.340 Dillon: It's still working in that way. 00:39:55.920 --> 00:39:59.940 Dillon: But anytime you're sort of considering where should I make my changes, 00:40:01.630 --> 00:40:05.300 Dillon: when it's in separate repos, it's really, really hard to know where to make your changes. 00:40:06.000 --> 00:40:08.220 Dillon: One part of that might just be the GitHub search is terrible. 00:40:10.660 --> 00:40:13.180 Dillon: So finding that stuff is really, really hard. 00:40:14.620 --> 00:40:18.200 Dillon: But putting it all in one repo, now everything's like locally searchable. 00:40:19.300 --> 00:40:24.239 Dillon: It's really, really easy to find and make changes and wrap it all up in like potentially one PR 00:40:25.100 --> 00:40:26.820 Dillon: versus multiple PRs. 00:40:27.920 --> 00:40:30.300 Dillon: It's just much easier to keep a mental model 00:40:31.020 --> 00:40:35.020 Dillon: of how your organization services operate 00:40:35.120 --> 00:40:35.900 Dillon: and connect. 00:40:37.000 --> 00:40:37.680 Dillon: I've never worked anywhere 00:40:37.840 --> 00:40:39.740 Dillon: where the entire company has a single monorepo. 00:40:40.560 --> 00:40:41.580 Dillon: It just sounds insane, 00:40:41.610 --> 00:40:43.700 Dillon: and maybe that's only something 00:40:43.700 --> 00:40:45.200 Dillon: a Google engineer has experience with. 00:40:45.640 --> 00:40:46.800 Scott: I was just going to also say, 00:40:46.820 --> 00:40:47.600 Scott: in 00:40:47.600 --> 00:40:48.160 Scott: a monorepo, 00:40:48.190 --> 00:40:49.840 Scott: you're more likely to discover the dependencies 00:40:50.110 --> 00:40:51.100 Scott: you need to solve something, 00:40:51.290 --> 00:40:53.600 Scott: whereas if you have things split up, 00:40:54.840 --> 00:40:59.480 Scott: more and you need a dependency to do something. You have to do more work and research to see if 00:40:59.520 --> 00:41:04.240 Scott: other teams are using certain things. So like things are more available to you, but like on 00:41:04.240 --> 00:41:09.960 Scott: the flip side, it also, to me, just like kind of like you need to strategically break down the team 00:41:09.960 --> 00:41:14.540 Scott: in a certain way. Like at Wayfair, you know, some teams would own like a homepage or the product 00:41:15.160 --> 00:41:20.880 Scott: page and that those things tend to create silos. I think Dillon was pointing out when you have a lot 00:41:20.840 --> 00:41:25.900 Scott: of engineers that tends to start to do that. That's totally, totally true. And I don't want 00:41:25.900 --> 00:41:33.060 Scott: to pretend that I know the best way to, to set up a team, but yes, people will be more likely to 00:41:33.160 --> 00:41:37.920 Scott: discover things and be able to contribute, which is good, but also how you structure the team. 00:41:38.640 --> 00:41:45.060 Scott: Like my example would be like put 10 web engineers on the actual application and then 10 engineers on 00:41:45.060 --> 00:41:52.000 Scott: the tooling and you might have maybe silos in a sense, but you might have a little bit more of a 00:41:52.200 --> 00:41:59.120 Scott: clear set of boundaries that you don't need folks to reach as often over the aisle. And, you know, 00:41:59.220 --> 00:42:04.500 Scott: that then silos folks into certain types of jobs. But then, yeah, like maybe we're getting more into 00:42:04.680 --> 00:42:15.020 Scott: like a HubSpot-like architecture without the multiple repos, just within one repo. But all of this is just to say 00:42:15.500 --> 00:42:16.900 Scott: there are pros and cons to each approach. 00:42:17.410 --> 00:42:21.460 Scott: And you really need to strategically think about what's the value you're trying to gain. 00:42:21.960 --> 00:42:24.940 Scott: And using Wayfair as the example, as we have, theirs was speed. 00:42:25.190 --> 00:42:26.700 Scott: So they want to deploy fast. 00:42:26.990 --> 00:42:28.360 Scott: They want to get features out fast. 00:42:28.900 --> 00:42:34.240 Scott: I would argue that speed should, this is my fireworks past talking to me, 00:42:34.640 --> 00:42:39.420 Scott: that speed should not be your only or your number one goal ever in just about anything. 00:42:40.020 --> 00:42:43.480 Scott: While it can be a goal complementary to a broader goal, 00:42:44.120 --> 00:42:53.880 Scott: You should never pin yourself on how can we do things as fast as possible because you will never be the fastest or one day you might not be the fastest. 00:42:54.520 --> 00:42:55.860 Scott: As you grow, that's hard to maintain. 00:42:57.100 --> 00:43:01.040 Scott: So just really understand your organization and try to balance those tricks. 00:43:01.120 --> 00:43:14.700 Scott: Like I could go on about speed, but just a hot take that, and I'm not talking about performance, but speed and execution is not the thing to put all your chips into that one 00:43:14.700 --> 00:43:15.120 Scott: basket. 00:43:17.140 --> 00:43:27.900 Dillon: I feel like I'm going to go on a tangent about like team setup, but I feel like as an entry, when I was more entry level, I feel like I had zero say in like what the team setup should be. 00:43:28.660 --> 00:43:37.080 Dillon: I guess a quick question to you guys is, do you feel like as you progress through your career, you have more say in the division of how a team should be set up for a project? 00:43:38.640 --> 00:43:41.040 Dillon: Or is it still kind of come down from leadership? 00:43:42.400 --> 00:43:45.140 Dillon: I feel like I'm going down on a whole new topic, but yeah. 00:43:45.880 --> 00:43:54.260 Scott: I once had the opportunity at Wayfair to tell John Klein how I thought the pod groups should be structured. 00:43:55.220 --> 00:43:57.660 Scott: And as a cop-out, I actually thought they were structured pretty well. 00:43:58.340 --> 00:44:00.060 Scott: and I didn't know better at the time. 00:44:00.650 --> 00:44:02.600 Scott: But I'm going to give him a kudos on that. 00:44:02.780 --> 00:44:07.380 Scott: That's the only leader who's ever asked my opinion on structure. 00:44:09.020 --> 00:44:13.320 Scott: I think more leaders should be receptive to people who are in the trenches 00:44:14.260 --> 00:44:15.620 Scott: thinking about those kinds of things. 00:44:16.110 --> 00:44:17.800 Scott: But I don't really feel like I've had... 00:44:18.520 --> 00:44:20.040 Scott: I've definitely been vocal about it, 00:44:20.040 --> 00:44:22.500 Scott: but I don't really feel like I've had that ability. 00:44:23.600 --> 00:44:25.620 Dillon: Maybe this is a hot take against Wayfair. 00:44:25.680 --> 00:44:26.940 Dillon: I'm sure we have tons of them, 00:44:27.140 --> 00:44:30.360 Dillon: but I actually spoke with Spencer Wednesday, 00:44:30.700 --> 00:44:31.540 Dillon: Spencer Gregson, 00:44:32.550 --> 00:44:34.180 Dillon: which maybe he listens to the podcast. 00:44:34.720 --> 00:44:35.060 Dillon: Maybe not. 00:44:36.940 --> 00:44:38.420 Dillon: And I was basically saying, 00:44:39.980 --> 00:44:41.900 Dillon: I feel like Wayfair just overhired. 00:44:42.940 --> 00:44:47.300 Dillon: And then we were forced to create tons of smaller teams 00:44:47.330 --> 00:44:48.820 Dillon: that had very narrow focus. 00:44:49.820 --> 00:44:51.360 Dillon: And then I, from my experience, 00:44:51.580 --> 00:44:53.580 Dillon: felt that that made it extremely hard 00:44:53.580 --> 00:44:56.700 Dillon: to make any sort of large impact across the web app. 00:44:57.760 --> 00:45:01.380 Dillon: so if you want to make a change that changed the critical flow in any way 00:45:01.880 --> 00:45:05.680 Dillon: it was like okay now I need to get six teams to do work for me 00:45:06.100 --> 00:45:09.600 Dillon: because six teams own that part of it. Now I'm just ranting about Wayfair 00:45:10.420 --> 00:45:13.520 Dillon: but this sort of does lead into the same situation 00:45:13.740 --> 00:45:15.600 Dillon: of the organizational structure 00:45:18.020 --> 00:45:19.580 Dillon: of how a monorepo 00:45:19.720 --> 00:45:21.420 Dillon: it comes to a monorepo at some point. 00:45:21.700 --> 00:45:23.580 Matt: I mean I want to say a general statement 00:45:23.600 --> 00:45:24.660 Matt: but it'll probably be proved wrong. 00:45:24.790 --> 00:45:26.780 Matt: But I feel like nine times out of 10, 00:45:27.150 --> 00:45:29.760 Matt: like most people think that their team 00:45:29.810 --> 00:45:31.600 Matt: could be better structured than it is. 00:45:32.220 --> 00:45:33.480 Matt: I think, and Dillon, 00:45:33.650 --> 00:45:35.520 Matt: I think you would kind of touch a little bit on this also 00:45:35.740 --> 00:45:37.280 Matt: of like, you know, 00:45:37.280 --> 00:45:39.340 Matt: I think anytime a team goes over a certain number, 00:45:39.580 --> 00:45:41.300 Matt: like, I don't know, six, eight, 10, 00:45:41.460 --> 00:45:41.860 Matt: something like that, 00:45:42.000 --> 00:45:44.900 Matt: it's like you can't have a single team anymore. 00:45:45.070 --> 00:45:45.800 Matt: And so you need to split. 00:45:46.090 --> 00:45:47.300 Matt: And then once you introduce that split, 00:45:47.770 --> 00:45:49.180 Matt: then just things are not going to work out 00:45:49.190 --> 00:45:49.800 Matt: the way you want. 00:45:49.950 --> 00:45:51.320 Matt: Like it takes a lot of time and effort 00:45:51.340 --> 00:45:54.100 Matt: to try to make two different teams 00:45:54.190 --> 00:45:55.520 Matt: or more than two different teams 00:45:55.700 --> 00:45:57.200 Matt: sort of work the way that you want it to work. 00:45:58.200 --> 00:46:00.780 Matt: And I think the sweet spot 00:46:00.860 --> 00:46:02.360 Matt: is always going to be a single team 00:46:02.520 --> 00:46:03.960 Matt: that's relatively tight. 00:46:04.530 --> 00:46:07.540 Matt: And maybe we're kind of basically reaching for the, 00:46:07.930 --> 00:46:09.380 Matt: what is it, like the Dunbar number or whatever, 00:46:10.280 --> 00:46:12.600 Matt: or the two pizza sort of rule of management, 00:46:12.800 --> 00:46:15.160 Matt: where it's like you don't want more people 00:46:15.360 --> 00:46:16.600 Matt: than what two pizzas can serve 00:46:17.530 --> 00:46:18.560 Matt: for a pod outing or something. 00:46:19.320 --> 00:46:19.900 Dillon: I guess to 00:46:19.900 --> 00:46:22.380 Dillon: try to tie this thought back into monorepos, 00:46:22.980 --> 00:46:26.100 Dillon: do you guys find that when you're working with, 00:46:26.180 --> 00:46:28.660 Dillon: or when you've seen multiple teams working in a monorepo, 00:46:28.880 --> 00:46:31.780 Dillon: do they have siloed ownership within the monorepo, 00:46:32.160 --> 00:46:33.120 Dillon: like certain parts? 00:46:34.200 --> 00:46:36.340 Dillon: Maybe this ties into code owners too, 00:46:36.540 --> 00:46:38.500 Dillon: but just want to hear your thoughts there. 00:46:39.100 --> 00:46:40.560 Matt: We saw this at Fireworks also. 00:46:40.860 --> 00:46:43.900 Matt: It's like, you know, there were parts of the repo 00:46:44.060 --> 00:46:46.460 Matt: that were for, you know, maybe at the time, 00:46:46.780 --> 00:46:49.280 Matt: slightly more experimental aspects of the product 00:46:49.300 --> 00:46:55.780 Matt: we were building out and you know that was like fairly it wasn't necessarily that we were like 00:46:56.100 --> 00:46:59.840 Matt: you know recommended not touch but it was just like you could definitely see the boundaries right 00:46:59.960 --> 00:47:02.180 Matt: you could see like this is the thing for 00:47:02.180 --> 00:47:03.360 Matt: you know maybe 00:47:03.360 --> 00:47:04.940 Matt: more of the web team and this is the thing 00:47:04.950 --> 00:47:10.220 Matt: for more of the like experimental team or whatever you know like whatever that split is and like it 00:47:10.300 --> 00:47:14.080 Matt: wasn't necessarily strictly forced but it was like I think it was just a natural thing that came out 00:47:14.100 --> 00:47:18.100 Matt: of like that, like, yeah, they're working on different things. 00:47:18.230 --> 00:47:22.100 Matt: And it's sort of like naturally enforced this separate boundary or sort of silo. 00:47:22.820 --> 00:47:26.720 Scott: Which as much as I wanted to work on some of that stuff, I actually think that that was 00:47:26.880 --> 00:47:27.180 Scott: more correct. 00:47:27.480 --> 00:47:31.940 Scott: That's more towards the example of Wayfair I gave where it's like, you guys are working 00:47:31.950 --> 00:47:32.640 Scott: on this one project. 00:47:32.880 --> 00:47:33.920 Scott: We're working on this one project. 00:47:34.859 --> 00:47:36.240 Scott: Velocity might be a little bit quicker. 00:47:36.400 --> 00:47:40.380 Scott: I mean, we had way less people there, so we probably could have crossed projects. 00:47:40.620 --> 00:47:46.280 Scott: But I think that will get you in a speed cycle a little bit faster. 00:47:47.380 --> 00:47:50.800 Scott: Just to piggyback on the speed thing, Matt and I had a little bit of side conversation. 00:47:51.420 --> 00:47:54.860 Scott: Matt believes speed is incredibly important. 00:47:55.020 --> 00:47:57.000 Scott: I just want to clarify that I agree that it is. 00:47:57.440 --> 00:48:00.140 Scott: But I don't think speed should be your only goal. 00:48:00.480 --> 00:48:10.160 Scott: If you don't know what your goal of what you're doing or why you're doing something and the answer is only speed, then you don't really know what you're doing. 00:48:10.460 --> 00:48:11.920 Scott: I don't know how else to describe that. 00:48:11.970 --> 00:48:16.360 Scott: Like speed is almost something that happens to happen with everything. 00:48:16.560 --> 00:48:19.680 Scott: I agree with Matt in the sense that it is incredibly important. 00:48:20.970 --> 00:48:25.180 Scott: Like performance as an example, speed is the number one, even though I said it wasn't 00:48:25.200 --> 00:48:25.760 Scott: the example earlier. 00:48:26.210 --> 00:48:31.660 Scott: But like AI, I would argue is like, yeah, you want to go maybe fast with getting something 00:48:31.730 --> 00:48:31.860 Scott: there. 00:48:31.950 --> 00:48:35.220 Scott: But at the same time, you want to be strategic about how you use AI. 00:48:35.310 --> 00:48:36.720 Scott: I think we've talked about this in the past. 00:48:37.060 --> 00:48:40.260 Scott: You don't want to just yeet out a bunch of AI features that don't help people. 00:48:40.640 --> 00:48:42.060 Scott: It's the same thing with building features. 00:48:42.620 --> 00:48:49.340 Scott: I think at Wayfair, we had maybe a lot of autonomy to just build new things and be like, 00:48:49.340 --> 00:48:50.100 Scott: we're going to try this. 00:48:50.860 --> 00:48:54.800 Scott: But also you don't want to do that and build crap experiences. 00:48:55.760 --> 00:49:01.220 Scott: And also you need to build it in such a way or test it in such a way that like you can 00:49:01.200 --> 00:49:07.340 Scott: actually identify if you've made a proactive positive gain, which I think in e-commerce is 00:49:07.560 --> 00:49:14.520 Scott: incredibly hard. You basically have to run a test with the same pool of people at the same time and 00:49:14.860 --> 00:49:18.260 Scott: see if people checked out more. The data for that is incredibly, incredibly challenging. 00:49:18.520 --> 00:49:24.280 Scott: So whether or not a feature does better in that, it's a hard thing to quantify. But basically, 00:49:24.550 --> 00:49:31.160 Scott: just want to clarify that speed itself is an important factor, but it shouldn't be the factor 00:49:31.360 --> 00:49:33.420 Scott: only single motivating factor for execution. 00:49:36.300 --> 00:49:37.800 Matt: Yeah, and I think as you were talking, 00:49:37.880 --> 00:49:40.040 Matt: I realized it's not necessarily speed 00:49:40.220 --> 00:49:41.360 Matt: that I think is critical. 00:49:41.440 --> 00:49:42.340 Matt: I think it's velocity. 00:49:42.520 --> 00:49:42.840 Matt: I think 00:49:42.840 --> 00:49:45.000 Matt: the 00:49:45.000 --> 00:49:45.740 Matt: key distinction there 00:49:45.880 --> 00:49:46.860 Matt: being that velocity is like, 00:49:47.700 --> 00:49:49.600 Matt: for physics majors or whatever, 00:49:50.340 --> 00:49:51.840 Matt: it's not only the speed, 00:49:51.860 --> 00:49:52.780 Matt: but it's also the direction. 00:49:53.340 --> 00:49:55.060 Matt: And I think that's the critical aspect. 00:49:55.720 --> 00:49:58.220 Matt: Speed is, you can move as fast as possible, 00:49:58.320 --> 00:50:00.440 Matt: but you could be building the wrong thing. 00:50:00.840 --> 00:50:05.220 Matt: right but velocity means that you're moving fast or you know high velocity means that you're moving 00:50:05.380 --> 00:50:10.400 Matt: fast and in a direction and maybe that you know that direction needs to be guided but um but i 00:50:10.400 --> 00:50:14.840 Matt: think generally speaking like if you have that right and it's like we're getting pretty far off 00:50:15.180 --> 00:50:20.520 Matt: monorepo topic but i think if you have the right velocity everything else can be solved like if 00:50:20.560 --> 00:50:23.680 Matt: you're moving fast and in the right direction like you can solve any problem on top of that 00:50:24.120 --> 00:50:30.140 Scott: it's related to why we picked a monorepo but yeah i i think we're we're again like kind of saying the 00:50:30.080 --> 00:50:35.060 Scott: same thing but i agree in the same sense of velocity like we want it to uh increase the 00:50:35.200 --> 00:50:42.680 Scott: ability to deliver essentially i i agree with that but like is that the only thing that you're 00:50:42.780 --> 00:50:47.380 Scott: gonna get from it like i guess like are we delivering the right things like it does it 00:50:47.610 --> 00:50:54.660 Scott: allow us to actually make gains like we need there needs to be uh some sort of north star in my 00:50:54.600 --> 00:51:00.680 Scott: opinion about how what we're building towards because velocity could be great if we if we can 00:51:00.820 --> 00:51:04.360 Scott: churn out way more work we could build things faster but if we we don't know what we're building 00:51:04.620 --> 00:51:12.120 Scott: towards we don't really um you know we're not making strides essentially any other thoughts 00:51:12.340 --> 00:51:15.920 Scott: folks like i feel like i ranted too many times matt ranted a few times 00:51:15.920 --> 00:51:19.020 Dillon: i feel like coming into this 00:51:19.540 --> 00:51:23.220 Dillon: I just, I was, maybe my brain was too filled with other nonsense. 00:51:23.980 --> 00:51:26.460 Dillon: So it was like really hard for me to think of certain reasons. 00:51:26.760 --> 00:51:28.860 Dillon: Monorepos either suck or are great. 00:51:29.780 --> 00:51:33.100 Dillon: And I feel like I'm coming away with a lot more pros than cons. 00:51:34.900 --> 00:51:36.200 Dillon: I just want to like call out really quickly. 00:51:36.820 --> 00:51:39.860 Dillon: One of the things I thought about was that like, 00:51:40.160 --> 00:51:41.620 Dillon: that one of the really nice things with Monorepos, 00:51:41.780 --> 00:51:44.140 Dillon: you just have so much more sight into what other teams are doing. 00:51:45.660 --> 00:51:48.000 Dillon: And like, we didn't really dig into code owners. 00:51:48.200 --> 00:51:54.580 Dillon: it's a separate episode but that the code owners has the potential to to maybe have someone from 00:51:54.680 --> 00:52:00.060 Dillon: another team have to approve your changes but also just like tag them on a review so that like you 00:52:00.180 --> 00:52:04.260 Dillon: have the best people at your company possible that like know the most about a certain part of your 00:52:04.480 --> 00:52:10.559 Dillon: system to to come in and review that code for you um and when you're working in like siloed repos 00:52:11.100 --> 00:52:15.340 Dillon: you're sort of just limited to the expertise of your team. 00:52:16.040 --> 00:52:21.340 Dillon: And you sort of limit, you cut yourself off from like a lot of really smart people in your org. 00:52:22.410 --> 00:52:26.080 Dillon: And there's like within a monorepo, if you're using code owners in a certain way that like 00:52:26.780 --> 00:52:32.500 Dillon: gets your, your Artys and your Joes to look at your code, those are real people, by the way. 00:52:34.940 --> 00:52:39.620 Dillon: Then like, you're going to feel a lot better about like, you're gonna be a lot more confident 00:52:39.640 --> 00:52:42.380 Dillon: about your changes they're gonna they're gonna point things out that like you didn't think about 00:52:43.100 --> 00:52:47.980 Dillon: um and in having that is i don't know one it's like really nice to be able to work with those 00:52:47.980 --> 00:52:52.880 Dillon: sorts of people and learn a lot of things from them but yeah you're hopefully gonna like have a 00:52:53.000 --> 00:52:55.520 Dillon: lot better quality at the end yeah 00:52:55.520 --> 00:53:00.960 Matt: i think i like i agree i think i've also like especially on the 00:53:01.100 --> 00:53:07.700 Matt: my current team right now i've seen like the the bad side of that and in the like we're in this 00:53:07.700 --> 00:53:12.640 Matt: interesting moment where like our teams are scaling and so we have like more and more people 00:53:12.860 --> 00:53:17.980 Matt: contributed to this repo that we work in but the people with uh you know the domain knowledge or 00:53:18.000 --> 00:53:23.420 Matt: the domain expertise are you know there's not that many people that know that much about the 00:53:23.820 --> 00:53:29.580 Matt: tool that lives in our repo um and and they're moving further away from it and we did have this 00:53:29.660 --> 00:53:32.780 Matt: sort of strategy where like we sort of had a single code review i mean we're kind of getting 00:53:32.840 --> 00:53:33.820 Matt: into the code owners topic but we 00:53:33.820 --> 00:53:33.960 Matt: had 00:53:33.960 --> 00:53:37.080 Matt: a single code owners group that would be round robin assigned 00:53:37.080 --> 00:53:41.360 Matt: reviewers on PRs and we found out that like actually there's so many different teams contributing that 00:53:41.480 --> 00:53:46.500 Matt: that's not scaling anymore and we're actually going to start reaching more towards the isolated like 00:53:46.900 --> 00:53:51.780 Matt: okay if you if you're making a change to the testing code of this repo then only ping someone 00:53:51.830 --> 00:53:56.520 Matt: from the you know the testing team or the team that owns like how we run tests or whatever but 00:53:56.580 --> 00:54:01.000 Matt: if you're making change to source file analysis then ping the dev tooling team or if you're making 00:54:00.940 --> 00:54:03.360 Matt: can change the webpack or rspack than ping our team. 00:54:04.420 --> 00:54:06.100 Matt: And so it's an interesting-- 00:54:06.660 --> 00:54:07.220 Matt: like, I agree. 00:54:08.040 --> 00:54:09.500 Matt: I want it to be more distributed. 00:54:09.760 --> 00:54:13.720 Matt: And I think that's the way to make sure people are kept up. 00:54:13.740 --> 00:54:15.820 Matt: But I think you start to get to a point where it's like, 00:54:16.340 --> 00:54:17.680 Matt: you can't keep that up, I think. 00:54:18.200 --> 00:54:19.160 Matt: Or it's very difficult. 00:54:19.680 --> 00:54:21.160 Matt: Like, a lot of things are moving against you 00:54:21.260 --> 00:54:22.100 Matt: to try to keep that up. 00:54:23.120 --> 00:54:27.260 Matt: And it's hard to know how much should you fight back 00:54:27.400 --> 00:54:30.420 Matt: against that versus just sort of let it happen almost. 00:54:31.660 --> 00:54:34.260 Dillon: what you're saying makes sense it's like you got to find the balance of like 00:54:35.790 --> 00:54:40.260 Dillon: how much time do I have in a day to like work on what my team's working on and also 00:54:41.180 --> 00:54:46.360 Dillon: like keep an eye on everything else the company's doing and that can't grow so far that like you're 00:54:46.720 --> 00:54:52.880 Dillon: completely like I don't know you get frozen in a sense when you have too many things to 00:54:52.980 --> 00:54:54.140 Dillon: keep track of. 00:54:54.980 --> 00:54:56.980 Dillon: I see that even when I'm 00:54:58.280 --> 00:54:58.940 Dillon: working at 00:54:59.140 --> 00:55:00.860 Dillon: Whoop where I'm trying to 00:55:01.100 --> 00:55:03.060 Dillon: solve for so many different things that I start to feel like 00:55:03.060 --> 00:55:05.060 Dillon: I'm not moving anymore. And I think that can happen 00:55:05.080 --> 00:55:05.740 Dillon: to teams where 00:55:06.960 --> 00:55:09.040 Dillon: you start to own too many things and then 00:55:09.040 --> 00:55:11.000 Dillon: next thing you know you're not able to make progress 00:55:11.100 --> 00:55:11.480 Dillon: on anything. 00:55:12.600 --> 00:55:13.160 Scott: I feel that. 00:55:14.240 --> 00:55:14.540 Scott: Breach! 00:55:16.400 --> 00:55:16.660 Scott: I had 00:55:16.660 --> 00:55:17.580 Scott: a last point 00:55:17.600 --> 00:55:19.380 Scott: on MonoRepos just to kind of talk about 00:55:19.440 --> 00:55:20.500 Scott: I know Matt 00:55:20.520 --> 00:55:25.480 Scott: kind of would use monorepos as his go-to architecture, 00:55:25.930 --> 00:55:28.620 Scott: and I kind of piggybacked off of what he had done for that. 00:55:29.940 --> 00:55:32.300 Scott: Now, I think that that's kind of nice. 00:55:34.300 --> 00:55:36.160 Scott: My first thoughts originally was it's overkill, 00:55:36.340 --> 00:55:39.160 Scott: but I think it's kind of nice when one person's working on it 00:55:39.260 --> 00:55:41.340 Scott: because you have the understanding and knowledge 00:55:41.340 --> 00:55:42.560 Scott: of how it all comes together. 00:55:43.400 --> 00:55:44.900 Scott: But could it be overkill? 00:55:45.400 --> 00:55:47.020 Scott: Yeah, it's probably a lot. 00:55:47.170 --> 00:55:49.060 Scott: If you think you're going to have two packages, 00:55:49.340 --> 00:55:50.960 Scott: Do you really need them in that repo? 00:55:51.110 --> 00:55:53.720 Scott: I mean, it's kind of nice, but if you have, 00:55:54.880 --> 00:55:58.300 Scott: it's more set up for like a long haul, large kind of thing. 00:55:59.050 --> 00:56:01.000 Scott: I don't know, this is like relevant to monorepos, 00:56:01.260 --> 00:56:05.080 Scott: but it's more of a tangent thing I just needed to bring up. 00:56:07.279 --> 00:56:09.140 Matt: - It's funny, yeah, I'm glad you brought that up Scott 00:56:09.310 --> 00:56:11.220 Matt: because I, yeah, originally, you know, 00:56:11.220 --> 00:56:14.440 Matt: a year ago at this time I was like, I wanna set up my, 00:56:14.570 --> 00:56:16.500 Matt: like, you know, my open source side project template 00:56:16.610 --> 00:56:18.980 Matt: is going to be a monorepo every, like, 00:56:19.620 --> 00:56:23.180 Matt: And not like a single monorepo, but every single project would have its own monorepo. 00:56:23.800 --> 00:56:28.340 Matt: And I think at this point, I've realized that is totally overkill and is the wrong default. 00:56:29.040 --> 00:56:32.120 Matt: I've flipped 180 and said, no, I don't. 00:56:34.560 --> 00:56:41.440 Matt: Certainly there are benefits to monorepos, but at the rate in which I was churning out new side projects, it just wasn't worth it. 00:56:41.960 --> 00:56:47.780 Matt: Maybe it would be different if it's an actual single monorepo where every side project is just a new 00:56:47.780 --> 00:56:48.460 Matt: package in that 00:56:48.460 --> 00:56:48.820 Matt: monorepo. 00:56:48.840 --> 00:56:49.740 Matt: which could work. 00:56:49.960 --> 00:56:54.760 Matt: But I realized also that there's just scaling costs to that 00:56:55.060 --> 00:56:55.460 Matt: that I couldn't 00:56:55.460 --> 00:56:56.240 Matt: maintain in 00:56:56.240 --> 00:56:57.720 Matt: terms of at the time I was deploying. 00:56:57.790 --> 00:56:59.600 Matt: So I docked site to Vercel, 00:56:59.690 --> 00:57:02.680 Matt: and Vercel had limits on how many things you can deploy from a single repo. 00:57:03.239 --> 00:57:06.320 Matt: And there's all these other limits that are difficult for a single 00:57:06.320 --> 00:57:06.960 Matt: person. 00:57:07.240 --> 00:57:09.080 Scott: That's a good approach for you to go all in on 00:57:09.220 --> 00:57:10.420 Scott: when you go all in on a ham stack. 00:57:15.180 --> 00:57:15.320 Matt: True. 00:57:16.380 --> 00:57:17.900 Matt: But just like so many tools, 00:57:18.120 --> 00:57:21.700 Matt: like even though we've had this like sort of resurgence into monorepo tooling over the past 00:57:22.060 --> 00:57:28.740 Matt: five years or so so many other tools are still very uh you know don't support monorepos that well 00:57:28.900 --> 00:57:32.080 Matt: i think github is a really good example of something that doesn't actually support monorepos 00:57:32.180 --> 00:57:36.940 Matt: too well right like if you think about issues and prs there's no way to refine down like this issue 00:57:37.060 --> 00:57:41.560 Matt: relates only to this package in this repo right you have to rely on additional context added to 00:57:41.600 --> 00:57:45.160 Matt: the title or description and say like this only impacts this package right there's a way to like 00:57:44.980 --> 00:57:47.140 Matt: filter that down easily. You have to build up 00:57:47.160 --> 00:57:48.800 Matt: all this other stuff to it. I don't know. 00:57:48.840 --> 00:57:51.040 Matt: I think it's just 00:57:51.140 --> 00:57:53.240 Matt: like it's not the right default for 00:57:54.279 --> 00:57:55.180 Matt: the work that I'm 00:57:55.260 --> 00:57:57.020 Matt: doing, I guess. I think there 00:57:57.620 --> 00:57:59.160 Matt: are teams that can make monorepos work, but 00:57:59.220 --> 00:58:01.120 Matt: it's just like, it's not a 00:58:01.200 --> 00:58:03.140 Matt: silver bullet. You have to 00:58:03.280 --> 00:58:04.400 Matt: do additional work to make it 00:58:05.220 --> 00:58:07.080 Scott: work. If you see it growing, it could be 00:58:07.240 --> 00:58:08.820 Scott: worth it, but it 00:58:09.240 --> 00:58:10.920 Scott: depends. Okay, sorry. Go ahead, Dillon. 00:58:11.480 --> 00:58:11.920 Dillon: My point 00:58:11.920 --> 00:58:12.400 Dillon: was just like, 00:58:12.460 --> 00:58:13.220 Dillon: it's sort of a callback 00:58:13.260 --> 00:58:17.920 Dillon: to one of the first things I said at the beginning of the episode is that I get my current company, 00:58:18.130 --> 00:58:25.920 Dillon: we don't have dedicated team or, or resources or time sort of set aside to spend time managing 00:58:26.080 --> 00:58:31.460 Dillon: the monorepo, setting it up, making sure it's like functioning as it should. So it can be really 00:58:31.620 --> 00:58:35.640 Dillon: hard, like, especially when all you're doing in your personal projects is you're just standing up 00:58:35.760 --> 00:58:40.060 Dillon: POCs. Like you're going to be spending two times the amount of time trying to set up your damn 00:58:40.080 --> 00:58:45.220 Dillon: monorepo and you could have just like set up your poc and and like validated that that idea works 00:58:46.700 --> 00:58:49.300 Dillon: so i think that kind of that can happen at startups too where it's like 00:58:50.959 --> 00:58:57.000 Dillon: dude in july i gotta launch this product i don't have time to like set up my monorepo like who 00:58:57.180 --> 00:59:03.080 Dillon: cares like i just got to get the code shipped like that that north star yeah for sure i want to get 00:59:03.220 --> 00:59:07.000 Dillon: there but right now is just not the time 00:59:03.220 --> 00:59:07.000 Scott: focusing 00:59:07.000 --> 00:59:08.600 Scott: on the goal i huge 00:59:11.040 --> 00:59:11.780 Matt: yeah yeah 00:59:13.800 --> 00:59:17.760 Matt: all right uh any other further thoughts here i think we've kind of ranted and rambled 00:59:18.210 --> 00:59:23.580 Matt: along this topic um but i think it was a good discussion on you know monorepos and like their 00:59:23.740 --> 00:59:28.780 Matt: aspects and like uh you know not necessarily the you know maybe we do an actual episode on 00:59:28.940 --> 00:59:36.300 Matt: monorepo tooling or more specifics feel free to rally out and uh throw us some some thoughts on uh 00:59:36.820 --> 00:59:38.880 Matt: on discord or on our blue sky account or whatnot. 00:59:39.360 --> 00:59:42.040 Matt: I'm happy to dig into more topics that people have. 00:59:42.640 --> 00:59:43.980 Scott: Is it time for spicy takes? 00:59:45.180 --> 00:59:45.720 Dillon: If we have them. 00:59:46.400 --> 00:59:46.640 Matt: I mean, 00:59:46.680 --> 00:59:46.780 Matt: yeah, 00:59:46.840 --> 00:59:47.560 Matt: we can jump into it. 00:59:47.560 --> 00:59:48.060 Matt: I feel like I, 00:59:48.180 --> 00:59:50.100 Matt: I feel like I shared one during the discussion, 00:59:50.940 --> 00:59:51.240 Matt: but yeah, 00:59:51.660 --> 00:59:52.840 Matt: if let's Scott, 00:59:52.980 --> 00:59:53.620 Matt: what's your spicy take? 00:59:54.760 --> 00:59:56.660 Scott: I think we're in a golden age of CSS. 00:59:56.900 --> 00:59:57.300 Scott: My friends, 00:59:57.940 --> 00:59:58.840 Scott: this is a golden age. 00:59:59.100 --> 01:00:00.720 Scott: You folks were saying to me, 01:00:02.180 --> 01:00:03.360 Scott: you don't know what that means, 01:00:03.640 --> 01:00:06.260 Scott: but basically I think we're at a point where we've, 01:00:06.300 --> 01:00:12.940 Scott: been in a point where we're getting a lot of new features. They're getting supported pretty rapidly 01:00:14.180 --> 01:00:20.740 Scott: that are making CSS and code simpler and easier to write. I don't want to get too into the specifics, 01:00:21.160 --> 01:00:26.440 Scott: but more and more APIs are coming out. There's solutions we've been solving with JavaScript. 01:00:27.000 --> 01:00:31.240 Scott: They're just going to reduce the amount of overhead and complexity. And a lot of these 01:00:31.440 --> 01:00:34.560 Scott: things, when you add them in, like if they just don't work, you just don't get them. 01:00:35.240 --> 01:00:37.980 Scott: So you could do with progressive enhancement, they say. 01:00:38.840 --> 01:00:42.040 Scott: So I just think that we're at a point where we don't have to, 01:00:42.240 --> 01:00:44.420 Scott: we used to have to worry like, oh, go on this browser. 01:00:44.520 --> 01:00:45.640 Scott: Does it work for this thing? 01:00:46.020 --> 01:00:47.740 Scott: And maybe that's more of an enterprise level thing. 01:00:48.880 --> 01:00:50.200 Scott: Although I did it at some startups 01:00:50.960 --> 01:00:53.160 Scott: because everyone would use Internet Explorer back in the day. 01:00:53.340 --> 01:00:57.480 Scott: But I just think we're at a point where you can do it. 01:00:57.680 --> 01:01:00.300 Scott: CSS isn't like a culprit that's slowing you down. 01:01:00.680 --> 01:01:04.820 Scott: And rather it has multiple tools that get you to get what you need done faster. 01:01:06.280 --> 01:01:11.120 Matt: so i i would actually argue and i know this isn't the point of this segment but i would actually 01:01:11.260 --> 01:01:16.520 Matt: argue that a lot of the stuff that's been adding to the css spec is really terrible over the past 01:01:16.740 --> 01:01:18.820 Scott: that's a hotter take than mine that's me 01:01:18.820 --> 01:01:20.180 Matt: that's my hot take because 01:01:20.180 --> 01:01:21.760 Scott: yeah i think it's a hot 01:01:22.500 --> 01:01:28.840 Matt: because i tried out yeah i tried out anchor positioning it sucks it's so complex to manage 01:01:29.100 --> 01:01:34.200 Matt: anchor positioning and it and it you can't handle the dynamicism that you get with a like a javascript 01:01:34.220 --> 01:01:35.820 Matt: tooltip library. 01:01:34.220 --> 01:01:35.820 Scott: It's not even available. 01:01:36.160 --> 01:01:38.060 Matt: You want to position it to the right if there's space. 01:01:38.720 --> 01:01:39.780 Matt: It is available. 01:01:38.720 --> 01:01:39.780 Scott: For Chrome? 01:01:40.020 --> 01:01:42.380 Matt: Anchor position isn't supported. It's hardly supported. 01:01:42.560 --> 01:01:44.400 Matt: No, it's supported in multiple browsers. 01:01:45.600 --> 01:01:45.820 Dillon: It is. 01:01:46.560 --> 01:01:47.060 Dillon: All right, I guess 01:01:48.000 --> 01:01:50.160 Dillon: my hot takes is reactions to the hot takes 01:01:50.240 --> 01:01:52.180 Dillon: at this point. But I guess 01:01:52.300 --> 01:01:54.200 Dillon: my hot take is you should just not 01:01:54.340 --> 01:01:56.100 Dillon: care about CSS anymore and you should just 01:01:56.780 --> 01:01:58.140 Dillon: put your trust in one of these 01:01:58.880 --> 01:02:00.080 Dillon: frameworks like Radix 01:02:00.220 --> 01:02:01.040 Dillon: or however you say it. 01:02:01.640 --> 01:02:02.040 Dillon: Shadcn 01:02:02.040 --> 01:02:04.020 Scott: only supported in Chrome. 01:02:06.600 --> 01:02:08.060 Scott: It's only supported in Chrome. 01:02:08.800 --> 01:02:13.400 Dillon: Wait for these frameworks to learn how to use it, implement it, and give you an easy way to use it. 01:02:13.760 --> 01:02:15.700 Dillon: Because that's kind of the way of the web nowadays. 01:02:16.360 --> 01:02:17.820 Scott: Are you talking about popover? 01:02:18.040 --> 01:02:18.920 Scott: Because that, I think, 01:02:18.920 --> 01:02:20.300 Scott: is a little bit more supported. 01:02:21.160 --> 01:02:21.980 Scott: Is it popover? 01:02:22.600 --> 01:02:22.700 Scott: Yeah. 01:02:24.100 --> 01:02:25.720 Matt: No, I'm talking about it. 01:02:26.240 --> 01:02:28.260 Matt: Another example is the CSS carousel stuff. 01:02:28.360 --> 01:02:28.760 Matt: That stuff's 01:02:28.760 --> 01:02:29.040 Scott: cool. 01:02:29.460 --> 01:02:35.520 Matt: Listen, I'm all for making it easier for carousels to do, but it's not accessible. 01:02:36.320 --> 01:02:37.520 Scott: Carousels are not accessible. 01:02:37.940 --> 01:02:38.900 Matt: It's horribly... 01:02:40.340 --> 01:02:46.400 Matt: I know, but the CSS carousel spec especially is even worse for accessibility than writing your 01:02:46.400 --> 01:02:46.460 Matt: own personal JavaScript. 01:02:46.460 --> 01:02:47.200 Scott: You're talking about snap 01:02:47.200 --> 01:02:47.840 Scott: positioning. 01:02:48.200 --> 01:02:48.940 Matt: I'll have to dig up a link 01:02:48.940 --> 01:02:49.340 Matt: to this article. 01:02:49.340 --> 01:02:50.100 Scott: You're talking about snap positioning. 01:02:50.540 --> 01:02:51.480 Matt: No, not snap positioning. 01:02:51.570 --> 01:02:52.220 Matt: Like this new 01:02:52.220 --> 01:02:54.580 Matt: CSS carousel stuff. 01:02:57.220 --> 01:02:57.880 Scott: I'll give you that. 01:02:58.270 --> 01:02:58.540 Matt: All right. 01:02:58.680 --> 01:02:59.720 Scott: Well, I was referring... 01:02:59.920 --> 01:03:01.120 Matt: It's absolutely atrocious. 01:03:01.810 --> 01:03:03.060 Matt: So I don't think we're in the golden age at all. 01:03:03.110 --> 01:03:04.340 Matt: I think golden age was Flexbox. 01:03:04.930 --> 01:03:06.480 Matt: And then anything after that, it was like... 01:03:06.560 --> 01:03:06.620 Matt: Well, 01:03:06.760 --> 01:03:09.740 Scott: I'm literally including Flexbox and Grid. 01:03:09.960 --> 01:03:11.200 Scott: We're in a golden age. 01:03:11.340 --> 01:03:12.000 Scott: It's like... 01:03:12.620 --> 01:03:13.360 Matt: Oh, Grid was... 01:03:13.630 --> 01:03:14.560 Matt: No, Grid's trash. 01:03:15.580 --> 01:03:15.960 Scott: All right. 01:03:16.240 --> 01:03:16.520 Scott: All right. 01:03:17.559 --> 01:03:18.280 Scott: I don't... 01:03:19.099 --> 01:03:19.600 Scott: We're done. 01:03:19.720 --> 01:03:20.500 Scott: Episode's over. 01:03:20.720 --> 01:03:22.060 Scott: I can't anymore. 01:03:25.020 --> 01:03:26.100 Scott: You can say the API 01:03:26.100 --> 01:03:27.580 Scott: is convoluted, 01:03:27.720 --> 01:03:29.900 Scott: but grid is actually like a good solution. 01:03:32.620 --> 01:03:33.520 Scott: Cause it is convoluted. 01:03:33.520 --> 01:03:34.120 Scott: I'll give you that. 01:03:35.840 --> 01:03:36.920 Dillon: I think you're just wasting time. 01:03:37.060 --> 01:03:38.140 Dillon: If you're writing CSS nowadays, 01:03:38.920 --> 01:03:39.480 Dillon: that's my hot take. 01:03:42.260 --> 01:03:43.980 Matt: That I think that's an great hot take. 01:03:44.810 --> 01:03:45.020 Dillon: I mean, 01:03:45.140 --> 01:03:46.800 Dillon: maybe it's fun and to learn on the side, 01:03:47.200 --> 01:03:48.820 Dillon: but if you're actually writing it at work, 01:03:50.060 --> 01:03:51.480 Dillon: there's just better ways nowadays. 01:03:53.300 --> 01:03:55.720 Dillon: Unless you have like a really specific use case where you, 01:03:55.780 --> 01:03:58.660 Dillon: you like have to break outside of the box 01:03:59.960 --> 01:04:01.980 Dillon: of tooling that's out there. 01:04:04.160 --> 01:04:05.620 Dillon: Maybe that's what Scott's working on right now. 01:04:06.000 --> 01:04:08.760 Dillon: He said he was doing some sort of graphical thing 01:04:09.140 --> 01:04:09.620 Dillon: with code earlier. 01:04:10.500 --> 01:04:11.100 Scott: I like to 01:04:11.100 --> 01:04:11.700 Scott: build UI. 01:04:12.980 --> 01:04:14.380 Scott: So, I mean, if you like to build UI 01:04:14.560 --> 01:04:15.860 Scott: like we did on the design system, 01:04:16.260 --> 01:04:18.760 Scott: then you need to know how these features work, but okay. 01:04:21.440 --> 01:04:22.780 Matt: No, yeah, I think that's a good highlight. 01:04:22.940 --> 01:04:24.220 Matt: I think maybe Dillon and I are maybe, 01:04:26.119 --> 01:04:28.720 Matt: okay, I'm going to use this word, but it's going to sound wrong. 01:04:28.960 --> 01:04:29.440 Matt: It's like a higher 01:04:29.440 --> 01:04:29.780 Matt: level than UI. 01:04:29.780 --> 01:04:31.040 Scott: That's completely incorrect. 01:04:31.480 --> 01:04:34.120 Matt: I think not, no, no, no. 01:04:34.190 --> 01:04:36.580 Matt: I mean like higher level of an abstraction, right? 01:04:36.720 --> 01:04:37.260 Matt: Like Dillon, I 01:04:37.260 --> 01:04:39.040 Matt: probably, maybe 01:04:39.040 --> 01:04:39.340 Matt: not Dillon. 01:04:40.980 --> 01:04:45.880 Matt: I don't like, personally, I don't, I don't care to write CSS manually anymore. 01:04:46.300 --> 01:04:48.160 Matt: It's just not something that excites me. 01:04:48.550 --> 01:04:50.700 Matt: And so I reach for those abstractions, like Dillon was saying, 01:04:50.710 --> 01:04:52.400 Matt: like Radix or Shadcn UI or whatnot. 01:04:53.860 --> 01:04:58.200 Matt: And that's perfectly fine. 01:04:58.520 --> 01:05:01.040 Matt: And so I think there's engineers that are fine with working at that. 01:05:01.080 --> 01:05:03.840 Matt: I think there's also engineers like Scott that specialize in... 01:05:03.840 --> 01:05:03.980 Matt: All 01:05:03.980 --> 01:05:05.180 Scott: right, now you're insulting me. 01:05:05.180 --> 01:05:06.000 Scott: I don't specialize. 01:05:06.080 --> 01:05:07.220 Scott: No, it's no layer below that. 01:05:07.820 --> 01:05:08.020 Scott: No. 01:05:09.500 --> 01:05:09.900 Scott: I 01:05:09.900 --> 01:05:11.620 Scott: started my career building with 01:05:11.620 --> 01:05:13.600 Scott: UI, and I find that fun. 01:05:13.780 --> 01:05:16.700 Scott: I want to build better experiences for people using 01:05:16.700 --> 01:05:17.200 Scott: a thing. 01:05:17.560 --> 01:05:19.020 Scott: That is fun to me. 01:05:19.580 --> 01:05:20.900 Scott: I like to do the other stuff. 01:05:21.120 --> 01:05:23.420 Scott: I like to build data transformations 01:05:23.420 --> 01:05:24.280 Scott: and make things 01:05:24.280 --> 01:05:24.680 Scott: work. 01:05:24.880 --> 01:05:27.180 Scott: But what you're saying is you're working on different problems. 01:05:29.340 --> 01:05:31.540 Scott: Like front-end engineering is still building you. 01:05:31.540 --> 01:05:31.960 Scott: Not necessarily that, 01:05:31.980 --> 01:05:32.980 Matt: just that we find interest. 01:05:33.700 --> 01:05:34.480 Matt: We have different interests. 01:05:34.780 --> 01:05:35.060 Matt: Yeah, I know. 01:05:35.160 --> 01:05:35.300 Matt: But we 01:05:35.300 --> 01:05:36.000 Matt: have different interests 01:05:36.000 --> 01:05:37.980 Matt: in the scope of front-end. 01:05:38.140 --> 01:05:38.820 Scott: That's what I'm saying. 01:05:39.540 --> 01:05:39.640 Scott: And 01:05:39.640 --> 01:05:40.420 Matt: I think both are valuable. 01:05:41.420 --> 01:05:42.000 Matt: I'm not attacking. 01:05:42.140 --> 01:05:42.820 Matt: I've agreed with you. 01:05:42.900 --> 01:05:43.720 Matt: I'm saying the same thing you said. 01:05:44.160 --> 01:05:45.600 Matt: All right, we've gotten maybe 01:05:45.600 --> 01:05:46.220 Scott: way too spicy. 01:05:46.230 --> 01:05:47.640 Scott: You didn't even rank my spicy 01:05:47.640 --> 01:05:47.960 Scott: take. 01:05:48.100 --> 01:05:48.580 Scott: You just ripped 01:05:48.580 --> 01:05:49.120 Scott: it apart. 01:05:51.880 --> 01:05:53.080 Matt: what's the spice scale 01:05:53.080 --> 01:05:55.060 Scott: meter whatever we call it 01:05:55.060 --> 01:05:58.360 Matt: the taco bell rankings the curry spice meter 01:05:58.980 --> 01:06:02.600 Dillon: oh man this segment's gonna change to like somebody gives a spicy take and then we just 01:06:02.730 --> 01:06:07.640 Dillon: we just try to like prove them wrong i would spice them yeah 01:06:07.640 --> 01:06:09.520 Scott: css socks 01:06:09.520 --> 01:06:10.180 Scott: if you're 01:06:10.180 --> 01:06:10.880 Scott: using css 01:06:11.140 --> 01:06:11.520 Scott: you're a junior 01:06:11.520 --> 01:06:11.980 Scott: engineer 01:06:15.920 --> 01:06:18.560 Matt: that's a spike that's no that's a lukewarm take that's 01:06:18.560 --> 01:06:19.780 Scott: the take that i i 01:06:19.780 --> 01:06:20.960 Scott: got from you 01:06:22.080 --> 01:06:23.160 Scott: funny i i tried 01:06:23.160 --> 01:06:23.940 Dillon: to describe it out 01:06:23.940 --> 01:06:25.080 Dillon: of your points my 01:06:25.080 --> 01:06:27.400 Dillon: career started the same way it was like just css 01:06:28.020 --> 01:06:32.760 Dillon: i built everything from scratch and that was like how i got into got into coding in the industry 01:06:33.500 --> 01:06:38.060 Dillon: i just feel like a lot of it's been abstracted away nowadays 01:06:33.500 --> 01:06:38.060 Scott: i'll go one step further yeah 01:06:38.060 --> 01:06:38.400 Scott: i 01:06:38.420 --> 01:06:40.960 Scott: I think because CSS is so much easier to use too. 01:06:41.050 --> 01:06:43.560 Scott: Like you don't really need to do as much with it. 01:06:43.650 --> 01:06:44.700 Scott: Like, yeah, sure. 01:06:44.770 --> 01:06:47.180 Scott: We make components that do the work for us. 01:06:47.360 --> 01:06:51.200 Scott: But I mean, if you're telling React to put margin on a thing, 01:06:51.520 --> 01:06:53.880 Scott: or if you use Tailwind, you're probably passing a class name. 01:06:54.500 --> 01:06:56.300 Scott: Like at some semblance, you're still using it. 01:06:56.420 --> 01:06:58.180 Scott: Maybe just albeit not directly, 01:06:58.670 --> 01:07:02.800 Scott: but people are still building things with it. 01:07:03.040 --> 01:07:05.140 Scott: And you're telling your code to do that. 01:07:05.360 --> 01:07:09.000 Scott: Sorry, UI components is beneath Matt. 01:07:09.240 --> 01:07:11.340 Scott: Like, God forbid you work on a feature. 01:07:11.880 --> 01:07:12.920 Scott: That's beneath Matt. 01:07:12.940 --> 01:07:13.380 Scott: He only 01:07:13.380 --> 01:07:15.740 Scott: transpiles, 01:07:15.860 --> 01:07:18.000 Scott: I don't know, web frameworks. 01:07:23.900 --> 01:07:24.760 Matt: I'm all in on Flash. 01:07:25.200 --> 01:07:26.760 Matt: That's going to be the future, guys, is Flash. 01:07:27.460 --> 01:07:28.980 Scott: Flash literally doesn't exist anymore. 01:07:31.820 --> 01:07:35.720 Matt: But also, who needs to write CSS when you have Figma generating their website? 01:07:35.960 --> 01:07:36.900 Matt: So, like, you know. 01:07:38.420 --> 01:07:38.700 Scott: Completely. 01:07:39.420 --> 01:07:39.520 Matt: Okay. 01:07:39.920 --> 01:07:40.120 Matt: All right. 01:07:40.300 --> 01:07:41.360 Matt: I'm not taking a bait. 01:07:45.740 --> 01:07:46.040 Matt: All right. 01:07:47.760 --> 01:07:48.720 Matt: Any other closing thoughts? 01:07:49.600 --> 01:07:52.660 Matt: I feel like we've been – I think it was a good, healthy discussion. 01:07:53.800 --> 01:07:55.020 Scott: Yeah, I got a closing thought 01:07:55.140 --> 01:07:55.680 Scott: And then he was right. 01:07:56.380 --> 01:07:56.520 Matt: I 01:07:56.520 --> 01:07:56.900 Matt: was wrong. 01:07:56.920 --> 01:08:01.300 Scott: We had a whole episode about the shattification and how the web sucks. 01:08:01.560 --> 01:08:03.220 Scott: but you think CSS sucks. 01:08:03.380 --> 01:08:04.660 Scott: So you just contribute to the problem. 01:08:06.120 --> 01:08:06.420 Scott: You don't, 01:08:06.520 --> 01:08:09.320 Scott: you don't want to redefine patterns because you just want to use the ones that 01:08:09.320 --> 01:08:09.620 Scott: are there, 01:08:09.700 --> 01:08:13.300 Scott: but then complain hypocritically about the ones that exist. 01:08:13.800 --> 01:08:14.040 Scott: All right, 01:08:14.380 --> 01:08:14.600 Scott: I'm done. 01:08:17.380 --> 01:08:17.460 Matt: What? 01:08:17.859 --> 01:08:19.560 Matt: I think that validates my thought. 01:08:20.380 --> 01:08:22.540 Matt: The web sucks and it's, 01:08:23.040 --> 01:08:25.839 Matt: and contributed to the web sucking is the fact that 01:08:25.839 --> 01:08:26.859 Matt: our specs like 01:08:26.859 --> 01:08:27.359 Matt: CSS and 01:08:27.460 --> 01:08:27.620 Matt: HTML. 01:08:27.819 --> 01:08:28.200 Scott: Oh my God. 01:08:28.400 --> 01:08:28.460 Scott: No, 01:08:28.560 --> 01:08:29.319 Scott: but you're a contributor. 01:08:29.339 --> 01:08:31.140 Scott: You don't want to make these changes. 01:08:31.600 --> 01:08:32.859 Scott: I don't want to bicker anymore. 01:08:33.120 --> 01:08:34.700 Scott: This is getting cut up. 01:08:36.020 --> 01:08:37.299 Dillon: We should just keep talking 01:08:37.430 --> 01:08:39.160 Dillon: and then fade the episode out at this point. 01:08:40.700 --> 01:08:41.100 Scott: Thus ends 01:08:41.100 --> 01:08:41.520 Scott: the episode 01:08:41.819 --> 01:08:42.500 Scott: of four hours. 01:08:42.660 --> 01:08:43.060 Matt: If you made 01:08:43.060 --> 01:08:43.480 Matt: it this far, 01:08:46.100 --> 01:08:47.319 Matt: thanks for listening to the podcast. 01:08:47.730 --> 01:08:49.440 Matt: You can tell that it's not a good thing 01:08:49.560 --> 01:08:51.200 Matt: for when we stretch out our recording sessions 01:08:51.350 --> 01:08:52.460 Matt: because we have so much to talk about. 01:08:53.060 --> 01:08:54.520 Matt: We need to schedule these more frequently probably. 01:08:56.160 --> 01:08:57.020 Matt: Feel free to share 01:08:57.540 --> 01:08:59.060 Matt: and share the episode with someone 01:08:59.240 --> 01:09:01.140 Matt: that you think should listen to it. 01:09:01.220 --> 01:09:02.160 Matt: That's how we get most of our listeners. 01:09:03.500 --> 01:09:05.859 Matt: Most of our seven listeners are because people share it. 01:09:07.600 --> 01:09:09.700 Matt: And yeah, feel free to reach out in the Discord, 01:09:10.240 --> 01:09:11.700 Matt: community Discord, or on Blue Sky 01:09:11.870 --> 01:09:14.640 Matt: if you have thoughts or hot takes on this episode 01:09:14.890 --> 01:09:17.500 Matt: or reasons why I'm wrong and Scott is right. 01:09:18.180 --> 01:09:18.839 Matt: Feel free to share them. 01:09:19.839 --> 01:09:22.720 Matt: Otherwise, we'll catch you maybe next month. 01:09:23.460 --> 01:09:24.620 Scott: Probably next week, right? 01:09:24.750 --> 01:09:26.960 Scott: But also feel free to pile on and tell me I'm wrong. 01:09:27.089 --> 01:09:27.740 Scott: I'm used to it. 01:09:29.160 --> 01:09:29.940 Scott: I'm a punching bag. 01:09:31.600 --> 01:09:32.420 Matt: Dillon's always right 01:09:33.240 --> 01:09:33.940 Scott: Dillon's got the 01:09:33.940 --> 01:09:34.779 Scott: spicy taste 01:09:36.279 --> 01:09:37.240 Dillon: They're getting spicier 01:09:38.259 --> 01:09:39.299 Dillon: I had a 01:09:39.779 --> 01:09:40.740 Dillon: spicy tikka masala 01:09:42.060 --> 01:09:43.759 Dillon: I went from mild to medium 01:09:43.839 --> 01:09:43.980 Dillon: this 01:09:43.980 --> 01:09:45.400 Dillon: week so I'm 01:09:45.400 --> 01:09:45.839 Dillon: spicing 01:09:45.839 --> 01:09:46.100 Dillon: it up 01:09:47.680 --> 01:09:49.799 Scott: Spicy as whole milk like you were saying earlier 01:09:52.180 --> 01:09:53.060 Dillon: Alright guys 01:09:55.100 --> 01:09:56.199 Scott: Have a good week