GitLab Code Review Weekly Workshop, 14 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Code Review Weekly Workshop - April 14, 2023

Description

In this session we discuss some topics pertaining to code review.

00:00 - Intro
00:20 - How to optimize review process looking at the docs?
24:40 - Imposter syndrome with reviews?
37:30 - Pair up on a review!

A

All right all right! Well, thanks for hopping on the code review, weekly Workshop, um we're going to talk about some code review stuff and potentially things adjacent and pertaining to code review, and it sounds like Chad may have something that is adjacent.

A

B

My medic question is like with the thermal development um where we've been working on this integration. Branch we're going to be having a bunch of vampires. You know, hopefully not the time, but a lot of small Mrs ready for review and I want to try to even I've, been here going around three and a half years. I've not worked in the monolith. A lot I've like worked out of the monolith and I've worked in isolated.

B

You know corners of the monolith, so I'm not familiar with a lot of the review guidelines and standards, especially around like authorization, the nuances of database reviews, error, logging, metrics, all sorts of stuff like that.

B

So my question is that I I know there's a lot of documentation in the dots.getlab.com around code reviews and then there's like a bunch of running Dodge, some back-end stuff, some stuff around graphql there's also some stuff littered in the handbook.

B

There's a lot of tribal knowledge that doesn't exist in either of those places like if I'm wanting to do a self-review of this Mr and I'm like I, want to try to make sure this is good.

B

So I don't waste the reviewer's time, but I really don't know what is good or what's not, or what rules we have or even where to look for them other than just like randomly searching the dots in the hand, but for some strings or you know the reviewer guide section but I'm sure, there's like other, maybe other stuff or stuff, that I'm missing. How do I? How can I find all that?

B

That's a good question and have a good confidence that I found the important things.

A

And what what do you think Johnny.

C

hmm um I think it's a it's a cool, it's an absolute fantastic, but also a super tricky question. um I feel it's it's very hard to answer.

C

If we don't boil it on a specific topic, speaking about the front end, for example like that is something that is coming to my mind, there is the in the handbook I suppose it is I'll search for it in a second, am I say: yes, okay, you have front-end guidelines, um so that is something that's coming to my mind, which is like a collection of best practices in a way and I would argue.

B

I think the front end is much better organized than the back end. To be honest,.

C

B

C

So that is in that area. So that's something that's coming to my mind where I'd be like: okay sticking to those, that's probably a good start. On the other hand, whatever you're working on is probably very specific, so there's there's always going to be one side of the Gap um I'd argue. If not, then we probably wouldn't need any reviews, so um yeah, probably nothing that can be answered completely, but the front-end guidelines are something that I can think of. That's the first thing coming to my mind, anything else, that's coming to you mindful.

A

um I think it's it's challenging, because, because the docks are so large I mean they have not only talks about how to review but docs as the single source of Truth for our developer guidelines, which are so large.

B

All right we're, starting just in the same place, they're like in China all under the you know, contribute thing of the the top level category of the dots, but under there it's like who knows, yeah.

A

um That I think the um the best use of your time and reviewers time is.

A

I mean this is we've talked about this before, but ideally, the code that already exists in the code base is ideally that's up to dates and as long as we look like existing code, then we're good. If something, if that code, that's where you know inspired from is not up to date, then yeah you're gonna get a whole bunch of comments of like oh this. That's that can be frustrating, but what can be really helpful in a Mr if I'm, just not sure, I kind of lean towards I?

A

Don't recommend like just trying to follow developer guidelines to the T, because a lot of linting and everything should solve that as long as we're not building things that are coupled, then things are simple functions like those are the great place to start and lenting is kind of what guides what should be enforcing the developer guidelines as much as possible, but then, if I've built something then I leaving some artifacts somewhere of like hey.

A

This is inspired from this other bit of code like even if that's just a comment on the Mr or in the MRI description, and when I ping, people of like hey I, did this. This is my process of how I got here, but I kind of want to bring I kind of want to show the reviewer as if we paired on it like they could see.

A

The story of this is how I got to to here and the easier you can make the reviewer come to that Journey with you of, like the the more I, think confident they'll feel about some of the changes of being able to understand the changes.

B

Yeah and I I always default to the the cargo quilting approach, like you said, but it's like things aren't always the same and like I try to find out a recent one and by somebody that I feel confident that they they did it well and columns and they're you know, is well reviewed, but still so I guess follow-on question. Those are good answers. Thank you.

B

If there's something that is done and I think this is even explicitly said in a DOT somewhere but I'm going to ask it anyway, like there's, not a limiting rule for it and there's nothing in the in the dots or the review guidelines. That say you can't do it. That way. Is it okay, okay to push back to their viewer and say no, this! This is sort of how I want it.

B

Even a maintainer.

C

I would argue yes um and yes as if and like nobody should decline, anything for the reason, because I don't like it that way like that is absolutely not a good reason and if I put myself into the shoes as the maintainer in such a case, then I would think it's perfectly fine to ask for you to be like well.

C

Okay, glad that you don't like it, but please update the docs now and and we're going to be having this discussion over there so um yeah, it's absolutely fair to have a stronger premium on something I. Don't think it's the greatest idea to have a strong, undocumented opinion on something so um yeah, there's a single source of truth. I wouldn't argue like if it yeah.

C

If it's not in the docs, it's not true, and if it's still true, it should be in the docs, that's kind of what it maybe a little extreme but um somewhere along those lines. That's where I would take it.

B

Right, so, if there's something you know that you're going to get pushed back on, you need to make sure you get it into docs first, so you can point to it, which is like the one that I've had in the past and like I've, had feedback on this like or Ruby mine.

B

I, really like I, have a scope set up. That's like here's all of the remote development stuff. You know the couple three dozen files and then I use the code inspection which, like tells me in years not only the built-in liners root of obviously and prettier, all of that, but also some built-in ones. But it's not perfect, like sometimes it says, hey I can't find this.

B

You know automatically derived variables, that's coming from math and record based after your field like it's, indexing is a little bit off and I have to say: hey, I, really, love when you tell me I'm using a non-existing method but you're wrong here, no inspection for this line and I've gotten multiple feedback multiple times so people say like. Why are you putting that comment in there? I, don't like it and I'm like because it's useful it lets me see a green check at the top Corner.

B

Otherwise, for this file and I have a wonder: I have to explain myself over and over so I'm, actually thinking of making an MR just in the handbook, because it's a much lower bar for getting it in like and starting like a jet brains, thing to say: I know you don't use this IDE and maybe it would litter it up. But it's just a comment: it's okay! It makes jet brains, users out of the box life easier. Yes, I could disable this inspection. I.

B

Don't want to do that because then that's not the out of the box experience for a new contributor who just opens the project in Jeff brains, so like there's legit reasons but like I, have to explain that over and over and there's like a lot of these in the remote Dev stuff. So I'm like okay I, think I'm gonna have to take the time to like put something in the handbook which I've been putting out quite like a whole jet ring section.

D

B

Can't complain about this comment because.

D

C

In the handbook.

A

C

Sure, sorry, no.

A

No sometimes I do things that um require some explanation at first because I'm, like oh I, like doing it this way, I, don't know that Paul I.

B

Married with you sometimes.

A

I do things that require explanation. That's that's skills without saying uh that expands, Beyond coding for sure um the, uh but the explanation tampers down after a couple of reviews, and especially after okay, this has become more of a solidified practice, either through documentation or acceptance and I yeah. That's that sounds great. I would highly just recommend writing a quick thing in the co-located jetbrain stuff of like hey, and you can leave comments here. Sometimes your brains can't pick something up so everything's.

A

All green leave a comment like this share it with everyone in the back end Channel, and so now everyone knows. Oh, it's okay, to see comments like this and like that. It takes a little bit of time before. Okay, we're all familiar with this new thing and I think that yeah, when it comes to like I, would just highly recommend the best thing you can do to um ensure positive review experience. This is two things is the self-review is really important, um but you can't be like overly verbose about it.

A

So you want to do a self review and being a little choosy about not picking everything, but only highlighting the bits that you think are really kind of standing out, because the goal is to make it so easy for anyone looking at it to approve, and if you can't do that, then it's a pretty good signal to you of, like maybe something's off here and I, really want to collaborate with someone to get new ideas. How can I make this fit better?

A

um In addition to self-review I've started like when I ping, people, if it's authorization, specific review or um if it's a back-end review but the whole Mr, isn't back-end I'll ping them with context of hey? Can you review this? This is the main goal. The back end is doing this.

A

Take a look at these comments and like that that goes a long way as well um for reviewers to to understand when they first get pinged to how much their what the block of work is in front of them when they see that email come in of, like oh I, got a new review. I gotta. Do this thing um so I think um self-review is a big deal, but also leaving context when you, you ping, the person um so that they know what they're kind of getting into.

C

D

C

More one more thing that is, that is crossing my mind regarding Raju on the edge stuff or new stuff, like if I think about things that are currently in progress, like obviously AI stuff, new apis whatsoever, so they're they're. What every once in a while you'll, be finding yourself working on things that will not be in the handbook, because they're just pretty much brand new.

C

What helps me quite a bit of what I've been using as a technique is to really boil an MR down to a very, very much prototype kind of stuff and then um actually Loop in the revenue are very in a very, very early stage and be like this is kind of how it's supposed to look architecture-wise like it's missing a lot at the moment and I'm aware of this, but in theory, which should be okay with this approach, because it has like the key facts.

C

We can then discuss and then later on, at Bells whistles unit tests, whatever you'll be needing um I, saw this to be quite an that it's a little counter-intuitive, but um I thought it should be quite efficient for the offer anti-regular because you're just keeping the scope as little as possible. So it's it's a little bit of uh more communication added, but um since you're cutting down the scope, it could be helpful depending on the use case.

D

B

And yeah, as far as the self-review I'm, like I'm, not good at reviews just in general and like they're, not something I've done a lot in my career, I've heard a lot more before that I worked in places that didn't have code, review, culture or or minimal so like even when I try to catch things, I, don't and that's even when I do know something much less the things that I don't even know that there's a processor guideline that we have that I'm not aware of so I feel like just waste people's time or when I do a review.

B

I. Have this huge imposter syndrome that, like the meditator is going to look at is like? Oh Chad was a God. How could have Chad and missed these obvious things? Like he's? Not even caring he's just understanding this and like when I look at the code, I've seen you do it and I know, there's ways to get better at it, but they don't jump out at me.

A

That's a that's an interesting point, I think um when what I find jumping out to me like I, want to leave a comment about this is um usually it's a it's at the top of the module and I say like what is this doing and I kind of leave those comments?

A

Sometimes I'll leave them as comments in the code. Sometimes they're not worth comments in the code and I leave them as comments in DMR and that's like the big thing is like this is a big unit. What is this unit doing and why did I feel like we needed to create a new unit here and that's I. Leave that comment a lot and it's I don't find myself leaving I, don't I, don't leave nitpicky comments to myself. I'll just go fix them I'm like ah I gotta.

A

Do this thing whatever like I, but at the same time it's like go for the review as early as possible. Don't I if I see a nitpicky thing that could be changed, I like to leave it in there. This is me being strategic I like to leave my you know.

A

One line uh this could be prettier for a reviewer to catch, so then we're collaborating and we all feel like we've contributed. I, don't have to do something perfect, and we can that's a way that we can collaborate and feel better about the thing that we're approving and looking at so I.

B

At least know you thought about it, even if you haven't done a good job of thinking about it, yeah.

A

But the the Top Line comments like this. This goes a long way for me. The Top Line comments I leave at like the beginning of a big function or the beginning of a class of like what is the responsibility of this thing is I. That's those are those those go a long way I so.

B

um So what about like, when you're, actually doing a review like I'll, often like I, try to at least exploratory test them and say? Does this work and then, when I, look at the code, like especially like I I, try to be full stack, so I have myself as a friend interviewer, but a lot of times, I'll get it and I'm like okay, I, don't know this looks good to me. I, don't see anything obviously wrong and then, like the maintainer will catch.

B

You know front end is weird but I'll, also or even on the back end to her life, especially if you're things like graphql or stuff I'll I'll miss or you know how to refactor things um like how bad should I feel about that. Just missing things very.

C

B

Very, very, very rare I. Do it's a good then I'm doing it right.

A

I don't know um I.

B

A

B

Like do they have tests, like my culture is like tdd and pairing them like. Do they have some test prints? Do the tests look like they cover them, the main pass of what they're doing, and maybe some exceptional cases? Okay good. Have you done and doesn't work like? Oh exploratory tested and like that's, my traditional bar I'm like okay ship it, but that is not the part. Get lab is much higher than that.

B

So that's the mismatch between the way I have learned to be a developer and what is expected here, it's like if there's something wrong with it, we'll we'll it'll get if a linter doesn't catch it if the Explorer, if it does what it's supposed to do and there's some decent looking tests, good anything else will get caught, but that's like not our bar. Our bar is much higher than NADA. It seems.

A

Speak it from Front End like View maintainability, has some weird uh not compile time caught quirks with it like the way you have to manage State and reactivity, and all of that is, is a different paradigm.

B

That their linters for all of that, is it not possible or we're too lazy or what I.

A

I, don't I there's for some things, but for other things, it's just design decisions and in reality it's like hey, you're, you. We need to be more reactive with this, rather than working off events and there's no way to catch that unless you're really really familiar with the tool you're using View- and you know this is how we best use View, and this is the trade-offs with that, and this is where, in these situations, it's not the way to do it so for front end.

A

I just say you should give give yourself a pass with view is just weird like View.

B

Especially as I found the background too, like, uh for example, the shaw was like saying: do we really like this time step? Isn't always the same I'm like whatever it's not a big deal, but then, when I I was like well fix the name, but when I looked at it, it wasn't n, plus one error. There's an in plus one Courier and I was like that was staring me right in the face and I didn't even see it. That was dumb. But, like you know, that's not something you feel like before.

B

D

That's why I called him and I was like thank.

B

You for for pushing me on this fish. All I was actually an invisible and performance there and definitely should have been fixed. It wasn't just the timestamps were different yeah.

A

Well, that's, but that's like the main thing with that's. The main thing review is is like pair. It's like asynchronous pairing with questions. That's the best thing you can do and if everyone's respecting each other's questions and we get down to it, we don't just write it off of like hey, stop questioning my code and just merge it like. Oh okay, you don't even really want to collaborate here.

A

That's so if I think you've done really good both front and back in reviews Chad, where you you may have identified, there might be a gap in understanding on my part, but you're still asking questions. That's like the best thing you can do.

B

Yeah, it's more like the obvious things. I feel like I should be getting that I, that I, missed or.

A

It's it's it's it's it's hard like front. It's it it's hard! No, absolutely what I do with revealing is I check it out locally and I start I start changing it and if I I start changing of like okay, this is weird. Can we make it simpler and it's like oh yeah? This is how we could do it and then I then I asked myself. Okay is this worth? It am I being nitpicky here, it's often times like yeah, that's not a big deal, but as I start changing it. Sometimes it's like wow.

A

We didn't even need this whole component, and so that's how I could get to I can review a bunch of new units in like 10 to 15 minutes, because I'm really really comfortable, writing front end codes. So it's like okay. This is how I would have done it. I was like all right. Here's how we can review it. Yeah.

B

And I'm pretty comfortable with Ruby but like with Ruby, there's at least a half a dozen ways to do anything you want and then like half the maintain your own symptoms like. Why? Don't you just do this and one line instead of five and I'm, like oh yeah, yeah, that's totally a thing we could have done missed.

A

That yeah yeah, no yeah I think get back to it. Don't don't feel bad if you get review comments, um everybody gets review comments. That means you're collaborating.

B

Yeah, it's me that I don't want to like. There is a. We now have the um inevitable uh deadline for Rd, which is like a nice month and there's like 100 reviews to get through. So the cycle you said of like yeah, it's an asynchronous collaborative pairing exercise. It's like yeah! Well, that's, that's! Not all gonna happen in the next month and.

C

That's not in reality on the timetable, then yeah.

B

Let me um why I want to really have them as policy possible, but not my original question before.

A

I hit him over, but how do I know what that is? But let me let me kind of kind of uh can I give to you um a strategy to potentially make reviews less friction. Full, um please I would potentially see if you can find maintainers ahead of time. Well,.

B

We already we already are doing that. We have a handful assigned and.

A

Then I would I would assign them first to do a like a big gloss. Over of like does this all kind of look? Okay, you don't have to detail review this, but is this kind of look okay and that then signed it to the initial review? With the context of the maintainer already said, this large approach is okay?

A

Can you do whatever initial review um that way, as you are looping in random initial reviewers, if that's the option or whatever they um understand that what the possible changes could be and no one's going to throw a huge curveball uh and an MR.

B

Yeah, it makes sense and we actually have like a you know like three back-end and three database reviewers and then you and Enrique are the ones for the front end and they're they're, all maintainers. So hopefully yeah everybody will have contacts. There won't be anybody random and as I get one thing since we've done all this on the integration branches I find out.

B

One thing that I missed I can go through the branch and make sure that I've pitched that everywhere else and they exist for future ones because we'll be pulling chunks out of this integration. Branch for multiple Memoirs yeah.

A

Oh, what uh why is git Labs telling me my Mac requires a security update, friendly yeah I did gitlab last night the fur yeah I'm gonna defer that nonsense.

A

It's gone it already. It already left me, oh well, all right.

B

Mission's about to reboot, okay! Well, thanks a lot just for just.

D

A minute discussion, it's good stuff.

B

Mostly just making me feel better, but.

A

um The initial review.

B

I have a lot of imposter syndrome around reviews, yeah I'm, like I suck at it so much it's.

A

Just an asynchronous pair programming exercise.

B

A

The thing about.

B

Like I can it's, it feels less when a pair calls me out on something it feels less worse than it's because of asynchronous nature. It's, like oh man, I wasted time and there's this whole Loop, and now there's like I've added a date of this. By doing something done, I like that, whereas para programming, by doing something stupid, you've added like 10 seconds and that's the feedback loop.

A

I yeah I know what you mean um yeah. Do you ever do like um mutation testing? Do you know what I'm talking about Buzz.

B

A

Am I talking about fuzz testing, I.

B

Don't know I'm talking about like coming up with random values within constraints. Oh no, so.

A

Mutation testing is you um change the production code and see if the tests fail like if the tests would have caught.

B

This oh yeah, like uh yeah um yeah. It is it's interesting that we don't have like I know why we don't have it in git lab, because that is a very high bar for code quality. It's hard to achieve that. But um yeah there are tools for Ruby I! Think reach is uh the one back in the day. I don't know if there's a cooler one.

A

um Yeah, so it's like it's able to test the level of like it's a way of assessing coverage, but also just like the type of coverage that you have of like if I've replaced a variable with a with a you know, null or false, like is this stuff still work and um coming from someone that does parrot? That does a lot of hair tdd?

A

This is I. I highly recommend this method of testing of reviewing the tests, knowing, if they're good enough, because that's kind of a a synchronous way for me to know like hey is our did. We may build this test Suite, you know respecting. You know, PDD principles where every little change has got to have a test around it and if off so often so often when I and engage in this exercise, there's like chunks of view, template that aren't caught in unit tests and there's there's always.

B

That's a little bit better because there is pretty strict code coverage like you have to have one for 100 line, not branch but line coverage. Marriage kind of forces you to which yeah that that is sort of the I didn't tdd a lot of this stuff on the on the Ruby side, but I did make sure 100 code coverage and it's amazing what the bugs that catches like one line, covered yep, there's a bug in that line that just happened last week. The one line that was not covered.

A

I know- and that's such a funny thing with the test of like yeah, going that extra mile really does help what you've written itself. It's gonna help your future self too, but it's funny how much testing helps that the initial development time.

D

A

D

B

A

Thanks for this discussion, yeah thanks thanks appreciate it John uh yeah, you know I, you know, I love, code review, um but I also understand like we do be nice if we, if there wasn't as big of a feeling of friction as there is with it and I, think, that's a interesting signal to be aware of of like why what's causing what causes people to feel friction with an MR well.

B

It's compounded by our async nature, so it's like the person happens to be on the other side of the world. You're like okay, there's at least a day cycle here, maybe more depending on your schedules, and secondly, especially in the back end.

B

It's like the the GDK and just the size of it with the Ruby code, like even if I want to run coverage locally, even if I want to run a test, Suite locally, like we're talking I'm in for at least a half an hour for to an hour like just even for a minor change that I need to face and then waiting the pipeline to run an hour.

B

It's those things make the feedback loops even worse than they would be just uh if, if it were a fast test suite and a co-located team, doing this sort of review, QA.

A

Yeah yeah um I was gonna say, like um initial reviews are uh optional, like they're, not the required. The maintainer is the only bit that's required. So when things have a tight deadline, um sometimes it's getting initial review from people within the same team is fine. You don't have to listen to Danger bots, so it's like all of the the normal Mr process. Isn't a lot of those are suggestions and um when things are have a deadline, we can be flexible with it.

B

Yeah and like remote development, it's a green field feature so I'm, not sure if that means like and we're in definitely an MVC mode. We're like just get something out that minimally Works to run the web IDE in it where they had that's her goal. So I'm not sure if that means like, like the bar for the code quality since the Springfield should be tend to be lower or tend to be higher, but.

C

B

I've architected, it is like there's, there's all of our plumbing in the graphql and the services and all of that stuff, but there's the creamy middle of all of the domain logic, which is mostly pure Ruby stuff under the lib folder, so yeah I've, tried to like all of the standards and stuff should be like in the architectural here is outside that layer. Does their service look right?

B

There's a database look right now the index is right, but then, in the middle of that it's basically this is just Ruby code and domain logic, so I'm, hoping that at least it segregates and and we're planning on doing those things in separate Mrs. So we'll segregate the types of feedback that we get for the different demons.

A

I think you answered, though, like the question perfectly just right, then of like hey, the the Greenfield architecture should be solid, uh but um sometimes there's gonna be messy parts, and as long as those messy parts are just kind of put in a little architecture box, like that's great I, get nervous with new things introducing messiness because I think don't. This is how we got here with all this technical debt at gitlab. Don't do it again, but.

B

A

But I think it's not it's more about architecture and my concern I think with new things that just like we got to just get something out there and you have no architecture and everything's referencing everything and everything's coupled it's like this is going to grow out of hand. So.

B

Yeah I explicitly avoided that, like there's coupling a high cohesion like that is my Mantra in my software development life, and this definitely follows that it's like okay, here's, here's the middle step with all of our domain logic, and then all of you know the the same like hexagonal or layered architecture and the ports and and adapters that that's that same sort of thing, it's like yeah, the middle parts of the database, you know, but other than that it mostly all the tiers above that are as decoupled as possible from it. That's.

A

Another great comment, though self review comments leave is like when there's those parts of the code that we kind of don't like ourselves, we know, are a little messy, but we've put effort to contain them into a little box, leaving a comment of like hey I realize this is weird and there's a lot. We could do to improve this, we're on a deadline- and it's just here and it's tested we're gonna refactor later, but we got to get this thing out like that's.

B

That's a great point because we have like a whole docs repo dedicated to this. That's got our architecture, but I should like, even though what I just said, I've told people like I should write that down to like link to it at the top of maybe every Mr like this is oh sure, overall, our architecture here- and this is how we're decoupling this and it's you know intentionally in a layered architecture, reports, adapter style, yeah,.

A

Yeah, and and and doing the best you can to like, give every every stakeholder in the Mr an executive summary not just read all the documentation I linked to, because they won't just saying hey here's the point you can look at it here like that. Goes so far. It always pays off uh I'm speaking hyperbole, so maybe maybe not always pays off, but.

B

A

Thought it was family and friends day. I didn't think it was going to show up I every day is family every day is Family Day for me, so I'm.

A

B

Yeah I, just I, have a meeting with Enrique about the remote. That's enough stuff, uh like on the hour. Okay I showed up early for this nice and wanted to chat about this. Thanks is some good feedback, cool.

A

Well, yeah: good luck with uh 16-0.

B

I, don't think you're gonna get out of this for neither Paul you're gonna you're gonna get a sucked into this. Oh.

A

No, you read between the Lions.

A

uh Jana, do you have anything? That's like 160 deadline that you're working on.

C

um Not so much fortunate uh yeah, luckily there's nothing.

D

C

Regarding the major version like there was um business end of Milestone stuff, but nothing that I I know that it is since the the deprecation and things are going on in my team, but I'm also yeah I do have some distance to them. Luckily, so nothing, nothing too too complicated on myself.

A

That's good somehow um editor is is, are we able to say the new group name I assume, so it was all in public channels. The new group IDE team um is uh um I, know. I, know.

A

um Somehow we, uh uh what was he gonna say we always end up like having deadlines.

A

I feel like we have a lot of deadlines for a team, a group compared to get other parts of gitlab.

B

Well, we we've started I've been pushing for the ad, like uh yesterday's weather-based, agile approach and we've got we're breaking down to smile issues and estimating them. So if we get everything that we know, we want to be in, it's really just broken down, and we we waited like we already have. Our velocity is 12.5 like I can come up with a quantifiable number that says we should make this or we're not going to make this when you want to cut, rather than the um arbitrarily imposed deadline, driven uh method of.

A

Planning, why is that's really wise? I I was really I was really impressed when you were able to calculate the the velocity I was like man. That's that's powerful knowledge.

A

It's really interesting.

B

The volatility is very high, so like it's coming with a huge caveat, we're like 25 the first uh week, five of a second, it's like this.

A

Oh, no, if you tell Eric well hey, we can only do 15. Eric's like what about that one week you did 25.. Could we get one of those weeks again? No airing Aaron doesn't do that. I know he wouldn't that's funny. Well,.

B

Shields is from that, if any of you.

A

Yeah, do you all have um any Mrs that you want to pair on or any other topics or.

C

I'm I'm just scrolling for something. If, if you folks wouldn't mind- and um let me just tell you about it in a second so I just couple of minutes ago, I got assigned an uh MR2 review. It is massive and it's just been scrolling through it. Don't know much about it um what's actually going on, but what I just figured was like: okay, interesting.

C

um It has some changes to Startup scss committed, which is um fine, I'm, hoping it's auto-innovated, but that's what.

A

I'm missing out of yeah, it will fail if it's not auto-generated. uh uh Startup CSS is like the Pod files. Gotcha.

C

Gotcha, the the thing is, the the changes in there are looking really really interesting to me and interesting, as is as if and buggy, um so whatever um this semi is changing. This is what we came up to add on Startup CSS, it's just two empty media queries, yeah.

A

C

Weird, do you agree, um and it looks like to me that this is probably calling us.

A

ah Super sidebar, um your super sidebars nearby um I, think I, think I know. What's going on I've.

C

Got an idea um can I give it a shot. First sure, I I, think that, like this there's some automatic uh automatic thing.

D

C

These things and it's probably taken all the media activities that are existing in account or something and it's like yeah. Basically, okay, I, don't really know, go ahead. Sorry, no.

A

You're good, uh can we jump to the oh seriously super sidebar thing there.

C

A

Wait though, I'm looking at the changes to the framework super cyber, can we scroll up on the that one, oh scroll down? No, no sorry I've just met the whole file. The super sidebar dot, CSS CSS yeah, so.

D

A

It is that and not.

D

A

Yeah, if we, if we, if we um can, we expand the rest of the files from the top of the super sidebar thing. Yeah.

A

Prefers reduced motion, what an interesting man CSS web specs! They go deep, I.

C

I get um like I get the first reduced motion, media, query and I. Think it's a good feature. What I love most about it is that it says like no prep, so why you bought it. Okay, well, it'll, be they'll, be some kind and ask people, but just if they don't care, then we're going to be doing this.

A

Right right, I I have a feeling it's related to the not, which is why, for some reason, it's.

A

Can we go down a little bit more.

A

Okay and then, if we go down to what's showing up in the the CSS, so we get these just completely empty ones.

A

It's possible that we are.

A

Oh I think um page with super sidebar.

D

A

Yeah, something weird something weird is going on: there.

A

At the same time, it's like startup CSS, isn't isn't super important, but it could be a sign if something's off with the actual CSS, that we're generating um I have a feeling that something's, probably off with our startup CSS.

A

um The script that generates this thing to.

C

Agree what would be the sorry? No, no keep going yeah. It will be the the takeaway like for me as a reviewer as a film like. It's definitely not like this is nothing to to bodily offer with, because it's um like that is all generated, I think so it's basic, probably opening an issue for the startup CSS. We have a link to it, but I can see this being quite a pain to to the previous, but that is probably a part of the solution for the well.

A

I would ask a question here: I would say this is really weird or is everything working as expected? I would ask a question uh on. Why are these media queries empty and.

C

Gotcha yeah, that's let's do it like that um I'm kind of afraid that um I already know the answer from the offer, which basically will be saying like no idea. It's order generated.

A

Well then, so you know at least he asked right, oh yeah, if we were pairing on this you're asking it right now, let's just ask it transparently, so everyone can see the question of like this is weird.

C

A

Up to you, I'm gonna say it's it's up to you. If you want to say it's blocking or non-blocking like and or just if you want to space say this is a non-blocking question, or this is a question with to with, alongside the other things and.

D

C

Yeah I would probably go with it's a a non-blocking thing, but I would hope. I would want to see a follow-up on this, like that. We saw that we don't lose it.

A

C

A

Very weird: do we have any other media queries in?

A

So let's, let's, let's take a look at something real fast, because because I got nerd sniped by this just now we gotta I gotta figure this out what happened with the media Min wits, 1200 pixel one, and how come that.

A

Do you see online 1486, so this is immediate query that is working.

D

A

So my question is.

C

I've got an idea: what's going on yeah, um nothing more than an idea, but in the media query in here we are looking in transition, uh we're speaking about transitions, which doesn't make sense, but I would argue that maybe it's the transition e is never considered in critical in startup, CSS I think you're totally right. If there would be a border or whatever in here, it probably would have made it.

C

So we have probably including media queries into startup CSS as long as they exist, no matter what and we're not checking if they're empty or not uh we, we are checking the keys in there. If they're important enough and transitions, probably don't qualify, that's more or less educated, guess, I.

A

Think you're a hundred percent correct.

C

Interesting stuff, yeah.

A

Out of the link, did you see the link I sent and the chat? um Not yet here we go yep so I mean this. This code is really old and it comes from. This algorithm comes from the original startup CSS generator, which was a separate which was like a separate project uh all together, but see get remove testers and one of the things we're testing for is.

A

If the prop is transitioned, so we don't need to include Transitions and startup CSS, yep, and so, but the reason why, then you don't see the class references. If you go down to get empty nodes to remove, we look for apparently we're able to look for empty, like selectors.

C

A

And remove those but we're not able to look for empty media queries. Somehow, oh.

C

My God, okay, honestly I, wish I haven't ever found this um because, like I I get it like that, that's uh spot on. That is what we're looking at, but that will probably be quite a pain to fix and the. If we get a fixed in this script, the outcome of it will be saving two four lines in our startup CSS. So that's quite a tedious job, but.

A

But like sometimes like I would just create the issue. No one here has to take care of it. This is a bug with startup CSS, we'll just create the issue. um Yeah. That's an interesting! That's really interesting.

C

Yep that was what's what's coming from I. Don't know why um I usually um skim through those those startups as changes yeah. It's.

A

A big deal because it can, it can show, even if sometimes, if we use at CSS like the Ampersand thing incorrectly, it can cause an explosion of selectors that we're not aware of so it's like. It's really helpful to see it um yeah. Let.

C

Me let me rephrase that I actually know what what I'm skipping through those startup CSS files um since I'm aware how vertical or about the high prioritization we're loading them with. um So that is that is our Superstar, more or less. So you really want you want to making sure that there's nothing odd in there. So therefore, that's that's what it's coming from.

A

Yeah yeah, ideally we can get rid of it like that's the we don't be great to get rid of startup CSS. If our CSS was small enough, that we could just or if we did things differently or maybe it's not yeah,.

C

Bundling would be would be a great Approach at first.

A

Yeah Simon um I know that he's he's really wants to he's trying to conduct some research to invalidate startup, css's existence and so.

D

A

Would be that'd be great, absolutely.

C

It is um yeah, it's it's a Band-Aid Solution, that's for sure.

A

Yes, yes, this is better than the previous Band-Aid, uh the previous Band-Aid. It was all checked in and not auto-generated. It.

C

Was handmade hand tailored.

A

We had a script on a separate project that generated it uh awesome, but it wasn't ever updated and one of the gnarliest things that would happen is uh flickering. You would try to remove a rule.

D

A

Startup CSS includes that rule, and so your production, CSS and the startup success are out of sync and service. He says is overwriting things and they're conflicting with each other. Very very gnarly stuff happens, reverse.

C

Than flickering okay, I see yeah.

A

But now it's all auto generated so we're a little better yep.

C

Yeah I remember that um I definitely remember the the introduction of the Auto Terminator um solution. Not so much don't remember, running into issues yeah no.

A

Thanks thanks for asking that, thanks for asking that that problem so I, what I did um I did a project-wide search for transition and then in files to include I did star startup star and it showed that line of code of like oh yeah, we're filtering out transition stuff in startup CSS. So um that's how I that's I! Think you had you had the idea of like yeah. Maybe transitions aren't important, startup CSS, it's like oh I, think you're right. So it's like okay, yeah.

C

uh One day in one of those sessions, we'll uh we need to be speaking about regex in vs code. I feel like I, can learn a lot from you that that area, oh.

A

Nice yeah well.

C

That'd be amazing.

A

More regex everyone loves reading regex, so I just highly recommend adding as much regex as possible to your Mrs.

A

I was a little offended that people like, even if I just add, regex and it's and it's straightforward people, don't want it because they're like this is grow out of they become unmaintainable but I like regex.

C

I've recently been in a situation where I had an MR, um it's two people reviewed and I had a non-veget solution for something, and the first review asked me to uh to add a regex to this um I'm, not comfortable with giving any names here, um and these second review actually came in and let's definitely not do the super regex. So sometimes, as you offer you kind of feel in between the lines, so that happens as well. You know you know. That's.

D

A

Yeah yeah, oh well, all right, Nicole thanks everyone for hopping up! This is fun. Shaded, I'll catch you all next time, bye thanks bye! Thank you.