Coding Blocks - Google’s Engineering Practices – How to Navigate a Code Review

Episode Date: June 8, 2020

As we learn from Google about how to navigate a code review, Michael learns to not give out compliments, Joe promises to sing if we get enough new reviews, and Allen introduces a new section to the show.

You're listening to Coding Blocks, episode 134. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And computer us at codingblocks.net where we find show notes, example discussion, and a whole lot more. And if you have any questions, you can be sent to our email address, comments at codingblocks.net. You can follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page.

And with that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. Man, I just had a moment of panic. I looked down. I was like, did I hit record? I did. So we're good.

We're good. Oh, I thought your moment of panic was going to be saying too many W's. Yeah, it might have been that too. But first, this episode is sponsored by the University of California, Irvine Division of Continuing Education. One of the top 50 nationally ranked universities, UCI offers over 80 certificates and specialized programs designed for working professionals. And Datadog, the cloud-scale monitoring and analytics platform for end-to-end visibility into the performance of your entire containerized environment. And today we're continuing to talk about Google engineering practices, specifically related to code reviews.

But first, a little bit of news. Yep, we don't have a ton this time, but we do want to say thank you to code reviews. But first, a little bit of news. Yep, we don't have a ton this time, but we do want to say thank you to Stitcher. Hey, we had some iTunes ones also, didn't we? Nope. No. Okay, just Stitcher. Alright, so we have Gene. Oh, man.

I'm not sure on this one. Giyami, Mistelli, and GitterSkow. So thank you both of you for leaving reviews. And I think both of those actually mentioned our Slack channel as one of the things that they truly love about Coding Blocks. And we mention it every time. If you haven't joined the Coding Block Slack, you're really missing out. Truly a great group of people there. And I say group lightly. It's like a small country worth of people in that Slack channel.

So definitely go up there, man. There's some great conversations to go on. And I will be back there soon, hopefully. I got to say, man, that was an impressive – even if it was wrong, the way you pronounced that name, it was impressively like – it sounds like it would probably be right. I think it's Guillaume. I think is what Guillaume. I think is what it is. But yeah, we'll find out.

I would have never even come close to anything like that. You want to give it a shot? That's my point. You want to give it a shot? No. Don't do it to him. Don't do it to him. Okay. I was trying to give you a compliment, man.

Why you got to make this a jab at me? Thanks. It's not a jab. It's just always more fun. Oh, yeah. Put me on the spot. How about you say the name? And I'm like, oh, thanks.

That's not what I was looking for. I was trying to give you a compliment. I won't ever do it again, though. I learned my lesson. Awesome. So as Joe said, we're going to get back into the Google engineering. I think this kind of wraps it up, this episode right here. So we're going to get back into the Google engineering. I think this kind of wraps it up this episode right here. So,

um, we're going back into code reviews. And the first thing that we want to talk about is navigating the change list in a code review. And it is changed list, right? Yeah. That's what they,

that's what Google refers to it as, which we've always in the, in, in the past called PRs, right? Pull request because we use the GitHub terminology. So, um, but get Pull request, because we use the GitHub terminology. Not GitHub, but Git.

Git terminology, yes. So first, does the change make sense, and does the change list have a good description? So we've talked about, I feel like some of this stuff is sort of rinse and repeat in other sections that we've talked about, but they go into a little bit more detail here. But one of the things they say is if it doesn't make sense, you need to immediately respond with why. And you should do that and you should tell them what they should have done.

But there's some keys here. Be nice when you reply, right? Like, you know, this is wrong. Torched. We're not touching it. You don't do that right? Like, yo, this is wrong, torched. We're not touching it. You don't do that. You say, hey, this looks really good, but hey, you know, we are actually deprecating this part of the code base, right? Like maybe if that's what you're doing, give them the reason why, and then also follow up with, hey, maybe what you could do is move this over here, or, you know, maybe I need you to change this here to make it

more in line. Yeah, we actually have a whole separate framework for logging that is not part of our authentication library. And so your logging framework belongs over here. Right. It needs to be dependency injected, right? Let's not bring that in here or something. So yeah, there's, but the key is you need to respond quickly so that the developer can make those changes for a number of reasons. But we'll get into those here in a minute. Now, let's be honest. How many times have you ever done this? Especially the be courteous part.

Oh, the courteous, I'm not sure. I try to be nice sometimes. The part, the thing that I guess is frustrating, and I think you guys can attest to this, if you haven't established some good boundaries in your code base, then it's hard to make anybody be the person that dies on that hill. You know what I mean? Yeah. I, that's kind of what I was thinking because like having, you know, not having worked for Google where they, where they have these published,

uh, you know, here, here's our published standards on how to review, you know, handle your code review. Right. Uh,

I guess in, in, in my career, like, you know, because there wasn't these published standards, then it was kind of like, okay, I said that this is the way it should be and you just got to take my word for it.

Whereas at least in this Google setup, then they're like, no, no, no, we actually have it documented. This is the process. You have to follow this. And if it doesn't, then it doesn't fit in. Versus in my situation, people are like, I don't care that that's how you want it. Well, one of the things that comes to mind for me is when people like, we talked about it before, like we've, we've all worked on projects where those projects sort of become the dumping ground, right? Like there's 5,000 utilities in it. There's everything under the sun just lands in

there. Yeah. The utilities project. Yeah. And it's really hard when you want to draw that line in the sand and be like, no, we're done with this, right? So Outlaw puts in a pull request. I'm like, no, dude, this doesn't go in here. He's like, what do you mean it doesn't go in here? But no, I mean, I guess what I'm saying is there might be, if you have a good, separated, a nice, clean architecture, right, where certain components live in certain places, it's a whole lot easier when somebody puts in a pull request or a change list that sort of bucks what should be in there

and you could call that out. As opposed to if you have this huge monolithic project that has everything in it, what are you going to tell somebody? Move the folder? Right? Like, so that can be hard. But here's, here's one thing that was interesting. If you do shoot it down and I found this really curious cause I never really

thought about it. If you find that people are putting in changelists to your code base and, and you're finding yourself multiple times saying, no, this doesn't go here. No, this doesn't belong here. No, this is the wrong pattern. Then you should probably set up like a readme, which I think Joe even said he's a fan of having readmes in every directory. And I'm not opposed to that. Like set that up so that people can see before they go do something that, hey, these are the standard guidelines for what should go in here, and this is what will get a PR approved or not, right?

Well, just to, like, give some clarification there, though, because, like, if you have a very small project, and you're like, why would you have a readme in every directory? Yeah, you're probably right. In that scenario, it doesn't fit. Right. right. In that scenario, it doesn't fit. But in the case of a mono repo, where you have a team with a big code base and everything is in that same repo, and it's broken apart by the directory structure, then you might want to have a repo, read me at the repo's root level to describe the overall, this belongs here and that belongs there. And then inside of each one of those things, be like, okay, here's what's, you know, uh, you know, to describe like, Hey, here's the

web app. And this is how the web app version works. And, you know, Hey, here's the database and how the database works, you know? So you might have different read meets for those different, uh, inside of those different folders, because those different folders represent different functional pieces. And I know you're going to argue with about like, well, why would that all be in the same thing? Trust me, mono repo, it's, it happens. It's kind of a thing. And by doing that, really what you're doing is you're saving a developer a lot of time and frustration. And not only that, you're probably saving yourself some time and frustration too, as one of the reviewers, if people know that they shouldn't

be putting this type of thing over here and instead it should go over there, then you're not going to get tapped on the shoulder a bunch to do reviews that don't make sense for your area of the code. So I like that. I wouldn't have thought about it, but I thought that worked out well. Yeah. The next thing that they bring up here is you need to examine the main parts of the change list. And this one's kind of interesting, too. I don't think I've ever thought about this, but I think it is actually going to change how I do code reviews is look at the file with the most changes first. Never thought about this because they're usually like. Untypical.

Yeah. I think you get the way that the PRs come in is it's almost always just what you said, right? Like directory, alphabetical, and then the file alphabetical under it. But if you could look at like, even if you have to skimp through the files, see which one has the most changes, like there might even be a number next to the file that says how many lines have changed in it. Click on that thing. That way you might get an idea of what the overall change is doing. And then chances are the smaller files that are being changed to the, the smallest number of changes.

Those are probably just tertiary to whatever that main file is doing. Right. So yeah, I can, that can help. I think this is going to be a big part of like it, it, it,

your, your tooling, though. For us, for example, we use Azure DevOps on a daily basis. And in Azure DevOps, when you submit that pull request and you're reviewing it, you see all the files in alphabetical order.

Directories and then files in alphabetical order. So you don't really like see hey this file had 90 of the changes in it or you know or even you know it had 30 changed lines versus this other file only had one you don't that's not apparent to you it makes me wonder what tools they're using that are different right like? Like I think Moralia had, you know, told us about the internal things that they do at Google. I'm curious if they've got some other sort of change list system that surfaces those things better, you know? Yeah, you know, you just remind me.

So I got my butt kicked hard on a leak code problem last month and it was doing a diff. And so I ended up going down a rabbit hole, like reading about how Git does diffs and like just common diffing algorithms. It turns out there's an amazing algorithm that works really well for diffing that like Git uses by default. Turns out it has a couple of different options, but it's pretty dense. But I grabbed a link to a really cool article that I read specifically about how Git does it.

And they looked at the main algorithm, Myers diff algorithm, which is like the most common way that diffing programs do their diffs. And it tells you like the minimum changes you need to make to make one thing equal another. It's really smart. It's really cool. Definitely not intuitive. And it's a dense read. But if that's something you're interested in, definitely check it out. And this guy actually wrote a book. And this is

a little segment of that book, too. If you really want to know how Git works at a very deep level, this is a good read. Yeah, this is not leisurely reading here. I just scrolled the page and I think my eyes melted. Yeah, it's crazy.

Just because I can't resist. What it does is it basically generates kind of a graph between the two. And it goes through. And so if you've got – if you imagine a matrix. Oh, here we go. Imagine a graph. But you generate a matrix. And where things are in common, you kind of draw a line. So it's kind of like – we have like a board game like Chutes and Ladders.

Yeah, Chutes and Ladders is the one where you can kind of draw a line so it's it's kind of like runs you have like a board game like chutes and ladders or uh yeah chutes and ladders is the one where you can kind of go through and there's like some places if you roll the right dice you can kind of take a shoot and shoot you to the next like level okay so you jump the line a bit and so basically that's kind of how it works you generate this graph and then you go through and you find the minimum uh distance from point 80 point b on this graph and you can kind of of take these, these shoots to jump the line and that's places where the files are the same. And so the result is that you get the minimum number of things that need to change. And you can tell the difference between deletes inserts and replacements.

I mean, it's an amazing algorithm, but I mean, prepare to spend a few hours reading about, you know, generating graphs. Yeah, this is one of those black holes that you fall down. So don't save that leet code problem for 11 p.m.

No, you know what they did? You know what they did? What did they do, Joe? What did they do? So I did May, you know, and then I did June. I did every day. I did the leet code problem challenge contest. Wait, we're only like four days did June. I did every day. I did the Elite Code Problem Challenge Contest. Wait, we're only like four days into June.

Oh, wait, sorry. I did April and then I did May. And, you know, April had some definite hard spots. May was mostly better. There was one spot where I did terrible. And then the last day of May was terrible. It was this different. It was the first hard problem.

By the way, Elite Code hard is insane. Elite was this diff one. It was the first hard problem. By the way, leetcode hard is insane. Leetcode medium is hard. Anyway, so it was like the last day of April, it was an easy problem. It was like, hey, thanks for playing. Here's an easy one. Oh my god, May. Punch in the gut. So I finally ended up cheating.

But in the meantime, I did read a lot about diff algorithms. That's awesome awesome but here's the thing it's fine to cheat when you're doing things like that because you still learn something right so yeah i mean i spent two hours on it still so it was like and streaming it so i streamed myself cheating uh in a contest awesome that's excellent maybe illegal who knows oh man so getting back to this changeless thing now, one of the things that they say is if the CL is actually too big for you to understand by just looking at it,

then there's a couple of options, right? One is ask the developer to point you at sort of what you need to be looking for. We all know that if you're just looking at these code changes and in partial lines or whatever, it could be nearly impossible to figure these things out. So that's one. The other one that I found really interesting, I'm curious if you guys have ever done that.

Before you go to that one, I just want to point out that other one though, we've actually talked about that where we talked about like the buddy review system where, you know, you might have, you pair up with them just like, Hey,

walk me through your change list here. Point me around what's what and everything to make it easy for me to figure out, to even try to review this thing. Now go on to this one because we're going to have a discussion here. Yeah, I'm really curious on whether or not you guys have ever done this.

You can ask the person, the developer, to split that change list into multiple change lists to make it smaller and easier for you to change list into multiple change lists to make it smaller and easier for you to digest in the multiple change list no don't do that don't do that why not well because it's separate it's hard to separate those changes it's not like you can just easily make changes in one folder without changing another and like what if one gets merged and the other doesn't and just it's asking someone to go back on something that was really hard and finicky and probably involved a lot of replacements and kind of dangerous like high wire walking and you're saying can you like do this in like eight

different ways you're like no no okay i'm gonna find a new reviewer that's all i'm gonna do yeah exactly i like how you think so so here's the thing. In a utopian world, right, then yeah, sure. All pull requests would be small and they'd be easy to reason about. I get it. I get it. And we should definitely strive towards that more often than not. but once you already put together a pull request and if it happened to turn out to be, you know, a beast with, you know, uh, you know, whatever that means to you, if it's 10 files or a hundred files or a thousand files, you know, you can't always split that apart

into multiple. So yeah, sure. You can ask me, that doesn't mean that it necessarily can, because what does it mean to like make, here's three small pull requests. Neither of the, none of them will compile on their own, you know, individually until they're all in. And so you worse, you don't want those things to get merged in individually in, because now in your Git log, you have three separate things that like, or, you know, or until you get that, that last, that third one, you might have like two commits in there that aren't going to work, which from a Git bisect point of view, you know how I feel about that. So, you know, you, you, you would want those things to all go in as one thing into, you know, whatever branch you're merging into. So you can ask, but that doesn't mean you're going to get it.

Be prepared for disappointment because it's going to be a big part of your life. I agree with that. I think the only time, and I may have asked somebody to do this one time, was when a bunch of style changes got mixed in with actual real changes. And I was like, I can't even see this. In the case of refactoring like that we kind of covered that once before the fine and the refactoring effort like put that in but i'm talking about specifically real changes you've made you've made some big changes and now all

the other changes that are following along are just like uh ancillary well i can't say that word uh you know side effects of whatever the big change is you know because i can't say that word, uh, you know, side effects of whatever the big changes, you know, because I can't say English doesn't mean that you can't, um, uh, you know, so, so, you know, you, that whole thing, it's not fair to like, try to ask me to split up like, Hey, I want 30 files that, you know, into a, into its own pull request just to make it easier to read. And, and if you like, hopefully you have, uh, some validation, you know, rules on your, your pull requests so that, you know, before a pull request, like one of the things that has to happen before a pull request can even be merged in is the fact that it has, uh, that it builds successfully and passes the test.

Right. And so that's my point is like, you know, if you were to do this, it might, you might have three independent, smaller pull requests that none of them compile. Yeah. Yeah. I don't think it's necessarily something that would happen all that often. It doesn't seem like it would be. So here's the next thing that they say. And this one's interesting, too. They basically say if you see a major problem with the change list that comes in, you need to send feedback immediately. And and. OK, I agree. This they have some really legit reasons for it.

So the first major one is that if a developer just put in a change set that's going to be pretty big and fairly gnarly and you see a big problem with it, chances are they're moving on to their next task that might build off that one. Right. And so if you're getting ready to give them a response that says we can't do this, hit the brakes. You want to do that early enough so that that developer doesn't then go on and waste a lot of time on the next thing that they're then going to have to redo. So here's my thoughts on this. Again, because of Azure DevOps, for example, as an example, when you're going through that and you're reviewing a specific file, right? And you can put a comment in line with what you're like reviewing like a specific file, right? And you can like put a comment in line with what you're reviewing, right? That, that feedback gets immediately sent back to the,

the author of the pull request, right? So, so you are immediately responding back. Now, where the rub though, is that this comes back to the one that we talked about earlier, where you want to review the biggest change first, you know, you want to, you want to review the meat of what the actual change was first. So that if there is this big, uh, showstopper problem, you know, that you can see it first, which in the case of like the Azure DevOps, you're not going to get to it eventually. You know, it, if that file happened to start with a Z and you know, the other 300 files were alphabetically before it, you're not going to see the real meat of the change until you get to the end. Right. The, the next thing that they said, and this also makes sense, this kind of

goes back to the previous one a little bit is all of of us have deadlines, right? It's not like you just get to work on things until you finally finish it and you're good, right? We've always talked about the fact that developers, if left to their own will, would just refactor themselves into the perfect state of code at the end of some millennium. But here's the thing. Knowing that we all have deadlines, if you're not getting back to them in some sort of timely fashion, right? Like somebody puts in a pull request or a change list on Monday and you're not looking at it till Friday and this stuff has to go out Friday,

you've now killed their ability to go in and do things in a timely manner, right? So it's really just respecting the time of the person who put the effort in, in the first place to put in that change list. If you want me to change three things, but person who put the effort in, in the first place to put in that change list. If you want me to change three things, but I still got the branch up, the editors open, it's on the file. No problem.

If you come back a week later, it's like, Oh, come on. Oh, right. And it seriously can be that bad, right?

Like if you're in the middle of a big, some big change that, that you're working on, sure. You could get stashed that, but, or, or,

you know, whatever your source control system is, but man man that context switching can be really tough it can be really hard you know this made me think that um even if your tooling doesn't show you the file that like where maybe the bulk of the changes were that like you know hey there's a there's a thousand files that changed but you know they changed, there's a, there's a thousand files that changed, but you know, they changed because of these, you know, 90% of them changed because of these five files. Right. So these are the five you should look at first. It made me think, you know,

we should all probably take better advantage of pull request templates so that we could like put it in as a template, like, Hey, as the author of the pull request, you need to call out what are the things, what are the, you know, the number of files that I should look at first, which, which, which are those files are the ones I should go after first during this code review. I like that. Yeah. Which I think, I mean, you do that. Yeah. something like a visual studio online to where they don't put it up in your face.

That's a really good thing for the developer to help the, the reviewer out. So, um, Oh, and then, so here's another thing they say that I thought was really good. Also it, I think at subconsciously I do this a lot of times,

but it's nice to hear it because it'll make you think about this. If you look at the change list in the appropriate order, the sequence that makes sense, and a lot of times that might mean look at the unit test first, because the unit tests typically are testing what the developer expects this thing to do. And you might be able to look at that and get a really quick understanding of what this change request is supposed to be doing. Right. And then, like we said, after you go to the bigger file, go to the files that sort of makes sense when you're looking at that bigger change set, then you can look at the files that look like they should be associated with it. And they said, not only will that help you understand it better, but you'll probably get through the change list much quicker, which I don't know about you guys, but looking at change requests

can take a lot of time. Yeah, not fun. Yeah, not usually. I mean, so yeah, that was all good stuff. Yep. One thing I mentioned here too was the speed of code reviews reviews we've kind of mentioned that a little bit and i think we hit on this before but basically the idea here is that the velocity of the team is more important than the individual so even though it takes time to do a pull request because code is so much more often read than written you're better off to to make sure it goes in good the first time and it's worth taking people away from their work with some caveats.

So the idea here is that if someone is slacking on doing an individual review, then maybe they're getting more work done, but they're slowing things down for the team. Because as you know, when stuff kind of sits out there in pending status, people get irritated, first of all. But changes start stacking up and people start saying, well, I'm waiting for this before I do that. You're creating dependencies and things get kind of deadlocked. But also, you know, if you can basically just find a good break point, you know, in your day.

Like if you know you've got some codes coming up, some code reviews coming up, they recommend kind of just doing that. You know, like if you've got a meeting, do it after the meeting or do it before the meeting. Cause you know, you're not getting much done before that. And, um, I mean, that's a good point. Is it like, if you, if you're, if you've already taken yourself, if you've already context switched for the point of view of like, you know, you were in a meeting and so now you're free or, you know, you just got back from the lunch. Those are great opportunities to be like, okay, before I dive back into like trying to some problem, let me just take a moment, review this pull request, and then go on. Yeah, don't drop what you're doing. But they do say roughly one business name is the max that you should try to let these things go because of all the reasons we mentioned.

I will say the thing that you have up above it there, if there's a long delay and it encourages rubber stamping, that's huge. That's huge. Yeah, it's another bad thing. It's like as time goes on, like you feel guilty going back and asking someone for, you know, those three changes that I mentioned earlier. And so, you know, if it's six days later, you might, you know, feel worse about asking them to make those changes and they're going to certainly feel worse about doing it so the the quicker you are to fix the easier that fix is going to be and uh like uh like you mentioned uh looking at the files in a meaningful order uh can help uh so either looking at which ones have changed the most or maybe if there's some sort of natural organization to kind of start at the top it's a good way of going and i also just wanted to kind

of emphasize that i'm talking about response times here. So when we talk about the speed of the code review here, I'm specifically talking about the length of the total time of back and forth between like reviewer and coder, not like how many minutes you spend reading the code. Right. So from the moment I've asked for you to review the code,

how long until you actually respond back with any feedback at all regardless of what it is yep so what's that latency what's that time that pull request is sitting idle that's the number to try and get down within reason uh and they basically say when's it okay to lgtm basically you know rubber stamp it and uh they gave two specific reasons and i was kind of uh i don't know i don't know how I feel about it. One, they say when the reviewer trusts the dev to address all the issues. In other words, they're just kind of saying, like, okay, there are three or four comments on this pull request. I'm going to go ahead and LGTM it right now, assuming that you're going to make these changes.

And I don't know, that felt a little weird i mean i i get i get saying that and kind of being like yeah okay you're going to change this name to that name and then we're good i get saying that but uh i guess i'm so used to kind of like once that approval goes through it like actually goes on emerges so i guess it kind of depends on your process but i didn't love that i don't know it just kind of felt weird. Well, okay. So just to be clear, because I don't know that we've ever defined LGTM, but that was Google's abbreviation for looks good to me. So, you know, again, in typical compaction format, you know, their middle out compression is amazing. And so, you know, they abbreviate everything. But I mean, like, again, if we were to compare this back to the Azure DevOps world, right?

Like, you can approve with suggestions. So, like, I've written some changes, but I can still go ahead and, like, mark it as approved with the suggestions. With the knit. But that's different than just sort of, that looks good to me. It looks sort of like a rubber stamp type thing is what they're saying. I don't think it's rubber stamp. It's definitely not a rubber stamp. Yeah, it's not hitting the approve button.

But it's like saying like pass. Right. Yeah. So, yeah. I guess what they're saying is if it's super minor stuff, then you don't – I don't know. Yeah, it's okay to let it go through. Well, that was actually the next one is that the changes are minor yeah and it's just not worth holding things up and so you can say hey go let's go ahead push this through but um you're going to fix this stuff afterwards and they did make a

big point to say uh you know sometimes it's tempting to say like okay let's push this through but then write another ticket and go clean it up afterwards because like i know you're trying to get this out from the demo and they basically say like yeah that's great in theory but uh as time passes you're less likely to return to that and so so often that ends up just never happening so don't do that which we all know to be true here all three of us know that to be true oh we're just gonna shove this in so that we can put it out there and we'll fix it next week year decade how many times you seen in to-dos or temps and stuff in comments so that we can put it out there and we'll fix it next week, year, decade. How many times have you seen it in to-dos or temps and stuff in comments?

Yeah, I remember there used to be, I don't think it was like built into Visual Studio. I think it was like a resharper bit where it would like find the to-dos so you could actually have a separate pane in Visual Studio that was specifically all of the to-dos so you could actually have a separate pane in Visual Studio that was specifically all of the to-dos. And it had already found them all in your code based on just searching for the string. They ended up being like the warnings. You just ignored them because the list got so long that you're like, whatever.

This episode is sponsored by the University of California Irvine Division of Continuing Education. UCI is no stranger to online education, having offered online courses to students around the world for almost 20 years. There's never been a better time to get a quality and convenient online education than right now. Learn from anywhere, anytime by choosing a schedule that fits your needs. And are you looking to get a job in data science? With UCI certificates in data science, predictive analytics, and machine learning, students gain the necessary skills to land their data science dream jobs. If you're looking to become competitive in the global marketplace,

advance your career, or start a new one, UCI has the resources to support you on your new path. Enrollment is now open for the summer quarter with courses beginning as early as June 22nd. And if you're concerned about the cost, don't be. UCI has scholarship options for those that qualify. So learn more by visiting ce.uci.edu. That was ce.uci.edu slash coding blocks to learn more and reserve your seat. One more time. That was ce.uci.edu slash coding. And reserve your seat today. All right. Hey, so Joe here. And, you know, I've asked nicely.

So I'm going to try and switch things up a little bit and tell you that just directly we need reviews. We need them bad. We are hooked. You guys have been too good to us. And we just need more. And so, you know, done being nice about it, I'm just going to say, you know, if you don't leave us at least 17 reviews for next episode, I'm going to sing a song about it on the next episode. Well, this is with this tattoo, right? Now you're just encouraging people to not leave a review so they can hear you sing.

Wait, crap. I said it the other way. If we get 17 reviews i will sing a song about reviews i like it that's there you go that's the way to do it yes sorry we get more reviews with honey than uh whatever the other thing was flies so wait are we doing ice ice baby what's the song going to be? Oh, yeah. You'll see. You've got a lead review if you want to hear the song. All right. Oh, man.

If there was ever a wish, please hit the 17 views because I really want to hear it. I really want to make this happen. No worries. It's a nice guy. Outlaw and I will make 10 fake accounts and we're going make this happen i'll accept it

okay well um until next episode right now my favorite portion of the show is coming up but next episode it's definitely going to be listening to joe's singing. But for now, survey says. All right. So a few episodes back, we asked, what tools are you using to ease work from home? And this was a multiple choice. And so your choices were RDP, VPN, Citrix, Zoom, Skype, Slack, WebEx, Hangouts, Team, Discord, Pigeon, Jitsi, Messages, FaceTime, Join.me, and GoToMyPC. So let's let Alan go first. And tell me which one you think would be the most picked choice in percent. Man, this one's going to be tough. I think this whole work from home thing has got people needing to talk to each other a lot more face to face.

So I'm going to go with one of those. Okay. And I'm torn because Zoom kind of got slapped around a little bit. I would say it's probably between Zoom and Teams would be my guess. Okay. But I'll go with Zoom, and I don't know how this is going to pan out. We'll say that 40% of people are using Zoom. Okay. I like your thought process there.

All right. Well, I think that we use the word ease. So I think I'm going to go with Zoom and 100%. Everybody. Everybody. First time ever this ever happened. Okay. Okay.

He is the math wizard. He is. You can't fight him on that. All right. All right. So, Alan with Zoom at 40% of the vote and Joe with Zoom at 100% of the vote. Joe wins with zoom at a hundred percent of the vote joe wins you're both wrong oh what was the skype skype hangouts no but i like all these second guesses that i'm getting like you know i can see where your

insecurities lie because you're like oh that was that was the one I was going to pick next. I truly don't know now. What was it? Okay. So look at this list, man. This is mixed, right? Because we were talking about just easing work from home. Are we going to say RDP?

VPN by a long shot. Oh, my gosh. How did you not miss the most generic of all of them you had to tunnel into your network yep so man that was surprisingly that was not 100 of the vote though yeah it really should have been so um i guess we need to have a talk with some of these people that didn't pick VPN. They just got their work computer sitting on a public IP somewhere. I guess, man, because it was only 67% of the vote. Wow.

I didn't even think about VPN. Yeah, that was definitely. But, I mean, I did like where your logic was going with the Zoom. I mean, that made a lot of sense. But Teams was number two. Oh, wow. Yeah. Which isn't surprising. A lot of companies use Microsoft tools for Office, Excel, all that.

It comes with it, right? Yeah. And if you've never used Teams and you're in an Office environment where you have to share documents and stuff, they do a really good job integrating that stuff. Yeah. Yeah. So Teams, it was like almost 58% of the vote. Wow. We'll call it.

Wow. Again, this was multiple choice, so this is why you could have these percentages the way they were. Zoom was the number three, though. Okay. At 36%. Even though it got beat down pretty hardcore during the beginning of this whole thing, but you know,

I mean to zoom's credit, I mean they, they, they, they got the feedback and they immediately went to work solving the problems, right? They stepped up their game.

So I mean it only ended up making their product better in the end, but yeah, they did take a lot of, um, bad, bad press, you know, for it. But interestingly, Slack was number four at 28%.

And I got to tell you, that's got to be much higher. So if you're not already a part of our Slack community, you need to join. You can go to codingbox.net slash Slack, or you can find out information on how to become a part of that if you're not. Because really, we need to make you can go to codingbox.net slash slack or you can find out information on how to become a part of that if you're not because really that number we need to make that number higher i agree the fact that you've got giphy integration is is enough to be on slack that's like the reason to be on slack so oh man they just got bought by facebook did Did they? Yeah. 400 mil. When did I miss that? I'm not even sure.

There's a lot of news lately. Why? I always questioned, hey, what is their... I get their value. I like the service. It's fun. It makes using the internet fun, right? Because you could just throw in a GIF every now and then. But you ever wonder, like, wow, how do they make money like how does this work

dude it's a tracking pixel yeah and they've got so much data you're talking about slack think about this oh giphy yeah yeah yeah giphy like they're basically one big tracking pixel you might be right i mean you really think that? Like, they just see that their ship it gif gets added to our Slack and that matters? Dude, that one's so good. You know, another one of my favorite all-time gifes is the rejection one where the guy opens up the door coming into an office in like a robot suit. Somebody shoots a basketball and he just smashes it down. That's funny. The company says that there are no

tracking pixels, cookies, or other embedded user tracking information in their Giphy GIFs. But, I mean, they're literally a tracking... The reason you use tracking pixels is because it's an image that's requested from a server so you can know more information about who requested the information. The same thing works for a GIF.

It's one big tracking pixel. Dude, so check it out. How Giphy makes money. Is this the Investopedia? Yeah, Investopedia. I had to do it. Giphy hasn't generated any revenue to this point. It does not charge any money for the use of its apps.

It's currently operating off the $20 million venture capital money it raised over the last two years. It has been busy lining up licensing deals when media producers and music companies become a major content distribution company. So they have plans. Yeah. I got plans. I got plans. We can sell plans. I didn't know we could sell plans.

It reminds me of Jeff Foxworthy. When the people come to him like, hey, we need you to pay off your car. They're going to repo his car. Yeah, you're going to repo his car. We need the money. He's like, if you can't yeah i ain't got no money well i mean can you write us a check he's like oh oh you need a check yeah i can write you a check i'll pay the whole car off right now

that's awesome yeah yeah i don't i don't understand it. It does make you wonder, is Giphy being bought a sign of the dot-com era coming back? To where you just have a plan for something, right? You're not making any money. And you don't really like... The value of Giphy is not going to the website so it's not like you have a strong advertising model there and when you use giphy you don't want anything else being injected into wherever you're using it except for the image so it's not like you can say like oh there's a strong advertising model here because now I get to see it.

And even with that tracking pixel idea, I'm like, I still don't understand what the value of that would be. Okay, so what if I see the ship it GIF show up 8 billion times on the coding box Slack? Like, what does it matter? Right? Right, yeah. Like, I don't know. I'm lost. No, their plan is this, right? You're going to say Giphy and then, you know, code review rejection or something, right?

And you're going to get your funny thing. And then right below it, there's going to be a little Justin Timberlake thing that's played, right? So that's what's going to happen. It's going to come along for the ride. Yeah, maybe. I don't know. But then people are just going to stop using it, though.

Right? Nah. Nah. It just depends on how offensive. No, I mean, if they make it too invasive i have an idea oh well let's hear it because you might be able to sell it for 400 million dollars let's make giphy too okay all right yeah yeah it's like seven minute abs yeah and we'll spell it uh gI-F-Y. Yes.

So it'll be shorter. That domain's probably available. Six-minute abs. All right, so for this episode's survey, we asked – because I thought like, hey, in light of the pandemic, right, and people working from home, have you guys ever noticed that, like, you go and work from the office life versus work from home life, that your work from home life, you tend to, like, spend more time. There's, like, less boundaries as to, like, when you stop working and start working, you know what I mean?

So you end up putting in more hours. So I thought, okay, now that more people are working from home because they're being forced to, we ask, how many hours per week do you work on average? So the choices are strictly 40. Work-life balance is a must. Or less than 40. I value my time. Or more than 40, but less than 60. Why do I do this to myself? And lastly, more than 60. Please help me. I have a problem. These are anonymous surveys. Just saying. I mean, sadly, I've been in situations where we would definitely put in way over 60. I mean, 80 wasn't even a thing. It was like, who got the most hours in this week?

Yeah, it's a bad pattern. Yeah, I mean, there would be times where we'd hit triple digits easily and it was like okay that's that's insanity i'm too old for that yeah no doubt i wouldn't do that now i wouldn't say well hold on when i said yeah i didn't mean yeah like i'm too old for that i meant like yeah i wouldn't do that anymore but i mean joe yeah you definitely yeah i entered a new decade man it's and let me tell you nothing's been the same since everything's falling apart now right oh yeah everything hurts it's falling apart like okay i understand every rem song suddenly wait you heard it gets better in the 50s why is that i thought i thought 40 was the dip and then it's it's up yeah i don't know

you're over the hill so everything gets easier hmm interesting i don't think i'd fall downhill from here great as a bicyclist i know what that means yeah you better have some good breaks that's all i'm saying today's episode of coding blocks is sponsored by datadog the unified monitoring platform for real-time observability and detailed insights into docker performance enhance visibility into container orchestration with a live container view and easily detect clusters that are consuming excess resources using an auto-generated container map out of box, Datadog collects critical metrics from each Docker container so you can get immediate visibility into aggregated and disaggregated service level traffic. So what are you waiting for? Try Datadog today by starting a free 14-day trial and receive a

Datadog t-shirt after creating just one dashboard. Visit datadog.hq slash codingblocks to get started. Again, that's datadoghq.com slash codingblocks. All right. So speaking about the kinds of comments that you can leave on a code review, we already mentioned kind of be kind and explain your reasoning. I think it's really important to explain your reasoning. Otherwise, you know, you could kind of sound like a jerk. You don't want that because it just makes it harder to get through.

I probably am bad about this one because a lot of times in code reviews, I'll just ask one or two things or make one or two statements. And then I don't go into a long explanation of it. So that's probably my bad. Yeah, I mean, you got to find out what works for you. But they did specifically mention questions kind of sounding accusatory sometimes. So if you say, like, why did you do something? It kind of puts the person in a defensive position where they feel like they need to defend themselves. But instead, if you just, you know, which maybe it's harder to even say, like, this could be simpler if you blah, or this

is in violation of statute 1113. Well, kind of the example that I was thinking of specifically to the questions though, is that like, if you, if you submit a pull request and you include commented out code in that pull request, it's a brand new pull request with brand new commented out code, then I'll ask like, Hey, did you mean to commit this? Like, you know, was there, cause there might, you might have a legit reason. Like, yes, I meant to do it because, uh, you know, I'm going to, I'm still iterating on it and tomorrow it's, it's not going to be commented out, but I needed, uh, you know, my boss needed me to go ahead and get what I had working already in there and I didn't want to lose it. So like maybe there's reason. So, you know, I boss needed me to go ahead and get what I had working already in there. And I didn't want to lose it. So like, maybe there's reason. So, you know,

that's the type of questions that I was thinking of. You know, it's so funny about this. I've definitely been guilty of the, why did you like, like I was almost personally offended by how something was done. You could read that and be like, why did you, and you know. And sometimes that's why you typed it that way too. Like, what in the world were you thinking, right? Right. Yeah.

So, yeah, definitely be aware of how your words may be read. Yeah. Yeah. Like, you know, whatever some of the, it almost sounds like rhetorical. So, if you're like, why did you name this that? You're like, oh, no matter what they, whatever I say, I'm going to get spanking. Yeah, exactly. Yeah. So, yeah, just remember that.

You know what it sounds like when you question. And, you know, it doesn't mean don't ever say questions, but just, you know, realize that sometimes it can sound like – and there's obviously cases where it's fine. But they also mentioned balance giving out directions with pointing out problems. And so there is kind of, I think, a tendency with programmers to kind of want to solve the problem, be like, look, type this like that, exactly this like that. But rather, they advise rather than saying how to fix the problem, just kind of demonstrate the problem and let the other person go back and fix it how they want to fix it. Because maybe they're closer to the code or maybe they have different ideas or maybe there's another reason there so just highlight the problem without trying to come up with a solution i like that because that's really part of the magic of being a developer right is having that creative freedom to to make things and you know all three of us be given one thing and do it three

different ways and it'll all get it done yeah and so there'll only be one right way though there's no right way might not be the more right way it jose's jose will be the most just right way yeah the most just right yeah i'm the most, well. So they essentially used to explain why things are important. But ultimately, it's not your responsibility to fix the problem. It's sufficient for you to just state the problem, but you want to be courteous about it. Because most frustrations, most problems, most bad things that come out of code reviews, most things that people are worried about with code reviews, actually have very little to do with the technical. It's more about those interpersonal kind of emotions. Like you don't want people to think you're dumb when you're

submitting a PR or you don't want to sound like a jerk if you're rejecting a PR. These are all people problems. These aren't technical problems. So it's important that you think really hard about how you phrase things because that's the sticky part. That's kind of the, that's the rub. So just thought it was really interesting. And at one else point, uh, they mentioned it was really good is, um, if you have comments or if someone has to explain something to you in person or via email or in the PR system, then, uh, that's probably good candidates for things that should be for information that should be in other places, uh, whether it's a ticketing system or it should be comments that are in the code or something searchable or that has history. Because usually once that pull request is merged in, like people don't see that again. So any comments, any discussion, anything that happens

over email or in person is lost. Like all that context disappears. So if you can codify that stuff into the code or into the ticketing system, then that's much better than leaving that stuff in the pull request system. Man, I completely agree with this one, by the way. And we've mentioned that we use Atlassian products. Like we use Jira. And I can't tell you how many times that a conversation might happen in email or might happen in these code reviews. And I will literally go put it back on there because it'll happen a month or

two later. Somebody asked me a question. I'm like, I can just go search here and it'll pop up. Right. And that is so invaluable because like Joe said, you're not going to be able to go into Azure or like visual studio online and search for that stuff.

It's not going to be as easy. And that's, it could be really valuable to have that in a place where anybody can go find it. Right. Yeah, absolutely. I'm,

I never, I mean, this is a great point. It never occurred to me and I'm definitely, I've, I'm definitely bad about it. I don't go back. I mean,

I mean my, well, first of all, I mean, not to brag, but my port of crest, I have a lot of comments on it. Uh, no, I'm just kidding. I mean, well, first of all, I mean, not to brag, but my port of crests don't have a lot of comments on it. No, I'm just kidding.

But, yeah, so you copy that stuff back out and put it in a JIRA? Like, no. If there are questions that arise in the PR that make it not clear, right, then I will put that in the JIRA ticket to be like, hey, this is the stuff in here, and this is what this does, because it wasn't clear enough or whatever, right? Then I will put that in the Jira ticket to be like, Hey, this is the stuff in here. And this is what this does. Cause it wasn't clear enough or whatever. Right. I mean, I do love the idea because, you know, definitely it's real easy to search the Git log, but to search the pull request. No. Right. Yes. Maybe a way of saying that it's like, you say, Hey, this could be simpler if you did this or that. And the developer comes back and says, actually, this is very specific

because the next ticket I have is going to make use of this. So it wasn't, you know, Yagni. This is like me getting ready for phase two. And so you could say, okay, well, you know, we've had this discussion. That makes sense to me. Is this documented in the ticket? Did you say that you did that? Or is that something you could add, you know, or document some other way?

And maybe it's not worth it. You know, that was kind of a bad example there. But it's worth considering to say, like, maybe this just should, you know, or document some other way. And maybe it's not worth it. You know, that was kind of a bad example there, but it's worth considering to say like, maybe this just should, you know, this kind of discussion, like this, this thing that I saw and had questions about is something that somebody else might have questions about. Like, let's make sure we have that somewhere else. Yeah.

And by the way, for those that have never heard the term Yagni, it's Y-A-G-N-I. You ain't going to need it. It's a very good one. And it's often true. It is. Unfortunately. I think that was a Fowler thing. It is. There's actually an article from Martin Fowler on it. It's a pretty good one. Maybe he didn't author it.

He just blogged about it. Yeah, he's got a good blog on there. I got the link. We throw it up in here. No idea. I'll put it in the resources. You know what, though? I bet there's a Wikipedia page for it.

There is? There is. I'll just read it. They also have see also and a list of other funny terms. Dry, Mascow method, Muncing, worse is better, solid. Some pretty fun ones. All right. So what do we got next on the docket here?

Oh, yeah. This is just kind of a continuation of the previous conversation, so handling pushback code reviews. So if the developer disagrees with you, if they push back, then you should take a minute and consider if they're right, because like we mentioned earlier, they are probably a lot closer to the code than you. They spent

hours with that, wrestling with that. Maybe there's some context there, some stuff that they don't know. And so if they do take the time to push back, then think about it. And if you think that your suggestions really do improve things, then don't give up on it. Don't be afraid to go back to them and say, well, I think this does make it better. I hear what you're saying. I hear why. But don't let that be a reason to roll over if your suggestions are still valid. And of course, everything needs to be polite because you don't want to end up in an office grudge match. What if it is an office grudge match?

Then what do you do? Well, then you take it to the court. Either the basketball court or Judge Joe. Oh, I thought you meant the people's court. Yeah, so streaming Thursday nights, Judge Joe. Judge Joe. I agree to mediate disagreements and pull requests for a minor fee of hundred dollars mock trial with judge reinhold that's right that would be fun please state your case how do you plead i plead correct my code is correct yeah and alan is wrong for

saying otherwise do you have any tests to back up let's see the evidence hey i like where you're going see here uh so people tend to it was which people tend to get more upset about the tone of the comments rather than the insistence on quality because like who doesn't want quality right so it's probably more that they feel like they're being picked on or they feel like uh you know someone's judging them harshly or not considering their needs or whatever this this is where like having like when i mentioned earlier about the published you know google has like a published standard and you know not having a published standard can actually be problematic

because then it's real easy for people to say, if you have the published standard, then people can't say like, oh no, you're picking on me because why would you do this? But if you have the published standard, then you're like, well, this is why we actually have this published reason why. But by not having that published standard, then it's real easy for the team in general to not be consistent about the process. And so then it's easy for somebody to feel like they're being picked on in the review because you're not consistent. Yep. You have objectivity. We talked about that a little bit with like metrics, like code coverage or whatever. If something goes down, you can say like, hey, code coverage is going down. We need this to go up. And that's something that the other

person can't, you know, dispute like it either it is or it isn't. And it also gives you some levity to say that without coming off like a meanie pants. And because you're just kind of, you know, pointing out the rules, like you hope someone would do for you. Right. And when he's mentioned, uh, the longer you wait for cleanup, the less likely it is to happen because, you know, it's just harder to do it later. It's easier to just gravy day one like it's gonna it's gonna be bumpy there's gonna be a rough spot there but i think over time like i i don't know anyone that's really gone through a case where they decided to back away from code reviews or gone away from i think like i've definitely heard horror stories of how you know reviews went bad or it didn't go so great but i think over time those businesses always kind of work things out for the better

and they either were less stringent or they relaxed the rules or they made the rules tighter or whatever. They did something to make those pull requests better. I don't think I've ever heard of an organization that stopped doing code reviews once they started. Yeah, I think so too. And I will say for people that are nervous about it, I think we might have mentioned this, not even when we were talking about this stuff, but back a long time ago when we first maybe did our Get episode, if you've never been a part of a pull review, it's natural to be nervous about it, right? Or a pull request, like putting in your first one because you're going to feel like people are judging you.

But just know that the entire process, if done well, is a perfect opportunity for everybody to learn and be involved and improve the product. Right. And ultimately, what you'll find out is they're not scary because you'll find out what people are caring about and what people are looking for. And so your code habits will tend to steer that way and vice versa. Right. As you're code reviewing other people's stuff, the same type thing will happen. Right. You'll start molding the patterns and things that you want to see come into there. So it's really a give and take type thing that ends up being beneficial for everybody.

Now, you know, in fairness, as you said, we were wrapping up this in the Google engineering practices. And, you know, this was all from the point of view of the Google engineering practices. And, you know, this was all from the point of view of the code reviewer, they actually have a set of documentation to from the author of the change list, like how can you, you know, write a your change list so that when it goes through the code review process, you know, all good things can happen. And just like in fairness, you know,

high level of some of these things, because a lot of this is already like, we've kind of already described it from the point of view of the, the reviewer side, but like, you know, one of the first things they talk about is just writing a good description in your, your change list, which, you know, is where I had the epiphany of like, for example, of using like a pull request template and like the value that that could have. And so they go through talking about like, you know, what the, you know, the benefits of the good description could be. And like we've said already, you know, if you, if you call out like, Hey, this is where the, you know, the body of what you need to go out, which you should look at first, right. And that way the reviewer can immediately focus on the meat of that problem. I mean, that, that makes sense. Right.

But they also go on to talk about like calling out like, you know, functional changes versus refactoring changes, you know, like, you know, in your description. So, you know, that makes sense. I think, though, I would still prefer the refactorings to be done as a separate pull request. If I had, you know, if it's possible, I think I would prefer to see that separately. And just to also go in a little bit, cause you mentioned the template earlier and I don't know if everybody's familiar with what you're talking about. You're basically saying when you put in a pull request or a change list, usually there's just a big text box there that you can just start typing stuff in. Right. But what you're saying is you should almost have defined sections of what you want people

to fill out. Right. Like, yes, here's the description. Give me the synopsis. Right. Give me the bullet points of what you expected to change in this thing. And then down below, it might be, did you include unit test? Check yes or no.

Did you do this? Did you do that? Right. So having that template that people have to go in and basically fill out and check the boxes and fill in those blanks, having that thing set up ahead of time that everybody follows can ensure that everybody's getting an easier, you know, view into this pull request when they go look at it. Yeah. And in the next section that they have, specific to, you know, the authoring of the change list, they actually do call out that it's best to put the refactorings in their own, you know, pull requests, like to keep that separate.

But, you know, really they favor small changes over, you know, here's my thousand file, you know, pull request, right? And it's for all the same reasons we've kind of already hit on in the past, you know, it's going to be reviewed more quickly, it's going to be reviewed more thoroughly, right? It's less likely to introduce bugs. You know, it's less wasted work if it's rejected. I never really considered that one before. But that makes a lot of sense, right? You know, think about this from the point of view of a code review. If you put in that thousand file change and somebody rejects it, you're going to fight. You know, you're going to want to be like, no, no, no, no, no. This needs to happen and here's all my reasons why, right?

And even if what you did was bad, right? Like you're still going to like, you're not going to be able to hear it for a while because you've got some investment in that thing. Whereas if it was like a two-line change and somebody is like, no, no, no, no, no, you should never do that, then you're not going to care, right? But they also say that the smaller ones are easier to merge, which I don't know. I'm kind of like we have the tools for that. I don't know that I'm kind of like, we have the tools for that. I don't know that I care about that one. Uh, it's,

it's, I would say though, it, it can be easier to deal with like fewer, uh, merge conflicts. You're less likely to have merge conflicts. So maybe that's what they mean.

Um, but they do say it's easier to design well. And, uh, you know, there's less blocking on the reviews because, you know, there's less to being reviewed.

And it's easier to roll it back on the small change. So you definitely favor the small over the big ones. But they do list out reasons where large change lists can't be helped, right? So like deleting an entire file, right? In that case, if you were to consider your changes by like lines within a file, right. Then deleting the whole file, you know, you're wherever you can do that. And, and we've talked about like, sometimes we're like, uh, because of refactorings, you

know, all the touch points that might happen elsewhere in the system require, you know, a bunch of files. And that's why it's so important to be able to call out like, Hey, this is where you need to, uh, focus your, your, your time from a reviewing point of view as to like, what, what matters when you look at the, um, the pull request. And, and, and some of these like, you know, it's crazy to even cut for them to even call it out. Like don't break the build. Like that should be obvious. If I it out, like, don't break the build. Like, that should be obvious. If I've got to tell you don't break the build, then there's other problems. But, yeah, they do call out another one that is important.

And this is kind of to your point, Joe, that you just said, was that keep your test code should be in the same pull request, right. So, you know, you asked for the proof, uh, judge Joe asked for the proof and, you know, if you have the test in there, then you can, then you have that proof there. Right. Um, so, and, and, you know, when, uh, I think it was Alan that was talking about like, or, you know, asking to make the pull request smaller and you're like, sometimes you just can't, right? And so they acknowledge that. Like sometimes you're just not going to be able to make a smaller pull request.

Like it is what it is and you're going to have to deal with it. And then it goes back to, you know, don't break the build. And then lastly, you know, as it relates to the, like, handling the pushback from the code reviews, right? You know, I mean, they start with, don't take it personally, right? Like it's, it's not meant to be personal, even though outlaw might've asked a dumb question like, Hey, why did you commit this commented out code? Like, I don't mean it from a bad place. I'm just not good at communication. How's that? Right. You know, but, but if there is like a legitimate, you know, thing that comes back, you know, a problem is, you know, then fix it,

you know, don't, don't take it personally, just fix it. Right. So, yeah. And, you know, worst case scenario, if it does, but if it does get to be the point where you are adamantly defending your change and why it might need to get in and some reviewer is saying, no, it doesn't, you know, then, you know, rather than taking it personally and getting into a fight with them, like, then that's where you might need to bring in a team leader, an architect, or someone to weigh in, another party to weigh in on what's happening here and give their two cents, right? Definitely. But yeah, so that's it. So we'll have a bunch of links

to the Google Engineering practices documentation. And I love that Google has this stuff available for us. You can see how they work and how they're thinking through it. So we'll have a bunch of links to that as well as Yagni cause we all need to understand that. Um, you know, and, and more importantly, like how does get diff work? Because that's, that's probably the most important thing we've learned this evening. Um, and with that, we head into Alan's favorite portion of the show.

It's the tip of the week. All right. So I just set up a pie hole. If you're not familiar with that, it's basically a Raspberry Pi that accesses the DNS server for your house. And it's got a gigantic multiple lists of domains that it will block, basically send to a black hole at the DNS level. So your computer goes out and says, hey, I need, you know, ads.google.com, whatever. And the pie hole business says no nothing

and so rather than your computer sitting there waiting for that request it basically you know returns quickly and so uh it makes things feel snappier you block a ton of traffic it's just really cool and i was amazed at how easy it was so if you were wanting to get started with like a raspberry pi and just kind of get one and you're like looking for a reason this is a great reason i mean it's like seriously 20 minutes and it was just kind of cool um i just have a lot to learn about networking so i'm kind of using that as a chance to play around with uh my new mac daddy router i just bought um so i got a link to that too uh it's a uh you guys familiar with ubiquity yep yeah so it's kind of. UBNT, you'll see a lot of people talking about it. Apparently,

once you get one, you want more and more and more. I now have a 10-point 10-port router, even though it's the Edge Router 12. The numbers are all kind of mixed up. It's just been really cool. I'm setting up subnetworks

and breaking all sorts of stuff, and then I just reset it and it's all good. It's been easy to set But anyway, it's just been really cool. So I'm like setting up subnetworks and breaking all sorts of stuff and then I just reset it and it's all good. It's been easy to set up, but it's been fun. So I now have a bunch of stuff wired and now I want more Raspberry Pis. I've been thinking about setting up a Kubernetes cluster because why not? I'm sure Kubernetes on a Raspberry Pi would run amazing.

Yeah, the new ones are good. So I bought the Raspberry Pi with four gigs of RAM, and now they have them with eight gigs of RAM. And I'm using like 2% for my Pi hole. It's ridiculous. You could run it on a way old Raspberry Pi and be totally fine, but I'm running on kind of one of the nicer ones. Does anyone else need that name, by the way?

I'm okay with it now. Okay. With what name? Raspberry Pi. The Pi hole? No. Oh, pie hole oh yeah i don't like pie hole yeah yeah it feels dirty i i just could we call it something else nope um yeah i mean i i i'm looking here at your links though this thing looks pretty awesome i'm not gonna lie i especially especially like you have in here. Can I steal this? Can I announce this?

Yeah. I love how you put it in the show notes as Outlaw's Next Pi Cluster Case. And, of course, I had to go click on that because how could I not, right? And I'm looking at it and I'm like, I would totally, I endorse that. I endorse this. I want to go to there and I need one of these in my life. And it is a, it is a, uh, was it like a four, a four? How would you say that? A four stack, four pies in this little bitty case that is a pie rack.

Yeah. Small pie rack. There you go. Better way to describe it. That is like just a little bit better, a little bit bigger than a 120 millimeter fan, but in true outlaw fashion, the fan is RGB LEDs. So yes, this is outlaw endorsed. I would, I would, this is the one I would get. Hey, so going back

to this model number on it, right? So it's called the 12, and I think it's fair to call out that it's 10 ports that are RJ45 ports, but it's also got two SFP ports on it so that if you needed to hook it up to another router or switch or whatever, you got

that fast transfer between it. So that's why you got the 12. So they weren't too wacky on the naming, you know? No, it's just confusing. Like if you get the four, it's got two usable ports.

If you get the, it's like all of them are weird. And even like the, uh, the edge router six pro has the same number of ports, ports as the edge router 12. And so like the numbers that for the series have nothing to do with the ports,

which is very confusing to me. Hmm. Got it. Now the, the edge router that i'm like more familiar with it everybody likes is the edge router x that's only the four ports yes like four or five ports something like that itty bitty and it's like 50 ish bucks i mean depending on like i'm looking at it right now on amazon and it's like 62 but if you watch the price mean, I've seen this one go down to like $40. I think I have one that I paid somewhere in like the $40, $50 range for it. And the big deal on these things is they're managed switches more or less, right? Like you can control at the different layers. Well, yeah, because it's managed, you could actually like on this five port one that I'm talking about, each one of those could be a separate network.

You could set up VLANs within it. And so, you know, you then plug five switches in. Well, technically four because one of them will be the end to it. But, you know, so you would set up four different VLANs that you could then connect to four different routers or switches, and whatever's on those switches couldn't see each other unless you, like, had specifically opened up traffic to it. So if you really want to, like, segment your network, you know, apart from one another, then you could.

So where this actually matters that I think that listeners to this podcast would really get something out of this is this whole IoT device thing around houses now where a lot of people just put them on the same network as all their other stuff. Well, almost by their very nature, the IoT devices just don't take security as seriously as your other things. And so like Steve Gibson from Security Now podcast, like he even recommended getting the Edge router back a long time ago so that you put all your IoTs on one subnet and your other ones, you know, your computers and whatever else that you want to be able to share things on another one. And then that way they're technically in the same network area and they can all communicate with the things that they need to, but they can't talk to your computers,

right? Like they can't get in there and do bad stuff because they're the weak entry into your network. So, so here's the problem that I have with it though, is that, um, support everything he said,

everything he says, right. Sounds great. The problem though, is that, uh, you know, if everything's wired, then yes, absolutely. But when you want to set up wireless, then it's like, okay, uh, well, depending on the size of your house, you know, you want to set up multiple mesh networks in your house for this. So then ultimately, you know, for a big house situation, then what you would probably want to do is go for a mesh networking system

that allows you to have multiple VLANs within it or, you know, SSDs that are broadcasted but then you know i'm not really aware of any of them that'll let you set up uh you know an infinite number you know usually they're like two two i guess you know you get you get one guest network and then the primary network so yeah i mean i want to like put all that IoT stuff off. And that's the problem too, is that like a majority of that IoT equipment that you're talking about is going to be wireless,

in which case, you know, in order to really take advantage of the Ubiquiti edge routers, you then have to have like multiple... Wireless routers or mesh networks. Wireless networks that are each connected to an individual vlan on the edge router hey so here's another question for you though joe because the one you bought is not just this thing that would just do vlans it's also power over ethernet right so the poe are you gonna buy you a bunch of wireless or security cameras and stuff

to hook into it now because you know i thought take advantage. So really the Pi, just being able to plug the Pi in without another power cord was part of what I wanted to try. I haven't actually done that yet, but I was going to do that. But I was looking at NAS too. But I don't need the PoE for anything else I know about. I thought about it. I'm going to buy some cameras. I'm going to buy some cameras.

You've got to use it, man. By the way, for those interested in the smaller version, it also supports PoE. Yeah. I mean, just a four-port router is in that price range. You can probably get it for $20 on Amazon, but for $50, you can get the Mac Daddy four-port. Yeah. That's managed on top of it. That's a big deal for that price.

I love your picks. I could talk about these all day. It is an extremely powerful router, but you know, if you, it can also be a little overwhelming because like this thing doesn't come with like instructions. Like you kind of have to know how to manage a network or, or be willing to go explore and learn and and do some searches to figure out like what how to do what you want to do because you know it doesn't come with a manual there's like a basic yeah it really doesn't come in the manual you got like i had to look it up on my phone while i was plugging stuff in yeah but there is 20 minutes yeah there was like a little wizard that kind of walks you up for basic settings and then you can just kind of go from there so like i mean i break it all the time

i've already reset it like twice just because i did something weird i couldn't figure out only twice so far so i'm doing pretty good hey so we didn't actually ask you did all this you set up the pie hole do you like it like is it okay all right yeah it's growing but my whole office is wired now and um before i had had the main wireless access point in my office, I had several devices that were all connecting over wireless. I don't know, it caught me crazy, but it just seemed kind of weird to have all these wireless devices that were sitting next to my, what do you call it,

my router, my cable modem. But then also it just kind of made me think about all the other devices that were kind of flying in through my traffic like i was just imagining like all these you know wireless signals bouncing around in my office which i don't love but then also anything else from the rest of the houses just kind of have to try to compete with those or wireless so i figured like i'll admit like half the traffic the wireless traffic in my house just by going wired so my stuff's faster and so is everything else so why not yeah cool between that and the pie hole, I'm very happy. Excellent.

I was actually asking about the pie hole. You like that too? Oh, yeah, yeah, yeah. Yeah. Okay, good. Yeah. Because you're basically trying to get rid of like tracking type of requests, you know, like ad tracking requests and all that, like you're blocking that sort of thing, right?

Yep. Yeah, I've been running an ad blocker for years just because I don't like them. And not so much that I don't like ads really, but just I don't like all the traffic. I don't like all the stuff. I don't like all the, you know, I don't love the tracking either,

but I love just not even seeing it. And there's the only thing that I've even noticed as I've been running the pie hole is sometimes I'll click on Google on the ads at the top. I'll search for something and it'll do the sponsored. And it will try to route me through like Google's ad stuff in order to take me to the product. And that doesn't work because they're blocking it. I could turn that off.

But that's the only thing I've found so far that actually did it. And everything else I haven't even noticed the lack of ads. It's been totally transparent to me. It's just been awesome. It's just like blocking 15% of my traffic without me even knowing about it. Yeah, it's you block origin for your entire house, right? Like that's really what it is. Well, I was going to say because, you know, to Alan's point, there's a plug-in that I use.

And I guess Alan uses it too since you just mentioned it for Chrome. I think they have it for Firefox and for – actually, they do. They have it for Firefox, Edge, Opera, Safari, for Chrome. I think they have it for Firefox and for, actually they do, they have it for Firefox, Edge, Opera, Safari, obviously Chrome, called uBlock Origin, which is basically like it, the idea, the principle is that like, if it's not coming from, if the request isn't coming from wherever you are trying to visit, then it's like a third party tracking pixel type of thing. And so like just block all those extra scripts and whatnot. And, you know, you can just cut down a lot of, uh, the noise from web pages that you go to visit. And, um, you know, as a, as a side effect, you're, you're increasing the performance of the page, uh, sometimes not all the time, depend very rarely. I'll, I will run into, uh, websites that,

uh, just totally break because of something like that. But, um, but yeah, that's only, that's only going to be effective on the, on the platforms where I can install this plugin. Whereas with the pie hole, it's just blocking everything on the network and just flat out denying like a request if it sees a dns request come through that it for a known uh ad tracking or you know ad serving type of thing it can be like nope yeah and so that's what at first i i just set up my dns on my computer just to try it out and that looked good so i set up for the whole house so i blocked all my devices that i use my Wi-Fi just like that I didn't have to go around and advise

I don't have to maintain them for all I'll give them some problem with I can fix it at that level and it just applies to all of them so it's great that's awesome and sadly it also as a benefit makes your your computers and your network more secure because there's a lot of a lot of

malware yeah cure because there's a lot of, uh, a lot of, um, malware. Yeah. I mean, ads because, because they're, um, injected in, you know, there's not like a lot of human oversight into like reviewing it. Right. It's just like, you know, trusting like, Oh, Hey, you want a 50,000 views. And so I'm just going to like insert your ad in, you know 50,000 views, and so I'm just going to insert your ad in. There's a lot of bad ones that get added in, which used to be worse in the days of the Flash ads, right? Punch them on the key, yeah. You guys remember, golly, we're spending a lot of time on your tip,

but that's fine. It was a fantastic one. But you guys remember when Bitcoin mining was huge, there were ads coming out that had Bitcoin miners that were running scripts of the ads on people's computers. That's still a thing. If you just sat on a website, it was actually using up your CPU. It's unreal.

Oh, the good old days. Yeah, that's still a thing, though. But what was it? Dang it. I can't remember. Okay. Well, it'll I can't remember. Okay. Well, it'll come to me later there.

There it did die off, but there was still like a, it started with a C or something. I thought, but no, well, no. All right.

So, uh, my tip of the week was, uh, actually, it may be like, you know, maybe how I'd like to like talk about some of these books coming up in the future. Maybe, um, Google in their, uh, site reliability engineering section of Google actually have some books available for free, uh, three O'Reilly books.

Uh, one of them is called Building Secure and Reliable Systems. The other one is the Site Reliability Workbook. And the other one is the Site Reliability Engineering. And these books are available for free. You can buy them if you wanted a specific platform version, like a mobile version to carry with you. But otherwise, if you're comfortable reading it from a web page, then you can read these books for free. So I'll have a link to that. And that comes courtesy of, oh, guess who?

Mike RG from our Slack who shared that great find with us. Never heard that name before. Never? Yeah, never. You must be new to the podcast. How you doing? Man, I couldn't get back on Slack. It's been a minute. I've been too busy of late. So I've got a handful, as always. The first one is actually one that came from Andrew Diamond, one of our good friends on Slack, and he's always got good stuff up there. But

he had actually sent this out a while back and this is NVIDIA's RTX voice thing. And it's so cool. I only put a link to the actual way to set it up. And I believe you have to have an NVIDIA RTX graphics card for this to work, but essentially it will noise cancel just about anything. You can have a lawnmower in your room with you and you be talking into the microphone and your voice will come through almost crystal clear and you will not hear that thing in the background. There's some YouTube videos. Maybe I'll get a link or two in here, but there's a guy that actually has a blower, like a leaf blower right next to his head. And he's talking to the microphone and you can't hear that thing in the background. It is unbelievable. How do we know he turned it on? Say what? That's a good point.

Maybe you don't know, but you can actually tell a little bit of a difference in his voice when it does click on, but, but man, so, so impressive. This, this is where software is really cool, right? Like somebody wrote these algorithms to basically cancel out these things. So really neat stuff. Um, these next two are interesting. So I'd never heard of scoop and I don't, and I searched on our website and I didn't see any mention of it. So, um, but I know outlaw knows about this cause I think he was talking about it earlier today. So scoop S C O O P dot S H. If you go there, it's almost like chocolatey, except it seems to be more geared towards command line type things. Uh, but if you go install this thing, like the next tip that I've got here is called cube forward. So the three of us have been working a lot in Kubernetes type cluster worlds right now.

And if you're running a Kubernetes cluster, let's say in Azure or in Google Kubernetes engine or AWS, right? AKS. There are times that you really want to be able to interact with the pods that are running in those cubes. So say, for instance, you have, you know, Joe Zach wrote an awesome little admin interface for Kafka. And there are times you want to be able to see what are the topics I have in my Kafka cluster? What are, you know, what are the schemas that are available in my schema registry, that kind of

thing. And it's driven from a web UI. Well, that's exposed through a port. Well, if you are not directly connected to that Kubernetes cluster, you can't access that stuff, right? So KubeFord will allow you to spin up basically these tunnels to your computer so that you can go hit these web interfaces. So I can turn on KubeForward service. It'll forward all those pods ports to my local.

And so I can just basically go to my local host or whatever the hosts that were named on the forward and I can hit these things. So fantastic tool. If you are working with Kubernetes, highly recommended, especially if you're working with remote clusters in Kubernetes. But the cool part is, and I don't remember what went wrong today, but one of our friends was trying to install the Kube forward service, couldn't get it working. And everybody else was like, well, I just use Scoop.

And it was you just go to your command line, you type in Scoop install K-U-B-E-F-W-D. And it did it. So, you know, again, very similar to Chocolaty, a very lightweight way to install things. And on their page, which I link here, it's kind of interesting because a lot of times, like if you do Chocolaty, it might ask for admin permissions to install something. They install everything in your, I think they said in your user path. So you don't get these admin permission pop-ups. Everything is allowed by default where it's putting it. So you bypass some of these security holes that come in by forcing other

things to run as admin. So they've thought about a lot of cool stuff. So I'm down with the scoop recommendation the the coop 4 you said that was a great tool and i gotta ask like is it it is so here's the thing it is joe you want to fill it in because it looks like yeah i'll probably say the same thing you're about to say so it's really great uh in that it kind of masks some other things that you have to do by hand so it does some some keep uh forward port forwarding which you would be doing you know depending on what you're doing in other words other ways and to get your stuff in and updates uh your host file for you so you can go

to things a little bit easier which is really nice for things like databases and stuff where you can't put in like a cube proxy kind of url so it's been really nice for that but the problem is and i'm sure the reason ala is frustrated is sometimes you make some changes to pods or services and then you keep forward kind of loses connection and loses value and so you end up having to restart it all the time and it just it kind of falls down a lot more often than just manual port forwarding which seems to just work all the time and same with the proxy just seems to work all the time but the proxy if you do cube proxy it's similar but you actually have to go through like a URL, which only really works for websites. And even then, it's kind of dodgy.

Yeah. It can be frustrating. It'll crash on you for no apparent reason, too. And you'll have to kill it and restart it or whatever. I like the premise of Kube Forward. And for all the reasons you just said, especially with like, you know, for things that aren't websites, then, you know, it works well for that. But like you said, though, if there's any changes happening in your Kubernetes environment, like pods are being created based on

demand or are being removed based on demand, like maybe I want too much from it because those situations, it doesn't handle well, at least in my cases. I've noticed that there are times where you will see it trying, but, you know, definitely not all the time. And it definitely, there seems to be some kind of like longevity to like what it'll, you know, how long it can run before it's just like, no, we're done here. And you're like, no, why did you decide to just stop working? Now I'm still using this. But let's be honest, though.

If you do the kube proxy and all that kind of stuff, you have way more commands to do based off the pods you need to do. So this is truly like it's a one liner. You basically way more commands to do based off the pods you need to do. So this is truly like, it's a one liner. You basically say cube forward SVC and it will forward everything. I get it. Now there, there is one more downside to it. And this is something to be aware of.

And we saw it happen today. If, if you haven't fully embraced Docker, like the three of us have, then you probably have installed things like SQL Server that eat port 1433 and 1434 or Postgres that eats port 321 or 4321 or whatever. 543. Which one?

5432. 5432. I was close. It was the backwards thing. So if you have those things installed and you're trying to forward services that are in your Kubernetes cluster that are using those same ports, you're going to get conflicts and it'll break. Yeah.

So you'll have to shut down those services locally before you can do it because you can't have conflicting ports, which is no different than anything else. But if you did the cube proxy on your own, you can basically tell it what ports you want to use. Right. So this thing's trying to make it easy for you. It's trying to let you go through it the easiest possible way, which has its ups and downs. But I would say on a whole, I'm happier with its ups

than I'm annoyed with its downs. Yeah. I'm surprised you didn't go with the most common example, though, of like a web server. Like I asked for something like that on port 80. Yeah, I mean, I hear you. Like I am definitely

not trying to to bash on uh cube forward but you know like i said i'm probably just wanting too much from it it is it if if you want just the easy route though that's probably going to solve the 90 right so whatever that like rule that you want to follow, like 80-20 or 90-10, this is probably going to get there. Just know that there are circumstances where if you need to have something, if you need to have proxy traffic for overnight or days Right. Like at least my experience has been that it, it crashes and, you know, I can't, I can't rely on it for that type of longevity. Yeah. So I'd agree with that, but I think we both also use it daily. Like it's,

it's valuable enough to where you're going to use it all the time, but there are definitely circumstances where it's not going to meet the call that you need. So, um, now here's this last one's not even a tip. This is an irritation. It actually really made me mad today.

Are we going to start a new section to the podcast now? Like, I don't know. Do we need to take a rant of the week? That's a lot easier for me to come up with than tips, man. You know what? What's irritating, Alan? Dude, look, I'll be honest with you.

I have this super love-hate relationship with open source projects. And I mean that in the best and worst possible ways. Google, of all people, right? Like Google in their own paid for environment, there's a thing called Dataproc, right? And I will try and give this as short of a description as possible, but more or less Google Dataproc allows you to spin up Hadoop environments on the fly and additional components like Druid and Presto and a lot of big data tools, right? And what they do for you is these are not like services,

like their data flow or anything like that, to where it's some sort of managed service. This is more like infrastructure that they manage that you pay for the VM, the compute, but they've pre-configured everything for you, right? So anybody that's ever worked in a Hadoop environment or anything like that, there are so many configuration files and so many things you have to hook up to make everything talk to each other. It's sort of a pain. Dataproc takes that pain out. Well, man, I was so mad today. So they have this feature when you spin up these Dataproc clusters to where you can say, hey, install these standard components that Google will hook up for you. And they've got Druid, they got Presto, they've got Anaconda, they've got all these ones, right? And it's almost like the click of a button, like, boom,

here you go. When this thing spins up, it's running. So Presto is one of them. And I think we've talked about this in the past. Like Presto is an amazing technology that was created by Facebook to basically be able to query disparate systems and then join that data together like it's in the database, right? Like it's crazy. Hey, I want to query Joe Zach's JSON logs on his server, but I also want to query my database and I'm going to join them on something like that's nuts that it can even happen. But here's where I absolutely almost came on hinge today. So their page for setting up Presto, their entire page is like, yeah, this is PrestoDB. They even have links to PrestoDB.io. And it's telling you everything on the page.

And it's like, hey, all you have to do is in the spin up, just say, hey, I want the component called Presto. Boom, you're done, right? So this thing doesn't come with all the plugins or the, yeah, the plugins that I'm looking for because I want this thing to be able to talk to Druid. So I go to install, I manually put Druid on there and it won't work. And I'm just, I'm pouring through logs,

like I'm going crazy, right? Like, man, I know I'm doing this right. And so I'm like, well, what version of Presto is running on here? And I go looking and it's not PrestoDB. And I'm like, what kind of garbage is this, man? And I think I might've used some stronger language, but the documentation page pointed to PrestoDB.io, right? That's the Facebook version. If you ever go looking into Presto, there's two things out there. There's PrestoDB, which is the Facebook one, and there's

prestosequel.io, which if you go to the webpages, they look eerily similar. If you click on the documentation, they look eerily similar. Basically what happened is at some point from my understanding, they, somebody decided that Facebook wasn't moving fast enough with the request and branched it. Right. And so there's Presto sequel. There's Presto DB. They're different paths.

They're mostly the same product, but things have changed. Right. I mean, to that end, they actually use the same logo. Yeah. It's ridiculous.

Yeah. I don't even know how they get away with it. And here's the problem. If you ever search for Presto, you're having a problem. You actually have to pay attention to whether they're talking about Presto SQL or Presto DB because they are two different things and there's different configurations. So at any rate, to make a long story short, the documentation page for Google Dataproc in Google's own documentation says that they're installing Presto DB and they have links to Presto DB. long story short, the documentation page for Google Dataproc in Google's own documentation says that they're installing PrestoDB and they have links to PrestoDB. I launched Dataproc. I go in and I do dash dash version and the version looks eerily similar to PrestoSQL. And I'm like, that can't be a coincidence. So then I go less out the readme in the Presto folder. And sure enough, Presto SQL.io, go look at the thing.

And I was like, I've spent a day trying to figure out why I couldn't get this configuration to work only to find out it's not that software. So you guys lied to me. And this isn't even an open source project, right? This is the part that irritates the heck out of me is the whole time i've had this cluster running i'm spending money on it right so it's like i've gone down the entire wrong path because at some point somebody's like oh well i think presto sql might make more sense of presto db so we're going to change what dataproc's doing behind the scenes but we're not going to change the documentation. Dude, I have thought so much of that kind of garbage in this open source world

that I've lost more hair. And I didn't even know that was possible, right? It's driving me crazy. So that's my little nit. That's my rant for this particular episode. Maybe we will have something, but I don't want it to turn into a negative show. But for the love of God, man, if people are paying for a product, especially like I'll give you a pass if it's completely free and open source. But if somebody is paying you to use it, man, that's a lot of time wasted. Not only was it money we spent on the data product cluster, but it was also

time of mind spent that the company's paying for me to be productive. It, you know, it, I don't know that that kind of stuff just drives me absolutely crazy. And sure. I know that, that it's hard to keep everything up to date, but man, I did send feedback on the page on the documentation page where that was, I clicked a little thing the page, on the documentation page. I clicked a little thing at the bottom, and I was like, this is wrong. And I don't think I did what we said in this and be courteous and all that. I was like, this is misleading. This is wrong.

It's all trash. Did you do what I do, though, and sign it Joe Zach? Yeah. I think I signed it Michael Outlaw. Oh. Yeah, right? See, I had a missed call from Google earlier. I was wondering what that was about.

Oh, man. See, I'm hot at thinking about it right now. All right. I'm coming to back off that. All right. back off that. So, all right, well, uh, we are done with the, uh, what's bothering Alan today portion of the show.

Uh, so, uh, we hope you have enjoyed this, uh, review of the Google engineering practices. Uh, if you happen to, uh,

hear about us from a friend, maybe a friend, uh, you know, let you borrow their device to listen or, you know, gave you a link to maybe a friend let you borrow their device to listen or gave you a link to it. Subscribe to us on iTunes or Spotify, Stitcher, whatever your favorite place to listen to podcasts are. I'm sure you can find us there. And if you don't find us there, let us know and

we will correct that. And as Joe said earlier, be sure to leave us a review. You can find some helpful links at www.codingblocks.net slash review. And remember, was it 17, I think, that we needed? 17 was the magic number. We definitely want to hear Joe Zack in his beautiful singing voice. Of course, it's going to be a beautiful singing voice. We need the 17 reviews to make that happen. Was it 17 or 70? Roll the tape.

It was a teen. It was a teen for sure. 17. It was 17, I guess. Hey, man, I'm completely going off script here. Joe Zayt, you said you were looking at doing a NAS. Yes. I am looking at doing a NAS. Yes. I am looking at doing a NAS.

I think maybe we should have like this little thing. Maybe we do a YouTube series to where you pick yours, I pick mine, and then we put them together and then we compare and contrast what we like. You pick first. That's hardware, man. Hardware is not my specialty. Dude, I've read so much about this. All right. So, at any rate, that would be fun, I'm not, it's hardware man. Hardware is not my specialty. Dude, I've read so much about this.

All right. So at any rate, that would be fun. I think, um, anyways, so yeah. Uh, while you're up there at coding blocks.net,

check out our show notes, our examples, discussions, and more. And send your feedback, question, rants, and reviews to,

uh, Slack, I guess. Uh, okay. I'm, I don't know. I'm tired.

I guess. I don't know. Make sure to follow us on Twitter at CodingBlocks or head over to CodingBlocks.net and you can find all our social links at the top of the page.