WEBVTT 00:00:12.040 --> 00:00:15.960 Scott: Welcome to the Bikeshed Podcast, where we talk about all things software engineering, 00:00:16.520 --> 00:00:21.260 Scott: our immaculate opinions, and conversations as real as an AI-generated girlfriend. 00:00:22.140 --> 00:00:27.480 Scott: I'm your co-host, UI aficionado, constant and consistent coffee consumer, 00:00:28.180 --> 00:00:30.320 Scott: and Golang Gremlin, Scott Kaye 00:00:31.120 --> 00:00:33.800 Scott: And joining me are my esteemed co-hosts, 00:00:34.280 --> 00:00:37.360 Scott: a man who's known for NPM package name squatting, 00:00:38.120 --> 00:00:40.300 Scott: the enforcer of pristine pull requests, 00:00:41.240 --> 00:00:44.220 Scott: and the most exquisite get commit messages, 00:00:45.140 --> 00:00:45.800 Scott: Matt Hamlin. 00:00:46.900 --> 00:00:47.840 Scott: And to my other side, 00:00:48.340 --> 00:00:49.800 Scott: a man you don't want to mess with 00:00:50.260 --> 00:00:51.560 Scott: because he's got a real kick to him, 00:00:52.300 --> 00:00:54.600 Scott: Dillon, spicy take curry. 00:00:55.839 --> 00:00:58.020 Scott: Dillon, what is our agenda today? 00:00:59.000 --> 00:00:59.860 Dillon: All right, today, Scott 00:00:59.860 --> 00:01:03.160 Dillon: and Matt, we're going to be getting into code review. 00:01:04.800 --> 00:01:11.080 Dillon: Not just code review, we're going to focus a bit more on how we create PRs and what makes 00:01:11.150 --> 00:01:14.900 Dillon: a good PR, and then also how do we review code? 00:01:16.000 --> 00:01:17.540 Dillon: What's the right way to review code? 00:01:18.500 --> 00:01:19.940 Dillon: So let's get into it. 00:01:20.520 --> 00:01:21.700 Dillon: Matt, why don't you kick us off? 00:01:22.960 --> 00:01:23.140 Matt: Yeah. 00:01:23.200 --> 00:01:28.880 Matt: um yeah first off uh i'm i'm freezing freezing outside to try to record this episode because 00:01:29.220 --> 00:01:36.320 Matt: apparently it's too much echo in my office but um let's let's see how this goes um yeah i kind of 00:01:36.520 --> 00:01:41.740 Matt: wanted us to talk a little bit more about like how do you approach creating prs i think like a lot of 00:01:41.820 --> 00:01:45.620 Matt: people maybe talk about reviewing and i think we can spend some time talking about reviewing prs but 00:01:46.200 --> 00:01:53.160 Matt: um i think really like to like set yourself up for success uh when getting prs reviewed 00:01:53.180 --> 00:01:54.700 Matt: you want to create a really great PR, right? 00:01:54.800 --> 00:01:58.360 Matt: Like you want to make it easy on the reviewers to understand the changes 00:02:00.720 --> 00:02:04.500 Matt: and be able to like make decisions around those changes that are, 00:02:05.200 --> 00:02:06.980 Matt: you know, like, or provide good feedback, right? 00:02:08.160 --> 00:02:11.560 Matt: So I think like that starts with like, how do you make a great PR? 00:02:11.620 --> 00:02:13.460 Matt: And I think sometimes it's like, what do you, 00:02:13.720 --> 00:02:16.360 Matt: sometimes it's like, what do you do before you open the PR? 00:02:16.820 --> 00:02:18.180 Matt: That makes it great, right? 00:02:19.340 --> 00:02:45.320 Matt: So I'm curious, I guess, like, before we maybe not necessarily talking about, like, highlights, but maybe talking about the workflow a little bit. And then we can go from there and see if there's any, like, sort of tips and tricks that you guys have to, to make a really good PR. Scott, I'm curious, like, how do you approach, you know, opening good PRs? Like, what's the what goes through your mind when you're like, you know, like, do you have a mental checklist of things that you want to do when you want to open a PR? 00:02:45.640 --> 00:02:51.980 Matt: or do you have any sort of like templated way that you do that, like open a PR? 00:02:53.480 --> 00:02:59.900 Scott: Yeah, I'd love for you to get back to your ideas on what you do before you make the PR. 00:03:00.190 --> 00:03:03.840 Scott: I have ideas of what I'll do during making the PR, 00:03:04.010 --> 00:03:09.220 Scott: but I want to start contextually that when I was more of a junior engineer, 00:03:09.320 --> 00:03:16.080 Scott: I didn't really consider this as much or take how serious this this can be. 00:03:16.540 --> 00:03:19.880 Scott: When you're isolated working on a problem, you just like, oh, here's my problem. 00:03:20.040 --> 00:03:22.840 Scott: Here's the answer. But problems become more complex. 00:03:23.680 --> 00:03:30.220 Scott: Even if you're still doing something small, we need to make sure we highlight to the person who might review it, 00:03:30.260 --> 00:03:32.820 Scott: has no context. How can we give them as much context as possible? 00:03:33.320 --> 00:03:37.160 Scott: What is the problem? I always actually write two headings these days. 00:03:37.300 --> 00:03:48.220 Scott: It's become kind of just the way I, two to three headings, the way I try to solve this is like I give context as a heading, like what is the problem here? 00:03:49.060 --> 00:03:50.280 Scott: And then I give the goal. 00:03:51.620 --> 00:03:54.640 Scott: And I say this is what I'm going to do to solve this problem. 00:03:55.460 --> 00:04:01.520 Scott: And then I have the screenshots video section that might be relevant to what I'm working on. 00:04:01.640 --> 00:04:04.920 Scott: Depends on if it's, you know, UI related, right? 00:04:05.540 --> 00:04:21.720 Scott: I also do a checklist. So as I'm building out this PR, I might, you know, I might be in a draft mode, but I want to check off all the things I do to get to from A to B, as well as I review the PR. 00:04:22.380 --> 00:04:24.500 Scott: I use Arc to pull up both tabs. 00:04:25.070 --> 00:04:26.300 Scott: So while I'm creating the body, 00:04:26.690 --> 00:04:29.300 Scott: I actually look at the PR and go through each file. 00:04:29.900 --> 00:04:32.320 Scott: And I notice, I note significant changes. 00:04:33.120 --> 00:04:35.860 Scott: Or if it's insignificant, I might just not. 00:04:36.040 --> 00:04:39.020 Scott: But I create bullet points based off those. 00:04:39.350 --> 00:04:41.640 Scott: And then I look for anything I may have missed, 00:04:42.130 --> 00:04:46.400 Scott: whether that's I didn't pull out a comment or whatever. 00:04:46.860 --> 00:04:51.260 Scott: And I'll add those remaining problems or edge cases or gotchas. 00:04:52.160 --> 00:04:56.580 Scott: as line items on my checklist 00:04:57.320 --> 00:04:58.920 Scott: so that I can go back and do it 00:04:58.920 --> 00:04:59.700 Scott: and then check it off. 00:04:59.740 --> 00:05:03.800 Scott: But I essentially try to do as much as I can 00:05:03.900 --> 00:05:06.300 Scott: to inform the person who's going to look at it. 00:05:07.300 --> 00:05:09.180 Scott: And yes, this is even at startups I do this. 00:05:09.300 --> 00:05:10.660 Scott: This is a really good practice 00:05:11.340 --> 00:05:13.580 Scott: because it even helps me to jump right back into it. 00:05:14.920 --> 00:05:16.620 Scott: But I like to feel like 00:05:16.720 --> 00:05:18.700 Scott: I have a cohesive understanding of what I've done. 00:05:19.020 --> 00:05:20.780 Scott: I can explain it to another user 00:05:21.280 --> 00:05:24.820 Scott: and if anyone ever needed to look at this PR for any reason, 00:05:25.170 --> 00:05:28.180 Scott: they have all of this context and it's in good standing. 00:05:28.740 --> 00:05:30.120 Scott: Matt, I know you had a comment on this. 00:05:31.010 --> 00:05:31.360 Scott: Go ahead. 00:05:31.500 --> 00:05:35.680 Matt: I think one of the earlier points you said really resonates with me 00:05:35.680 --> 00:05:39.680 Matt: and this is something I was thinking about within the past week or two. 00:05:40.740 --> 00:05:43.060 Matt: You sort of called out in your description, 00:05:43.360 --> 00:05:45.100 Matt: you highlight the problem to be solved 00:05:45.280 --> 00:05:47.060 Matt: and then you highlight your approach or your solution. 00:05:47.700 --> 00:05:48.720 Matt: I think that's really key. 00:05:50.200 --> 00:05:57.800 Matt: know i think maybe too often you know maybe i'll look at a pr and it's like uh and uh it's 00:05:59.919 --> 00:06:06.420 Matt: um i'll look at a pr and and it's uh it's just like a a like a description of the solution 00:06:07.280 --> 00:06:10.920 Matt: without much context on the problem that it's solving right and so it's like very 00:06:12.960 --> 00:06:16.840 Matt: maybe i don't know it's hard to dig into and understand like what were the trade-offs made 00:06:17.360 --> 00:06:20.120 Matt: it's like okay the person presented a solution but 00:06:20.980 --> 00:06:24.200 Matt: I don't really know what the problem they're solving. Maybe it's solving the right problem. 00:06:24.590 --> 00:06:28.460 Matt: Maybe it's like solving a different problem. And it's hard 00:06:28.850 --> 00:06:32.480 Matt: to know that with just looking at the PR. So sometimes it requires the 00:06:32.680 --> 00:06:36.420 Matt: reviewer and I know we're kind of getting into reviewing PRs but it's like 00:06:36.900 --> 00:06:40.160 Matt: if you don't provide that context as part of your description then it 00:06:40.900 --> 00:06:44.580 Matt: makes it maybe more difficult or more work on the reviewer to do that work 00:06:44.600 --> 00:06:46.160 Matt: to understand what it's trying to do. 00:06:48.220 --> 00:06:49.800 Matt: Yeah, Scott, I don't know if you had 00:06:49.800 --> 00:06:50.680 Matt: thoughts there. 00:06:51.440 --> 00:06:52.620 Scott: Great point you're making. 00:06:53.160 --> 00:06:56.440 Scott: I left this out, but I do try to get as nuanced 00:06:56.600 --> 00:06:58.440 Scott: to say this is the solution I chose. 00:06:58.780 --> 00:07:00.140 Scott: And if there were other failed solutions 00:07:00.350 --> 00:07:02.880 Scott: or solutions that just didn't seem like they fit that problem, 00:07:03.580 --> 00:07:04.420 Scott: I note that. 00:07:04.610 --> 00:07:06.700 Scott: I try to explain why this is the one 00:07:06.860 --> 00:07:08.320 Scott: that has been decided upon 00:07:09.820 --> 00:07:12.160 Scott: and where other ones seem to go wrong 00:07:12.340 --> 00:07:14.200 Scott: and why we came to this conclusion. 00:07:14.300 --> 00:07:18.720 Scott: to just try to get as much out there as possible so a reviewer doesn't hit me with like well have 00:07:18.720 --> 00:07:24.680 Scott: you tried this or this um let them know you know we've been here we've done that this is why we've 00:07:24.780 --> 00:07:27.420 Scott: landed where we are and just strengthens your argument 00:07:27.420 --> 00:07:30.580 Dillon: yeah one thing i wanted to point out is 00:07:31.200 --> 00:07:39.779 Dillon: um another thing with good prs is um the scope of the pr needs to be like isolated to a single 00:07:39.800 --> 00:07:44.980 Dillon: problem. I've seen this problem. I've created this problem in my PRs where I start to like change 00:07:45.130 --> 00:07:49.200 Dillon: random things that have nothing to do with each other. And I've seen other people do it. And it's 00:07:49.400 --> 00:07:55.140 Dillon: usually a bad practice because one, if you deploy this code and something goes wrong, you don't know 00:07:55.860 --> 00:08:00.600 Dillon: where it went wrong. So if it's isolated to a specific feature, it's very obvious. I can just 00:08:00.600 --> 00:08:02.040 Dillon: roll this back. It's only affecting that one thing. 00:08:02.350 --> 00:08:03.260 Dillon: I just want to point that out. 00:08:05.080 --> 00:08:09.760 Matt: Yeah, a hundred percent. We have a HubSpot. We have like this like pretty big template that we call 00:08:09.780 --> 00:08:15.640 Matt: brave i think and it's an acronym i you know blanking on what it stands for but um like one 00:08:15.640 --> 00:08:21.780 Matt: of the key aspects of it is like outline what is the rollback procedure of like if you release this 00:08:21.840 --> 00:08:27.620 Matt: change like what is it what what do you need to do in order to roll it back safely um which i think 00:08:27.620 --> 00:08:32.039 Matt: is really like a good aspect to think about when you're making a change and like you know i think 00:08:32.140 --> 00:08:36.419 Matt: really that speaks to like you know simplifying your change or trying to do as few changes as 00:08:36.440 --> 00:08:41.280 Matt: possible right because that makes it generally speaking makes it easier to roll back um so yeah 00:08:41.380 --> 00:08:46.100 Matt: 100 percent agree with that i think that's like a really good uh really good perspective i 00:08:46.100 --> 00:08:46.840 Scott: I think that's 00:08:46.960 --> 00:08:53.460 Scott: really interesting i've never heard of that um i i feel like in my process though like i i try to 00:08:53.510 --> 00:09:01.040 Scott: think about how i might roll back ahead of time um and and not make something complex i feel like 00:09:01.040 --> 00:09:05.699 Scott: that should be only applicable though to like large scale changes that might require multiple 00:09:05.720 --> 00:09:13.060 Scott: downstream services to change. I don't know if necessarily every single change should be that 00:09:13.160 --> 00:09:18.460 Scott: verbose. Rather, there should be an overarching understanding of how you roll back a maybe 00:09:18.960 --> 00:09:24.080 Scott: smaller change. That's just a quick hot take on that. And maybe within your template, 00:09:26.160 --> 00:09:31.480 Scott: it says like a standard how you would roll back a normal change. But when things are more 00:09:31.480 --> 00:09:37.740 Scott: distributed in larger systems i can see why you start to need to know that on on larger things 00:09:37.790 --> 00:09:42.200 Scott: but just kind of going back to the principle dylan was calling out which we've all been there it's 00:09:42.300 --> 00:09:46.700 Scott: it's very easy to work on like 10 problems at once and try to solve a whole bunch of stuff but if you 00:09:46.780 --> 00:09:52.260 Scott: are doing things modularly and smaller um that you would need like a more defined project level 00:09:52.960 --> 00:09:57.720 Scott: way of rolling things back uh but yeah i see i see value in it i'm not knocking it it's just 00:09:58.220 --> 00:10:01.900 Scott: it starts to argue like how simple is your product how distributed is your product 00:10:02.370 --> 00:10:05.320 Scott: uh how many layers are there in which to roll back 00:10:05.320 --> 00:10:08.600 Matt: yeah and i think it or at least the way i 00:10:08.820 --> 00:10:14.100 Matt: interpret our implementation of it is like more as a forcing function to like not try to bulk 00:10:14.320 --> 00:10:19.540 Matt: changes together but it's also like you know it's useful to to recommend or you know um 00:10:20.460 --> 00:10:26.439 Matt: ensure that the the the contributor knows that process to roll those things back um 00:10:27.259 --> 00:10:32.320 Matt: so i think like right like if you're releasing a bug fix but then you also include a you know 00:10:32.560 --> 00:10:37.000 Matt: partial new feature or something like that in it it's like rolling back means you're not only 00:10:37.160 --> 00:10:40.420 Matt: rolling back the bug fix but you're also rolling or you know you're not rolling back the feature 00:10:40.580 --> 00:10:44.000 Matt: you're rolling back the bug fix as well which is unfortunate so it's like maybe that's just a 00:10:44.120 --> 00:10:49.020 Matt: forcing function to make the right choice there we're kind of with like you know maybe lucy's 00:10:49.020 --> 00:10:54.200 Matt: touching on it but like templates for prs i think is an interesting thought like we use them at 00:10:54.200 --> 00:11:00.560 Matt: spot but we don't like overly use them in the sense of like most people go in and delete the 00:11:00.700 --> 00:11:06.020 Matt: pre-filled template and then fill it out with more things i think my take is usually just like keep 00:11:06.020 --> 00:11:12.840 Matt: it simple right like and and i i personally like the like context and then details sort of template 00:11:13.000 --> 00:11:16.500 Matt: like just two headings like one is context of like what why is this change being made and then the 00:11:16.580 --> 00:11:20.600 Matt: second one is like how is this change being made um but i can see like other sections being added 00:11:20.620 --> 00:11:21.120 Matt: there as well. 00:11:23.600 --> 00:11:24.500 Matt: One popular one 00:11:24.540 --> 00:11:25.700 Matt: that I've seen inside HubSpot 00:11:26.540 --> 00:11:28.400 Matt: so far is alternatives considered 00:11:28.780 --> 00:11:30.500 Matt: as a subheading under the details 00:11:30.820 --> 00:11:32.500 Matt: and outlines like, okay, we thought about 00:11:32.670 --> 00:11:33.980 Matt: three different approaches for solving this problem. 00:11:34.600 --> 00:11:36.500 Matt: We picked this path. And it's like, why do we pick 00:11:36.580 --> 00:11:38.380 Matt: this path? Why are the other two ones ignored 00:11:38.900 --> 00:11:39.960 Matt: or not chosen? 00:11:41.620 --> 00:11:42.340 Matt: I don't know. Yeah, I think 00:11:42.580 --> 00:11:44.140 Matt: templates sometimes get overused, but 00:11:45.560 --> 00:11:45.620 Matt: yeah. 00:11:46.880 --> 00:11:48.540 Dillon: Yeah, Matt, I just wanted to touch on the 00:11:48.620 --> 00:11:49.160 Dillon: templates thing. 00:11:50.360 --> 00:11:59.320 Dillon: One thing I've seen at my last job and my current job is that templates sort of just fill up space because people don't really use them. 00:11:59.780 --> 00:12:00.800 Dillon: I don't really use them either. 00:12:01.300 --> 00:12:07.960 Dillon: I just like fill out the beginning of the description with context and everything that the PR accomplishes. 00:12:08.600 --> 00:12:12.700 Dillon: And then I'll like add additional context if it's needed, depending on the complexity of the PR. 00:12:13.460 --> 00:12:16.280 Dillon: So like I'll give an example of like a recent PR. 00:12:16.290 --> 00:12:19.760 Dillon: I was like, it was pretty complex because I'm changing a lot of things. 00:12:19.880 --> 00:12:22.580 Dillon: I'm afraid that it could potentially cause an outage. 00:12:23.000 --> 00:12:25.160 Dillon: So there's like a rollout plan in the PR, 00:12:25.640 --> 00:12:28.680 Dillon: but not every PR is going to have that level of description 00:12:28.940 --> 00:12:31.660 Dillon: or like amount of information. 00:12:32.160 --> 00:12:33.440 Dillon: Sometimes it's just a lot simpler. 00:12:34.080 --> 00:12:34.640 Matt: Yeah, yeah. 00:12:34.720 --> 00:12:37.480 Matt: I think you were kind of hinting at this. 00:12:37.580 --> 00:12:40.820 Matt: I think for large templates in PRs, 00:12:40.820 --> 00:12:41.880 Matt: I think sometimes you like, 00:12:42.660 --> 00:12:44.300 Matt: I don't know, at least as a reviewer, 00:12:44.300 --> 00:12:45.360 Matt: the more you see it, 00:12:45.360 --> 00:12:47.120 Matt: the more you're just going to like skim past sections 00:12:47.540 --> 00:12:49.320 Matt: just because it's like there. 00:12:49.720 --> 00:12:54.560 Matt: it's in every PR so it's like hard to you know I don't know if I feel like that maybe makes it 00:12:54.740 --> 00:13:01.180 Matt: worse to uh to like try to manage like what um you know what are the details that I need to like 00:13:01.240 --> 00:13:07.060 Matt: key into when I'm reviewing a PR which maybe we can get to a little bit later um I think Scott 00:13:07.320 --> 00:13:12.140 Matt: like I guess like you know maybe sort of pivoting a little bit um Scott you talked a little bit about 00:13:12.680 --> 00:13:17.540 Matt: potentially like kind of self-reviewing as you write your description um I'm curious like do you 00:13:17.540 --> 00:13:24.880 Matt: also like something i picked up um in my career is like actually going through and adding comments 00:13:25.050 --> 00:13:29.840 Matt: in line on the pr myself like on my own pr um before i like open it up for review for others 00:13:30.480 --> 00:13:33.920 Matt: like curious if scott if you do that or or Dillon if you do that as well 00:13:33.920 --> 00:13:36.120 Scott: I have some thoughts on templates 00:13:36.360 --> 00:13:42.899 Scott: but i can get back to it if time allows uh but that's a good question sometimes i do uh sometimes 00:13:42.920 --> 00:13:47.540 Scott: if there's like minor bugs i'll just submit them but it depends depending on what it is i often 00:13:48.580 --> 00:13:55.260 Scott: first i didn't call this out but i often start to build my pr in draft mode when i do this and then 00:13:55.440 --> 00:14:02.340 Scott: look at it and kind of try to like reason with how does it look um and then from there i just 00:14:02.720 --> 00:14:08.579 Scott: make edits locally because it's faster but yeah if it's like a minor thing like spelling fix i'll 00:14:08.600 --> 00:14:16.680 Scott: just literally fix them in the pr and just crank them out um but i tend to use my editor since it's 00:14:16.800 --> 00:14:20.080 Scott: not that much further away and it's just preference 00:14:20.080 --> 00:14:24.420 Matt: yeah i think yeah like you know i the suggestions 00:14:24.660 --> 00:14:29.700 Matt: featuring github was like i think a really cool feature that we got maybe a little bit later on 00:14:29.850 --> 00:14:35.779 Matt: at wayfair but um i like i've used that a little bit but i've also like found it really useful just 00:14:35.800 --> 00:14:39.820 Matt: like look at my draft PR and say like oh like I forgot this edge case in this you know bit of 00:14:39.920 --> 00:14:44.980 Matt: logic and I add a comment to it and then I like revisit it in my in my editor you know either 00:14:45.340 --> 00:14:52.620 Matt: right then or later just to like kind of provide like a more I don't know separate workflow of like 00:14:53.100 --> 00:14:55.280 Matt: reviewing the changes itself and then going in 00:14:55.280 --> 00:14:56.000 Matt: editing after 00:14:56.000 --> 00:14:57.560 Matt: just to like get a comprehensive 00:14:57.780 --> 00:14:59.960 Matt: picture of it 00:14:57.780 --> 00:14:59.960 Scott: I guess it's just worth saying 00:14:59.960 --> 00:15:01.999 Scott: that like part of the reason I rely on my editor is 00:15:02.020 --> 00:15:08.640 Scott: Like if it's a code change, I don't even want to have to think about spacing or formatting. 00:15:08.980 --> 00:15:11.560 Scott: And, you know, the code editor is always going to do that for you. 00:15:11.660 --> 00:15:19.960 Scott: So if it's more than just like a simple one line couple character change, I tend to rely on my editor to just do auto formatting for me. 00:15:20.060 --> 00:15:22.000 Scott: And I don't have to think about it or move it around. 00:15:23.220 --> 00:15:27.460 Scott: When we get into PR reviewing, I love the suggestion feature and we can come back to that. 00:15:27.780 --> 00:15:32.400 Dillon: You guys are going to tell me what the suggestion feature is because it's just not, I don't know what you're talking about. 00:15:33.420 --> 00:15:39.920 Dillon: So, but also I just wanted to touch on the fact that I usually get my PRs about 90% of the way done. 00:15:40.280 --> 00:15:45.640 Dillon: And then I create a draft PR and then I sort of just like work my way up to the final description. 00:15:46.560 --> 00:15:48.320 Dillon: But also I'll do like a self-review of my code. 00:15:48.380 --> 00:15:54.840 Dillon: I feel like seeing my code in GitHub and then like putting myself in the reviewer's shoes and going through the code. 00:15:54.960 --> 00:15:58.100 Dillon: It's just easier to look at the code that way versus in my editor for whatever reason. 00:15:58.320 --> 00:16:00.900 Dillon: Maybe it's just it feels like I'm reviewing it. 00:16:00.900 --> 00:16:05.020 Dillon: I can like suss out a lot of issues before anyone gets to that, to my code. 00:16:06.280 --> 00:16:13.480 Dillon: Another thing that's probably going to be like a weird take is or just a weird part of my process is I usually don't write tests. 00:16:14.780 --> 00:16:22.740 Dillon: Until I feel like I've found like a solid solution and gotten some feedback, like a little bit of feedback. 00:16:23.840 --> 00:16:25.200 Dillon: I'm not saying this is a good idea. 00:16:25.980 --> 00:16:26.700 Dillon: I'm curious. 00:16:28.040 --> 00:16:29.520 Dillon: Maybe we don't have to go straight into it right now. 00:16:29.590 --> 00:16:30.480 Dillon: Maybe it's like we save it. 00:16:30.660 --> 00:16:32.820 Dillon: But how do you guys think about that? 00:16:33.560 --> 00:16:35.240 Matt: Yeah, usually I'm not test-driven development. 00:16:35.580 --> 00:16:37.640 Matt: I'm not usually in that bucket of people. 00:16:38.180 --> 00:16:40.940 Matt: But sometimes when the change feels like it's straightforward enough, 00:16:41.240 --> 00:16:43.580 Matt: usually I'll write a failing test case, commit that, 00:16:44.190 --> 00:16:48.380 Matt: and then make the change, and then ensure the test pass. 00:16:48.540 --> 00:16:50.000 Matt: And that way, so I can push up my PR. 00:16:50.070 --> 00:16:51.280 Matt: It's like, okay, I have a test. 00:16:51.720 --> 00:16:52.820 Matt: It was failing on one commit. 00:16:53.220 --> 00:16:57.780 Matt: I push up the fix and then like, you know, the status on the CI is like goes green or whatever. 00:16:59.100 --> 00:17:01.140 Matt: Usually like I don't do that for every change, right? 00:17:01.560 --> 00:17:05.120 Matt: That's usually like very specific or focused changes. 00:17:06.699 --> 00:17:12.660 Matt: But usually I find it like useful to like outline the tests in a separate commit just to make it easier to understand. 00:17:13.199 --> 00:17:16.780 Matt: Like it may be like, I don't know very many reviewers that do review commit by commit, 00:17:16.980 --> 00:17:21.959 Matt: but sometimes it can be useful to just like look at a commit of just tests and see like, okay, yeah, 00:17:22.120 --> 00:17:24.079 Matt: They understand the behavior of the expected change 00:17:25.260 --> 00:17:27.880 Matt: and then can understand how is the change actually implemented 00:17:28.060 --> 00:17:29.780 Matt: itself as a separate commit. 00:17:31.320 --> 00:17:35.500 Matt: And then in terms of suggestions, it's the comment feature. 00:17:36.000 --> 00:17:37.780 Matt: Like when you comment on PR, sometimes 00:17:38.360 --> 00:17:39.140 Matt: GitHub will show a little-- 00:17:39.370 --> 00:17:40.660 Matt: I don't know what the icon is, but it's 00:17:41.240 --> 00:17:43.460 Matt: I think it's three lines and a pencil maybe or something. 00:17:43.580 --> 00:17:45.780 Matt: You can click that and it creates a markdown code fence 00:17:46.900 --> 00:17:48.340 Matt: that's prefixed for the suggestion 00:17:48.530 --> 00:17:52.080 Matt: and allows you to basically suggest a change in line 00:17:52.100 --> 00:17:55.860 Matt: on that comment maybe i'm doing poorly describe that i don't know scott if you can describe it 00:17:56.040 --> 00:17:56.540 Matt: better than i can 00:17:56.540 --> 00:17:58.620 Scott: i was impressed 00:17:58.620 --> 00:17:59.020 Scott: that you 00:17:59.020 --> 00:18:01.360 Scott: knew the icon i don't i don't know that but essentially 00:18:01.700 --> 00:18:08.380 Scott: you can click on a line or or highlight a series of lines and it pre-fills like what the code 00:18:08.480 --> 00:18:13.360 Scott: that's there and then you can edit that code and give them a comment suggestion so they can easily 00:18:13.620 --> 00:18:15.340 Scott: change the code is what matt's getting at 00:18:15.340 --> 00:18:19.880 Dillon: i do i i know this feature i didn't i know this feature 00:18:19.900 --> 00:18:20.700 Dillon: I just didn't know what it was called. 00:18:20.840 --> 00:18:20.940 Dillon: Yeah, 00:18:21.130 --> 00:18:22.460 Scott: I do want to recap a few things. 00:18:22.510 --> 00:18:32.460 Scott: So it's like, interestingly, back to templates just quickly is we all kind of align and maybe I'm concluding this because we all kind of work together. 00:18:32.700 --> 00:18:33.500 Scott: But templates minimal. 00:18:33.720 --> 00:18:37.940 Scott: We all like do this context or goals slash details kind of thing. 00:18:39.340 --> 00:18:42.780 Scott: We do deviate a little bit in some of the way we think about things. 00:18:43.720 --> 00:18:47.920 Scott: Dillon and I both at least use draft PRs and kind of review ourselves. 00:18:48.600 --> 00:18:50.120 Scott: Dillon said about 90% of the way. 00:18:50.250 --> 00:18:54.120 Scott: I arbitrarily probably around the same, maybe a little bit more. 00:18:56.420 --> 00:18:59.800 Scott: And tests, I think we deviate a little bit more here. 00:19:00.040 --> 00:19:02.920 Scott: I'm a little bit still with Dillon where it's like I might add it later. 00:19:03.180 --> 00:19:03.840 Scott: It's really dependent. 00:19:04.360 --> 00:19:06.840 Scott: Matt will look for opportunities to add it first. 00:19:07.360 --> 00:19:13.000 Scott: I usually need to wrap my head around what is the best approach. 00:19:14.600 --> 00:19:21.340 Scott: Not often. I feel like not as straightforward for at least the majority of the things I do most often. 00:19:21.780 --> 00:19:25.160 Scott: And if it is, I feel like it's usually trivial of a problem. 00:19:25.380 --> 00:19:33.840 Scott: And maybe at a startup, at least where I've been in the last year, a test is like we don't we have we only have so much time to make this product make money. 00:19:34.040 --> 00:19:39.800 Scott: So let's forego really, really simple tests at a larger scale company. 00:19:39.960 --> 00:19:42.520 Scott: I might be thinking like, oh, let me just crank this test. 00:19:43.080 --> 00:19:48.260 Scott: I mean, I'm trying to put my decade of corporate time hat back on. 00:19:48.350 --> 00:19:49.460 Scott: And yeah, that sounds right. 00:19:49.620 --> 00:20:01.620 Scott: But so there's a lot of variability between who you're working for, what you're working on, what it is that needs to go out and how fast it needs to impact things. 00:20:02.000 --> 00:20:03.200 Scott: Is it a POC? 00:20:03.230 --> 00:20:04.780 Scott: Do you need to prove viability on 00:20:04.780 --> 00:20:05.880 Scott: what you're working on? 00:20:06.680 --> 00:20:06.960 Scott: I 00:20:06.960 --> 00:20:07.980 Scott: think both of you have thoughts. 00:20:08.070 --> 00:20:08.820 Scott: You can fight it out. 00:20:09.620 --> 00:20:10.540 Matt: Yeah, I absolutely agree. 00:20:10.780 --> 00:20:14.980 Matt: I think it completely depends on what pressure you're under, 00:20:15.740 --> 00:20:16.980 Matt: what is the state of the code base, 00:20:17.580 --> 00:20:18.920 Matt: what is the state of your testing framework. 00:20:19.920 --> 00:20:22.140 Matt: If I'm working on a project that basically has no test setup 00:20:22.480 --> 00:20:24.820 Matt: or doesn't have the ability to write tests very easily, 00:20:25.060 --> 00:20:28.420 Matt: then it's like I'm not going to spend the time in a PR 00:20:28.620 --> 00:20:30.580 Matt: that's unrelated to writing tests or adding tests 00:20:31.240 --> 00:20:32.720 Matt: to actually put in that effort, 00:20:33.320 --> 00:20:34.340 Matt: which is maybe a little bit unfortunate, 00:20:34.460 --> 00:20:35.479 Matt: but I think it's more so like, 00:20:36.360 --> 00:20:38.160 Matt: oh, I'll revisit that in a future PR 00:20:38.240 --> 00:20:40.320 Matt: to stand up the testing infrastructure if needed. 00:20:40.940 --> 00:20:43.020 Matt: in order to allow us to write tests more easily. 00:20:44.960 --> 00:20:46.120 Matt: Yeah, so I 100% agree. 00:20:46.960 --> 00:20:49.240 Matt: And maybe we should do an episode on testing. 00:20:50.660 --> 00:20:52.840 Matt: I think we have some interesting thoughts there. 00:20:53.520 --> 00:20:56.600 Matt: Scott, you worked on a good project that we found out 00:20:57.000 --> 00:20:57.780 Matt: as we were working on it, 00:20:57.980 --> 00:21:00.320 Matt: like, oh, actually, we need to spend time on tests first 00:21:00.480 --> 00:21:01.600 Matt: and then dig into it. 00:21:01.700 --> 00:21:03.400 Matt: But maybe we'll save that for our testing episode. 00:21:05.240 --> 00:21:06.960 Dillon: Yeah, I just wanted to add some more context 00:21:07.140 --> 00:21:10.300 Dillon: to why I tend to save tests till the end. 00:21:10.880 --> 00:21:12.900 Dillon: I don't actually want to do that 00:21:13.660 --> 00:21:15.120 Dillon: I'd prefer to just write my tests 00:21:16.340 --> 00:21:18.340 Dillon: but writing tests takes a long time 00:21:19.300 --> 00:21:21.140 Dillon: sometimes it takes longer than writing the code 00:21:23.720 --> 00:21:26.680 Dillon: and if there's any sort of major change 00:21:27.100 --> 00:21:28.180 Dillon: that comes from feedback 00:21:28.300 --> 00:21:30.780 Dillon: or something you just notice later on as you iterate 00:21:32.980 --> 00:21:35.180 Dillon: you end up needing to rip out your tests 00:21:35.220 --> 00:21:36.419 Dillon: and rewrite them sometimes 00:21:36.440 --> 00:21:41.420 Dillon: like if the code changes drastically like your tests are just useless and it's like 00:21:42.180 --> 00:21:46.160 Dillon: it just feels bad at the end to just be like oh i just wrote all those tests for nothing 00:21:46.780 --> 00:21:51.780 Dillon: sort of maybe not for nothing but it's a lot it feels like a lot of wasted time so i feel like 00:21:51.840 --> 00:21:54.160 Dillon: i've been burned by that in the past oh 00:21:54.160 --> 00:21:58.340 Matt: yeah 100 percent i think um the another thing that like and maybe 00:21:58.480 --> 00:22:02.280 Matt: this is kind of like what reiterating what you were saying but it's like sometimes you're maybe 00:22:02.480 --> 00:22:06.400 Matt: unsure in the approach that you're taking right like i was talking about kind of like alternative 00:22:06.400 --> 00:22:11.180 Matt: approaches in the PR. It's like, you know, maybe you go down path A, right? And you feel good about 00:22:11.340 --> 00:22:15.240 Matt: path A. You write some tests for path A. And then the reviewer comes along, you know, maybe it's like 00:22:15.300 --> 00:22:20.460 Matt: a staff engineer, principal engineer comes along and says, no, actually path C is better. Like, 00:22:21.320 --> 00:22:26.320 Matt: ignore path A. We should go down path C. And now you've like, you know, maybe the way that you've 00:22:26.400 --> 00:22:30.660 Matt: written your tests is very specific to the path you've chosen. And I'm sure there's someone arguing 00:22:30.750 --> 00:22:34.760 Matt: in the stand saying, you know, you should write tests in a way that doesn't matter with the 00:22:34.780 --> 00:22:39.500 Matt: implementation approach you take but um but yeah 100 like i've fallen into that trap before where 00:22:39.540 --> 00:22:43.700 Matt: it's like i was putting a lot of effort on a specific approach write tests for it and then 00:22:43.840 --> 00:22:47.320 Matt: someone comes along he's like actually there's a better path and it's like okay yeah i agree like 00:22:47.420 --> 00:22:51.120 Matt: there's a better path but now i have to like you know throw away it's like the sunk cost fallacy 00:22:51.210 --> 00:22:55.520 Matt: of testing right throw away the tests i wrote and approach and go down the other path 00:22:58.400 --> 00:22:58.920 Scott: yeah this 00:22:58.920 --> 00:23:00.820 Scott: is like i 00:23:00.820 --> 00:23:03.400 Scott: feel like my constant argument of the great it depends 00:23:05.400 --> 00:23:06.280 Scott: situation solution. 00:23:06.560 --> 00:23:08.600 Scott: It is great to actually, I agree with Dillon, 00:23:08.650 --> 00:23:10.440 Scott: it's great to write tests first in some cases. 00:23:11.820 --> 00:23:14.140 Scott: At one point I wanted to make is often now 00:23:14.800 --> 00:23:16.940 Scott: everyone wants tests to be written by AI. 00:23:17.480 --> 00:23:19.260 Scott: A, that's not guaranteed to be the best test, 00:23:19.480 --> 00:23:21.600 Scott: but B, that's like an after-the-fact thing, right? 00:23:21.740 --> 00:23:23.060 Scott: You have to write the code. 00:23:23.370 --> 00:23:25.540 Scott: So it's hard to do test-driven development, 00:23:26.220 --> 00:23:29.060 Scott: but test-driven development does make sense in some scenarios. 00:23:29.320 --> 00:23:30.860 Scott: Sometimes you just have no clue 00:23:33.139 --> 00:23:38.720 Scott: what the solve is, but you know the problem and you know how to replicate the problem in a test 00:23:38.940 --> 00:23:43.080 Scott: environment that can get you to the right place. And one of the great things that we all did when 00:23:43.080 --> 00:23:48.020 Scott: we worked together was when we found a bug that we didn't want it to occur again, or we were really 00:23:48.200 --> 00:23:53.299 Scott: unsure about how to get code from A to B, we would write those tests first. Those are like some 00:23:53.320 --> 00:24:00.660 Scott: scenarios where testing really was a good strength, but you need to use it strategically. 00:24:01.190 --> 00:24:06.020 Scott: Sometimes if you're changing the color from red to green, sometimes you don't need to 00:24:06.160 --> 00:24:06.460 Scott: test it. 00:24:06.470 --> 00:24:11.260 Scott: Sure, if you have a great visual regression testing framework that can test that for you, 00:24:11.280 --> 00:24:11.760 Scott: that's wonderful. 00:24:12.040 --> 00:24:15.560 Scott: But it's really situational on what you're doing. 00:24:16.300 --> 00:24:21.500 Scott: It's value to the bottom line of the application you're building or your team and the stakes 00:24:21.520 --> 00:24:24.200 Scott: that that team owns and the feature or product that you're driving. 00:24:25.140 --> 00:24:27.620 Scott: Just testing everything, like Dillon says, 00:24:28.020 --> 00:24:31.380 Scott: once you change stuff, it's just adding pain and overhead. 00:24:32.120 --> 00:24:33.540 Scott: We want to test the features. 00:24:34.280 --> 00:24:35.940 Scott: I say this actually at startups all the time. 00:24:36.060 --> 00:24:39.340 Scott: We want to make sure we're testing the features that make us the most money 00:24:39.370 --> 00:24:41.480 Scott: or keep our product running the best, 00:24:42.160 --> 00:24:44.240 Scott: not just everything for the sake of doing it. 00:24:45.160 --> 00:24:48.420 Matt: Yeah, I think we have a lot of thoughts on testing. 00:24:48.760 --> 00:24:51.340 Matt: and maybe we save some of them 00:24:51.420 --> 00:24:53.560 Matt: and revisit some of them in another episode. 00:24:53.700 --> 00:24:57.160 Matt: I think getting a little bit back to sort of PR, 00:24:57.460 --> 00:24:58.620 Matt: maybe templates or PR description, 00:24:59.420 --> 00:25:01.400 Matt: Scott, you talked a little bit about screenshots 00:25:01.800 --> 00:25:02.660 Matt: and screen recordings. 00:25:03.400 --> 00:25:04.460 Matt: I think that's something like really, 00:25:05.340 --> 00:25:08.200 Matt: like I really enjoy when I review another PR also 00:25:08.360 --> 00:25:10.040 Matt: is like a great way to contextualize the change. 00:25:11.180 --> 00:25:12.300 Matt: Something I've seen in the past, right? 00:25:12.440 --> 00:25:15.820 Matt: It's like, if you have a really good preview deploy setup, 00:25:17.060 --> 00:25:19.540 Matt: talking about front-end changes, but also back-end changes. 00:25:19.750 --> 00:25:21.820 Matt: If you can deploy your changes in a branch 00:25:22.040 --> 00:25:23.660 Matt: and allow someone to interact with it 00:25:23.830 --> 00:25:25.420 Matt: in the same way they interact with production, 00:25:25.920 --> 00:25:27.400 Matt: I think that also offers a really great way 00:25:28.740 --> 00:25:30.660 Matt: to provide more context to the reviewer. 00:25:32.440 --> 00:25:33.740 Matt: Yeah, I don't know if you guys have further thoughts 00:25:33.880 --> 00:25:35.860 Matt: on screenshots, screen recordings, preview deploys, 00:25:36.100 --> 00:25:36.620 Matt: anything like that. 00:25:36.750 --> 00:25:38.680 Matt: I think a lot of that makes a great PR. 00:25:39.520 --> 00:25:40.060 Scott: I agree. 00:25:40.340 --> 00:25:41.440 Scott: It adds visual polish, 00:25:41.650 --> 00:25:44.920 Scott: and for people who are visual learners, 00:25:45.420 --> 00:25:47.200 Scott: we'll be able to like catch on faster. 00:25:47.650 --> 00:25:50.140 Scott: There are a few methods that I like. 00:25:50.550 --> 00:25:54.760 Scott: A lot of people use just like a traditional Mac screenshots because we all use 00:25:54.960 --> 00:25:55.260 Scott: Macs. 00:25:55.880 --> 00:25:58.040 Scott: But like Mac screen recordings can be great. 00:25:58.400 --> 00:25:58.500 Scott: I, 00:25:58.940 --> 00:25:59.760 Scott: I try to, 00:25:59.920 --> 00:26:02.720 Scott: if I'm doing something that interacts with multiple elements, 00:26:03.400 --> 00:26:04.820 Scott: use videos if I can. 00:26:05.300 --> 00:26:06.800 Scott: And another great feature, 00:26:07.320 --> 00:26:13.140 Scott: which with some UI can be buggy is capture full size screenshot within your 00:26:13.200 --> 00:26:13.520 Scott: dev tools. 00:26:14.320 --> 00:26:16.820 Scott: A lot of people don't know, maybe know about this or use it, 00:26:17.220 --> 00:26:19.840 Scott: but like the screenshotting in your dev tools is super powerful. 00:26:19.920 --> 00:26:20.920 Scott: I highly recommend it. 00:26:21.560 --> 00:26:23.420 Matt: For the longest time I was using Dropbox Capture. 00:26:23.960 --> 00:26:24.840 Matt: This is like completely tangent, 00:26:25.280 --> 00:26:26.680 Matt: but Dropbox Capture was really great. 00:26:26.680 --> 00:26:28.640 Matt: It allowed you to take like screenshots and screen recordings 00:26:29.260 --> 00:26:31.260 Matt: and then it immediately copied it into your clipboard. 00:26:31.680 --> 00:26:33.820 Matt: So you can just like capture the screen, capture whatever, 00:26:34.080 --> 00:26:36.820 Matt: and then just directly go to your PR and paste it in 00:26:37.320 --> 00:26:39.220 Matt: without needing to like muck about and whatnot. 00:26:40.040 --> 00:26:41.040 Matt: But it also like saved the files. 00:26:41.320 --> 00:26:44.040 Matt: Unfortunately, they're like end of life in Dropbox Capture. 00:26:44.140 --> 00:26:51.140 Matt: like this month um and so i had to come up with a replacement but uh yeah well well maybe i'll 00:26:51.360 --> 00:26:59.040 Matt: i'll drop the link into that uh replacement in uh in the show notes 00:26:51.360 --> 00:26:59.040 Dillon: i just need you guys to add 00:26:59.500 --> 00:26:59.900 Dillon: or i need 00:26:59.900 --> 00:27:04.700 Dillon: scott to add um these like dev tool screenshots to the show notes as well because 00:27:05.620 --> 00:27:11.280 Dillon: i don't know what he's talking about once again um scott can you give me a quick rundown of what 00:27:11.320 --> 00:27:16.900 Dillon: how that works does that does that help with things like um like when you're screenshotting a ui and 00:27:16.900 --> 00:27:23.420 Dillon: you like open a menu and you go to use the mac screenshot the menu closes like is it help with 00:27:23.440 --> 00:27:28.900 Dillon: that sort of thing can you can you handle that with like the chrome dev tools screenshots you 00:27:28.900 --> 00:27:32.820 Dillon: know what i'm talking about 00:27:28.900 --> 00:27:32.820 Scott: you're talking about because javascript like when you click outside 00:27:33.180 --> 00:27:35.320 Scott: something it might close the menu yeah 00:27:35.320 --> 00:27:37.559 Dillon: the only way i can figure out how to solve that is like 00:27:37.580 --> 00:27:41.900 Dillon: use a debugger statement to like lock the javascript at that point that's 00:27:41.900 --> 00:27:42.420 Scott: That's a case where i 00:27:42.520 --> 00:27:47.260 Scott: would use the video to be honest with you though because like if you're trying to show that you 00:27:47.340 --> 00:27:51.080 Scott: can literally screenshot the video and you don't have to do all your debugging techniques i've done 00:27:51.180 --> 00:27:57.400 Scott: the same stuff drop the debugger or just turn the javascript off so so you could take the picture 00:27:57.900 --> 00:28:03.219 Scott: but in reality i think that's a perfect example for a video i don't think though um necessarily 00:28:03.240 --> 00:28:09.600 Scott: this would solve it using like the full capture in Chrome DevTools because you still have to click 00:28:09.780 --> 00:28:16.680 Scott: outside. However, I'm not sure that if you use command shift five, which gets you a video by 00:28:16.820 --> 00:28:22.080 Scott: default, but if you set it up, you can set it up to take a photo. So you might be able to do it 00:28:22.480 --> 00:28:28.979 Scott: that way. Maybe not, but yes, there are just like more tools for you to be a little bit more 00:28:29.160 --> 00:28:30.500 Scott: savvy when 00:28:30.500 --> 00:28:31.200 Scott: you're taking your screenshots. 00:28:31.720 --> 00:28:33.220 Matt: Yeah, like let's say you have 00:28:33.340 --> 00:28:35.100 Matt: some JavaScript running and you want to kind of pause 00:28:35.180 --> 00:28:37.120 Matt: an interaction in order to take a screenshot or whatever. 00:28:37.520 --> 00:28:38.900 Matt: What I've done in the past is, I think it's function and f8 00:28:39.180 --> 00:28:41.360 Matt: at least on a 00:28:41.460 --> 00:28:43.100 Matt: Mac, we'll like pause 00:28:43.240 --> 00:28:45.080 Matt: JavaScript execution wherever 00:28:45.150 --> 00:28:47.340 Matt: it is. So it's like basically an instant debugger 00:28:48.380 --> 00:28:49.100 Matt: wherever JavaScript's 00:28:49.180 --> 00:28:49.740 Matt: executing currently. 00:28:50.210 --> 00:28:50.920 Matt: And that way you can like 00:28:51.140 --> 00:28:52.260 Matt: then take a screenshot or whatnot. 00:28:53.760 --> 00:28:54.220 Matt: So yeah, 00:28:54.300 --> 00:28:54.860 Matt: I've used that 00:28:54.860 --> 00:28:55.240 Matt: in the past 00:28:55.370 --> 00:28:57.119 Matt: also. But yeah, I think what Scott's saying 00:28:57.140 --> 00:29:00.280 Matt: And also it's like a screen recording, especially for things maybe like deeply embedded. 00:29:00.440 --> 00:29:04.600 Matt: Like sometimes you want to capture the journey that a customer is going to go through until they hit the part you changed. 00:29:05.280 --> 00:29:06.380 Matt: Screen recording, I think is great. 00:29:06.610 --> 00:29:06.700 Matt: Right. 00:29:06.940 --> 00:29:12.160 Matt: It's like a really great way to like provide a guided tour to the reviewer of like, here's what the change does. 00:29:13.800 --> 00:29:13.940 Dillon: Yeah. 00:29:14.460 --> 00:29:19.920 Dillon: I'll add that like anything that has user interactivity typically should just be a video. 00:29:20.900 --> 00:29:21.480 Scott: Well said, Matt. 00:29:21.620 --> 00:29:25.400 Scott: just connecting the dots of how you get to this feature, 00:29:26.110 --> 00:29:29.160 Scott: how the interactivity of the feature occurs for a customer, 00:29:29.840 --> 00:29:33.660 Scott: just puts a lot of perspective in the mind of someone reviewing it. 00:29:34.020 --> 00:29:35.920 Scott: Or even if you write a good enough video, 00:29:36.190 --> 00:29:37.620 Scott: or sorry, recording a good enough video, 00:29:38.380 --> 00:29:40.300 Scott: you can just kind of show that to the team. 00:29:40.330 --> 00:29:41.260 Scott: You can drop it in Slack. 00:29:41.510 --> 00:29:43.660 Scott: You can show progress to people who aren't technical. 00:29:44.420 --> 00:29:48.180 Scott: It's a great way to get some buzz around what you're building. 00:29:48.620 --> 00:29:51.340 Matt: Yeah, this is like a little bit tangent from PR reviews, 00:29:51.520 --> 00:29:54.460 Matt: but HubSpot has a really strong Loom culture. 00:29:54.880 --> 00:29:58.780 Matt: We use Loom, the software that allows you to record screen videos 00:29:59.280 --> 00:30:00.060 Matt: and share it. 00:30:01.280 --> 00:30:03.320 Matt: And it's used for a ton of things internally. 00:30:03.620 --> 00:30:04.300 Matt: It's like someone will be like, 00:30:04.960 --> 00:30:07.280 Matt: oh, I figured out this way to use Cursor to do X. 00:30:07.660 --> 00:30:09.160 Matt: And they just drop a screen recording 00:30:09.340 --> 00:30:10.360 Matt: with them talking to their computer 00:30:10.720 --> 00:30:12.560 Matt: and everyone watches it and reacts to it. 00:30:13.300 --> 00:30:13.800 Matt: I don't know. 00:30:13.940 --> 00:30:16.860 Matt: I haven't seen other company cultures that are similar in same regard. 00:30:17.000 --> 00:30:18.760 Matt: But anyway, I think screen recording is like, 00:30:19.380 --> 00:30:21.260 Matt: if a photo says a thousand things or whatever, 00:30:21.320 --> 00:30:23.380 Matt: a video says a lot more 00:30:25.880 --> 00:30:27.660 Matt: so we've talked quite a bit about 00:30:28.060 --> 00:30:30.020 Matt: how do you craft a good PR 00:30:30.510 --> 00:30:31.320 Matt: I think it might be worth 00:30:32.440 --> 00:30:33.760 Matt: pivoting to our second 00:30:34.150 --> 00:30:35.840 Matt: topic here of how do you guys 00:30:36.060 --> 00:30:37.700 Matt: review PRs? What is the 00:30:37.900 --> 00:30:38.820 Matt: process you follow? 00:30:40.760 --> 00:30:41.920 Matt: I think we could talk about a lot 00:30:41.930 --> 00:30:43.780 Matt: different things here. I don't know if anyone 00:30:44.040 --> 00:30:45.320 Matt: wants to kick us off with 00:30:45.900 --> 00:30:47.120 Matt: any specific approach that you follow 00:30:47.880 --> 00:30:49.960 Matt: or technique that you use or whatnot 00:30:51.860 --> 00:30:52.980 Dillon: I can start us off. 00:30:54.620 --> 00:30:58.920 Dillon: I mean, the first thing I do when I see a PR is just try to get, try to understand the 00:30:59.120 --> 00:31:01.660 Dillon: breadth of the, what the, what problem is trying to solve. 00:31:03.400 --> 00:31:08.700 Dillon: And for like UI changes, if there's like going back to what we were just talking about, there's 00:31:08.800 --> 00:31:09.360 Dillon: videos, great. 00:31:09.580 --> 00:31:10.340 Dillon: Like I'm going to start there. 00:31:10.400 --> 00:31:11.140 Dillon: I'm going to watch those videos. 00:31:11.250 --> 00:31:15.140 Dillon: If there's preview deploys, I'm going to go to the preview deploy and like try to go through 00:31:15.230 --> 00:31:18.000 Dillon: the flow of what they're, what they actually changed in the first place. 00:31:18.840 --> 00:31:19.840 Dillon: That's not always the case. 00:31:20.620 --> 00:31:21.760 Dillon: for back-end changes. 00:31:22.660 --> 00:31:26.200 Dillon: It's a lot harder to have that workflow 00:31:26.520 --> 00:31:27.400 Dillon: when you're reviewing code. 00:31:29.060 --> 00:31:31.700 Dillon: So I just tend to sift through the review, 00:31:31.980 --> 00:31:33.500 Dillon: try to see the major changes 00:31:33.700 --> 00:31:34.680 Dillon: and what it's trying to accomplish, 00:31:35.580 --> 00:31:37.480 Dillon: ignoring any sort of minor issues, 00:31:37.900 --> 00:31:40.100 Dillon: maybe saving some of those for the very end 00:31:40.200 --> 00:31:42.040 Dillon: or the second pass is what I would call it. 00:31:42.800 --> 00:31:45.920 Dillon: Yeah, that's kind of how I would start. 00:31:46.260 --> 00:31:47.300 Dillon: What about you, Scott? 00:31:48.020 --> 00:31:49.920 Scott: Yeah, so I think... 00:31:49.940 --> 00:31:56.220 Scott: talking about how we create PRs is very much informed by how we reviewed PRs. 00:31:56.860 --> 00:32:02.880 Scott: A lot of what I'm going to say is the inverse of why I make the PR the way I make it. 00:32:03.560 --> 00:32:07.560 Scott: Because the first thing I do is I look at a PR and I try to read the context and get some idea. 00:32:08.640 --> 00:32:09.880 Scott: Preview deploy, great point. 00:32:10.260 --> 00:32:14.320 Scott: Maybe you don't need a video, but if there's a video or an image, I'm going to look at it, 00:32:14.440 --> 00:32:16.120 Scott: and then I'm going to start reading from that point. 00:32:16.440 --> 00:32:20.900 Scott: I know we usually put that at the bottom, but it's great to see it and try to read it. 00:32:21.420 --> 00:32:25.380 Scott: So I want to get all the context I can to understand how they're solving a problem. 00:32:25.800 --> 00:32:29.020 Scott: Because I don't want to just look at their code and be like, have you tried X, Y, and Z? 00:32:29.580 --> 00:32:35.760 Scott: I want to see what they told me they have tried, why they took that path that they've taken. 00:32:36.460 --> 00:32:42.800 Scott: This helps inform how I look at the code after I look at it and what to look for. 00:32:43.280 --> 00:32:43.960 Scott: It's a lot harder. 00:32:44.760 --> 00:32:54.940 Scott: And this happens at starters, too. Someone just slaps a PR up. The title's not good. There's no details. And you look at it and you're trying to formulate an opinion on how they tackled it. 00:32:56.020 --> 00:33:02.620 Scott: You might formulate nothing. You might formulate a million. And then now you're having a conversation with the person and you're just like wasting time. 00:33:02.720 --> 00:33:06.380 Scott: they went through this and they just didn't note it like if you can just say as much as possible 00:33:07.040 --> 00:33:13.980 Scott: in that pr you can inform how i can make uh decisions on on solving it or how i can even 00:33:14.160 --> 00:33:18.720 Scott: help you with thoughts you might not have had yeah 00:33:18.720 --> 00:33:21.060 Matt: i think that's a lot of good like a good insight 00:33:21.400 --> 00:33:26.180 Matt: i think the the way i like sort of give you maybe 30 seconds of thought i haven't necessarily 00:33:26.580 --> 00:33:31.700 Matt: sort of extended extended this thinking further than that but um the like the way i would categorize 00:33:31.720 --> 00:33:36.720 Matt: the way I review PRs is maybe a little bit of like a what, why, how sort of approach, right? 00:33:36.820 --> 00:33:41.240 Matt: Like, what is this change from a, like, you know, 30,000 foot view? Like, what is this change doing? 00:33:41.820 --> 00:33:46.700 Matt: Why is this change, the change it is? Like, why are we making this change? What, like that stuff? 00:33:46.860 --> 00:33:50.100 Matt: And then, and then digging into the how, right? Which I think is basically the same thing you 00:33:50.100 --> 00:33:54.020 Matt: were saying, Scott, where it's like, you review the, you know, the artifact, right? Like you view 00:33:54.400 --> 00:33:58.140 Matt: like the visual aspect or whatever it is in order to understand the change and then look at the 00:33:58.120 --> 00:33:59.420 Matt: description, then dig into the implementation. 00:34:00.980 --> 00:34:04.900 Matt: Something, and maybe not necessarily for us to dig all the way back into it, but I think 00:34:05.000 --> 00:34:09.120 Matt: on the preview deploy aspect, something I've actually found where it's like, that can sometimes 00:34:09.280 --> 00:34:14.159 Matt: not be as great as a screen recording or a screenshot is that it's up to the reviewer 00:34:14.260 --> 00:34:17.780 Matt: now to track down where this change happens in the application that's been deployed. 00:34:18.399 --> 00:34:21.179 Matt: So sometimes it's like, oh, there's just a link to a preview. 00:34:21.379 --> 00:34:24.200 Matt: I need to go through the application and find a place where your change was made. 00:34:24.540 --> 00:34:30.040 Matt: And maybe as the reviewer, you might not know all the places that change is going to be impacted. 00:34:30.950 --> 00:34:36.179 Matt: And so screenshots, screen recordings, I think just adds to the context for a reviewer. 00:34:38.020 --> 00:34:41.440 Matt: One thing, and this is maybe a little bit of a tangent or a different path down, 00:34:41.879 --> 00:34:49.159 Matt: something in the past that us three have done is what I like to call live reviews and pairing reviews. 00:34:50.520 --> 00:34:53.840 Matt: Sometimes if a change is really gnarly and hard for me to understand, 00:34:55.940 --> 00:35:00.120 Matt: then I'll just like slack someone you know that slack the person that they opened the PR and said 00:35:00.200 --> 00:35:04.940 Matt: hey do you want to hop on a quick huddle like and walk through this change and talk about it right 00:35:05.060 --> 00:35:09.780 Matt: like help me understand the change why we made the change that provides a faster feedback loop 00:35:10.220 --> 00:35:14.780 Matt: of me reviewing the changes also it's like I don't want to add a comment wait a day for you know the 00:35:15.040 --> 00:35:19.320 Matt: the original author to like come back and reply to it and then wait another day for like me to reply 00:35:19.520 --> 00:35:23.920 Matt: and whatnot you know doing a live review or a peer review I think is really useful I don't know 00:35:24.540 --> 00:35:27.000 Matt: I don't know if that's going to be clear to everyone listening to the episode. 00:35:28.400 --> 00:35:29.220 Dillon: This is yet 00:35:29.220 --> 00:35:31.360 Dillon: another tangent off of what your tangent was, 00:35:31.660 --> 00:35:35.960 Dillon: but I think that sort of makes me think of pair programming 00:35:36.040 --> 00:35:45.900 Dillon: and how pair programming can basically add the reviewing process 00:35:46.160 --> 00:35:47.600 Dillon: to the implementation process. 00:35:48.880 --> 00:35:51.500 Dillon: So it's almost like you have someone helping review the code 00:35:51.560 --> 00:35:52.400 Dillon: as you write the code. 00:35:53.280 --> 00:35:56.500 Dillon: Matt's got some nods, but I'm not sure that he agrees with me. 00:35:56.760 --> 00:35:56.880 Matt: Well, 00:35:57.220 --> 00:36:01.720 Matt: I'm nodding as if I'm trying to understand what you're saying in the same regard. 00:36:02.760 --> 00:36:08.440 Matt: I guess you're saying that pair programming can help lead into a better review process. 00:36:08.560 --> 00:36:08.920 Matt: Is that right? 00:36:09.420 --> 00:36:16.240 Dillon: Yeah, pair programming sort of mixes development and review at the same time, if that makes sense. 00:36:16.960 --> 00:36:18.540 Matt: Yeah, that resonates with me also. 00:36:18.620 --> 00:36:23.100 Matt: It's like you're getting even earlier feedback from a potential reviewer as you're working on it. 00:36:24.319 --> 00:36:30.500 Scott: yeah i agree with her saying Dillon you you're getting like empathy up front about the 00:36:31.240 --> 00:36:36.060 Scott: problem you're solving so like the reviewer is going through the any pain or at least 00:36:36.760 --> 00:36:43.620 Scott: the motions that you have to go through to solve the problem so like empathetically the reviewer 00:36:43.620 --> 00:36:50.680 Scott: is like has more context and understands like why you might get to a specific place the reviewer 00:36:50.700 --> 00:36:55.780 Scott: might also push you and nudge you and give you a little bit of influence which will help like make 00:36:55.820 --> 00:37:01.060 Scott: it easier for it to pass code review but those things help because everyone is now like on the 00:37:01.240 --> 00:37:07.740 Scott: same page and they're agreeing like this is the problem and this is like an approach maybe not 00:37:08.100 --> 00:37:14.580 Scott: a prescriptive code approach but rather like a prescriptive way to tackle it like we want to we 00:37:14.600 --> 00:37:22.120 Scott: want to get to a specific result based on that. And then how you get there can be, again, 00:37:22.460 --> 00:37:27.840 Scott: empathetically followed from both parties. So you essentially see eye to eye with your reviewer. 00:37:28.220 --> 00:37:34.140 Scott: It does help, especially when we had large, big-scale changes, working on those and seeing 00:37:35.000 --> 00:37:39.700 Scott: that through, it works really well because you're on the same page, you're working together, 00:37:40.340 --> 00:37:46.420 Scott: And it's almost like it's peer programming and reviewing, but it's also like basically working on the problem together. 00:37:46.730 --> 00:37:49.220 Scott: So you build trust and confidence. 00:37:50.560 --> 00:37:59.880 Dillon: Pair programming and like live reviews is really great, but it does require that two people basically dedicate their time to the problem together. 00:38:00.720 --> 00:38:03.700 Dillon: And the whole point of PRs is that they can be like asynchronously reviewed. 00:38:04.400 --> 00:38:10.800 Dillon: So I think this is all leading back to like the positives we're seeing from pair programming and live reviews can be solved by a really good PR description. 00:38:12.380 --> 00:38:21.680 Dillon: To give all that context that you would give when you're talking to somebody face to face, you should you should try to like think about it, writing your description in terms of like I'm talking to a person. 00:38:22.640 --> 00:38:26.140 Dillon: What what should I tell them to let them know everything I'm trying to accomplish here? 00:38:26.720 --> 00:38:27.680 Matt: Yeah, I really like that framing. 00:38:28.500 --> 00:38:45.000 Matt: This is like maybe yet another tangent, but something I've, uh, something I've like, you know, I've been on teams in the past where we actually considered the possibility of like, if, if every PR has been paired on or swarmed on by the team, like, do we even need code review? 00:38:45.500 --> 00:38:47.480 Matt: Like, can we just like yeet that into production? 00:38:47.960 --> 00:38:49.680 Matt: It's an interesting question, more of like a meta note. 00:38:50.080 --> 00:38:53.700 Matt: Um, I think it's like, you know, code review, like, yeah. 00:38:54.040 --> 00:38:56.340 Matt: And like, maybe like kind of related to that, right. 00:38:56.420 --> 00:38:58.840 Matt: if you pair on a problem with someone else, 00:38:59.579 --> 00:39:01.480 Matt: like, sometimes, like, okay, 00:39:01.620 --> 00:39:03.020 Matt: it could be useful for them to also review it, 00:39:03.160 --> 00:39:05.460 Matt: but, like, you guys both have the context of the problem. 00:39:05.560 --> 00:39:07.040 Matt: Sometimes you actually want to find a different person 00:39:07.580 --> 00:39:10.360 Matt: to review it in order to, like, get a different perspective. 00:39:11.680 --> 00:39:14.620 Matt: And so, yeah, like, yeah, I think pairing, 00:39:14.780 --> 00:39:16.920 Matt: it's, like, doesn't necessarily completely remove 00:39:17.000 --> 00:39:19.000 Matt: the need for code review, I think, in all cases, 00:39:19.580 --> 00:39:20.380 Matt: but sometimes it could be, 00:39:21.340 --> 00:39:24.060 Matt: it provides an even better experience for the reviewer. 00:39:24.320 --> 00:39:27.180 Matt: I guess that's like the thought I was leading to there. 00:39:28.680 --> 00:39:29.280 Scott: I agree 00:39:29.280 --> 00:39:29.920 Scott: with what you're saying. 00:39:30.420 --> 00:39:34.680 Scott: Again, both of you, there's a, I'm going to say it depends. 00:39:34.840 --> 00:39:37.400 Scott: I wasn't going to say that, but there's a balance, right? 00:39:38.240 --> 00:39:43.000 Scott: Like it is good for teams to like build relationships and trust and work on these things together, 00:39:44.060 --> 00:39:45.540 Scott: especially when skill sets could be different. 00:39:45.760 --> 00:39:49.000 Scott: So it could help grow people and their, their, their abilities. 00:39:49.740 --> 00:39:52.420 Scott: And again, cultivate more morale for the team. 00:39:53.800 --> 00:39:54.560 Scott: But it also like 00:39:54.560 --> 00:40:01.720 Scott: we don't want to go too far down one end where everything we're doing is now pairing and it's slowing us down. 00:40:01.900 --> 00:40:03.820 Scott: So there's there's fine lines between the two. 00:40:05.340 --> 00:40:09.460 Matt: Yeah, but yeah, as you were talking, I'd like another thought come to mind about code review. 00:40:10.520 --> 00:40:14.920 Matt: This is like maybe kind of on the ancillary aspects and not necessarily about how I review code. 00:40:15.740 --> 00:40:30.260 Matt: Something that's been highly encouraged on my team at HubSpot and I think maybe other teams as well is using code review as an opportunity to onboard and learn about the team, learn about the changes, learn about whatever. 00:40:31.960 --> 00:40:33.540 Matt: I think it's an interesting aspect. 00:40:33.740 --> 00:40:39.720 Matt: I think maybe I can see benefits and problems with that approach. 00:40:42.200 --> 00:40:51.580 Matt: And yeah, it's like code review is more than just ensuring that the code is correct, right? It's like, you know, it's like, I think there's deeper aspects to it that are, you know, provide benefit to a team. 00:40:52.620 --> 00:41:09.960 Dillon: Yeah, I had a point that kind of spins off of what you're talking about, Matt, where like some an example of like my own code review is I tend to want to like give the PR to somebody I know has experience in that area and is going to be able to like have a quick turnaround time on the review. 00:41:10.440 --> 00:41:16.540 Dillon: but that's not to that's not actually like good for knowledge sharing within the team as a whole 00:41:17.140 --> 00:41:22.800 Dillon: so it's like a balance of like sure i can get the person that's going to give me the best comments 00:41:22.930 --> 00:41:27.840 Dillon: but i also need to like help my team learn what is going on in different parts of the system that 00:41:27.840 --> 00:41:28.860 Dillon: they don't typically work in 00:41:28.860 --> 00:41:34.300 Matt: 100 agree i think it's like you know sometimes totally there's times 00:41:34.350 --> 00:41:37.880 Matt: where it's like oh i just need to get this code change out so i'll just ping it to the person that 00:41:37.900 --> 00:41:38.760 Matt: knows the most about it, 00:41:39.540 --> 00:41:40.720 Matt: is going to review it the fastest. 00:41:40.900 --> 00:41:42.040 Matt: But there's other times where it's like, 00:41:43.680 --> 00:41:45.120 Matt: it would be great to get this change out, 00:41:45.280 --> 00:41:47.060 Matt: but it's also useful just to throw it to anyone 00:41:47.220 --> 00:41:48.460 Matt: to review it and then hopefully 00:41:49.520 --> 00:41:50.700 Matt: try to encourage people on the team 00:41:50.940 --> 00:41:51.280 Matt: that we're on 00:41:51.280 --> 00:41:52.620 Matt: to review 00:41:54.220 --> 00:41:55.020 Matt: changes that 00:41:55.280 --> 00:41:57.340 Matt: they don't know that much about in order to learn more about it. 00:41:59.420 --> 00:42:01.020 Matt: Does everyone have spicy takes 00:42:01.620 --> 00:42:02.800 Matt: for the 00:42:03.420 --> 00:42:03.700 Matt: spicy 00:42:03.700 --> 00:42:04.200 Matt: takes segment? 00:42:05.540 --> 00:42:07.860 Matt: I think my spicy take, if we were to have 00:42:07.880 --> 00:42:09.720 Matt: would probably be that code review. 00:42:09.830 --> 00:42:11.940 Matt: You maybe don't need it. There's a spicy take. 00:42:14.700 --> 00:42:14.900 Matt: Yeah. 00:42:15.700 --> 00:42:17.100 Matt: I don't think every 00:42:18.120 --> 00:42:19.040 Matt: situation requires code review. 00:42:20.080 --> 00:42:20.420 Scott: Mild. 00:42:21.800 --> 00:42:23.540 Scott: I work in a company where 00:42:24.600 --> 00:42:25.680 Scott: maybe 50 to 00:42:25.840 --> 00:42:27.600 Scott: 75% of things don't get code 00:42:27.780 --> 00:42:29.580 Scott: reviewed, so it's mild. 00:42:31.200 --> 00:42:31.640 Scott: If it was a 00:42:31.820 --> 00:42:33.220 Scott: corporation you're talking about. 00:42:34.040 --> 00:42:35.440 Matt: HubSpot for a long time 00:42:35.880 --> 00:42:36.540 Matt: didn't require 00:42:38.860 --> 00:42:40.540 Matt: actually someone stamping a PR. 00:42:41.660 --> 00:42:44.640 Matt: I don't know if this is going to get us in trouble, but we didn't 00:42:45.440 --> 00:42:47.820 Matt: require someone approving a PR before it being merged. 00:42:49.500 --> 00:42:50.120 Matt: But now we do. 00:42:51.100 --> 00:42:52.400 Scott: What do you mean us? 00:42:53.360 --> 00:42:54.740 Scott: I'm not going to show up. 00:42:57.620 --> 00:43:00.460 Dillon: I feel like that's like a Diablo take, which is the top of the scale 00:43:00.950 --> 00:43:02.440 Dillon: of our 00:43:04.620 --> 00:43:12.040 Dillon: take a spicy take scale i don't know what it is whatever um because i mean it really does depend 00:43:12.820 --> 00:43:22.160 Dillon: right scott um because yeah if you're on a team with two people and like you need to move quickly 00:43:22.440 --> 00:43:31.440 Dillon: and maybe you have two customers like you just yeet it as as matt would say but if but if you have a 00:43:31.340 --> 00:43:37.940 Dillon: million customers or more it's i would say like you should probably get some reviews maybe one to two 00:43:38.900 --> 00:43:45.180 Dillon: like at where i work like two is like required in specific repos and then other repos it's only one 00:43:46.010 --> 00:43:51.620 Dillon: um so it sort of depends now that scott's put this word in my head i'm just using it over and over 00:43:52.240 --> 00:43:52.440 Dillon: but yeah 00:43:52.440 --> 00:44:00.320 Scott: it does depend honestly i think two is like almost absurd unless like one team's working 00:44:00.340 --> 00:44:02.460 Scott: on a problem and they just don't know what they're doing. 00:44:03.620 --> 00:44:05.280 Scott: The hot take right there, I guess. 00:44:06.410 --> 00:44:10.060 Scott: You should never have to do, almost never have to do two code reviews. 00:44:10.210 --> 00:44:13.940 Scott: Is that spicy? I feel like that's not even mild. 00:44:14.010 --> 00:44:17.600 Scott: It's lukewarm. It's like, it's a cold take. 00:44:18.600 --> 00:44:19.720 Matt: It's the white bread. 00:44:21.210 --> 00:44:24.420 Scott: My take is that all code should be able to be written by speaking. 00:44:27.440 --> 00:44:29.920 Matt: That's a very lukewarm take, in my opinion. 00:44:30.720 --> 00:44:35.240 Matt: we're very uh it's like i don't know that's 00:44:35.240 --> 00:44:38.000 Matt: the that's the trend right now i just said it okay 00:44:38.300 --> 00:44:39.580 Matt: it's off the scale it's it's 00:44:39.580 --> 00:44:43.920 Matt: it's so far so far cold that it's it's not even present on the scale 00:44:44.780 --> 00:44:47.040 Scott: why are you so hostile towards my spicy takes 00:44:47.040 --> 00:44:49.580 Matt: it's not that spicy of a take 00:44:52.040 --> 00:44:57.720 Scott: Dillon come on help me out 00:44:52.040 --> 00:44:57.720 Dillon: scott i wasn't listening can you give me your take again 00:44:58.680 --> 00:44:59.460 Scott: we're gonna move 00:44:59.460 --> 00:44:59.960 Scott: on to 00:44:59.960 --> 00:45:00.780 Scott: i'm gonna 00:45:00.780 --> 00:45:01.960 Scott: make up another spicy 00:45:01.960 --> 00:45:02.580 Scott: take here 00:45:03.020 --> 00:45:06.340 Scott: all after that but yeah typescript is overrated 00:45:09.840 --> 00:45:14.200 Matt: what about go is overrated that's spicy take 00:45:09.840 --> 00:45:14.200 Scott: how is it spicy 00:45:17.040 --> 00:45:19.340 Matt: oh because maybe it's not maybe it's underrated 00:45:22.579 --> 00:45:24.780 Scott: i just don't know why all my takes are 00:45:31.060 --> 00:45:34.820 Scott: I think Matt's just mad that he hasn't won two takes and a fake yet. 00:45:36.480 --> 00:45:37.560 Scott: Actually, I think he won last 00:45:37.560 --> 00:45:37.760 Scott: week. 00:45:37.860 --> 00:45:39.280 Scott: I don't know what the score is. 00:45:39.340 --> 00:45:39.400 Scott: It's 00:45:39.400 --> 00:45:39.820 Scott: made up, 00:45:40.220 --> 00:45:41.160 Scott: and the points don't matter. 00:45:45.100 --> 00:45:45.360 Matt: All right. 00:45:45.940 --> 00:45:48.900 Matt: Do we want to close this out with what's up with you? 00:45:49.980 --> 00:45:52.440 Matt: What's something new that you guys have been looking at or thinking about? 00:45:52.840 --> 00:45:53.480 Matt: Could be tech-related. 00:45:53.520 --> 00:45:54.700 Matt: Could be unrelated to tech. 00:45:54.780 --> 00:45:57.460 Matt: Dillon, do you have anything that's new? 00:45:59.060 --> 00:46:00.380 Dillon: This is a stand-up update. 00:46:04.760 --> 00:46:06.420 Dillon: At work, I was looking into something called 00:46:08.860 --> 00:46:10.200 Dillon: embargoed assets in Contentful. 00:46:11.540 --> 00:46:16.180 Dillon: It's basically a way to have your CDN assets 00:46:17.430 --> 00:46:21.540 Dillon: be secured so that only specific users can see them. 00:46:21.620 --> 00:46:29.180 Dillon: So that was like digging into that and writing up a tech plan and trying to estimate how long it would take, even though I've never built anything like this. 00:46:29.760 --> 00:46:40.580 Dillon: But it requires like spinning a new service that authorizes, like making sure the user is authorized and reaches out to Contentful to make sure that like it's just a lot. 00:46:41.800 --> 00:46:43.000 Dillon: It's a lot for a front end developer. 00:46:43.270 --> 00:46:44.620 Dillon: It feels like a back end thing. 00:46:45.980 --> 00:46:47.860 Dillon: That was a terrible thing to add. 00:46:48.600 --> 00:46:54.640 Matt: Well, I was just going to say, you were talking before we started recording about your new coffee beans or coffee that you've been trying. 00:46:54.690 --> 00:46:57.620 Matt: I figured you were going to talk about that. 00:46:57.930 --> 00:46:58.540 Matt: I guess not, though. 00:47:03.300 --> 00:47:03.860 Dillon: I should have. 00:47:04.220 --> 00:47:04.860 Dillon: That would have been a lot more. 00:47:06.180 --> 00:47:07.640 Dillon: I just put everyone to sleep. 00:47:08.620 --> 00:47:09.520 Dillon: So I'm sorry. 00:47:09.550 --> 00:47:10.920 Dillon: I should have given you caffeine instead. 00:47:12.380 --> 00:47:20.220 Scott: Yeah, so code-wise, recently I learned about, I guess, for the first time I used the Canvas tag. 00:47:20.570 --> 00:47:28.900 Scott: I learned about animating on scroll videos and pictures in React and in vanilla JavaScript. 00:47:29.030 --> 00:47:31.640 Scott: You can go to tollbit.com and check out the hero image. 00:47:32.260 --> 00:47:33.920 Scott: It kind of animates on scroll. 00:47:34.820 --> 00:47:36.240 Scott: It was pretty cool. 00:47:37.480 --> 00:47:48.960 Scott: I learned about PNGs versus WebP files, and I have to remind myself right now to install that command line tool in my dotfiles. 00:47:49.800 --> 00:47:51.100 Scott: Hold on, I'm writing that down. 00:47:55.180 --> 00:48:01.440 Scott: Okay, so what I did here is I was originally going to do this all in CSS, and I started it that way. 00:48:01.980 --> 00:48:03.900 Scott: We want to animate and make something look 3D. 00:48:04.000 --> 00:48:06.240 Scott: I got really excited and I started doing it in CSS. 00:48:06.420 --> 00:48:13.640 Scott: I almost did everything but, well, I did everything but the three-dimensional transforms, which was what I was about to solve. 00:48:14.000 --> 00:48:17.260 Scott: And then I was told, stop, here's a video, animate this video. 00:48:17.520 --> 00:48:24.640 Scott: And I kind of learned that in JavaScript, you can get 60 FPS easily in the browser. 00:48:24.920 --> 00:48:28.260 Scott: But with React, you can't because it's a virtual DOM. 00:48:29.620 --> 00:48:29.840 Scott: And, 00:48:30.020 --> 00:48:31.100 Scott: you know, I took every approach. 00:48:31.100 --> 00:48:31.980 Scott: I didn't use states. 00:48:32.120 --> 00:48:35.280 Scott: I used Matt. Matt doesn't agree. I used. 00:48:37.580 --> 00:48:39.660 Scott: refs, I tried some things. 00:48:42.000 --> 00:48:45.220 Scott: Web P or Web M Web P is pictures. 00:48:45.660 --> 00:48:48.200 Scott: So I learned about both Web M and Web P. 00:48:48.660 --> 00:48:50.460 Scott: So that's fair to clarify. So I started with video. 00:48:50.940 --> 00:49:01.760 Scott: The video didn't like this kind of copying what Apple does, but they don't actually make the video a video specifically play. 00:49:01.860 --> 00:49:02.380 Scott: when you scroll. 00:49:03.900 --> 00:49:06.660 Scott: React can't really handle that level of loading. 00:49:07.130 --> 00:49:09.580 Scott: But what they'll do is they'll do like a CSS transition 00:49:10.660 --> 00:49:12.960 Scott: and then they'll play the video on scroll. 00:49:13.150 --> 00:49:14.800 Scott: So that's kind of the technique they'll use. 00:49:15.180 --> 00:49:18.220 Scott: If they want to make it like a video that does happen on scroll, 00:49:18.460 --> 00:49:19.020 Scott: they use pictures. 00:49:19.580 --> 00:49:21.380 Scott: So I went over and I changed everything to pictures, 00:49:23.200 --> 00:49:26.340 Scott: but that looked great at like 1x PNGs, 00:49:26.420 --> 00:49:30.540 Scott: but when we 2x'd them to optimize, it was very stuttery. 00:49:31.000 --> 00:49:44.200 Scott: So the way I solve this to get full circle to my point about the canvas tag is I use the canvas tag instead of images because canvas bypasses reacts need to re-render. 00:49:45.120 --> 00:49:50.040 Scott: So it allows you to update more frequently faster and we got a more smooth transition out of it. 00:49:50.380 --> 00:49:51.740 Scott: So that was a really, really cool project. 00:49:52.150 --> 00:49:53.060 Scott: I had never done it before. 00:49:54.540 --> 00:49:56.800 Scott: I created a reusable component that does this. 00:49:57.380 --> 00:50:10.660 Scott: And I'm going to be putting that into my private but public UI solution that I have yet to, I've told most people about, but I'm not going to talk about it publicly here. 00:50:11.760 --> 00:50:12.620 Scott: And that was really fun. 00:50:13.440 --> 00:50:14.760 Scott: Matt, what's up with you? 00:50:15.920 --> 00:50:16.600 Matt: That's really cool, Scott. 00:50:16.740 --> 00:50:26.780 Matt: My stand-up update today is, or this week, is I've been digging into CSP, which is content security policy. 00:50:27.120 --> 00:50:27.820 Matt: A lot of fun. 00:50:29.180 --> 00:50:30.780 Matt: Hint, it's not actually a lot of fun. 00:50:32.900 --> 00:50:39.080 Matt: We have a very lax CSP setting right now across basically all of our websites. 00:50:42.720 --> 00:50:47.260 Matt: And so we're trying to figure out how do we actually go from being very lax to very strict or enforced. 00:50:47.770 --> 00:50:49.700 Matt: In CSP, it's like all or nothing. 00:50:49.930 --> 00:50:57.740 Matt: You have to specify everything that you're planning to reload that you need to load in order to allow it to work on the page. 00:50:57.900 --> 00:51:00.700 Matt: So that's my stand-up update. 00:51:01.370 --> 00:51:02.820 Matt: Yeah, CSP is a pain, exactly, Scott. 00:51:05.140 --> 00:51:10.200 Matt: Separate from that, I've been digging into durable objects on Cloudflare, which is kind of interesting. 00:51:10.680 --> 00:51:12.000 Matt: I still don't know what they are. 00:51:13.860 --> 00:51:15.520 Matt: but hopefully I figured that out 00:51:17.140 --> 00:51:17.820 Dillon: you know 00:51:18.440 --> 00:51:19.660 Dillon: you know why you're looking into them 00:51:20.660 --> 00:51:21.780 Matt: they allow you to persist 00:51:22.060 --> 00:51:23.800 Matt: state kind of like a database but 00:51:24.060 --> 00:51:24.420 Matt: they can be 00:51:25.580 --> 00:51:27.700 Matt: spun up and spun down really easily apparently 00:51:28.100 --> 00:51:29.680 Matt: and it's very cost effective maybe 00:51:30.920 --> 00:51:31.900 Matt: anyway I gave 00:51:32.140 --> 00:51:34.180 Matt: I like paid Cloudflare $5 last night 00:51:34.300 --> 00:51:35.420 Matt: so I could start testing them out 00:51:36.280 --> 00:51:36.520 Matt: so 00:51:38.440 --> 00:51:39.960 Matt: we'll see if I actually end up 00:51:40.060 --> 00:51:40.939 Matt: needing them or not 00:51:42.120 --> 00:51:49.100 Scott: yeah i think we i'm proposing to call this uh segment what's stand up with you and and Dillon 00:51:49.340 --> 00:51:54.000 Scott: also just kind of like i think he tossed out a name but i think we should just have uh stand up 00:51:54.060 --> 00:51:59.000 Scott: in the parking lot is this rant time that we have post what's stand up with you 00:52:02.020 --> 00:52:07.399 Dillon: yeah i just feel like we're the reason i said stand up in the parking lot is because 00:52:07.800 --> 00:52:09.500 Dillon: this is like the very end of the episode 00:52:09.710 --> 00:52:11.440 Dillon: and then we're giving our stand-up update. And usually 00:52:11.630 --> 00:52:13.540 Dillon: you do your parking lots at the end of 00:52:13.640 --> 00:52:14.720 Dillon: stand-up for anyone 00:52:15.800 --> 00:52:16.240 Dillon: that does that. 00:52:16.340 --> 00:52:17.720 Matt: Perfect. Alright. Do we want to call it there? 00:52:18.120 --> 00:52:18.620 Matt: I think that 00:52:19.500 --> 00:52:20.460 Matt: covers our topic for the day. 00:52:22.000 --> 00:52:23.420 Matt: Thanks everyone for joining 00:52:23.560 --> 00:52:25.340 Matt: and talking about it. Like and subscribe. 00:52:25.700 --> 00:52:26.380 Matt: Share it with a friend. 00:52:28.039 --> 00:52:29.060 Matt: Scott, what do you got? 00:52:30.200 --> 00:52:31.380 Speaker 5: I was going to say what you said. 00:52:32.359 --> 00:52:33.080 Speaker 5: Bikeshedpod.com 00:52:33.700 --> 00:52:34.580 Speaker 5: Like and subscribe. 00:52:36.200 --> 00:52:36.560 Speaker 5: Peace! 00:52:37.500 --> 00:52:37.940 Matt: peace out