Coding Blocks - The Pragmatic Programmer – How to Debug

Episode Date: July 23, 2019

It's about time we finally learn how to debug by taking take a page from The Pragmatic Programmer playbook, while Michael replaces a developer's cheat sheet, Joe judges the H-O-R-S-E competition for VI, and Allen stabs you in the front.

You're listening to Coding Blocks, episode 111. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And we got a website at codingblocks.net where you can find show notes, examples, discussion, and a whole lot more. Hey, guess what, y'all? We got a website. We do.

We do. Send your feedback, questions, and rants to comments at codingblocks.net. Follow us on Twitter at CodingBlocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm reviewing the look at the notes.

And I've got a name. Do we want to leave it there or do we want to We leave it. We leave it. Alright then, we leave it there. This episode is sponsored by Clubhouse, the developer friendly project management platform and Datadog, your monitoring platform for cloud scale infrastructure and applications. All right. So in this episode, we're continuing on with the pragmatic programmer. And this time we're talking about tools.

No, editing. Power editing. Debugging. Debugging. Source control. We got a few things on tap on this episode. All right. But first up, a little bit of news here.

As always, we got to say a big thank you for all the reviews. I'm going to read iTunes. But this time we got big thanks for sebastian schrodinger uh trick jen's savalsky uh burt 1994 dk uh brandon ford mike mac au dylan w roberts manufacturing engine ear uh and john 08 jan jan 08 i think john maybe well thank you very much. We really appreciate those. And then in Stitcher, I dare you to try F sharp, Jester, Mr. Maladroit, Sticker Soft, Infinite Pumpkin, and Space Dance. Hey, and if anyone, because Sticker Soft likes some stickers.

So if anyone likes some stickers, you just got to let us know how we can get those stickers to you you can send us a self-addressed stamped envelope you can find all the information on codingblocks.net slash swag or just hit us up on any social media platform or you know slack comments at codingblocks.net or whatever just let us know how to get some stickers

to you we'll get some stickers to you we have a website I've heard that did you know yeah my buddy joe is telling me that we have a website uh yeah uh yeah so also want to mention uh there's a great episode of the change log podcast that came out where they actually had the two authors of the pragmatic programmer on the actual show and that's of course the book we've been talking about lately and we'll be talking about again today and they had some interesting to say thing things to say about it particularly one thing i thought was interesting is just how much of the book they changed and they ran a diff of course they did right against the

old version and the new version we talked about the tools they used to write the book and of course they're not using the those same tools from 20 years ago but they're still able to diff pretty easily and they like um wrote a specific tool for doing it so they could like set the threshold that they were willing to see because like if they add a space or comma they didn't want that to count and they ended up saying i believe it was 75 of the paragraphs have changed and that was like significant change yeah i thought that was interesting that they had like specifically their uh that the threshold part of it kind of like piqued my interest, my curiosity when he said that. I was like, oh, wait a minute. What all did – what all included – what all had to count for that threshold?

Right. Yeah, because, you know, back in the day – and I used to do this. It was crazy. We used to do two spaces after a period. I wonder if they did that. There was also a stat they gave too related to the tips that have changed. And I don't remember the exact number, but there was some number of like almost all of the tips were changed or new.

And it was like only a small percentage of the tips alone that, that survived as is all the way through. Yeah. So that was really interesting. It was just interesting to hear the perspective. It was not the episode I expected to see based on the title. I thought it was going to go in a totally different direction, but it was really cool to see. A lot of it was just about what changed

and how they wished things had changed and what did change, what they hadn't expected. It was just a good historical episode. It definitely made me excited for the new version that's coming you know when the print version still doesn't come out until the fall but it definitely like made me happy you know that to like even like you know the effort that we're going through like you know kind of in my mind like as i was listening to i was like you know we're kind of like celebrating the 20 years of the pragmatic programmer. Right. And, you know, I can't wait to hear, to see the new version.

I will say before we get into the show, I've been impressed with how well this has held up over a 20 year period. Right. Like, I mean, there's definitely specifics that are different, but I mean, I'm still, I'm still like dumbfounded by things like tracer bullets, where it's like so far ahead of its time 20 years ago. And we don't call it that now. It's agile, but it's the same thing. Yeah, I guess kicking this one off then, we are going to be talking about power editing. I got a little catch to that, though, too, is that there will be like a there's another thing that's coming up in this episode related to what we were just saying about like things holding up over time.

There was one that I was like super surprised about. So I'm teasing that now. Cool. All right. So one of the things that they say, and maybe this holds true nowadays, I don't know, but they say learn one editor very well and use it for everything and i think maybe back then that might have been more apropos but nowadays i feel like there's so many good editors that do so many things really well that why would i try and force this and one that's just not as good at it right so yeah i know i'm like visual studio used to encourage you to use it for python and for

other types of language and different types of things and i just can't imagine doing that now i know i had to do that i had done that especially when i used to use eclipse a lot i used to use eclipse for just about everything i remember trying to do C Sharp and Eclipse briefly. I can't imagine doing that now. Just like I can't imagine trying to use, you know, like IntelliJ for writing C Sharp, but they have Rider, which is very similar. So I could see using something in the same family. Like that makes a lot of sense to me. And Visual Studio Code at the same time is actually really good for just about everything. So unless you're doing like a hard, well-tooled, like static language likeava or c-sharp then i think visit visual studio code might be that editor yeah that's kind of what i was getting at is if you're if you work in windows

and you're a c-sharp developer visual studio makes a lot of sense could you do it in visual studio code yeah probably but you're gonna lose a lot of the benefits that have been baked in for that language for a long time. And so it's like, eh, but there are things that I just love doing in visual studio code. If I'm dealing with Jason at all, I'm in visual studio code because I can change language mode. I can format the thing. I can like, I can, I could get plugins to parse, uh, stringified JSON. Like there's all kinds of features in visual studio code that are just perfect for that. It's like my all around editor.

Whereas I have my specialized ones that I use. Right. So like SSMS, right. Like SQL server management studio is perfect for SQL server. Could I use a different, like i tried to use visual studio code with it at one point and it works but it's no it's just not the same i did feel like like okay so i understand where they're coming with from with here and i totally am on board with like i love the visual studio analogy that joe brought up and and definitely like we're we definitely

live in a world where we're trying to do everything in code like we're trying to make it do everything right you know as a developer community but I did kind of think that like isn't this contradicting some things that were said in like a previous chapter where it was like

hey don't fall don't be that guy don't fall victim of just using the one editor. Yeah, that's right. I was like, we just said don't, and now we're talking about just use the one. Well, nobody can be bothered to go back and read that other chapter now. Well, yeah, I mean, you're right.

Yeah, I think it's really interesting. I think I mentioned maybe it was the last episode where I used to kind of be in the camp of like, you know, shortcuts are great and all, but don't waste your time. Don't try to get better at typing and, you know, you don't really need to care about that stuff because it just doesn't slow you down very much. Because the typing, my argument used to be that the typing was such a minimal part of the job that it wasn't worth working on. But I've since renovated. I'm regurgitated.

I've changed the way I thought about that particular thing. And that's from working in Java lately and trying to work with IntelliJ when I'm just not used to it. And it makes me realize just how much it can slow you down and how much of your cognitive load is dedicated to just typing. Or even VI. I don't use VI day in and day out. So things even like copying a word or deleting three lines are things that i still have to google for occasionally and so it could be really frustrating and you don't realize that like when you're so caught up with the like the minutiae of typing that you're not thinking

more high level and you're dedicating you know resources that could be going to like doing code better and better abstractions and all that stuff and it's shifting way too much of that stuff just to these really minor things that you should be having kind of just done muscle memory that's a good point i never thought about it like that it's actually a distraction when you're fighting your editor it's true like it it totally takes you out of what you were trying to do i can totally give you an example of that, exactly. Is that, and this kind of ties back to a previous chapter where they were talking about trying to use similar key bindings throughout. And we were talking about using VI, for example, key bindings.

But have you ever found yourself where you are in, say, Chrome, and you're stepping through some JavaScript stuff, and you accidentally hit F5 to continue. Oh, so frustrating. When you meant to hit F8. But it's a reflex to hit F5 because tools like Visual Studio have trained you that, like, hey, when you're just ready to continue from the breakpoint, you just F5 it, right? Yep.

But then when you're in Chrome and you do it, you end up reloading the thing, right? Reloading the page. So, I mean, that's a case where it's the reflex that Joe's talking about, but you also fight yourself because you don't have the same key bindings that they discussed previously in the book. Yeah, they're different everywhere.

That is frustrating. Yeah, those context switches kill you. They do. And it does, you know, I was thinking about like, well, man, why isn't there a way to like change those key bindings? But I guess F5 has been such, you know, before Chrome DevTools, F5 was the refresh. Yeah, and that's all browsers too, right?

Right. Yeah, And, and that's all browsers too, right? So yeah, yeah, it's crazy. So tip number 22, use a single editor. Well, yeah, definitely do that, right? If you're going to pick one, learn how to use it. Um, if you use a single editor for everything, the keystrokes, command shortcuts will become second nature and same thing that we just said a second ago um but this one's funny uh how many vi commands are just second hand for you i mean like 12 5 it's definitely like i i have to think about it for a moment like whenever i go to quit my natural reflex is to write the file and then quit in the same command that's what i do same vi command so like i have to think about it for a moment, like whenever I go to quit, my natural reflex is to write the file and then quit in the same command. That's what I do. Same VI command. So like, I have to think about it.

If I like, wait, no, no, no. I didn't want to write it this time. No W, no W. Just quit. Yeah. Get rid of the W. Just quit. Yeah. Yeah. I wonder, I'm trying to figure out just how many there are. It's, that's really hard to figure, to figure out. Yeah. There's just something going to the top of the file and going to the bottom. I think I know those G and Shift G. But they'll make your life so much better if you've got a long file to deal with. And it can be so annoying to go Google for that when you're just trying to do something simple. Yeah, that's why those cheat sheets are really good for things like that.

And the book is trying to push you towards one of these ubiquitous editors, right? These things that exist on all the platforms. So VI, Emacs. I mean, nowadays, back then, they didn't have something like a Visual Studio Code that was everywhere, right? I think probably the closest thing before VS Code was probably Sublime Text. And, you know, things have changed quite a bit here just in the past couple years. So there's a lot of options out there. Yeah, I just learned something new, Joe. Yeah, what's that?

I didn't know. So I knew Shift-G would take you to the bottom. I didn't realize just G would take you to the top. I've always done colon zero. Oh, that takes you to line number, huh? Yeah. Yeah. Yeah.

I love this show. I learn something new every time. Yeah, I thought there were hundreds, but there's actually not. VI is maybe not as horrible as I thought it was. There's maybe 40 if I'm looking right. Nah, somebody put a truncated cheat up. That's garbage. Joe indexed all of the VI commands.

I can think of 10 off the top of my head, and that's like none. It feels like one of those 80s coffee commercials. We've replaced this developer's VI cheat sheet. Let's see which commands he's missing. Oh, God. The thing is, though, Joe, if you you remember right there's like all kinds of uh macros yeah yeah like macro keys and and modifier keys and stuff that you could it's it's crazy like it's crazy powerful and it's amazing how strong that thing is considering how old it is

right but yeah i remember doing stuff like record a macro and i would do these five actions and i repeat it x times uh now i'm wondering like what the heck was i doing and why was i doing vi like was that really the best way to solve that problem it was the coolest yeah it felt cool like when it man whenever you know the command to do the one thing you're like check this out delete word poop now see that was amazing like like yeah exactly deleted a word yeah with only two key presses yeah it's very exciting all right so what features should you look for in your editor right so one of the things that they that they say you should look for is that it should be configurable and it should you should be able to configure all aspects of the editor to your

preferences and we kind of talked about this before like i i know that i'm probably pretty bad about just leaving defaults i am we're good we're good is that what you said yeah i think it's nice to be able to like leave defaults and then when you ever return to someone else you're like yo just hit that button and it's the same button yeah yeah i'm a big deal i'm pretty solid with the defaults minus a couple of things but we'll get into that here in a minute uh-oh yeah um i do like um most editors now will like have a profile you can save with the project too so in case you want to enforce things or if you want to kind of save things differently for different projects i like that vs code we'll do it like the dot vs folder that's really nice um extensible i definitely expect plugins now

and now thanks to code i expect to be able to do them like and install them within like two seconds i code is it spoiled me for installing control shift p man so good uh yeah and with code like you're not only uh i mean it's to an extreme right because it's not just like the look and feel of something it's like oh hey i want support for this other language you want docker support boom yeah here's there's an extension for that oh i see you're working in a docker file right hey would you like to install this extension? How do you know? Clippy lives. Yeah.

Yeah, it's pretty amazing stuff. It's funny. They said, but somebody put, but how often is it really done? Like pre-Visual Studio Code type IDs, like IntelliJ. Well, okay, but hold on. Wait, because there was a very important sentence before that, because when they said extensible,

they said you should be able to configure or integrate with the compiler of your choice. Oh, with the compiler. Okay. And so I wrote, well, okay, pre-Visual Studio code or similar, you know, Atom or whatever. Like, how often was that done, right? Like, if you had IntelliJ, you were just doing Java. Right. Right.

Or if you had Visual Studio, you were just doing, like, whatever the Visual Studio languages were at the time, which it's always been a handful. But, you know, you weren't going out of your way to be like, oh, hey, let me add in support for COBOL. Yeah. But now they've got things like these extensions or even further than that. Right. It's not just swapping out your compiler like in Visual Studio. You can be like, hey, I want support to be able to, I don't know, edit projects in a different way. Or I want to be able to, I don't want to use NuGet, I want to use Pact or something like that, right? Like there's extensions to actually make your IDE better as opposed to just, you know, swapping out features underneath the cover. So every, I'd say almost all of them have gotten pretty dang good at this like i can't

think of an editor that's not extensible right today today 2019 now go back 20 years yeah when this book was written right and like what were they talking about yeah borland oh well eclipse eclipse was kind of like that but it was just so obviously catered to java So you'd be like, okay, I'm going to use Python for Eclipse. And you go in there and you're like, okay, what's my class path? Why is it asking me for a class path in this menu? Do I need to fill that out? Hey, but we used Eclipse for some ColdFusion, didn't we? So it was definitely a –

Okay, well, I wasn't – okay, so Eclipse, fine. But I don't remember anything else though maybe maybe i just have like a bad memory then yeah i don't think there were many yeah i'm visual studio i definitely tried to do some weird stuff with visual studio like a python and stuff like that um but i think i think i forget how you installed it but uh you could install basic language support but i think it was because it intended intended for you to do like Iron Python. And so it has some support for kind of doing Python syntax highlighting. But really, ultimately, at the end of the day, I was just using a big Visual Studio just for color, you know, some basic color coding for Python.

Yeah. They also say that they should be programmable, right? So you should be able to script out or program some complex tasks which i'd say a lot of them do have that yeah i mean and to this point like they're not necessarily saying that you need to be able to like write your own extension right to it right that's covered by it being sensible but you know this is more like macro related yep and so i was thinking about like well snippets might be an example of this in visual studio yeah yeah i used to love snippets i don't do it anymore though i don't either i think because auto completion is just

so good nowadays that you don't have to deal with it yeah i don't really handwrite much html either i used to like write a lot of html and so a lot of my stuff was just like doing forms and stupid stuff like that where you have like the label and the input and it'd be a rep and a div. And so I would kind of have my common ways of doing that stuff. Just all saved. You know what though? I think that that actually holds true for where snippets matter a lot to me is when you're doing UI type stuff,

right? Um, when, when you're doing C sharp or that type of code, it doesn't usually seem to be something that I'm doing much of. Getters and setters and Java. Oh God oh god okay i do use it for that yeah but that's like kind of built into the the tools a lot of times now you don't have to set those up but like back back in the day you did yeah now you can say refactor encapsulate fields thank god oh yeah so i

think i might have added this last time i don't remember. But what are some of our favorite editor features? Code formatting is one for me, for sure. I mean, the type ahead, IntelliSense type of features, that's definitely up there now. Because almost every IDE for any language now has that. And it's just such a boost to productivity now because you can just type a few letters. Yep, that's what I wanted to tab and move on to the next thought. And it's just to me, that editor is just an extension of yourself as trying to like get the thought out as fast as possible. Right.

Before you get distracted and forget it. Yep. I'll list off a couple of the ones that I had here. Case toggling, I use quite a bit. I don't know why. Really? I do. I use that too.

I use it quite a bit. Line manipulation, this one I didn't think I would ever really care, but it turns out to be extremely useful. So what I mean by line manipulation is when you're splitting or joining lines, like let's say that you have something that needs to all be on one line inside a pair of quotes because it's part of a program. Being able to select a bunch of them, like in Visual Studio Code and say, hey, join all the lines together. It's amazing. Like it's just so easy to do. Block commenting. And then the other one that I had that I don't leave default is theming.

And a perfect example is IntelliJ doing some Kafka streams work in IntelliJ doing Java. You couldn't read the code. If you turn, if you went to Darkula, like almost everything was gray on dark gray. And it was like, what? Like i seriously would stare at the screen like i i don't even know what i'm looking at and if you went to the light theme then it was it was almost inversely as bad and so like this this one dark theme in intellij is amazing so like changing the theme and changing the font like i've really grown on this fear code with ligatures so oh watch it yeah so we got some hate we got some hate some people don't like ligatures and so i get why some people wouldn't i totally do no i do because it squashes what you're used to seeing right so like the

triple equals if you have that next to each other you'll see that it's three blocks of equals. Right. In the ligatures, it's just like a longer equals bar and it's not pretty goofy. Yeah. It's not quite as obvious, but the not equals is sexy. Right.

So it's like, yeah, I don't know, man, but, but that is the one part of an IDE that for me, I almost never leave default. Yeah, I did. I also got some hate for saying I enjoy

Darkula. It was only like three, but I was like, wow, people really don't like Darkula. No, Darkula is awful, man. I added a couple things in here that I really enjoy like regular expressions and being able to undo multiple times, of course.

But yeah, I love regular expressions and Visual Studio Code and Sublime before that. Bracket highlighting, do you guys use colorizer or anything? Wait, wait, wait, wait, wait. You mean regular expressions as in the ability to use it in a find and replace type of scenario, not as in write my code, regular expression code. Use it.

Yeah. Yeah. Like using regular expressions as a way of doing something else like finding or totally totally yeah just like a little stupid stuff yeah colorizer yes for for visual studio code i don't that's nice oh yeah it is it'll color the brackets different colors yeah in addition to like putting your mouse on it and seeing it just makes so like i'm dealing a lot with big json files lately and it's just so much easier to see like it it goes between like high contrast colors too it's like blue pink yellow pink whatever like

and like when you're in like let's say you're in an if block right you'll see a line of that color that matches the brackets all the way all the way down through that if block you use this as a tip of the week a while back. And I meant to add it, but I wasn't at my computer, so I totally forgot about it. Yeah, no, it is awesome. Well, it's two seconds. Control shift P, colorizer. Boom.

Auto-tabbing. So this is kind of mixed because I hate it when VI does it. But in Visual Studio Code, when you kind of paste something in, it doesn't necessarily put it all the way to the left. It puts it in the spot you want it. That works out well. I have a really tough time with this in uh mvi for whatever reason i just need to learn how to paste on format i guess because i'll click copy like a docker file and open up a dark file maybe a yaml file and i'll paste and it'll start like tabbing stuff over so it's like a i don't know like a landslide or a hill

i'm like what yeah i don't know how to it. I have to close the whole file and start again. I do, too. It's irritating. You're like, rename it to text and paste it and then change it back to YAML. Yeah, so that's annoying. Vertical selection was something I learned about here on the show. I forget who brought it up.

Oh, that's what I have as mine, yeah. Oh, block selection, yeah. Yeah, so, yeah, I love that. I actually, actually surprisingly use that a lot and then this is your code in particular it's really nice like i don't know if you notice like and sometimes when you do block selection and you kind of hit the left or right arrow keys it'll move over like one or two keys in visual studio you can do the cool stuff like the um encode you can do like control and arrow and it will move it to the end of the word

dude so dude I was actually. I was going to do a video on this. Visual Studio Codes, that vertical selection you're talking about. That selection, yeah. You could actually hit the end key. So if you're on like 15 different lines and they're all, you know, different links or whatever, most editors won't do this. But you can hit the end key. It'll put you at the end of every one of those lines. Like if you need to put a comma on them and it'll do all of them.

It is so amazing. But does it do it at the last character that's on that individual line or does it still block the other end of that? You know what I'm saying? It's exactly what you want. Like you might have like 10 spaces on one line and five on another. No, it's at the proper. Oh, that's beautiful. No, it's amazing. It's exactly what you'd want it to be. That should have been your tip of the week. Can I steal that one? I'm going to make a video of it. No, that's my tip of the week. Hey, if you were listening to that already, just forget about it for now. Yeah, I was definitely

going to mention block selection because that has been a game changer ever since I've seen that. Now I'm like, it's so awesome. And then sometimes I'll find myself in a tool where it's not on by default or it works a little bit different. And it'll kind of like frustrate me because I'm so used to like in the Microsoft tools, just being able to do like an alt shift and then, you know, selection with the keyboard. And some tools want you to use the mouse instead. Click, that's so irritating. And I'm like, no, I would rather just use the arrow key, thank you. And like DataGrip, for example, is one of those where if you do the alt shift

and then the arrow. It moves the line? It'll move the line. I know, dude. Yeah. I hate that so much. So instead you have to do like, I want to say, if I remember right off the top of my head, it's like Alt-Shift and Insert, and that will toggle the selection mode.

Ah. It's either Alt-Shift and Insert, or it's Control-Alt. So either replace the Control and the Shift. It's one of those. But yeah, so that you can do the box selection mode like i'm used to doing in you know so many other editors using the freaking line around man it's so irritating intellij does it i do it every day i mess it up yeah every day i mean i'm not saying that that doesn't have its value right i mean it does and i use that the thing is

what's funny is because i've i've messed it up so many times, I know that it moves the line. I'm like, oh, that's actually useful right now. Let me, let me do that. Right. And you could select multiple lines and move them. Yeah. Which is a cool feature, by the way, like, you know, a lot of times in the past, you would typically go down and cut the line that you wanted to do and then paste it, but then you lost your clipboard. So the move line allows you to actually shift things around but not lose your clipboard. So, yeah. You know, I've never had good luck with a clipboard extension.

Like, there's been a bunch of them where you can have multiple things in your clipboard. I've tried a couple of them. I've just never found one that really fit. But, I mean, you know, your love of Visual Studio Code, though, I mean, Visual Studio Code's the same way. You'd have to do an alt-Shift and then the mouse. Control-Alt.

Yeah, it's different than big Visual Studio. You have to hold the Control and Alt. Yeah, it works. So, Control-Alt and then? And then the arrows. I mean, I'm trying it now and it's not. Or it might be Shift-Alt and the arrows. It's Shift control alt.

Shift control alt? Yeah. Yeah, which is different than Visual Studio, which is just shift alt. Yeah. But I can't up arrow, though. How does that work? I've definitely done it. I mean, I don't have it on here.

Control shift arrows. You can do it. You can go up. I mean, because like. You're on a Mac right now, though. I'm talking about Windows. I don't know what it would be like on there. Yeah, because this is where I'm saying like like to just add to this frustration, right?

Cause I'm so used to the block selection, visual studio code, uh, alt shift arrow will copy and paste the line. Yeah. Yeah. Yeah. So I'm like, that's not what I meant at all. And that is another frustrating thing too. Right?

So this, what we're talking about just compounds the problem. If you're between Mac and windows and other OSs, right? Like it's whatever. I mean, thing is you're going to get comfortable with some stuff, but these are some of the things we love. So one other one that, you know, this is the, this is the, uh, downside to going last here in this list is that like you guys took so many good ones, but, um, one that you know this is the this is the uh downside to going last here in this list is that like you guys took so many good ones but um one that wasn't said was change history so you know in visual studio for example um you can see like you know there's like the uh what do they

call that intellisense no uh code lens yeah you know that'll show up at the top and it'll have like some information about like hey who changed this last and you know, that'll show up at the top and it'll have like some information about like, Hey, who changed this last? And you know, how many times has it changed or whatever. Right. And, uh, specific to visual, visual studio code, there's a previous tip of the week that we've talked about, which is the get lens extension and get lens is my ultimate favorite because you can be on an individual line of code and it'll be like, this person changed it on this date. Here's the commit ID and here's their commit message. So if there's ever a question about like, you know, I find that so helpful when you're debugging something and you're like, well, how am I, what am I looking at? Am I looking at something that's like,

you know, three days old and maybe it's a problem or is it you know three years old and it's likely okay right right and so sometimes when you can see that kind of context of the change history it can kind of give you a feeling like this this might be okay right yeah that is that is an excellent excellent feature and then joe always likes to do our challenges. I do love these challenges. So it says, learn the language your editor uses for customization and scripting. Then write code tasks for things you do repeatedly. Do you guys know what Visual Studio Code is written in?

It's in... It's based off of Atom, which was based off of... Node, right? Electron. Electron. But that's JavaScript. Okay. Okay.

Yep, and Visual Studio, the extensions are C-sharp, so I assume it's C-sharp. I don't know. Don't know. You know, IntelliJ, all their stuff is definitely Java for sure. Uh, jet brains. Uh,

so here's another one. Uh, Oh yeah. Good friend. Got to mention, uh, Ryan monster, buddy,

uh, road extension. That's really great for finding, uh, emojis, not emojis. Um, awesome.

And other, other, uh, icons. It's really nice. No, it just slips in there. I like this one too.

Uh, try to stop your friends with knowledge of your editor. Try to accomplish editing tasks in as few keystrokes as possible you can imagine like playing horse and you're like all right do this to this and four keystrokes or less i mean there's the horse thing but like when i wrote this down i was like well can this show count like does this count does this show count for the three of us as that challenge right because we're always doing that like even even during the course of this show like joe mentioned uh you know lowercase g would take you back to the top of the file and i was like oh i always do you know colon zero right so yeah i think we need to have competition we need to have we need to host

a tournament a horse tournament for VI. And I'm the judge. I'm not a contestant. Wait, wait, wait, wait. That's not fair. It's good to be the judge. Yeah. All right. Well, we can talk about one of my favorite topics.

Let's talk about Git. Oh, wait, no. Oh, this is pre-Git. Yeah, this is more generic. This is just source code control. We're out. So they called it source code control. I could not bring myself to type that in.

I had to put source control because that's all it is. It doesn't matter. So yeah. So Git, I think, was 11 years old. Is that right? Is it really? That's quite a... I think so.

2005. So it is now 14 years old. Wow, man. What do you think Subversion... When do you think Subversion was released? Subversion was after CVS. So I'm going to go. Wait, you said Git was 14? 14. Subversion's going to be a good six or seven more than that. It's 21.

I was thinking in the late 90s for its introduction to the world. Milestone 1 was October 2000, which was far less than version 1. 19. Wow. Version 1 didn't come out until 2004. Okay. So it was right behind Git. But I'm pretty sure it was right before Git.

Right ahead of Git. Right ahead of it. But I'm pretty sure I used it way before it was in its GA version. So then that means that Subversion, Mercurial, and Git all came out really close. Because, am I wrong? Wasn't Git came out as like Mercurial was gaining popularity and it was like, no, we would rather not go that route. And then linus started working on git instead am i mercurial is just uh it was first announced in 2005 so it's one year later one year later than subversion but i mean i'm comparing it to get though because if git is

14 years old then they would have both came out in 2005. Git was 2014. Oh, 2014 you said. Mercurial was 2005, so Mercurial is actually slightly newer. Wait. Wait, slightly? You said Git was 2004 a minute ago. I thought he said that Git was 14 years old. Yeah, he did. Which would have put it at 2005.

Oh, sorry, they're both 2005. I can't do math. They were even the same month they're both in april 2005 but git is a few days earlier oh is it okay yep i guess i had that wrong and subversion was 2000 and cvs was 1990 i thought i thought i had remembered some story then i guess that maybe i'm totally had that wrong about the beginnings of Git then. So I apologize for confusing that.

That's been there now. I don't know when people really started noticing or paying attention. Things could have changed in those early days. Well, we need to add a favorite feature for Joe for his next IDE of choice, and that needs to be math. Yeah. A calculator. Math with two F Yeah, I need a calculator. Math with two Fs.

I need Clippy back. I need Siri in the corner helping me out with things. So it's funny. I remember the first time I was introduced to source control some long, long time ago, and the selling feature to me was it was a backup for your code. That was what it was and it wasn't mentioned in this book or anything but that's kind of how everybody viewed it is like

hey it's not just on your file system right um but in the book they tried to take a little bit more um i guess adult type approach to this so it gives you this undo button that allows you to undo a day ago five days ago weeks ago ago, whatever, right? Like that's actually a big deal. Not because it's just an undo, but because you can get back to a working state or before you did something crazy that needed to be undone. See, this is what I found curious about this section. To me, the most important feature of source control isn't mentioned in here. Like this whole concept of a giant undo. Well, that's only,

that's only, that only matters if the past is what you care about. So, so let's do this then let's go through the list. It's here. Cause I'm curious what you say the most important feature is and how it doesn't fit in here. Okay.

So the next one they have is it allows you to see who changed something. That's good game with that. Yeah. Um, commenting allows you to see who changed something. That's good. I'm game with that. Commenting allows you to see why somebody changed something. All right. So that's good. You can see the difference between the multiple versions of the files. Also a nice thing.

Which files changed the most? We've talked about that in the past. It can matter a lot in terms of regressions and that kind of stuff. If you use it properly and you tag your releases or whatever, then you can go back to a specific time and recompile the code just the way it was released at that point in time. It keeps code in a central repository. That is not necessarily the case nowadays. Back then with CVS, Visual Source Safe, all that. Yes, that was a centralized thing we get now you have the distributed but whatever you have you have a way

to be able to access the thing and i'd say most people probably use git in a centralized fashion um in terms of where it's actually hosted um and then it allows you to do multiple changes or concurrent changes right like the three of us can be working on a file at the same time. And if you're doing things, if you have a workflow that is conducive to it, then it's not going to be that painful. And what was the episode that we talked about the various different Git workflows? Oh. Episode three. No, no, no, no, no.

Git workflows. Git workflows. Yeah. Comparing Git workflows was the name of the episode. I don't remember the number. but you're thinking Joe's thinking of source control etiquette was like episode three or something like that. That's a good one. I'll look it up.

So you said yours didn't fall in any of these buckets. So I'm curious. Yeah, I was mistaken. I forgot it. It's in here. Oh, okay. What was it? Well, yeah.

So, um, I mean, because the most important thing that I was thinking about was this last one, like the concurrent, like the ability to merge in changes to the same file, you know, that, you know,

might be being edited concurrently. Now they talk about the concurrent changes and you think back to like, this was written 20 years ago. Visual Source Safe was a thing at the time this was written right and visual source safe you did you know it would lock you out you couldn't do that right like you'd be like nope alan has that file checked out already like you you know for those that have never used visual source safe visual source safe worked in the i like to think of it as like the library model.

Like if Alan's checked that book out of the library, I can't get it. And that was so bad because if somebody didn't check it in at the end of the day, you couldn't touch it. Yeah, unless you were like an administrator on the box, in which case you might mess them up in regards to any changes that they had, right? Oh, yeah. had right but oh yeah the distributed nature distributed development nature that has happened since with systems like um cvs subversion get mercurial like that to me is the most important thing yeah like everyone kind of agrees that gets so much better in subversion but then we all mostly use it like get i mean uh damn y'all use like subversion with the centralized model i mean the branching is cheap so that's the big difference there and of course like we've got our own local copy of the repository so we don't really use it like a centralized it's just funny that we tend

to have like one big centralized repository but i guess that would depend on what project you're working on there too right like i mean imagine if you're working on the linux kernel what you just said isn't true right like if you're i mean i guess we all have our own local repositories that we can check into and merge and keep things up to date uh feature branches and stuff so i mean yeah i guess i do use it distributed but it's just when i say distributed i just mean me and then like the main yeah i mean we do more often than not i would say that we probably stay with just the one origin. Right.

But if you like, if forking is part of your workflow, right. Which is very common in like, uh, get lab, get hub, you know,

those type of, uh, environments, right. Then you're going to have multiple origins that you might use. In which case that distributed nature is to your advantage. Right. Yeah.

Is it, by the way it was episode 90 that was way harder to find since yeah we don't show it on there we should fix that one these days itunes and their stupid lack of numbers yeah so episode 90 if you go to codingblocks.net slash episode 90 uh we actually covered different git workflows. And I only bring it up because the concurrency editing thing is easy if you're using the right workflow for what you're doing. Otherwise, it can be an absolute nightmare of code conflicts, nonstop conflicts. Yeah, they made this point here, though, in this chapter where they were talking about the better um source

control systems keep track of the compiler and os versions as well and i made a note here for myself because i was like wait which ones do that that's kind of weird i don't remember that specific about the yeah that's weird yeah i don't either like maybe maybe something like Rational Rose. Was that? No. What was the Rational one? Was it Rational? No, Rational Rose wasn't the source control, right?

That was the UML stuff. Yeah. Clearcase. It was Rational Clearcase. Never used it. Maybe that one did it. Like, I mean, that one, I was trying to think of like obscure ones, right? And like, I don't remember that one that well so i'm like well maybe it was

the rational one yeah i don't know so tip number 23 joe you want to hit this one you know uh ibm is still selling clear case but uh yeah 23 always use source control uh i tend to check in real like locally even like pretty often stuff i don't even push up with GitHub just because it feels strange to not. It's so easy to accidentally delete a folder or something and just be like, oops. Yep. Yeah, I mean, they make a point to call it out.

Like even if you're just a single person on the project, you know, still use source control. Now, what do you feel about this? They also called out, hey, commit your documentation, your memos, your your phone numbers memos to vendors you know yep i don't know i mean i used to be bigger on that but so many of the tools that i used to do that with actually have that built in now like google docs saves different versions right what's the oh key pass uh last pass will save different like older versions of your

passwords and stuff which is a really nice feature so something you have like that kind of built in now that i don't know i don't really care so much about that go ahead it does make me like jokingly think back to this i think we've talked about this before i don't remember if it was on air or not though but um i'm sure we've talked about this before about like using uh git for operating system backups do you remember that conversation yeah i mean technically i guess you could i think i think the only reason why i probably don't do this with like memos and that kind of stuff nowadays is because typically your project management software integrates pretty tightly into your source control so so you don't necessarily need to save it in Git.

You know, they're kind of linked. Like if you're using something like Atlassian or... Well, I mean, to Joe's point, though, I mean, we live in a very different world now. So you have OneDrive, you have Google Drive. You know, you have these other systems that are automatically versioning for you that you don't have to really think about it.

Right, that's a good point. So, but I mean, also think too about in regards to them saying like version everything, you know, we talked at the very beginning of this book about like the tools that they even used to create the book. Right. And how like it was literally like this book is literally compiled, and I'm saying that in the computer science sense of the word. This book is compiled like you would compile any other source code. And that episode of The Change Log that Joe mentioned earlier, if you listen to that episode, go into that not into great detail but i mean they

they talk about it a little bit more you know just like how easy it was for them because they do keep all everything related to the book and version control and because they are like literally compiling it how they could change things so when they say put everything in source control you know that they mean it like they they took that to heart and still do. That's hilarious. So another one of the benefits is you have these builds, right? If you have things in source control, then you can automatically pull that data down from source control and use it to do your builds and also run any kind of tests that you have. Now, they were talking about doing things for regression tests and whatnot.

But what was funny is they mentioned that they do these things nightly, right? Like you're going to run your build nightly. You know, nowadays, especially with the tooling available. Right. I mean, every time you commit, you're probably having to do a build and all that kind of stuff. And do tests and everything. Yeah. Yeah.

I mean, it was definitely a different world back then. I mean, we've definitely a different world back then. I mean, we, we've talked about that before, you know, like even, I know that even I've been on projects where like, that was the norm, you know,

you, you, you just did nightly builds cause it was too costly. Like, especially like, you remember, um, like just even compiling your JSP pages,

right? Like, you know, it was, it was just more efficient to just have something run through at night and pre-compile all of those to hit all those pages and then that way you didn't have to deal with that uh you know if you were trying to like test something out right yeah so yeah and and they they made this point here which you know they called it the tremendous hidden benefit of using source control is the fact that you could have this uh automation and repeatability

around the builds and and it's still a big deal today so i don't know if it's considered hidden benefit today though not today no like i said a lot of the tooling nowadays your githubs your vs onlines whatever they're they're just amazing what they give you for free even Windows backups depending on the version of Windows you can get older versions of your files stored automatically it's pretty cool so our challenge is Joe yep we got a couple challenges so

install a source control setup on your personal machine not that hard nowadays yeah I think it probably already comes with windows now i don't know you probably have like 18 of them it doesn't come with windows which is really crazy i think it's on mac it's definitely on every linux system no wait wait it's not on mac unless you have the mac build tools right oh is that just yeah you have to

have that you have to have the mac build tools okay maybe that's why i always had it it's like uh my my developer checklist i used You have to have the Mac build tools. Okay, maybe that's why I always had it. It was like my developer checklist. I used to have like a big checklist of all the things that I needed to install and configure, and it would take me a long time to set up a new computer. Nowadays, it's like down to a few things. I don't even keep the list anymore. It's just like Node and Git, and then I'll take care of the rest as I need to.

Because he's a JavaScript developer. What about ChocolateyScript, though? I don't bother with Chocolate anymore. What? Yeah, what yeah i don't either all right you know what you guys don't use your bin folders properly nope you're not like creating automatic scripts to rebuild your dev environments that's right no yeah that better be in the reby and then and then the uh the other one we got here. Yeah, take a look through some open source repositories for your favorite language. Now, this one I really do like. Every once in a while, I'll go look at open source projects, like big and small. And I'm always amazed at how hard it is to understand what the heck is going on for any project of any size.

So whenever you feel bad about maybe your workplace and maybe the code you got there and how hard it is and how obtuse, go look at any open source project and i'm sure you know i'm not saying that it's bad but just when you look at anything that you're not intimately familiar with any product of size and complexity you're like wait where's the execute where's where's start where's the where's the main for firefox go go go to firefox and try to find the main like good luck it doesn't even necessarily need to be like at firefox scale though it could just be like a third-party library yeah you know you might want to use like i have a lot of stuff's really hard to build from source yeah i've definitely found myself here lately like digging into the dapper source code trying to understand like wait why yep and a lot of complex stuff um there'll be licensing

issues so they won't be able to deliver all the pieces you need so like you need to go do this and then you go need to go get the JDBC drivers and then you need to go do this based on what you're going to be using it for and you're just like why can't you just give it to me yeah or mp3 used to be a big deal like if you wanted to

play mp3 and like audio players and stuff you had to like go down with the codex separately from someone who's providing it to you illegally so so much for win app yeah yes really because it really kicks the llama's tail this episode is brought to you by clubhouse clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products their customers love. While designed to be developer first, the UI is simple and intuitive enough for all teams to enjoy using. And Clubhouse has been totally built for developers by developers. And you can really tell because they've sprinkled things like GID tips throughout the UI. And they even make a big point to highlight open source

projects that integrate with them. And they're always adding new features. I mean, we've talked to you about the search enhancements that they've added, the Android app that they've added. You can even go and see their roadmap and see what's coming out next for Clubhouse in 2019. And Clubhouse has recently launched the Clubhouse community, where you can connect with other software engineers and product managers using Clubhouse. With a simple API and robust set of integrations, Clubhouse also seamlessly integrates with the tools you already use every day, like Slack or GitHub.

They get out of your way so you can focus on delivering quality software on time. Sign up for two free months of Clubhouse by visiting clubhouse.io slash coding blocks. Again, that was clubhouse.io slash coding blocks to get your two free months and see why companies like Elastic, Full Story, and LaunchDarkly love Clubhouse. so like you've heard us say before if you're a long-time listener uh if you haven't already we would greatly appreciate it if you would leave us a review you can find some helpful links at www.codingblocks.net slash review but in case if you find yourself using a system where you can't leave a review i wanted to encourage you like hey put out a tweet uh with the link to the show or if you're using a system like uh not overwatch that's a game uh what's the

other one the overcast overcast thank you for the assist there i'll shoot somebody shoot somebody while you're at it. Purposely setting you up there to make sure you were paying attention. Yeah. If you're using like Overcast, you know, star it. You know, like whatever the system of choice is that you're using. You know, thumbs up it. You know, put it out there on Reddit or something.

Like whatever you can do to help spread the word. We greatly appreciate it. It'll help the show grow. And it really means a lot to us when we find those because inevitably we do find them and it we always uh enjoy it and we like to we share it amongst each other like hey did you see this one so with that we head into into my favorite and your favorite part of the show. Survey says, all right. Back in episode 108, we asked, do you discuss podcasts with your friends or coworkers? And your choices were, are you kidding? That's all we talk about. Or absolutely. They need all the help they can get. Or absolutely. I need all the help I can get. Or no, it's my secret superpower.

They can't know where my tips come from. All right. So I think alan went first last time maybe so let's say joe goes first this time maybe i should just come up with something to where like if it's an even number it starts with a and if it's an odd number then it's j that'd be good good work wait which one was it but yeah so this is this is J, odd number J. All right, odd number J. I can remember that. All right, yeah, this is really tough. I think that I discuss podcasts with friends or coworkers,

but I try not to let them know that it's a podcast, so I'm going to say it's my secret superpower. What's the percentage, sir? 50. 50? 50. 50? Oh, you went all in almost.

All right. So if going halfway in is all in, you went all in. That's right. You went all in halfway.

You went all halfway in. So I don't know on this one. I'm going to say absolutely. I need all the help I can get. Like it. Okay.

And then I'm going to go 50. Why not? Yes. Drum roll, please. No, don't. No,

I said, don't, I said, don't, I said, don't try. As soon as I, as soon as it came out of my mouth,

the words came out of my face and I'm like, wow, what did I just do? Okay. Joe wins. Oh, wow. Yep. How high is it? It was 58% of the vote. Wow.

Yeah. Selfish people, man. Yes. People think that they look at you weird when you tell them where it comes from. What? I remember somebody, they made me listen to Eminem. And it made me think less of them because I thought they were like really funny and witty. And it turned out they just listened to rap.

And so all the times after they were making just, you know, interesting jokes, it turned out they just listened to rap. All the time they were making interesting jokes. It turned out they were just singing. Dude, that's... Really? Rabbit is going to say this to us? I can't take this right now. Alright, all you selfish people out there, share with a friend.

Protect your sources. Don't tell them that you got a cutting blocks. No, wait. I mean, it's not like you're a journalist here. You can tell people where you heard it from. Oh, man. That's awesome. Whatever you do, don't tell a friend about the show. No.

Okay. Hold on, Joe. We got to have like a little marketing 101 here what are you doing all right well for today's survey based off of episode 110 i thought it might be fun to ask what's your favorite shell of choice because if you recall that's what that episode was about so your choices are bash k shell ash dash z shell fish command prompt yep or power shell i feel like if you say command prompt we should have a talk right in at comments at coding blocks not getting the jury or anything like that feel free to pick

command prompt if it's honestly your favorite yeah maybe you didn't know that there were any other options yeah i i didn't even realize like how many different uh different shells there were for linux that i i've only really ever used bash or k shell like i never even bothered with some of these other ones yeah that was good things about z shell but i've never used it yeah it was interesting like one of the things that i learned while putting this list together was like well i also knew there was just like plain SH, right? But what I learned though was that that's really just calling one of these other shells. It's just like the default for you.

It's the wrapper. So I was like, ah. I did not know that. You know, Programming Throne Out had a really great episodes on shell recently. Shells. You should check them out. We should. Oh, I thought you didn't tell. I did not tell you. Yeah, I thought should check them out. We should. I thought you didn't tell. I did not tell you.

Yeah, I thought you didn't share. Man, what is it? I didn't even tell you which episode. So, yeah, just, there was a great episode on Shells, but I'm not going to tell you which one. How would that make sense in the context of not telling your friends that this tip came from a podcast?

If you're just going to say, like, I heard a great episode from the radio that talked about shells. I got to put it in my sources. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Go ahead and try it out yourself today by starting a 14-day free trial and also receive a free Datadog t-shirt when you create your first dashboard. Head to www.datadog.com slash codingblocks to see how Datadog can provide real-time visibility

into your application. Again, visit www.datadog.com slash coding blocks to sign up today. All right, so let's talk about debugging. So we probably all have heard this, but just as a refresher here, this term is credited, the term bug is credited to Rear Admiral Dr. Grace Hopper, who's the inventor of COBOL, where there was a moth in a relay of the computer system. And when asked to explain why the system wasn't working as expected, a technician reported that there was a bug in the system. That's still amazing to me. You know, have you ever seen her like on like the the david leonard show or anything she's really funny um she was famous i didn't know about this before but i watched it fairly recently she was famous for carrying nanoseconds around for and i i didn't know what the heck that meant so i googled it and i found a clip where i think it

was letterman maybe johnny carson she's on the show and she pulls up this wire. And he's like, what's that? It's a nanosecond. This is how far light travels in a nanosecond. When people, other admirals or whatever, complain to me how long it takes for things to happen. I show them, look, this is a nanosecond. Do you know how many nanoseconds there are between here and that satellite it's a lot come come here break and it's kind of funny to have like a visual representation but it's on youtube so she um she uh only passed away kind of fairly recently yeah

and um i always thought of her as like being kind of like a like a you know luminary from a long time ago but she was actually really active still doing cool stuff and educating people for a long time like recently it did make me question though like the way the way this was written in the book though where like she's credited with it but it was a technician that made the comment yeah it was like one it made me think of like one of those things is like wait a minute is this where the boss takes all the credit for the thing you did probably yeah yeah probably oh yeah she passed away in 1992 i thought it was more recent but there was i guess it must have been another person yeah i don't know

well maybe you're thinking of the c++ inventor because wasn't that just like a handful of years back? Yeah. I don't know. We sound like old fogies now. Yeah, exactly. I want to tell you about the corns on my feet. Wow. I'll edit that out. Cornshell.

Is that what it is? Bunion shell? Alright. So, they make a point here, which Is that what it is? Bunion shell? All right. So they make a point here, which I felt was very sad but true, that debugging will consume a majority of your day. Yes. If you're lucky, then it's not meetings. Well, there's that.

Well, there's that. That's also debugging, just not code. Yeah, that's true. It made me question, like,'s also debugging, just not code. Yeah, that's true. It made me question, like, I wonder if there's some stat out there. Maybe there is. There's got to be some stat out there that, like, for every line of code, how much time is spent debugging it. Man, I don't think I want to see it. Yeah, they say how I've heard how more often it's read than written.

Let me see if I can find that. All right. Well, while you're looking for that, we'll go ahead. Just keep the ball rolling. But there's the psychology of debugging. And they say that you just need to accept that debugging is just another form of problem solving. And attack the problem like that. Like, work at it like that.

Like, don't get defensive or upset. Just attack it like, hey, this is another form of problem solving and attack the problem like that. Like work at it like that. Like don't, don't get defensive or upset. Just attack it like, Hey, this is another form of problem solving. And then it doesn't matter who's to fault for the origin of this bug because it's your problem now. I mean, I so agree with that. I cannot tell you how much it irks me for people to point fingers when something's going on it's like i don't care right you know if i'm being honest with myself though i know i have definitely been guilty of like somebody will have written some code and then they leave the company and then a bug is found in their code and i and i get tasked with fixing it and i'm like uh just kind of like you're cursing that person in your mind.

You're like, oh, my God, this is awful. Why would you do it this way? Yeah. No, I mean, we've all been there. But if you ever had that thing where something's broken and somebody's like, well, who did it? It's like, who cares? Fix it. Wrong question.

Yeah, if you want people hiding their mistakes, that's a great question to ask. Other than that, by the way, if I look at the ratio um i found where but uncle bob said 10 to 1 10 to 1 time debugging huh you'll read it 10 times for writing it once yeah i couldn't find like a hard citation where he got that from though huh so that's a lot yeah you know going back to the who who did it you know question we treat it like it's a whodunit, like it's a mystery, like it's a murder mystery. Like, oh, there's a bug in this class. Well, who wrote that?

You know, and to your point, like, who cares? But we treat it like knowing that answer is going to matter. It's paramount. But, you know, there are, there are times though, where it's like, you know, there are, there are work environments where it's like the whodunit question becomes like, oh, well, have that person fix it. Right. Right?

Yeah. Because they know that area of the code. They know that area of the app, that file, that class, whatever, that function, that feature. Yeah, that's fair. I mean, as long as it's to try and make progress and not to try and like squash somebody. Because let's be honest, every single person has written some bugs right like it's gonna happen but i mean don't make me feel like i'm the only one though that's cursed out the person that left the company oh no no we've all done it we've all done it i got screenshots

of my code before from friends what is this comment oh yeah well i mean if you wouldn't put such gems in there man my comments are entertaining well you know i do like sometimes just knowing who did it can give you a lot of context like if you've been in the company for a long time you're like like oh alan did this so it was probably when he's working on this thing or that thing and so those are the kinds of things i need to be thinking about when i'm thinking about taking this thing out or changing it. So those are the areas that I should be cognizant of. Yeah, that's true. So tip 24 is fix the problem, not the blame.

Yes. Yep. Down with that. Debugging mindset. So adopt the right mindset before you start and drop your defenses and forget your ego. Totally believe that a lot of times i tend to uh come at it from like let me prove why this bug cannot exist and that's just totally not a good mindset of going way of going into things because you end up um just looking at things in kind of a weird way and i have a real bad uh habit of doing this where i'm

just like so determined to like catch the compiler well it's like you're looking at it through like filtered lenses already right like yeah and so i'm thinking of like all the ways that couldn't possibly be rather than like what's the one way that it could be right that's because that's ultimately what my goal is right so just going out from the wrong angle so i like that uh yeah forget about the project from the project pressures and get comfortable. Yeah. Right. Yeah. That's the way I felt too, though, about that. It was like, okay, I mean, I'm down with the, you know, okay. So I kind of took the get comfortable part as like a joke, like, you know, cause they were saying like, okay, you're going to spend the majority of your day debugging. Right. So I'm like, okay, well maybe that's what, you know, they're just kind of like maybe being humorous, but like,

okay, it is get comfortable with the fact that like, this is what you're doing, right? This is the job. But for, but there is some value about saying like, forget the project pressures though, because there have been times where like, you know, you could be totally under the gun, like in a high pressure situation, right? And it's easy to get caught up into the emotion of that high pressure situation. And then that cloud your ability to like focus in on the problem. And thoroughly diagnose the problem, right?

Like you might fix the surface level thing. And because you were under such pressure and stress, you didn't look through it completely. And so you didn't fully resolve the issue, right? Which is a great segue to tip 25. Don't panic. Yeah. So just take a step back, think about what conditions might cause the bug. And to Joe's point earlier, like don't waste any brain cells on thoughts like, well, that can't happen because clearly it has, right? It just happened and now you've been asked to fix it.

And then to Alan's point, like, don't just fix the bug though. Like determine the root cause and make sure it doesn't happen again. That's actually where you spend most of your time in my experience, right? You might be able to track it down real quick, but then you start looking at, well, how are all the ways this thing is called or what could this happen? And that's where it's like, man, just trying to set up the 10 different ways that you can get to it could take you hours, and the fix takes you five minutes, right? Yeah.

I mean, that's just the world you live in when you're dealing with stuff like that. That's just modern JavaScript development right there. 10 hours of debugging for one one character change that solves everything uh yeah uh tip 26 here is bring a towel i'm just kidding that was like was it on the cover of the hitchhiker's guide to the galaxy don't panic it was like page one or something oh i have no idea oh i mean y'all need to up geek cred like uh the the falcon the heavy uh spacex uh has it written on there or something too i got none nada i don't need to get with it up the nerd game apparently yeah thanks and yeah and rule

to always have a towel because it makes just there's a lot of things you can do with towel anyway all right so where to start yep uh before you start make sure that your environment compiles god yes start from a known good state is that the deal there yes yep uh they add without warnings yeah well don't believe that. Warnings don't matter. Seriously, you should never, ever, ever have warnings. And if you've ever had any warnings and not fixed them, then it's already too late for you and you need to start over again. Yeah, that's probably true. But I will say in today's world, depending on what kind of crap you got installed in your environment, whether it's linters or whatever else, right? Like you can get all kinds of warnings. Oh yeah. So it's. And you could do back-to-back compiles.

And in today's world, we're like, you know, because of all the different NPM, you know, packages that might be coming in, like it compiled fine. Just a moment ago. Oh, now there's a new version. Oh, you got a warning about, Hey, you should upgrade. Right. So, so I will say say like i agree with this in principle like if if you see that you've added some sort of warning then you should probably try and take care of it if you're working in a project that are that already had 300 warnings in it you shouldn't add to the pile

but it's not necessarily going to be on you to have to try and go fix them all either. Well, I mean, they do add that you should set your compiler to treat warnings as errors. This way, the point being is that by doing that, you can then focus in on the more difficult problems. That's a good point. So rather than what the thing was trying to warn you about that might eventually become a problem but to your point though there are times where like in say a sql server a project right where just the very nature of the things that you're doing there like it might be perfectly valid what you're doing in there like if you are creating temp tables or something like that inside of a proc, right? There's nothing wrong with that, but the compiler won't like it because at the time that it goes to compile that SQL server project, it'd be like, oh, I can't find

that table. Yeah. It's a temp table that I'm creating on the fly. Like, of course you can't, but it'll throw warnings about that. So it's a shame because there are some environments such as that one where it's like what can you do yeah you do unless you just disable warnings and then it's like well that kind of kills some of it right so well you can add the like the directive to disable that one particular warning whenever you see it i mean i think if you're doing a new project you got to turn that on like or else you know what it gets it it turns into. Right. But yeah, those brown print projects, like... Turn on the warnings as errors? Say what? Turn what on? Turn on warnings as errors?

Right away? Yeah. On a new project? Warnings as errors and, like, start out with linting. Start out with everything. I agree with that. Because, yeah, it's only going to get harder to add later. Yeah, I agree with that. I definitely agree it'll get harder to add later. And for anyone out there who thinks they never have warnings and think they're a purist, then, yeah, just look at your audit.

Run NPM and just look at your warnings for security issues. You're like, oh, well, crap, there's everything. And as soon as you upgrade, yeah, you get warm. Yeah. This next one, talk to the user that reported the bug if possible because you might be able to get more information. Absolutely agree with this. I would say, if possible, don't just talk to them. See if they can walk you through how it happened.

Because there have been so many times where somebody's like, well, I just did this and this. And then you go watch them do it. And it's like, oh, wait a second. You did like eight other things in there that you didn't tell me about. Like, that's not legit. Or they did it in a way that you didn't know was possible. Oh, yeah. Did you ever have that happen? All the all the time wait how did you just get to that right like oh you didn't know you click over here and do that like didn't you write this thing and i'm like uh i mean i'm like the

eighth developer in line that's been maintaining this thing right yeah nobody knew that was there i don't even know how you knew that was there. Yeah. Yep. What else we got here? Test bug conditions under realistic usage patterns. A lot of times if you are even thinking about realistic usage patterns and the bug has already been found, a lot of times it's just the weird stuff. And so a lot of times if you're seeing a bug in a main thoroughfare, then you know that's probably not something uh that is you know just a normal realistic usage pattern a lot of times it has to do like say permissions or some odd combination of whatever things that are specific to the

environment which is why it's so good to talk to somebody if you can but of course you should you know look at those boundary conditions and those realistic usage patterns. Cause those are probably going to be like the 80% of your traffic, right? Yeah. They make a point here of saying that like the best way to start fixing a bug is to make it reproducible. Yeah. And,

and I added a note here that like, uh, you know, I like to do this is like when you're in this kind of situation, if you can then create a unit test that reproduces this bug like if it's a if it if it's applicable if you can i completely agree with that and i think we've talked about this before in the past like specific to um when we were talking about unit testing right like i think i've mentioned where like i've actually put the

ticket number as part of the name of the the unit test method in the past hey one thing i do want to point out on this one this whole you know make it reproducible i've known so many people they're like yeah i fixed it and they check it in they never run it they never try to see they you know they look like oh i know that's what that that's what it was right and they make a code change to check it in they're like hey ship it it's good it's out there and the same thing's happening it's like wait a second you said you said you fixed it well i i thought it would fix it what what do you mean you thought it would fix it you know like be thorough see it yeah be thorough if you're one of the people that owns this thing, own it from beginning to end,

reproduce it, check it out, make sure it works, try it a few different ways, make sure you can't break it again, and then ship it. Don't ever assume that what you thought was there in the code is exactly what was going on. There should be a tip that's just check your work. Yeah, I mean, that's really what it is. Debugging includes end-to-end, right? Set it up. Make it happen. Fix it. Verify it.

There should be like tip 25A, check your work. Man. Or going back to like a few episodes back, check yourself. Check yourself. You know, there's times when you can't reproduce something. You theorize like, I think this is why this is happening, but I can't really tell because of specific environmental reasons. So let me throw up something with some logging and let's, you know, see how it goes tomorrow. Oh, totally.

Totally. Like, I'm not saying that there's not extenuating circumstances where you just can't do it. Right. But, but, you know, if you are able to reproduce it, don't just go make a code change and not try it out. Right. Like I've seen it happen so many times. Well, Joe's comment about logging though, is a great segue into the next section here that was tracing. And so they say that like debugging is focusing on the state of the application now, but sometimes you need to watch the state of it over time. And so you could add tracing statements, which are diagnostic messages that you'd print out that might say something like, you know, you got here or, you know, the value of some variable. Right.

And I mean, I know that we've all, I'm sure we've all done that. Right. Like, you know, got here, you know, got here one, got here two. You ever done that kind of thing, right? Oh, man. Oh, all the time. It always starts out lazy like that. You're like, you know, one, two, three.

Like, where is it? How far? 25. Dang it. You know, and then it's like, yeah, you might write out like 25 statements, but then like when it stops at 17, you're like, okay, it died between 17 and 18. Okay. I've at least narrowed it down, right?

Yep. Okay. I've at least narrowed it down. Right. Totally. But, um, you know, I have found though that, yeah, I mean, that's definitely like the old, the, the lazy way of doing it, like the one, two, three, four that we mentioned, but I found that it's helpful to like write out the, to have the fully qualified name sometimes to that. If you're going to have like, you know, Uncle Bob would kill you if you had to have all those tracing statements in one method. If you were able to have 25 different tracing statements in one method, then it's way too big. So sometimes your tracing isn't just in one method. It's going across multiple classes, multiple methods within a class. And so I like to

have my statements written in a form of like, kind of like a C++ kind of style, you know, like class colon colon method name. And then I'll have the message to the right of that. And that way I can kind of like, as I'm tracing through this and kind of see like, what was the to see the value of, right? Then hopefully by having that class and method there, like that ambiguity is removed and you can see like, okay, this was the value at that time. But by the time that value, that variable was passed to this other method, it had this other value, right? I will say this is something that we've talked about in the past as well. And it's worth looking into if you're doing stuff like this. If you can introduce something like aspect-oriented programming, it can help you a lot with this because you can basically just say, hey, you know, I want to put in a logging aspect. And for every single method, you know, I want to see what happens when it's

coming in, going out, everything, right? And then you don't have to write a bunch of code in between. You can kind of just toggle it on and off. So that's sort of an elegant way of doing that if you ever need to. Yeah. And they add that this tracing methodology, right? this can be invaluable when time itself is a factor within your application yeah the only big problem that you have with this with this approach is if it's something that's in a production environment you got to get the code out there right so you're gonna have to add all the code into it and be like all right well let's deploy this thing right and then wait for your feedback loop which which can really stink, but it can be probably your last line of defense. Yeah.

And this is where like that format that I mentioned about like the class colon colon method, right? They say that these tracing statements should be in a consistent format, right? So, I mean, like I've shared what my format is, whatever your format is, it doesn't matter that your format might be different than mine. What matters is that, you know, there's just consistency in how you do it, right? So that you can, you know, be able to easily scan through those. Because if you ever, have you ever had it to where there are multiple different formats

of logging messages and you're trying to like scan through for yours, but you're like constantly like your eye is like zigzagging back and forth through the screen. It really does matter. Right. So this one I found like super interesting though, then this next section, which is rubber ducking, which,

um, if you'd never heard of this, this is just simply talking through the problem to someone else. And as silly as this seems, you know, it just, it just works. It does. It's probably like an 80% success rate. Now here, here's the thing that I found most interesting about this. So at the start of this episode, we were talking about how, you know, like Tracer Bullets, how ahead

of the curve Andrew and David were when they wrote this book, right? And I'm questioning, is the pragmatic programmer the origin of the term rubber ducking? Because they give a little, a story about like, you know, about this, where they say, why rubber ducking? Well, an undergraduate at Imperial College in London, Dave did a lot of work with a research assistant named Greg, I don't know how to pronounce his

last name. Poe, I'm going to say. P-U-G-H. Pugh. Oh, Pugh. Okay. Greg Pugh. One of the best developers Dave has known. For several months, Greg carried around a small yellow rubber duck, which he'd place on his terminal while coding. It was a while before Dave had the courage to ask. So clearly Greg is the one who was doing the rubber ducking first, but did the writing of the, you know, did the, did coining the term rubber ducking come from the pragmatic programmer? And that isn't answered in here that I saw. And I'm too lazy to Google it. Wikipedia.

What? It's listed as a reference to a story in the book, The Pragmatic Programmer. Nice. Ah-ha-ha. So, going back to them being ahead of the game, right? Yeah. And setting the curve for so many things that we now take for granted. Rubber ducking. So, yeah, this is the simple act of describing step by step what is supposed to happen.

And it often causes the problem to leap out to you as you explain it. And by forcing yourself to explain it verbally to someone else who has no knowledge of this thing, right? Then you're forced to state things that you might otherwise take for granted. And that's key, by the way, right? And have you ever been in that situation where like, you're trying to, you're trying to rubber duck something and then the other person be like, yeah, but wait, why is this do that? And you're like, ah, stop. I'm trying to explain it. But, you know, it really is helping though, right? Like they're questioning the things that you're taking for granted. Like every time that they're asking you something, it was because you took something for granted.

Right. And they don't know about it. Right. Right. Yeah, it's so true. It happens way more often than not that the person that needed the help ends up figuring it out because they're telling the other person, well, what I did, I did this, this, this. Oh, I mean, just asking good questions is good to you. Be like, well, so I think it got to here, but I don't know how to tell.

So here's the five weird, weird ways I've been trying to figure out if it stopped here. And you're like, well, did it send an email and you're well yeah i mean it should have but i guess i didn't verify let me go look at the email i said didn't send the email i'm looking at the totally wrong part oh my gosh right right right yep yeah it whenever you are whenever you feel like you've gotten to a point to where you've spent more than the amount of time that you feel is reasonable for the particular bug you're trying to resolve then it's time to rubber duck it yeah i would agree but that's after you've given it your due to the diligence though don't don't start with rubber ducking yeah we got the process of elimination here this is a what i'm a big fan of so um where it might be

possible that exist in a third-party library which i'm always trying to prove that they're wrong it's probably not it's probably in your code so you should always probably assume that it's your code first and don't go for reaching for those uh massive like windows errors or whatever until you've kind of exhausted the easy stuff to check on. He says even if there is a bug in that stuff, a lot of times, what are you going to do about it? You still need to kind of figure out and investigate it. Even going through GitHub looking for issues and stuff

can be really difficult. If you've ever gone to any sort of project of size, you're going to go there and sometimes they'll have hundreds of issues. You're like, well, it might be in this mess already. i don't want to create a new ticket if it's already there so let me just you know maybe check out your code first yep and and you know they make a point of calling it out in the book that uh even if it was in their system you're likely going to have to rule out the possibility of it being in your system first in code first, before you can even submit that bug report.

Right. So this was like maybe the first tip that we are about to encounter that might not stand the test of time as written, as it is written, right? And that is tip 26, select isn't broken. I mean, I get what they're saying there, but I wonder if they're going to reword that one. Because of the word select? Well, I mean, I guess that they're just referring to SQL in the way that they would be my assumption, right? And then they're saying like, hey, select isn't broken, and whatever SQL you're trying to write right but i'm wondering if they would rewrite this tip in a different way yeah maybe i'm wrong i could be wrong if you find a bug in sequel like sequel

server maybe oracle one of the big ones and it's probably not a bug it's probably documented intention what's that i forget what the there's something in sequel that i've tripped on a few times where it's like you can't access the temp table that was created in a proc that was like nested to there's some like weird thing that happens when you get like two products deep and it works if you test things in isolation it doesn't work when you put it together i've run into a couple times and i've already forgotten what it was now. Dang it. But yeah, that's not technically a bug. It's a known limitation. That's what they say anyway. Yep. And they say here, if you change one thing and things stop working, guess what?

It's probably that one thing you changed. Yep. Seems obvious, but a lot of times it's like Joe said. Well, it can't be what I did. What I did had to be right. Yeah, and it's so frustrating though when you do change something and it breaks and you roll back your thing and it's still broken. Oh, that, that's irritating.

That usually means there's some sort of environmental thing that changed. It wasn't your fault at all, but. Or you found another problem. Yeah. Yeah. Yeah. That is frustrating. And of course it was the whole, like, how did this ever work thing?

I love that. We've all had that. This never worked you couldn't have why why yeah that's generally where i start yep you deliver the fix and you confidently say that it never worked and someone confidently tells you that it did actually work and you're like well wait did i fix it then i don't know anymore yeah uh if you don't know anymore. Yeah. If you don't have an idea of where to start, a binary search can help. Yeah. So when they referred to binary search here, though, they're not like immediately I, my brain jumped to get bisect.

Oh, yeah. Right. So I was immediately being like, okay, I get it. You know, you're going to go back to some commit where it previously worked and then you're going to like bisect your way until you find the commit that introduced the problem and then, you know, get blame it. Right. Yeah. I'm pretty sure they were just talking about splitting the code in half and putting a break point somewhere in the middle and being like, did it break? I mean, this is kind of like going back to your 25 print statements, right? Right. Yeah. Like, okay, it stopped at 17.

Okay, I know we're somewhere after 17. Right, yeah. This is literally just find somewhere in the middle, put a break point and see what happens, right? Did you make it there? Did you not? Okay, you didn't. All right, then cut it in half again and go back.

But yeah, but in today's world, though, when we talk about binary search, it's very easy that you could, as it relates to developing and bugs, then get bisect is the thing that might come to mind. Or maybe it's just me. I think it might be. It's not me. It's the source control in you.

Yeah, I am. I am much more prone to delete half the file than I am to get bisect. I think I am too yeah store procedures and stuff and it's like sequel it's like step one go get the definition and delete the uh delete and change to declare like i could almost like list the steps for like converting a proc to sequel you can just run it so it's such a pain such a pain uh the element surprise so when you find yourself surprised by a bug saying something like that's impossible then obviously you need to re-evaluate what you think is like your base case so definitely agree with that it was like there's something about your

assumptions that are wrong or you stepped into the twilight zone either way possible yeah they had this statement here that i was like i felt was so true because it was like the amount of surprise you have is directly proportional to the amount of trust you have on that bit of code i agree and i was like we've all been there right like somebody says like oh such and such is broken you're like no it can't be oh it is like i definitely had this happen to me one time before actually uh it's been it was a few years back now it was a it was a caching system and they were like hey there's a problem with the caching system and i'm like no it can't be and they're like no no there totally is i'm like what no that thing is like there's so many unit tests like protecting that thing like really it's it's broken and they're like yeah i know it's it does this and i'm like it just doesn't sound possible turns out was it broken it was broken

hey guess what there was a there was a test case that wasn't covered yeah but it also goes the other way there's been lots of times when it was like someone, hey, there's got to be a bug in your stuff because all my stuff's right. And I'm like, no, there isn't. I don't think so because it's been working forever and nothing has changed here in a long time. And they go back and forth and go back and forth. And, like, somehow you end up with it. And by the time you, like, end up researching it, yeah, it was you. I told you it was you.

Yeah. So I like this. You must accept one or more of your assumptions is wrong sometimes that's the hardest thing to do but i mean proof is in the pudding i mean it goes all the way back to the beginning of this section right like put your ego aside yeah yeah there is there is a problem with the caching system so just you know accept, move on. Don't gloss over a piece of code because you know it works. I mean, it's easy to do. Prove that it works. That's about the only way that you're going to make sure that, you know, everything is what it's supposed to be. In this situation, with this data, in these conditions.

Totally. And that's the key part. And that's where having a unit test can help you. Because you can easily add in that, recreate that state. Yeah. I'm confident this part still works right with the given input. So what am I not looking at? And that's where tip 27 comes in.

Don't assume it. Prove it. You know, if somebody says there's a problem there, the easiest thing to do is go prove it that it is or it isn't. Right? So. Yep. So, you know, once you do find that, you know, find the bug and, you know, what's's caused it try to determine why this bug wasn't caught before and you know they make a point of saying like i've already kind of said this before

but you know create or update the unit test so that this is caught in the future right and then they also said like you know to ask yourself like are there other places where this bug where you might have this same bug and if so fix them too. But I kind of questioned myself when I was reading that part because I'm like, uncle Bob would be really upset if he read that line. Yeah. Does that mean you copied and pasted a bunch of code all over the place? Well, it doesn't necessarily have to mean copy and paste, but it definitely means that you have like the same thing being done in multiple places maybe right so you don't have a method that's just doing that one thing but if we go back to our clean architecture series remember you might have

code that is very similar in multiple places right accidental duplication either accidental or purposeful right because because you actually want those things, they don't change at the same time. Yeah, they change at different times for different reasons. Yep. Yeah. So, yeah. If the bug took a while to fix, ask yourself why. Because programming is hard.

That is true. Yeah. So, did you see the challenge for this section? No. It said debugging is challenge enough. No homework for this one amen yeah i mean this one about like asking yourself why though that was kind of i thought it was kind of weird but they were like saying like is there anything that you could do that would make this easier in the future and the

only takeaway that i had from that was like well I guess what they're really getting at here is like, if it took you a while to debug this or fix this bug, then is it maybe possible that you could refactor the code in such a way that you could more easily isolate and unit test portions of it, right? Because like, I could definitely see a situation where it would be more difficult to debug or, or find the problem in a, in a particular system. If there's a bunch of dependencies that are baked in and it's all intertwined and tangled and you can't easily mock things or create unit tests and whatnot. And so therefore you're just stuck in a world where it's like, well, I just have to run through the system live. And if I happen to like stumble upon the bug then i can

find it you know what i'm saying um i'm not sure what else i guess where i'm going with this i'm not sure what else you could do other than to try to untangle the mess though yeah i mean i guess every situation be unique i mean it could even be that there's just really bad patterns, right? And it's super hard to follow because it's just a nest of garbage. But, yeah. Okay. I mean, because there was something that all three of us had tried to do in the past. I don't even remember what it was. But each one of us had hit something at one point.

We were like, man, I'm making this better. And then after a day, you're like, I don't have time to make this better. And you just back out, right? I don't remember what the situation was, but I'm pretty sure each one of us had both hit the same place. And we were like, and it just, the rabbit hole never ended. I'm trying to remember. And it seems like that was back a couple you know, a couple of gigs ago. It was several years back now.

Yeah. And, and I know we had all like, we had done it and then we had a discussion like, Oh, you tried to do that too. Right. Yeah.

I gave up. Yeah. So, yeah. I mean, sometimes it's just, it's, there's some problems.

There's some hard things to do. Now, here's an interesting point that they made though. If the bug is due to someone else's wrong assumption, then discuss the issue with the whole team so that you can highlight that person's mistake and call them out in front of the team. No, I'm just kidding with that part. But no, they do say- Nicely done. You're welcome. I made it sound so seamless. They do say, though, that if the bug is due to someone else's wrong assumption, to discuss it with the whole team.

But the point that they're getting at is that if one person misunderstood it, then it's likely that others did too. Right. Like, yes, we charge sales tax. And then they had a debugging checklist and and a lot of the checklist here uh i don't know it was just stuff that it it didn't really seem like it would be to me it didn't really feel like it was part of a debugging checklist because like one of them was like is the bug really in the compiler or is in the operating system or is it in your code okay well just accept that it's in your code yeah right like i mean like if you gave me a bug

i'm not gonna be like well is it really mine hold on now probably yeah are you sure that this bug is not in the gcc i mean i mean i'll give you an, though, like it won't always be your code, right? Like one of the tips I gave out at one point in time was disabling quick edit mode on a console window, right? Because you can, if you were to click in that window, it'll stop the operation of your console application, right? If you have quick edit enabled. So there could be things in the OS in an environment that you're just not aware of

that could be causing things. And it's not actually a bug in your code, but it was a feature in the OS that's causing it. So the point is start in your code, exhaust everything there. But it could be. Like as your checklist of things that you're going to go down you wouldn't

you wouldn't start you wouldn't say oh it's the operating system but but the one that i really did like though that was in here was that like you know are your tests complete you know do you have enough test unit tests to cover the various scenarios like edge cases boundaries you know whatever it might be right yes yeah the cash thank you alan hey you brought it up i didn't think it was gonna be a knife later dabbed in my back no in your front this is awkward all right well uh so with that you know hope you're enjoying uh the pragmatic programmer i'm trying to not say it wrong anymore and i was struggling right there i don't know if you can hear the straining in my voice i did but

uh yeah so obviously we'll have some links to the resources we like and obviously uh a copy of this book will be one of those resources and with that we head into Alan's favorite portion of the show. It's the tip of the week. Yeah. Some people like this portion of the show. Yeah. Yes. And so I'll start with the tip that Ketch added this in. And so, by the way, if you have a tip, you can head to codingblocks.net slash tips, and you can submit a tip there. Or if you're in our Slack channel, there's also a, uh, tips and tricks, uh, channel in Slack. But, uh, he reminded me that in visual studio code, um, it has this really awesome ability to preview your markdown. So like, as you are editing it, you can see the, uh, pretty five

version of your markdown and you know, the cursor moves with you and whatnot. So, uh, you can do this a couple of ways. Like you could, uh, on a Mac command plus K and then V or switch out the command with control. If you're on windows, uh, to open up the preview window or if you are would prefer to not use your mouse to not use your keyboard rather then you should probably listen to the previous episode where we talked about keys keystrokes but there's a little window when you're in your markdown that has like a it almost looks identical to the split pane one, except it has like a magnifying glass over one side. And that little button right there will open up the preview for the markdown. So, and it splits it out, right? Like when you click that thing, it splits it out to the right. So

your markdowns on the left and then your previews on the right. Correct. So thank you catch for, uh, submitting that tip of the week. Very nice. All right. So mine, I've actually got to one because I just used it recently and forgot how much I love this thing. And the other ones from somebody in our site group. So the first one is link pad. Like I know we've mentioned it probably years ago now in terms of tools that we liked. And the reason why this came back up for me recently is I was having an issue where in a CS or a SQL project file, there were duplicate files in there and it's an XML file. And so there were like duplicate XML entries. And I was like, man,

like there's gotta be some sort of utility out there to where I can see what these dupes are. Right. And I couldn't find anything that was like just an XML, you know, thing. And I was like, you know what, if I had a C sharp app, I could write something that'd be a link query that load up this XML. And then I could just group and see the counts of these things. Right. And then I don't know, I guess when I was thinking a link query, Oh, I'll try a link pad. So I was easily able to say, Hey, load up the, the SQL proj file. And then I could just say, all right, give me where the, the particular in, uh, include tag was grouped by the name value. And I could actually get the count of it. Like I was

able to de-dupe the entire thing in a couple of minutes. Like it was amazing. And the reason I bring it up as the tip of the week is you could do all kinds of stuff like that. It's not just if you want to do link queries, you can write C sharp F sharp or VB. And the cool stuff that I didn't even realize they had available is you can do things that aren't just link specific. If you just want to write like a little app to dump out the date time or something, you don't have to spin up a console app to do that, right? You don't even have to go to.NET Fiddle.

You could do it here. And another thing that's cool is they have this wrapper feature to where if you want to test out like a chunk of code, you can actually create several classes and then tell it to run it as an EXE. It'll wrap it and then run the whole thing. And one of the super nice things about it is almost every object has this dump feature. So you can call dump on whatever the object is and it'll pretty print out the contents of that thing down below. So it is a fantastic utility for just being able to one off some,

some code that you might need to do in the OS or just, you know, you want to see how it operates, but you don't have to run an entire program to do it. So definitely check that one out. Yeah. I mean, I found myself just, you know, you mentioned going to like a.NET Fiddle. I've definitely done that where I'm like, wait a minute, I think this would be the syntax for it.

And I didn't want to like, you know, mess with whatever instance of Visual Studio is already in and didn't want to spin up another one. And I've also found myself in a situation where like, even today where I was like, well, I think this is the syntax for this particular thing. I'm going to go to the immediate window, try it, verify that what I'm thinking works the way I think it works. And, you know, but then like it would, when you,

if you weren't already in a debug session, then the immediate window would like spawn off, you know, a background console window that everything's executing in. And you're like, okay, well, how do I stop this thing? And you're trying to close that because it's not really in a debug session, so there's no stop. But yeah. It's frustrating. Like, it seems like just being able to do some arbitrary C sharp or F sharp or VB would not be that hard. This makes it super easy.

So I highly recommend it. If you need to do any like utilitarian things, like I said, I was trying to de-dupe a CS SQL proj file and it worked fine. Yeah. We, we covered link pad originally in episode guess six Joe you got a number you cheated no you were right episode six yeah

there's something about link was the episode wow that's been a minute and it was pretty interesting we had a section called never have I ever and one of the things that we had in here is And it was pretty interesting. We had a section called Never Have I Ever. And one of the things that we had in here is,

Never have I ever written out a for loop only to have ReSharper complain that it could be written as a link expression. Oh, I do that. Yes. I still do that. All right. So my second one, this one's actually pretty short, but this is from Zach in Bristol and in Breton. So this is really cool. I didn't know it existed. If you have them installed on your system, if you're on a Mac, it's probably in your terminal already. If you're on a Linux system, you can do it there. You can just type in Vim Tutor and hit enter, and it'll open up an interactive tutor for learning Vim. That's amazing.

I didn't know that existed. Now, the funny part here, though, is that when you do it, like if you had zero knowledge of vim or vi you would already not know how to get out of it until you completed this tutorial yeah you will be in there for the long haul because right away there is no there is no like oh hey if you didn't mean to do this this is how you quit no you're gonna close the terminal window wait what like how how but but super cool i didn't know that existed it's built into vim yeah now in fairness though to that little joke because somebody's gonna like you know complain like you it is on like the second page okay so it's not that far down like i i honestly like one of the things i didn't know was the hjkl for navigation i truly don't understand

why they use those key bindings wait how are you navigating then i always use the arrow keys oh really yeah so i mean because they work the same it's actually easier in my opinion to use the up down left right arrow keys but but, but whatever, like I, this is where some of the things for Vim just sort of fall apart for me, like H J K L for your navigation. Like, yeah, but it's all about like keeping your hands on the letters. Give me WASD. Like seriously, I'm not doing, I'm not WASD, not WASD, WASD, WASD, WASD. Yeah. So, at any rate. I'm just picking on you. Fantastic tip. Thank you, Zach, for that one.

And that's it. Yep. And I got one, which I thought I had mentioned before, but I hope not because I'm going to do it again. And that's Reversi, which is a super simple proxy that you can use. You can go download it. It's free. It's by our friend over at, I don't know how to pronounce your name. Sorry. Gillespin.

Oh, you did mention this one before. I think I might have, but it's just so good. It's so nice because it's kind of like, you know, Fiddler is nice. If you've ever used it, you could do everything in the world with Fiddler. But it's kind of stupidly complicated. It's like there's a lot of different things. It does a lot of different use cases in it. And, you know, it could fit in between

your browser and whatever if you've just got like some sort of endpoint that you're hitting and you want to see the request responses man do yourself a favor download reversi in five seconds you'll be up and running you can pause it you can kind of manipulate by hand if you want to change things or repeat stuff it just it's that one single use case but it just does it perfectly and, and it's all simple, and all the buttons are there. You don't have to go Googling around for the Telerik Fiddler instructions on how to do simple proxies and stuff in this because it only just does the one thing. It's really great. I use it quite a bit, actually, and it's just so nice that I had to mention it again or maybe just once. I don't know.

It's totally again. Well, if he has mentioned it we didn't document it as the tip of the week all right good or bad i don't know but i'm still trying to figure out like this is in place of using like a fiddler yeah we're saying right because and like in the advantages of your browser or lighter weight we're saying right simpler yeah so what i do is like i'll be communicating with a service like a, you know, elastic searcher database or something. And I'll just go ahead and like plug in, like, I don't know. Let's say I'll go to localhost 999 and it will forward to this URL and that's it.

You can hit start and it'll just start proxying. So wherever you hit on localhost 999 ends up going wherever you want it to. And you get to see all the requests in between. Yep. Pretty great. Beautiful, pretty great. Beautiful. Very cool. All right, so that's it for this episode.

We talked about kind of power editing. I've got the tips here again so we can blast through them. So 22 through 27 today, we've got use a single editor well. Do we all agree with that? Yes, sort of. Yeah, yeah, sort of. I'm with that. How about always use a single editor?

What counts as an editor? I gotta say no. There's too many editors, right? You're going to use more than one, but learn to use them well, I guess is what I say. How about learn to use one well and just kind of use the others poorly? No, use them all well.

All right. Always use source control. Definitely yes on that one. Yeah. Yes. Yes. Fix the problem, not the blame. I assume we're all yes on that one. Yes. Alright. What about don't panic?

Yes. Okay. Also, I didn't write down 26. What was 26? Oh, uh... What was 26? Select isn't broken. Right. So assume that you had the problem yes and tip 27 finally was uh don't assume it prove it yes i like it which yeah i like that too so the only one that we were kind of iffy on was uh you use a single editor well and that's probably just a case of how things have kind of evolved well because like as you said it though like i was

thinking like well what counts as an editor right like you could you you know you and i might not be willing to count like a data grip or a sql server management studio as our editor but to a database developer they would definitely call that an editor so yeah i have it open all the time right so so if you say just one editor well it's like well i mean man i'm always between you know some kind of code editor that's not sql and then some editor that is sql so at a minimum it too yeah i say that's what i'm saying i sort of agree with it except i instead of single you say get the ones that you're going to use and learn to use them make them proficient for yourself i mean i understand where they were wanting to go with like just one but yeah yeah maybe it's a little bit dated we fool stackers yeah well yeah

i'll tell you i have several and there's a couple admin panels i always have open to like websites website so pg admin no thank you all right well with that uh subscribe to us on itunes stitcher spotify and more using your favorite podcast app and as i mentioned before we greatly appreciate it if you take the time to leave us a review and you know that could just mean whatever uh platform of your choice that you happen to be using, thumbs up, star, or leave us a review. If it's iTunes, Stitcher, you can find some links at www.codingblocks.net slash review. And we have this thing called a website. It's at codingblocks.net.

Is that on the World Wide Web? That is on the www. You can check out our show notes examples discussions and more and check out the slack channel because we have the best and brightest minds and all the programming in there and I'm not afraid to say it

it's super awesome and I need to spend more time there because it is super awesome but we're in there not enough I've been busy last couple weeks so I've like lost touch but it's nice there's a couple channels I like to go in there and just enough. I've been busy the last couple of weeks, so I've lost touch. But it's nice. There's a couple of channels I like to go in there and just kind of pop in and be able to catch up a little bit. So the best and brightest minds, you're referring to those other people.

Oh, yeah, yeah, yeah. For sure. That makes a lot more sense. I get it. Yeah. And also, we're on Twitter at CodingBlocks. You can head over to the website, CodingBlocks.net, and find out the social links at the top of our page.