Coding Blocks - How to be a Programmer: Personal and Team Skills

Episode Date: January 28, 2016

Talking about the short book “How to be a Programmer”, which covers a huge spectrum of important topics for developers of all levels. The Puddle Poll! Thanks for the share pwright08! News Thanks for the reviews! JKCooper2, CSharpest, Joopkins, NickStuer How’d you get into programming? Join codingblocks.slack.com! Survey – Star Wars wins! Check out Allen […]

you're listening to coding blocks episode 38 subscribe to us and leave us a review on itunes stitcher and more using your favorite podcast app this is at codingblocks.net where you can find show notes examples discussion and more 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. Nobody even knows what's up. Do you know what that's about? Yeah, I do.

I do. I do. Let's finish the introduction and then we'll get into it. Yeah. And with that, welcome to CodingBlocks. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw.

And today, for every time we say um, we'll be giving away a dollar. Wait, whoa. Okay, maybe not. No. But we're really going to try and stop doing that. Yeah. So since you brought up www, let's get into, if you're not already, we've been having a lot of fun conversations over at coding coding blocks.slack.com. So, uh, you hit us up on Twitter.

You could, you know, send us a DM or you could email us at comments at, uh, coding blocks.net, or you could hit us up on discuss right now that it's by invitation. So what I mean is hit us up on one of those sources and, uh, we will add you to the, to the team, but at some point we will add you to the team. But at some point, we will automate that to where it'll just be a click of a button. Here was the thing about the DM, and this is what I found out on Twitter. Twitter won't let you DM somebody that's not following you as well. And we've gotten several people that literally have been like, they will have just followed us.

And so we haven't followed them and they're like, Hey, I can't DM you. So if, if you can't direct message us because we're not following you, it's not because we're trying to be rude. We just, we're terrible at social.

So, you know, find one of the other ways, definitely get it back to us. And even if you want to come drop a note on, on the, uh, what are they called?

The comments down at the bottom of our show notes page yeah discuss you can do that and if you want to delete it afterwards so that your email's not hanging out on the interwebs for people to try and scrape you can do that too so yeah i mean that's totally your call yeah just find a way but comments at codingblocks.net is a good way to do it and we've had some great conversations over there, guys. A ton of really good conversations. People are talking amongst themselves and with us. And it's a lot of fun. We've got like 25 people in there right now. And it's really turned out to be pretty awesome. Yeah, I didn't think anyone's going to join, but it's been really good and really funny. And I always learn something that someone's always saying, have you looked at this?

And I haven't. So it's been really great. Yeah. I mean, not just the entertainment factor, but again, people are sharing tools. Uh, Stephen Kurt, I had a really great conversation with him the other day. He's attending some Microsoft conferences currently right now, and he's like shared a ton of useful information. So, you know So definitely go up there and check it out. You'll learn something. You'll meet some new people. It's a lot of fun. We'll get into some more stuff here in a second,

but I guess we should go with the flow of our show notes. Well, yeah. I mean, I brought that up because you brought up the WWW thing. But actually, while you were speaking, I realized, oh, yeah, that actually wasn't brought up on Stitcher review on, yeah, on, on the Slack channel that was brought up as a Stitcher review comment. So point is join us on Slack. We're having a lot of fun conversations over there and you know, it's just a place for like-minded developers. You know, we can all, uh, you know,

chit chat about random topics and there've been like some cool little one liner, like puzzles that we've thrown out there too. Um, that, uh, you know, there, there have been a little good brain teasers.

So fun times. Yeah. And so the next part is our iTunes and Stitcher reviews. So we've gotten one new review on iTunes. I think outlaw, you dug this one up right yeah this one was from australia and it was awesome from my jk cooper too so thank you we've got uh you know some new reviews on stitcher from the c sharpest uh jupkins and i'm gonna mess up your name nick uh stewart yeah yeah okay okay well at least alan agrees with me so it can't be

totally wrong and nick was the one that brought up the www i guess i'm i know i'm i'm probably pretty bad about saying www or dub dub dub that's usually what i say i do that one too but you know i was actually thinking about this because when he when he made this comment basically he was joking around or well maybe he was serious about uh us not pronouncing w w w but instead saying like either dub dub dub or w w w but like well for one i mean come on it's the year 2016 nobody's got time for all that like really and then number two like the thing i was thinking about the other day is like okay i kind of feel like there was some guy that invented the alphabet and this was his like you know insert expletive here to the world because he was like you know what i got a b c i'm tired of all these single syllable letters i want some some letter with some strength about it.

You know what I'm saying? And so that's what W was. It takes, there are more syllables and letters in W to say it than in the actual letter itself. That's crazy. I think it might have been masterpiece. He's like, oh. That's pretty good. that's pretty good that's great you know best impression that's up there with the wookiee impression

and for all of you who haven't been around long enough you just have to go look that one up and i did want to bring up so we talked about our Slack channel a second ago. And again, we're excited about it. It's fun. But I did have a great conversation with Stefan the other day. And he lives in Austria. And so that's really cool. And we got to chatting about, you know, coding in general.

And he shared a really cool story with how he got started into programming. It was all based out of wanting to do something really well in a video game. And he was having to keep track of how he was allocating resources and that stuff to go over and take over planets. And it's that kind of stuff that drives a lot of great programmers, right? Some people are motivated by money and they're like, hey, I want to get into computer science because I hear you make a lot of money, right? Some people are motivated by money and they're like, Hey, I want to get into computer science because I hear you make a lot of money, right? Those people usually don't last because as you know, if you're listening to this podcast, if you've been in

programming for a while, you know, it's like lifelong dedication to learning, right? Like it really is. And if you stop learning, then chances are you're working in a job that's, that's getting stale. And if anything ever happens to it, you you're working in a job that's getting stale. And if anything ever happens to it, you're going to have a hard time adjusting. So that was just kind of interesting. So what I'd like you to do is if you guys don't mind, if you get a second, you know, go up to this particular episode and share your story about, you know, what turned you on to programming? Was it, you know, I don't know, you were doing a math problem, and, oh, man, I could make something that could totally do my homework for me,

which is kind of what I ended up doing. Or, you know, was it a video game? I know video games are a big one. They're huge, right? Yeah, I mean, I definitely have friends like that was the thing, especially back in the LAN party days. Yep. Well, you go back to console party days.

But, you know, yeah, the LAN party days, Joe knows what I'm talking about. But, you know, a lot of friends got started. That was their thing was, you know, just trying to, like, either fix a problem in a game or trying to understand, like, how to make it work. You know, definitely reading the code, you know, was how they got started. And, you know, fixing the problems, you know, to make it so that they could keep playing this fun game, right? Yep. I mean, levels. Yeah, there's tons of stuff. And nowadays, it's like, you know, nowadays kids for, you know, this generation of kids, you know, if they want to create a Minecraft mod, like that's a thing, right? Some kids learn Java to be able to do that kind of stuff, right? there are entire classes and courses and books about like just just around minecraft alone yeah so totally if if you guys want to share

you know an interesting story bring it up there and post it on the site and also you know come join us on slack and let's have a cool conversation so uh that pretty much covers that part well speaking of comments uh we have a riddle for you from, uh, episode 37. Well, I don't know that we have it. There was a riddle.

That's right. We can't take credit for it. We'll share it. Yes. So, uh, let us know if you figure out what the answer is because, it's been three days and,

uh, he hasn't posted an answer. So, uh, the riddle is another survey, another contest, the Riddler, another poem. No, but how about the riddle is another survey another contest the riddler another poem no but how about

a riddle i'm both hot and cool at the same time what am i did you and did you say uh who who the author of that riddle was yes tired of the carp yes i think there was a typo there i don't know you can find it i wasn't sure if that was a slam or if he was just tired of fish. I don't know. Yeah. Yeah, I know I've heard this riddle before, but I can't remember it. Yeah, this is going to drive me crazy. Yeah, we're not going to try to solve it now. But going back to the Slack channel for a minute, right?

There was, you know, actually this time I'm prepared with a survey, right? Very nice. Because there were some interesting conversations on there, like, you know, apparently someone's sensitive about their age, right? I don't know who but apparently somebody and uh you know one of the interesting conversations that came up there i don't even remember who somebody somebody posted this video and i want to say it was uh uh andy that posted this video of people jumping a puddle. Oh,

right. Right. Now I want to post this, this video, uh, you know, in our show notes here, cause I want you to take a look at this because at the end,

one person just decides, you know, everyone else is walking around the puddle or jumping over the puddle. But this one person is just like, you know what? I'm going for it. I'm walking. Hold on. They weren't walking around the puddle.

They were actually having to climb through mud and trees to get around the puddle. No, they were not. You're totally exaggerating. It wasn't exactly the easiest thing to walk around because of the way the path, because there was a handrail around the path but uh yeah so it's a little bit of an effort a little bit but you know someone maybe alan said that the last person who just straight up walked right through this puddle did the smart thing and i'm like wait a minute what what it wasn't even an

inch of water like your souls on your flip-flops would have been deeper than that puddle was no way man you gotta walk you got if there's if if you can walk around it or walk over it then you walk around it or over it man you don't walk through a puddle yeah but these people weren't just walking around it wasn't like they could just you know strafe to the side of it they were literally climbing trees and oh by the way like everyone in there like they kind of looked you know the dress of everyone in the video it wasn't like they were like super casual right you know they they were wearing you know nice clothes like it looked like it looked like they were probably going to work or someplace you know i think what we're getting at

here is outlaw totally would have spent half an hour trying to figure out how to get around this puddle i just thought it was crazy that you said that the smart guy the only one who was smart was the one that walked through it i'm like that can't possibly be nobody would agree with that statement right i think we're gonna find out we're gonna find out because this is science and in the name of science we're gonna we're gonna do this survey awesome so it was either that or i do have a backup survey if you want to hear it no let's keep the other one for the next one i think that's a good survey all right so go to uh episodes slash episode 38 watch the video and vote in the poll yeah yeah we definitely need to like find this out for science purposes and then uh you know

i don't know joe if you've noticed this but i think um this celebrity has gotten to alan's head here because uh for all you dear listeners that don't already know, Alan was recently interviewed. He was on another podcast here, the MS Dev Show. What do you got to say for yourself, Mr. Celebrity? I wasn't getting any romance here at home. Alan was stepping out.

I had to step on out. Wow. And then you guys started showing me love again so that's that's harsh yeah but we've mentioned ms dev show before uh it's a great show and it's a great episode um so yeah you guys should definitely check it out we'll have a link in the show notes yeah it was a lot of fun so you know hopefully you know you guys go over there learn some stuff they have lots of episodes about tools and stuff. This particular episode was about our tools.

Wow, that just sounded... That was not a really good or even planned... Interesting. They talk about tools and stuff. Our tool episode. This time they talk about our tools. Okay, so that's great. That's the way to sell it. They talk about tools and stuff. Our tool episode. And this time they talk about our tools. Right, yeah. Okay, so that's great.

That's the way to sell it. Go check out that episode. We'll have a link in the show notes. I would say maybe instead of saying they talk about tools and stuff, maybe say they talk about a lot of Microsoft technologies. Well, all kinds of technologies. Not just Microsoft. They actually talk about all kinds of stuff. Not just, but a lot of them, right? Yeah. I mean, all kinds of technologies. Not just Microsoft. They actually talk about Microsoft. Not just, but a lot of them, right?

Yeah. I mean, there is a focus. And if you're into Azure and that kind of thing, they definitely have an Azure tip of the week. So it's an excellent show. Great guys over there. Always excellent sound quality as well, which is, for me, a big deal.

I can't listen to a podcast with bad sound quality. And don't say the answer, but what question did they ask you? They asked me, would I rather give up celebrating my birthday or celebrating the winter holidays? All right, don't answer. You got to go over there and listen to the show to find out Alan's answer. That's right. Nice, nice. All right, don't answer. You got to go over there and listen to the show to find out Alan's answer. That's right. Nice, nice. All right. All right, so, oh yeah, go ahead, sorry. Yeah, I was just saying we were done with the news, so I want to tell you what we're going to be talking about this episode.

And basically the deal is that we found a great summary slash book that attempts to cover the entire spectrum of everything you need to know about being a programmer and it um it's got kind of um sections on like harder skills like technical stuff debugging stuff like that as well as like people managerial type skills and we've all read it and so uh we're gonna give it a go it's divided into three sections uh the first one is uh geared towards beginners but really uh you know it's it's useful for developers of all uh experience levels and uh yeah i'm excited i said oh like three times in there i'm gonna be broke by the end of this episode you're gonna be a poor man yeah i think he was like 50 bucks so before we get started in this like when we first talked about this particular topic i i have to admit, like I was not looking forward to it because if I don't know, just sometimes when you read things about programming, you know what it takes, they can come off as really boring. But this was a pretty good read.

So, yeah. Yeah. I mean, it's not a terribly long essay, but it's got some good content in it. And, you know, each section is is bite size it's easily digestible so yeah it was a good little fun read so yeah it's 60 pages total it was published in 2002 and the first section of the beginner section is roughly like 17 pages you know there's some um contents and some indexes and appendixes that make it so it's not actually that many pages. But it's a really quick read.

And you can actually get it on your Kindle from Amazon as well. It's actually got a book as well. It's really cheap. I think it's like $1.99. We'll have a link to that. Now, here's the crazy thing. Is that, you know, go back to that episode. I want to say it was episode three.

We still don't understand open source licensing. Right. Does that sound right? I'll verify that in a moment. Five. What? It was five? I believe it was five.

Oh, well. I don't understand our episode numbering either. But this book has a GNU free documentation license on it. Like, I thought that was awesome and interesting that it was, you know, and clearly stated right there in the appendix. Like,

here's the, what can you do with that? Oh, it goes over all kinds of, uh, interesting details about like, you know, you can use this for commercial purposes.

And as long as you include the license, you know you can use this for commercial purposes and as long as you include the license uh you can there's verbatim copying in it like i'm no lawyer so i don't know yep uh but yeah i thought it was interesting that the book like literally one of the appendixes is here's the license to the book. Yeah, I think basically the deal is you can take this content and do other stuff with it as long as you kind of maintain that license so other people can do the same. So the information just kind of propagates and theoretically lives along and gets updated as needed, which is really cool. Yep, and I will say this. This thing was written several years ago, and honestly, I didn't read anything that I would really dispute in it. So I think there was a lot of interesting things.

There's probably things that we'll each feel more passionately about than some of the other topics, but I think it's worth starting. Let's dive into this thing. Well, you know, I should mention that because it was written in 2002, you know, that was pre-cloud. It was also pre-Git. So they are missing the section on how to revert merges,

which would be very important for any sort of programmer coming of age now. It's difficult and confusing. You just get cloned to a new directory. I don't know that that's taught anywhere. Revert your merge? Like a merge gone bad? Yep. It's never happened.

Just reset. Get reset hard head. All right. So let's do this thing. Pull request. That's why we pull request. Yep. All right.

So the first kind of part of the first section we're talking about for beginners here is personal skills. And at the top of this we've got learning to debug yeah and one of the i highlighted this in this particular quote in it is awesome to me a programmer that cannot debug effectively is blind and that's that that about sums it up right there i mean yeah and and should also mention too, there's a lot of these chapters. So I don't want to go too deep into any one of them, only because we'll never get through all of them. But yeah, that was a great quote though. yeah and um one thing uh i think it's kind of interesting and they kind of they kind of hint at it is you're going to be spending so much more time debugging than doing anything else

like you are going to be clicking that f10 button of the step through or looking at you know logs or print lines you're going to spend so much more time doing that than you are going to be typing new code it's not even funny. So debugging is very important. Yeah. So, so yeah, I totally agree. I wasn't necessarily crazy about the methods that were mentioned because basically, you know, this section gets into, you know, in order to learn a debug, you need to get visibility into how the program works, right? Like if you, if you just started a brand new job, right?

And they're like, hey, here's a ticket. You know, go fix this ticket, right? Like the first thing you got to do is start stepping through to see like, well, how does it, how does it, before I even look at the code, maybe like see like, okay, what steps does it take to reproduce this problem?

And then, okay, now that I saw the, you know, it's running state and how that worked, like, where are those actions at? And let me start driving into this thing to see, like, okay, well, where is this part executing and how does this happen? So, you know, you got to gain visibility into it. And they mentioned, there were three that were mentioned for, you know for ways of getting into that. And they were categorized as using a debugging tool, printlining, and logging. And I guess especially the printlining one just didn't sit well with me. I mean, I guess sometimes you've got to do it.

It's been a few years ago, though, too. I mean, if you think about that. Oh, yeah. Yeah, totally. Great point. Great point. I mean, if you think, Oh yeah, yeah, totally good. Great point. Great point. I mean, cause it's like 13 years old,

right? Yeah. Back then. That's kind of what you did back then. Yeah. I mean, 13 years is a long time in terms of programming. I mean,

look at how far things have come even in five. Were there any good JavaScript debugging tools five years ago? Well, well, five. Yeah. I would say the fire, bug fire i guess i guess what didn't what i didn't like the most about it wasn't that the author wasn't correct it's just that like

i cringe every time you're in an environment like that right every time you're working in javascript just tell me that you don't still do console.logs and throw some extra information because that's not logging because you delete it before you uh check it in you know it happens console.log would totally be an example of print lining yep right like anytime you're writing out to you know a standard out right that that would be print lining but i can beat that though because it wasn't so like it's it's been a few years for me since i have last used xcode but i can totally remember a time in that with using xcode where if you wanted to debug the value of a variable you had to output the value somewhere whether

that be to a log file or to the console and that's why like when i read that i was like i just kind of cringed inside because like oh that's horrible you know debugging tools are great for static languages or um i guess not necessarily static but just compiled languages and if you're working in something like ruby or python or something you know the debugging tools there are really uh really rough you know it's just not the same so you know sometimes print lining and logging are you know your main options but whenever i see print lining i know that there's a failure in testing because what you're doing is basically validating you know that certain areas of the code work or have the expected um input so you know what that means is that code isn't tested and you're not really confident that it's working and you know that and you know that's valid it happens but it's just something to think

about well they also said though sometimes you're using like a third-party library where you can't step through their code so you don't have a ton of other options then you're back into either logging or print lining right it print lining is usually more if you're trying to step through the problem whereas your logging is you know you've got a more long-term solution in place typically if you're doing logging type things so now i will expand on joe's example though for the print lining or the logging where you know you mentioned just spitting out a value i've actually done in the past where like just outputting like i am entering or leaving a method too because oh yeah i don't i i know that the method's good and i'm trusting the method but

sometimes it's just helpful to see like you know make sure the flow what the call stack flow like what's happening so you know in lieu of a call stack from an exception i'm creating a call stack at like runtime just to see like how it's going through. So, I mean, it's been horribly gross and, you know, usually more verbose than I ever wanted. So no, here's one thing that was kind of interesting in this entire chapter. Like this was one of the longer sections, if I remember right. But one of the things I said is you have to learn to poke at the code and make it jump. You have to learn to experiment on it and understand that nothing you temporarily do to it will make it worse. If you feel this fear, seek out a mentor.

I take a little bit of issue with that. Saying that nothing you do temporarily to it can make it worse is not necessarily true. If you have some sort of transactional system and you jack something up that is a credit card type processing type thing and you you first

off you're not debugging in production though it doesn't say it doesn't make that distinction but but i'm just saying like saying that temporarily changing code doesn't jack something up this this isn't talking about environments if you are trying to live change something like you know ruby or a scripted language in a production environment. What you do could have really bad implications. Well, okay. But we're talking about debug here. And it sounds like you're talking about like, oh, you're telling me you've never cowboy

debugged in production? Really? I've definitely done it. Definitely. I've never. Well, I guess, you you know you know how um not not detailed that's not the word i'm looking for but like like oh how calculated how calculated let's use that word you know because like if i'm making a change then i'm i'm trying to be like absolutely certain like

this isn't going to impact something else but yeah you're right i mean but that's still like a really bad habit and that's not what this is trying to this isn't trying to teach you like cowboy it as you put it that totally sounds america but uh yeah i mean the but the point being is that, especially for a new developer, you have to get over this fear of, well, I can't modify this. No, you can't be afraid to break it. You need to get into that code. You need to tear it apart to understand it and try things and see what happens. And that's the essence of what the author was getting at here. I completely agree.

I just didn't want anybody to think that making changes to code isn't going to hurt anything. You need to be aware of what situation you're working in. But totally agree. The best programmers out there are the ones that are just like, I'm getting my hands dirty, right? I'm going to figure out what's going on, and you dig in. And you dig deep, typically.

Well, speaking of which i have two questions for you guys um number one uh our friend john uh has a habit of calling this the granny method you know i'm talking about have you ever had a problem you just can't figure out what the heck's going on and so you just start deleting the sections of the code until something works and then like slowly kind of putting it back together until you figure out what's going on. I believe you just jumped into section two of this version, which is how to debug by splitting up

the problem space. Right. That's kind of a common way of solving the problem. It's kind of weird to me that they split it into different sections. Maybe I'll take this license and add that to their list here.

I did have one more question for you guys. I didn't get the first question. Well, he was saying it. Well, I guess you didn't ask the question. Are you familiar with, or you guys use the granny method? Oh, have we? All the time. Yeah, all the time.

It's an excellent way to do it. I mean, you just split it up until you find what's breaking it, right? I don't know about if I would say all the time. I kind view it as like that's like a when you flash resort when you when you can't find the problem easily right that's like because he's literally talking about like deleting or commenting out you know big sections it typically is a last resort you've been chasing something for an hour and nothing seems to work. And then basically your last resort is, okay, let me just go cut this code.

Unless it's CSS. And then if it's CSS, you've been chasing this problem for 18 hours. Yeah. And you're still not sure how to make it work across all the browsers. And I think this goes hand in hand with print lining. Like if I'm print lining, it's probably a similar situation where I don't know what the heck's going on and i'm just trying to get more insight and yeah so

granny method and print lining go hand in hand for me yeah that's true i would agree with that but sometimes you'll do the print lining before you even get to the granny method right because now you're just trying to track it down granny method is i give up i'm deleting everything a little bit at a time until i find the one piece that's breaking, you know? So yeah. So question two. Yeah.

I want to hear this one. Have you guys ever had a situation where say your boss says, Hey, I found a problem in, and before they even finished the sentence, you know what the problem is and how to fix it. Uh, no,

because I've never had a problem with my code. No, I don't know.'t have such resources um there's something weird on the say the cart page and i'm like oh no out of the way and i you know i kind of wonder it's like how is that i know as soon as someone says there is a problem how did i know that there was a problem and why didn't i prevent that problem it's like it's almost like a little hidden nugget in your brain well i've had i've had situations where it was like i'm trying to think like it wasn't necessarily a bug per se but it was like like i knew that maybe the layout like this button was to the right of this one and it felt

like you know hey that's fine right like that's the way it was supposed to be and then someone comes along and is like hey did you know those buttons over here and i'm like okay yeah i can move it or whatever like like there have been obviously that's a contrived example and it's a really silly one but you know there have been times like that where something like you know i kind of knew but i kind of thought that that was also supposed to you know the way it's supposed to be actually i i can think of a solid example that solid and well maybe not solid but a real example that I had in, well, maybe not solid, but a real example that I had in the past where I remember saying in my code, like, I have no idea how in the world you would ever get to this point. I've tried this 5 million different ways, but I'm putting this little catch down here at the bottom so that if it ever does happen then you know somebody can maybe go back and figure out what happened and i actually had a guy email me a screenshot of my code one time was like

how did i even get down here right and it's one of those things you're like i totally don't know i tried to figure it out but but yeah i mean in alan's defense i'm gonna go ahead and like let the audience know like that was code he inherited because because you know for it as as i'm listening to the story i'm like wait a minute so he wrote some code and he had no idea how he could possibly get to it no this was completely inherited code but it's one of those things too like where you say you know somebody comes up to you like oh I totally know what you're talking about and I have no idea how it got there. So, so how to debug by splitting the problem space. Right. So, so, you know, one of the things that I liked about this section too, was that it, it,

the way that one of the methods that was described here, it kind of reminded me of like a binary search algorithm yes right like you just keep dividing the code until you get to the part where the problem is right like once you've verified a half of it that nope it's not in that half then you go to the next that's totally it you just keep chopping it down and it's it's pretty effective i mean like i said a lot of times that's like a you know last ditch effort but it's it's very effective you just got to remember to undelete all that code that you deleted here that's really important that is really important definitely seen situations where something's not working so you just kind of comment out the section of the

code it's not working because it's not it doesn't really apply to what you're doing, and then it gets checked in. And then it's like, what the heck is happening? I've definitely been on the receiving end of that where someone left the commented out code checked in, and you're like, wait. Yeah. Yeah, that's always frustrating to be like, oh, I don't understand why you commented that out.

Is that legit? And if it's commented out oh, I don't understand why you commented that out. Is that legit? And if it's commented out legitimately because you don't want it there, why didn't you just delete it? Yeah, and, you know, that happens. Like we all do things sometimes where we kind of put little shortcuts in the code to help us, you know, get to where we need to get to. But I think, you know, looking at the stuff after you checked it in, like, you know, reviewing your own code or having someone else do a code review or a pull request helps. But if you've got a large feature with say a hundred of modified files, then it can really,

uh, you know, hide out there and it can be hard to know that that's a problem. So that, that is a real danger when you're modifying code in order to work on something. Yeah. That,

that's one reason why like that granny method, um, as it was put, you know, that's one reason why I kind of reserved that for a last-ditch effort. That's the Hail Mary. I couldn't find it otherwise, so I'm going to try this. Because there's another section in here, and I don't remember what, but it was talking about, actually, it was the next section about how to remove the error and it was talking about like making the smallest amount of change necessary to fix the bug right and i feel like in that approach that that um that granny approach that you're you're

referring to that you're not adhering to that because you're introducing a whole bunch of change by deleting or commenting out things or changing whatever the normal flow of the application is right like you're changing all that so that's that's why i don't like that method but in regards to this you know binary search type approach that the author gives here i mean that's certainly one way that you could try to approach the problem. Well, one thing that I want to point out that Joe said that I think is huge, and this kind of jumps into a further later, we'll, we'll talk about it in a little while, but source control with pull

requests. That is, if you find yourself doing things like this, this is where pull requests become extremely important because not only if you can get another set of eyes on it, but sometimes it's useful just to have that visual interface to show you what you've changed, right? Like you push that thing up there and you say, wait a second, I don't remember changing that many files, you know? So it can be a nice visual tool just for yourself so that you can say, so you can kind of double check yourself, like do a sanity check. So I'm going to give you a tease here, okay?

Because I am rather, let's say, meticulous when it comes to putting together my commits and pull requests. And I review my own stuff like crazy, like mad, before I put that commit or pull request in. So I've got a tip for you uh that's going to help out with that let's do that well wait oh okay that's why it's a tease oh okay i know i know what it is all right so um yeah i don't know what else to say about splitting it so and and you know as far as like you know the next section about removing the error like i said you know the author here was talking about like introducing the smallest amount of change necessary to fix the bug and he also makes another great point too that like sometimes

there might be several bugs that are disguised as one and sometimes as as the, you have to make the call like, well, do I fix all of these or do I just fix this one and then maybe ticket the other ones? Because, you know, maybe their scope is so grand that it's like, well, you know, I'm not going to do it as one person in a given amount of time, right? Like, you know, you might have reasons that, uh, to ticket it so that it can you know as a as a call to action to the rest of your team right that like hey this needs attention right and you don't want to introduce new regressions like he even goes into or i assume it was a he who was the author oh yeah we didn't say the author's name but uh it was a he oh you did it was robert um robert reed yes robert l reed red so the thing that he also says is even if you see other code in there this is not cleanup time right you shouldn't

if you're if your goal is to go in and fix a bug you shouldn't be going in there and trying to clean up code or rewrite a bunch of code you're supposed to try and fix the bug and then that way you understand the change that you're making you fully understand it right like if you start trying to go through and make major sweeps i do take a little bit of an issue with that though but i will say this though and and because getting back to the like the the core essence of what he meant here like i ran into an issue even as recently as last week where like i saw some problems that weren't necessarily part of the ticket that I was working on. But I thought, well, I can fix that while I'm here.

Right. And then that ended up being a rabbit hole all by itself, like just a gigantic, deep rabbit hole of like, oh, my God, I can't believe I had to change that much stuff. Right. gigantic deep rabbit hole of like oh my god i can't believe i had to change that much stuff right and then and then you know when problems came about i was like okay look i mean the what the real thing that i was trying to fix here was like maybe three lines and now i've got like you know 81 files that have changed because i wanted to fix this other thing. No way, man. I'm like, and it's not working. So I'm undoing that and I'm just sticking to the, you know, the one fix. So, so sometimes you have to be aware of that, but to say, to say no cleanup at all, uh, sorry about that to say no cleanup at all, though, I don't necessarily agree with that because I also like, and I think we've talked

about this, the boy scout principle of making it better than you found it right like leave it cleaner than you found it so like if you see some little things in there like especially like you mentioned uh javascript a minute ago so like if you see like oh this line doesn't have a semicolon and it should it's javascript so it'll still work but you know hey make the world a little bit cleaner and and put it in there right like there's little things that you could do if you fully understand the code that you're working in like if it's somewhere that you've been before and you're pretty familiar with it i totally agree with that if it's something where you're working in a new area of code that maybe you're not as familiar with and so you don't know the ins and outs and the pitfalls then that can be dangerous like you said you went

down a rabbit hole right and i'm not saying that you should avoid that either because that is how you learn things but if your goal was to fix this one problem and it's and it's a major issue then that should be your first task and anything else is secondary to that. So I agree with it. I also agree with the Boy Scout rule. I try and leave things nicer than what, you know, I came in, but you, you do have to know your limit sort of, you know, what, what are you trying to accomplish? Right. Not major refactoring, but like as a developer, we owe it to ourself and to, you know, where

the, the company, the client, whoever they're receiving into that code is. You owe it to them. If you're going to be in the file and you see some things that aren't huge major refactoring efforts that you could do to clean that up, then clean it up because you're only helping yourself out the next time you come along. Right. I agree with that what about debugging using a log i thought this was pretty straightforward yeah i didn't really think that there was anything more uh to add to that that you know as far as like you know um what we hadn't already said yeah i mean we even covered this pretty well in the 12-Factor App episode where we were talking about logging.

Yeah, we love logs. We should make a shirt that just says, We Heart or I Heart Logs. I think the one thing to point out here is with anybody that's dealt with logs, there's different log levels, right? Your info, your warns, your trace, that kind of stuff. So really what you want to do is you want to make sure that if you do have login statements in your application, make sure that you have them in the right places so that all you have to do is change a config and now you can get that extra information. So that's really the one key thing here,

other than, you know, it's a stream of information. It tells you your flow. Yeah, and I think Jason mentioned that, one of his favorite things about Log4Net on the MS Dev Show that you were on. So yeah, we like that, and we talked about logging a lot in the 12 Factor app, so we will have a link to that.

Yeah, I'm trying to remember too if it was even, maybe if it was in that episode that you just mentioned, Joe, or if it was in this section where they were talking about changing it on the fly. I think that was in the episode, though, that Alan was on. Yeah, I don't remember. Where they talked about changing the log level

as the app was running. I thought that was an interesting approach, too. Yeah, that would be really cool. So, next, how to understand performance problems. Yeah, this was a big good section. One thing I thought was interesting is they said that it was easier than debugging. Do you guys think that performance problems are easier to deal with than debugging? I definitely did a double take when I read that.

I mean, after reading the rest of it, I understood where he was going with it. But initially, I was like, whoa, wait, what? That's a bold statement. I sort of disagree because it depends on what your environment looks like, right? What is your stack? If you have 20 different pieces that come together to make your application work, then trying to find the performance bottlenecks might be a little bit more challenging. And if it's a black box, you know, you're using some third party cloud service, you have no idea what's going on, it can be a real challenge to find that stuff out. So, well, I guess, too, this is like another reason why I don't know, I really don't know that I stand by that statement, because he makes a statement of saying, or the point of saying that, like, you know, before you try to make something faster, you need to have a good mental model of why it's slow.

But that, to me, signals that you already have a strong understanding of the overall picture of the application, right? Like its architecture and what components it's talking to, or what external backing services it's talking to, things like that. And if you just start debugging an app for the first time, like you're not going to have all that, but you might be able to say like, oh, well, this is the page that is where I'm at, where this button, where this form is at. So I can easily find that. So now I've, you know, dramatically reduced the scope of the problem down to this one page, right? And then I can go from there and I know that it's on this form. So now I've,

within that page, I've narrowed the scope even further. And I know that it's on this submit button. So now I've, I've narrowed it even further. So the debugging part actually felt a little bit easier to me depending on what type of problem you're trying to solve, right? It also depends on the type of profiling tools that you have, right? If you're trying to do a SQL Server type thing, it's fairly easy nowadays to run a profiler and find out what is terrible. If you're working with some sort of third cloud service,

you may not have those kind of tools available to you. That's a good point. It depends on what you're working with, and that's why this is such a tough one. And back then, maybe it wasn't as hard because he does go on to speak a lot about most of your performance bottleneck is I.O. Right. And in your case of the cloud, that would be I.O. bound, right? Yeah. And network bound case of the cloud, that would be IO bound, right? Yeah. And network bound, whatever. There's so many different pieces that come into play with this.

Well, some form of IO. Right. Yeah, and he has in there the line about 90% of your time is going to be spent in 10% of the code. Yep, totally. Right. And one thing I liked here too, is that he mentioned that it's usually not worth trying to get like a two or three times improvement. Usually you're looking for some sort of, you know, order of magnitude. So 10 times improvement, 100 times improvement, you know, it doesn't really matter if something takes three seconds or six seconds, six seconds,

sometimes, but you know, if you can get it from three seconds down to 30 nanoseconds, that's pretty impressive. You know, this kind of brings up one thing, though, that one of the reasons why I like MeteorJS, it was an article I read where a guy was like, you want to, a lot of us as seasoned programmers know how things work pretty intimately right like we know all the things top to bottom and so we'll focus on the most minute of details starting off like oh i'm gonna make this thing to work and scale to five million servers you only got 10 users right

like it's in so that's one thing i want to bring up with this performance is something you attack as it becomes a problem build your application get your mvp out there and then go back and i know that's kind of outside the scope of this well it's actually not because if we go into the next section which was how to fix performance problems it it's what you're saying is right on par with a point with that section because there was actually you know um one of the things he says is you know you know don't don't waste a lot of time trying to optimize something if it's only used 1% of the time. Right. Which is kind of in the same vein of what you're getting at.

You know, if you're only going to have a few users using the thing, don't try to, you know, over-architect it so that it can handle, you know, a babillion users concurrently. Right? And I said babillion, so that's a, that's kind of a real name. One of the, one of the quotes in here that I liked was as a rule of thumb, you should think carefully before doing anything, unless you think it is going to make the system or a significant part of it,

at least twice as fast. So going back to Joe's order of magnitude larger, you're talking about a 100% improvement, right? So that's what they're saying. Unless it becomes a problem, don't be spending time on it, right? Yeah. Yeah, absolutely. And a lot of times it's tempting to do what I call micro-optimization. So like swapping out arrays for lists or things like that.

And a lot of times those are nowhere near the bottlenecks. It's that query you've got running in a loop a thousand times that's killing you. Unnecessary inner loops is one that he specifically calls out. Just optimizing loops in general is a big section of the...

I did like the example that he gave here about counting cows by their legs instead of by their head. But then I was like, oh, what if there's a three-legged cow? Then you're going to overcount the legs. And he also said, before you talk about redesigning any part of a system, will it make it five to ten times faster? Because as we all know, redesigning any portion of anything can take a significant amount of time. So you really do have to weigh the benefits with the opportunity cost of what you may be leaving on the table. Just do some redesign.

And these are just the beginner steps of how to be a programmer. Yeah, this is the basics. It is really important. And it's also really important to use a profiling tool. And even if that tool is just looking at logs, you really shouldn't be guessing at what you think are the slowest parts of your application because oftentimes that will be wrong. Yeah, but you mentioned logs and guessing there.

Wasn't that specifically one of the things the 12 Factor app called out as if you were using logs to – how did they put it? Forget it. I can't remember it. I'd rather use logs than just going around and swapping out micro-optimizations, moving variables up top, or reusing variables. Man, I can't find it in here. But there was somewhere, and it might have been this section or another one,

where you said don't make like weird looking changes if you're going to make something like just minorly faster if it's at the expense of readability and maintainability it may not be worth it i think it was in this section but i can't find it oh i think i know um yeah i i recall that vaguely we'll get to to it. But, you know, we mentioned dealing with like inner loops and unnecessary loops and whatnot. You know, and Joe, you brought up that there was a whole section on, you know, how to optimize loops, which is, you know, the next section. And there were some interesting ones in here. Like, you know, he says, try not to divide. Yeah, I saw that.

I was like, that's an awesome little like you know it's a micro optimization right i mean but i guess if you're dealing if you're trying to you know squeeze out that extra bit there you go yeah i will wager though if you're working on a modern web application that uh dividing in a loop is not your problem right well. But it was one of the ones he lists here. You know, again, to Alan's point from earlier, this is like a 13, 14-year-old document. But still, I mean, even Division wasn't that big a deal back then. Try not to do expensive typecasts.

That's actually a big one because that can take up heap space and that kind of thing. Yeah, well, typecasts, yeah, I mean, that's a big one, definitely. Now, so this kind of goes off on a small tangent i was listening to a javascript jabber today and they were talking about the internet of things it was i thought you're gonna bring up meteor again because we know how you feel about me no um so here was here was something that was kind of cool is we think about things that we program in terms of you know how many gigs ram do you use you know we've got pretty fast processors and all that.

I've never thought about that. We, well, I mean, you don't think about it. I guess that's what I'm saying is you kind of take it for granted. Like what we write, we just know it's going to work for the most part, right? They were talking about, in this, the one guy designs chips that they're running JavaScript enginescript engines on now and they might be small subsets but he's like you know some of these chips run at eight megahertz some of them run at 200 megahertz and so when you start thinking about things like this this might still be valid

depending on what your type of platform or architecture is yeah fair enough so and yeah remember this book was written in 2002 so that's right when google was getting started they got started in 98 so this is around the time that you heard about google and this is one year after xp was released wow so times were a little different let's put that into perspective so what you're telling me is hotbot was on its way out that's right auto vista yeah and there was um you know another one of the optimizations though for uh loops that was mentioned here was you know moving a pointer rather than recomputing indices and this made me recall back uh shoot i i think the i think it was mike that made the suggestion um alan had the the tip of

the week about using the for each loop right and and how to deal with you know modifying that for each loop uh while you're iterating through it and then i want to say it was like uh it was a twitter it was a message that came in mike that, that said, oh, yeah, because it was Mike. Because he sent the tweet about, I've been mentioned on CodeBox. And he had mentioned, well, if you use a for loop instead of a for each loop, then you don't have the problem of that exception when iterating through it. Yeah, because you're no longer referencing something that you're changing. I'm going to look up that Twitter handle real quick, just so that way he gets mentioned twice,

because I know it was on his resume. I definitely thought it was interesting to spend so much time on loops, but the next one was more relevant to me. Dealing with I.O. problems. And they mentioned three main solutions for dealing with that which i thought were all good um basically caching lets you avoid it representation that's basically storing your data in a smaller format another in order to make it more efficient and the third one was uh they called it improve locality or pushing the computation

closer to the data i think of that as something like doing your where clause and your source and your order bys in your database rather than in code. Stuff like that. Just moving the work kind of further away from where you're fetching it to. Yep. You just covered that entire section.

Yeah, sorry. That was a good section and I just totally just ruined it. I don't know what to say about that. No, I mean, that sums it up. That was it. The next section was managing memory. Oh, go ahead. I don't know that he said this, though. But there was a quote about often it's just the question of improving the I.O.

It's better to question improving the IO than some loop, right? So rather than going through optimizing a loop, sometimes it's better to go and look at your IO and that's going to have orders of magnitudes of a performance benefit on your application. Yep. All right, so how to manage memory yeah and so um you know depending

on your language this can all kind of um vary a lot but one topic that kind of comes up a lot of times with um with oo with garbage collected languages is basically stack memory versus heap and um you know i don't know if we've done a real big deep dive on this topic, but we should. No, we did. Totally. Back when we talked about boxing and unboxing. Oh, that's right. And.NET because we actually got into the garbage collection, stack pointers, heat pointers, all that.

When they get cleaned up, you know, your two stages of garbage collection. We really did go deep on that one. That might have been episode two or three. Like it was pretty good. Yeah, it was episode two. That deep on that one. That might have been episode two or three. It was pretty good. Yeah, it was episode two. That was a good one. I don't think it got a lot of love because boxing doesn't sound very sexy. Well, that and I think we had in.net in the title.

It's like, well, who cares about boxing and unboxing in.net? If I don't already know what that is, then I'm probably not going to care about it if I'm not a.net developer. So it definitely wasn't a fan favorite but it's still some good content yeah and we actually got better about this over time because what we found out as we started doing the podcast more and more is a lot of these topics transcend various different languages right so even even that episode if if you don't know a lot about memory management and you don't know much about garbage collection and what boxing or any of that is this applies to basically any kind of language that runs in some sort of vm so java.net any of those kind of things so while the specifics might

be slightly different that is an excellent episode to go back and find out about how your memory is managed for you. And functional languages typically do a pretty good job of keeping this stuff, keeping the memory usage down. So you don't have to really think about that as much. But I think that most people are still probably working in OO languages, although you hear about functional more and more every year. Yeah, definitely. And a lot of people are bringing those functional type patterns over into OO.

So yeah, picking up things. There was a quote in this particular section. That's where faux came from, right? I don't know, faux. Functional objectory.

I've never heard of it. You should have a link for that. I was making that joke about the, I made that joke about faux programming before.

Never mind. It's gone. Yeah. So check this out. People have probably heard the term memory leak before, and there was actually a pretty decent little line in here for, for this. A classic mistake is to use a hash table as a cache and forget to remove the

references in the hash table. Since the reference remains, the reference is non-collectible but useless basically nothing's using it anymore but it can't get rid of and it's called a memory leak so basically this thing hangs around forever because it can't be garbage collected now i would venture to say that a lot of our more recent garbage collection has gotten smart enough to take care of these type of things well maybe not so there was another great a great quote in here this is probably my favorite one of the of the document or the essay because um for all objective c developers this one is going to ring

true for you you're going to love this, especially if you've been doing Objective C for a while, right? And, you know, it's talking about, he's talking about garbage collection and how, you know, dealing with, you know, allocating memory and freeing it up when you're done with it and, and trying to automate that through some kind of garbage collection processes is so different. It's so difficult, a problem that the programmers often don't implement a rudimentary route.

Yeah. Often simply implement. This is easy for me to say, I'm trying to read this quote. It's so difficult that programmers often simply implement a rudimentary, rudimentary, say this word, G form of garbage collection.

Just trust that Alan said it is such as reference counting to do this for them. So, but, but that's how Objective-C works, though. It uses a reference count to know when it can be collected, garbage collected. Interesting. I'll never be able to say that rude word about it, but I don't know why I can't say that tonight. You can read it, which you can't say it.

Yeah. There's no way. That's like a tongue twister word. I think that word is like Latin and it means cannot be spoken. What did you say? Speaking of rude? Speaking of rude, yeah, I was going to talk about the next section, which is intermittent bugs. Yeah, these aren't fun. And that's when something works right nine out of ten times. But that tenth time, which is probably going to be in the big demo to your board of directors, it's a big deal.

And so it's going to crash and do bad things. And those are so horrible to track down and include things like race conditions or maybe specific setups or specific data. And that can be such a nightmare. And those are the kind of things that can, you know, keep you up to two in the morning and have no measurable progress made. Right. Or maybe it's like a load problem. And until you get to a certain size of load, you're not going to be able to like see the problem.

So in the meantime, you're like, nope, works on my machine. Yeah. I mean, he had the perfect example in something that he actually got hit with was they were using some third-party library that did some string manipulation or something. But basically what it boiled down to is it almost never had a problem. But when it did, what it turned out to be was there was a super long string and this thing was quadratic. So, you know, it ate up way more memory than everything else so when you hit this boundary it would just crash and it took them a long time to figure it

out and really the only way to go about this thing is to put good logs in place and definitely uh it it's horrible when you don't have logs or something like this so there's something that's happening you can't reproduce it and there's no signs of it at all. It just makes me want to put my head down and cry. The one thing, though, that wasn't mentioned in this section that I was actually a little shocked about, because it definitely was one that I always, this is always my go-to.

The first thought that goes through my head whenever I deal with a problem like this is like, okay, what's new? What has recently changed? Right. And is that in any way related? And that wasn't one of the options that he discussed. That's a really good point.

I mean, that's kind of how we figured out that we fell out of iTunes for a little while, right? I mean, we literally had to just bang our heads against the wall and say all right hold on a second what changed yeah yeah I mean in his example that uh you know that he gave well with that third-party library that they affectionately referred to as the French stripper I loved that that that name for it it it was software made in france that stripped html tags from text yep um but uh you know i mean that that might not have applied in his situation but certainly in a lot of situations i've seen that has been a you know a good starting point at least is to say you know to ask yourself like what's new here.

Absolutely. The next section I thought was pretty good. And that is how to learn design skills. And this is written before bootstrap, by the way, is this CSS? No, this is not CSS.

This might be before CSS actually. Yeah. Come on, man. 2002 wasn't that long ago. I mean, this one's kind of cool this is how to design software and they say design skills and you know nowadays we think of design a little bit differently you hear design you're like okay who made the website look that way no this is talking about basically why is the logo on fire how do you put together a solid piece of software how do you

put together a nice product at the end and one of the things that they talk about is go sit with a mentor, somebody who's been there and done it. Watch them, follow them, tag along, see what they do, and then pick it up. You know, start doing it yourself. Take a small project and work through it. Yeah. And I also wanted to mention the book, Don't Make Me Think. It's really's really nice it's really short it's got some really good examples and we'll have a link to that in the resources we like there were a couple quotes in this section that I liked though

one is that design is a matter of judgment that takes years to acquire yeah you really need to respect your UI and UX people it's hard and I know I for sure can't do it. Well, I didn't even take it that way. Because I was joking about CSS,

but in this section when you were talking about design skills, I took this more to mean software design architecture, not just visually designed. So I kind of took that statement as like, architecture. Yes. Like, okay. Not just visually designed. So, you know, I kind of took that statement as like, um, you know,

take, take, uh, how to say this? Like you, your peers that have been either working in this framework for, they have more experience in this framework or maybe they've just been, you know, uh, working period longer than you have, you know, there's things that you could learn from them and, and, you know, they might have judgments around design for specific reasons

because based on that experience. So, you know, you could learn something from them. So I thought that that was an interesting one and then another one that he says is you know don't become dogmatic about particular design styles yes i agree with that and i thought yeah that that's a good one too like don't get stuck in your ways design is an art not a science and that's true i mean there's if you think about it like when you go to build your application, you've heard of, what's it called, domain-driven design to where you think about your business and department. So you have your customer service and you have your accounting and you have this kind of thing, right?

Do you build your software that way? Do you build everything in layers? Do you have a database tier? Then do you have some sort of REST tier on top of that? Like there's, there's tons of things and that's why they say don't become dogmatic about it. There's so many different ways to do it and they all have their pros and cons. So it's, it's worth watching what other people do and experiment yourself. Right.

You know, it's interesting too, is a lot of times teams will have like a style. And so if you say work on a small team for uh you know a number of years and it's in the same framework then you can kind of develop um you know patterns that aren't necessarily the best and i think it's kind of funny if you like switch jobs or you know maybe switch teams or switch projects a lot of times you'll get some kind of some fresh ideas you'll see people solving similar problems in different ways and sometimes it's better and sometimes it's not and you can kind of update that but it is interesting uh always just to see how other people solve

problems and you don't want it to to deny yourself that experience if you uh don't say, you know, work with a large team or, or don't get out there much. Yeah. So the last section in this, uh, um, the personal skills part was how to conduct experiments. Yeah, I thought it was pretty good. I mean, I, the, uh, the big takeaway for me there was just having a hypothesis and I think it's good good. It's one thing to just kind of refresh and click around and see if anything interesting happens. And it's another to say, all right, I did this and this should happen. And then if it doesn't, then you've got somewhere to go and somewhere to think about and try to figure out what you think of that's incorrect. What of your base case scenarios, which thing you were assuming to be a fact is not?

Yeah, I mean, one of the kinds of experiments that he gets in is talking about testing with small examples. It reminded me of unit testing. It's very similar to that. I mean, basically his description there, how did he word it?

Testing systems with small examples to verify that they conform to the documentation or to understand their response when there is no documentation. I'm like, well, that's pretty much like a unit test, right? Like you're confirming that it does what it's supposed to do. Yeah. Yeah. And there are little things like that. Like a lot of these were like that testing small code changes to see if they actually fix a bug.

Right. Right. Like we've talked about, you know, writing unit tests just to see, to, to, to see the bug so that the test fails and then keep coding,

you know, until that test passes. Right. Yep. So I thought that was interesting. All right. So it's now that time of the episode where I'm going to beg, please, if you haven't already and you're enjoying the show, you know, it's awesome that you guys come up and leave our, our comments on, on our episodes and please do come join us at Slack. But if, if you want to really have a heart, go up to codingblocks.net slash

review and click on either iTunes or Stitcher and just leave us, I mean, even a one-liner or something, you know, I mean, some of what we do is just one lines but if you do that that would greatly help us out it helps us get in front of more people and you know we we really enjoy doing this and that is just a small way of repaying us for the time that we take to do this so if you would please do that we would greatly appreciate it and as mentioned before we'll give you a shout out here uh in in the. And there have been listeners that have specifically installed the applications necessary to leave that review. And I can't tell you how much I appreciate that. Yeah.

I mean, seriously. The fact that you took not only the time to leave the review, but you went out of your way to install an application or two, as it might have been for some. That's awesome. And I can't thank you enough for that and if you're like me and you truly hate itunes like that's special like that's that you actually deserve a badge for that wow because i i really hate itunes but unfortunately it's the only way to actually leave a review is to go in there and do it unless you have an iphone so yeah if you would please do head over to codingblocks.net slash review and drop us one liner up there. Or if you want to make it longer, we read them and we'd love them. So please do that. This episode is sponsored by Infragistics. The Internet of Things, mobility and connected

systems are driving the need for big data solutions that are imperative to help your users and customers make better decisions faster than ever before. Experts in data visualization, Infragistics developer tools drive custom app development for any data visualization scenario on any platform. And ReportPlus is an enterprise-ready, self-service BI dashboard solution that opens up your enterprise big data for end-user consumption. Now head over to www.inferntistics.com and get your free trial today. All right. So before we get back into the next section, which, what is that next section? Team skills? I wanted to go over which series is more often. So in the last episode,

the survey that was asked was which series is more awesome. Is it star Wars or is it star Trek? And if you recall the last episode that was during the star Wars season, right? So, you know, movie was coming out, you know,

it was fresh on everyone's mind. And it was Star Wars season. Everybody was celebrating Star Wars, right? Which one? Now, you haven't cheated, have you, this time? So I haven't gone and looked at the results. Okay, okay. But I saw some emails trickling in. Da, da, da, da, da, da, da, da.

So hold on. I feel like programmers are going to be Star Trek. Sorry. Okay, so Joe are going to be Star Trek. Sorry. Okay, so Joe's taking the Star Trek side. Alan's taking the Star Trek side. That's not my choice, but that's what I feel most people chose. Wait, what? Jar Jar Binks.

That's not your choice? That's not my choice for what I would have picked. Oh, I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry.

I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry.

I'm sorry. Okay, well, let me ask you this then. Since you both picked the same one, you want to narrow it down. Put a number to it. not my choice for what i would have oh i think what the majority was star trek okay well let me ask you this then since you both picked the same one you want to narrow it down put a number to it and since it was since it was two choices which percentage do you think what do you think that where do you think it landed 65 35 65 star trek 35 star wars okay yeah 35 35 for star wars Star Trek, 35 Star Wars. Okay. What about you? 35 for Star Wars only because of Ad Ats and Star Destroyers. Wait, what was that number? 35 for Star Wars.

So you're both going 65, 35. Apparently. You guys aren't really being fun about playing this because there's supposed to be a winner. I'll go ahead and tell you, neither one of you are it. It was Star Wars. Really? And here's the most interesting part. Really?

Somebody put that Wookiee back in the cage. You both went with 65-35. It was 69-31. Wow. Did I say that right? 61-39. 61-39. Okay, so I wasn't far off on the percentage.

I just had them flipped. Yeah, you had them in the wrong order. Wow, I really thought Star Trek was going to win that one. Now, here's the question. Do you think that most people voted Star Wars only because of all the recent hype because the movie was out? Yeah. Like, if the next Star Trek movie was coming out in two days, that the hype would be around Star Trek. Well, when the next Star Trek movie comes out out in two days that the hype would be around Star Trek. Well, when the next Star Trek movie comes out, we're rerunning the survey.

There you go. Right? You know what? The thing is Star Trek doesn't get hyped as much because it's for more rational and logical people. So it doesn't have that huge kind of wave. Like there's some jabs in that statementabs are you trying to say i'm irrational i'm just saying there might be you know a difference in average iq between the two wow wow please don't stop listening listen jar jar abrams did a good job of directing that last movie. Nice.

All right. All right, so let's get into team skills. So why is estimation important? It's not. I hate it. I'd just let the architect do it. Oh, God. Really?

All right. So, I mean, God. Really? All right. So, I mean, I get why it's important. It's important for people that make plans. It's important for project managers and bosses and people who have to report to boards of directors and the public. Why it's important to programmers is because, you know, we don't want to look stupid. And we also don't want to look like we're slacking or like we're stupid for not being able to get things done well i can go even better than that though like you want to make your boss happy your boss wants to make his boss happy your boss's boss wants to make his boss etc until you ultimately make the company happy the the customer happy

so part of your making your boss happy is being able to provide an estimate and it being something realistic like if you tell him you're going to have something done you know a new feature done by a certain time then you know you want you want to live up to that well if i recall our buddy john might have estimated six months on one thing and had it done in a day well there's also been the opposite you know something was like you know five days and three months six months but you know those those things happen right like um and and and that's why there was a great quote in here about the fact that it is impossible both theoretically and practically to predict accurately how long it will take to develop software is often lost on managers. And it really is.

I mean, he even goes on with another quote that I loved. I estimate that if I really understand the problem, it is about 50% likely that we will be done in five weeks if no one bothers us during that time. What this really means is I promise to have it all done five weeks from now. That's what it gets translated to in your manager's mind. Well, really, but put some context around that quote because I liked that quote too. He was saying that when we, let's say okay let's let's say that i'm your manager and i come up to you and i'm asking you to give me a quote on something the tendency is to think wishfully and that's where that first quote about you know i estimate that if i understand

the problem it's like 50 likely blah blah blah right like you're you're thinking wishfully that that's what's going to happen and you're even putting there like if no one bothers me during that time there's so many assumptions in there like if i really understand the problem right that it's 50 likely that it's going to be done right no no not halfway done it's no halfway confident that it will be done i'm either going to have it done in five weeks or I'm not. Right. It's binary. Right. And then there's the assumption that no one's going to bother me during this time. Like I'm going to shut the door, lock it and turn off all social platforms. No one's going to contact me. Like that's never going to happen. Yeah. I mean, I think the key takeaway

to this entire thing is why is it actually important? There's a couple, right? Your manager needs to be able to report to his boss that they have a plan for when something can be done. And that's key. But then the other two is so you build trust with the people that you're working with. Oh, somebody's skipping ahead. Well, that's part of it, right? Like, I mean, you don't want to sandbag too much

because then people will know and you don't want to you don't want to fall behind unfortunately as programmers we know that you run into brick walls that you just can't anticipate right like it just happens and that's why it's so difficult but it is important because you want people to know what your plan is and what and what you can you know realistically have done right yeah there is an incentive there to give a shorter answer you know you don't want to be the guy that says oh it's it's gonna take probably a couple days to add that button even though that you know my teammate added a similar button in an hour because things are different and uh you know sometimes you spend four hours trying

to figure out why your computer keeps restarting you know and it happens yeah yeah and and the problem as he puts it is that like if you're going to um you know say that wishful estimate right then that requires that you explicitly discuss that with your boss so that you can say, listen, I don't know if you caught all of those assumptions, but let's iterate through them one by one and make sure that we are on board with what this means. I'm only 50% confident that I'm going to make it in five weeks. And that's if I understand this thing. And if no one's going to bother me, nothing else is going to come up in the next five weeks for me, right? Right. Well, I have two more questions for you guys.

Yeah. The first is, have you ever had a boss change the goal line on you? Oh, never. Change the feature. What? Why would anybody ever do that? That never happens.

That only happens in movies. That's right. Yeah, it happens all the time. People who ask for something don't know exactly what they want or what they want changes kind of over time or as things get closer. And so you've estimated on something

that you're not doing anymore. Yeah. And now you're working on something completely different. Well, the term for that though is scope creep yeah i was gonna say affectionately known as scope creep uh so what was your second question what do you do uh if your boss asks you for an estimate on a large task okay so this leads into the very next section how to estimate programming time and the thing that i love the most was his honest response was if you're asked to do something big stall yeah i loved that statement here's the thing right and he says it's the most honest thing you can do it's true it's

absolutely true i'm actually going to give an example so So we had Vlad Hrybok on the show months ago. I don't remember what the episode was, but he was the one that did Aspectacular. Oh, yeah. That was, oh, I was going to say six. Was it nine? So we were all working on this huge project at the time that was, you know, we were trying to scope it out. And when I say huge, like this thing was going to span anywhere from six months to a year. Nobody had any idea and the problem was is everybody was trying to figure out how much time is this going

to take and here's the biggest problem as a program we all run into it you don't know you can make all the the speculations in the world even being a super experienced guy until you get in and start iterating towards it you don't even know the kind of stuff you're going to run into. And that's what he did. So while everybody else was trying to plan out, okay, well, we're going to need at least this much time for this or whatever. He was like, you know what, let me just start tearing it apart and see what happens. Right? And so that's why the stall thing is so important.

While he was able to start iterating towards it, he was able to come up with a better estimate. So stalling in the beginning, he couldn't give a good answer. But as he got in and started feeling what the pieces were like, then he could actually realistically say, hey, look, man, it took me this much time to do this one section. All right. I know that we have 20 other sections. If I were to extrapolate out, I can tell you that it's going to be at least this much time. Yeah, and the author here, he specifically points out that while stalling,

you could possibly consider doing or prototyping the task itself, which is exactly what you're describing here, except that actually happened. And there's a lot of benefit to that, to both the author's point and to Alan's point there with that story, is that, you know, you get like a real world experience of like whatever that implementation of that task is, right, that can then be used as a data point to help, you know, later. Now, I have had situations though where the initial uh prototype or whatever you know the part that was initially

um picked just at random happened to be um you know an easy one in disguise right and you know that's then thrown off the estimate. Cause then you, you, you, you prototype that one, not realizing at the time, not knowing that it just happened to be easier than others that you thought were just like it. And then you, you base your estimate off of that first one. And then as you get into it, you're like, Oh my God, wait a minute. These other scenarios are so much more difficult. I've had that happen. I will say along those lines, though, I've worked with some really good project managers in the past, and the whole thing is if you think that it's going to take longer,

let me know sooner rather than later. What you don't want to be doing is you've scoped this thing out to be six months. You base that off that simple task that you had at the front of it. And then all of a sudden here you are, you're five months in. And now you're like, man, there's no way we're going to get this done. Whereas if three months in, you had said, you know what? That first one we did was a softball. Like we knocked that one out.

But then these other ones that we've started on have really set us back. You know, you're only halfway in at that point. If you can somehow set expectations and talk to your manager, they can then go, go to bat for you. Right now, that's not saying that it's going to get moved, but at least if you set, if, if you do constant communication to where you let people know along the way where you're at, people are way more receptive to it other than what you've been hiding this from me and now you're going to tell me at the very end that you're not going to get it done you have to

communicate yes and that is this is not a technical problem and that's why it's under the team skill section this is communication you know you need to communicate early and often raise the flags and you need to constantly be setting expectations to the people you're working with so that they you know aren't aren't surprised yeah and I really liked, he went into things like, programming's part of what we do, but then there's documentation, there's other things. And he said, give visibility into what you're spending time on. If you're spending two times more time on documenting

than you actually thought, you need to let the people know that right don't don't like if it's going to take you twice as long to document than it is going to be to code then you need to let you need to let your boss know as part of your estimate here's what the estimate is and here's where the breakdown of that and this part is going to be the documentation so that it's clear to everybody absolutely and you know there was another thing that i found at the i think it was towards the end of this that I loved and we've all done it. When you estimate, you typically are estimating based off your knowledge and your skill set. Yeah.

And it's easy to do because you know, your knowledge, you know, your skill set. But if you have a team of people with different experience levels, you can't assume if you're an, if you're an expert programmer that everybody's going to work as fast as you and so if you have a few people on the team that maybe aren't as familiar with the product or whatever you can't say hey it's going to take two weeks assuming that everybody's working at your level right when you got people that obviously are going to be slower and that's hard to do right yeah i it's funny because i had that that same quote highlighted that you know the strong programmer estimates um based off of his or her skill and then a weak program a weaker programmer is assigned the task and held and

held to that estimate you know and then it's like oh but you know because he also goes into like padding the your estimates too and that you should explicitly pad them, right? Don't implicitly pad it, but explicitly pad the estimate. And that's part of what you're communicating is like, hey, I'm going to explicitly give myself a couple of days, one or two extra days just in case and here you know here's why right there was vacation time there was sick time there was well that was when you're on a grander scale yeah right sure but that's what they were saying they said write it out don't just say i was actually on a project

one time where they were going to let a consultant go because he wanted to take a vacation in the middle of this project and it's like wait a second you didn't think a vacation in the middle of this project. And it's like, wait a second. You didn't think that anybody in the middle of summertime was going to want a vacation, right? Yeah, but I mean, he even talks about it, you know, padding it explicitly and communicating that even for the smaller tasks. So, yeah, you're right. Definitely, if you're doing this for like a team, then you need to take that into consideration. But even if it's just something for you yourself that you're being asked to ask me like how long is this going to take you to do and you if you are uh you know if you want to pad that then you need to make that

padding known yes right and and that goes back to your point too about uh building trust right so that so that as a developer you know there there's this trust between you and your manager. He knows, hey, if Alan says that it's going to take three days to do this, then it's going to take three days to do this. And if he says, hey, it's going to take three days, but just in case if I run into some problems, there may be an extra day or so, then

that's establishing that trust. Like, hey, I can really rely on that estimate, that quote that he's given me. It's goodwill. And and as a developer that's hard to do because you run into i mean outlaws joked about css i know joe's run into this as well but sometimes you get that problem that seems like it's a five minute thing and they're five hours later you're sitting there going why is this a thing why why is this a problem right so? So it's very, very difficult. I don't want to,

I want people to understand estimation is tough. It is very hard. And sometimes it's even worse when you give an estimate and then you have to backpedal, but you need to have open communication. Yeah, I mean, the problem is that,

I'm sorry, Joe. Oh, good. The problem is that these quotes, these estimates that you give, they become deadlines. Yeah, I think that's the rise of Agile really reflects that thought. You know, waterfall

didn't work. Planning things out so rigidly just didn't work. And so, you know, we're basically the industry as a whole has been working towards getting things to work in smaller batches. And so we can kind of control those variables a little bit more. Because it's easier to say, I think this is going to be four hours than to say, I think this is going to take us four months. You know, it just, there's less risk involved when it's a smaller estimate.

Right. Although it does mean more estimating, I guess, you know, daily or weekly or sprintly. But that kind of brings up another thing real quick. This I don't even think was mentioned in here is that really brings out the need for people to think about iterating towards something as opposed to I have this huge project. Right. Yeah. I want you to scope this entire massive project out. Start building it up, right?

Start thinking in pieces and start building towards it because you can get way more done. And let's be honest, if you can get little pieces in front of people more frequently, they feel more comfortable about it. If you tell somebody you're going to have something done in a year and a half and it's going to take you this much time, people are going to lose confidence because they're not gonna see this thing

well I guess this is part of their popularity and you know the ultimate win for agile versus waterfall right absolutely so the next section is how to find out information I like this section I like some of his insights here it one of the pre stack, by the way. It really was. This was pre a lot of things that we use nowadays. According to you guys, man, this thing might have well been before the internet. Oh, man.

We were coding on stone tablets. These are back with T-Rexes. Oh, my God. This is before Fitbit, man. It was before Fitbit. Before iPhone. So one of the things that he said and i still think there's a lot of truth to this although there's way more resources available now but a lot of people their

first inclination is go search the web he's like if you were looking for solid information go to the library and get a book or go buy the book. So the best way I know how to describe this is try and figure out how to set up Apache on Linux. All right. Go search on Google. And after you get back 10 billion results, I don't even know if it's even that little. And they all are different. Then you're going to be frustrated because you're going to be chasing your tail. You're going to get bits and pieces of stuff everywhere and you're not

going to know what you did. If you go buy a book, then you're going to have one author explain from beginning to end how he set it up. And so at least you have a resource you can go back to if you need to figure it out again. Right? So I think there is a lot of, there's a lot of value to having a reference that you can go back to consistently. And that's one thing I like about the book. RTFM. Oh God, don't. you were talking about searching the internet, right? And he was talking about avoiding that for like opinionated, you know, or subjective type of information, right? Because you're not going to get, like you're going to get 10,000 answers, like your point about Apache, right?

But it did remind me of not a quote, I guess, but like Albert Einstein is quoted as saying something that he really didn't. It was just his actual words were, I don't know, changed. But there's this, I don't know what else to call it, but a quote. This statement that supposedly Albert Einstein said that says, never memorize what you can look up in books. Now, the actual statement that he said was that, I do not carry such information in my mind since it is readily available in books. The value of a college education is not the learning of many facts, but the training of the mind to think.

And so I thought about that statement while I was reading the section and I thought it was interesting. Well, can you imagine, you know, a scrum in the morning and your boss asks for your stats and you're like, well, I ran into a problem with Apache.

So I went to Barnes & Noble and I got a book. I'm in chapter two. So, you know, well, okay. For a week. But,

but books today are far different, right? Like you can go online for most of the stuff. Like you're not, you're not going into a brick and mortar store. Yo moron. Why'd you drive all the way down there? You could have just downloaded it on your kindle right right or or your nook since he mentioned barnes and noble right right equal opportunity because nook nook is

a big deal a lot of people used to be is it still i don't it still is so yeah i don't know this one was pretty interesting the other thing i liked about it at the very end was and we've all been there right where you have this thing and you're like man and you're waffling on it you've gathered more information than you could ever possibly consume and you're still waffling on it and and he basically closes with use your gut you know you make a decision at some point like there's there's a point to where you you have to quit thinking about it you know there's there's you know do it or get off the pot basically make the decision and move on and and you got to feel good about it yeah i have a friend that's done that like he's read everything there was about the surface pro 4 right knows all about knees

like so badly wants it but he hasn't dropped the hammer to buy it man whatever so oh did you know who i was like it wasn't the surface pro for it's a surface book well it changed when the surface book came out yeah so you know that guy i i've heard of him he told me it was a surface book and and he just wasn't, yeah, whatever. So this next section was kind of scary to me. How to utilize people as information sources. Yeah. We've talked about this before.

So the one thing that he starts off with saying, though, is that you have to be respectful. You know, respect your own time, but also you have to respect the other person's time too. That's key. Yeah, I worked with a guy once who would always say, I've never gotten any training in this. And as you know, for programming, there usually isn't some sort of training. There's no one-week program I can send you to to teach you how to do what i do but he was constantly coming to it with like really minor problems and it would always be no one's trained me how to do this no one showed me how to do this like i don't know it's setting variables and then you know using them like what is their what is their training

on like i'm sorry you just got to kind of struggle through it one thing I liked about this is, so what you just said, I would have gone crazy. One thing that this guy wrote in here that I really liked was the amount of time you spend talking to each person in your organization depends on their role more than their position. And that's important. Like people, a lot of times will think, well, the VP, I can't eat up his time. You know, that may not be it. It might just be your direct manager who's involved in a lot of things. And so their time is very important. So you can't just suck it up. And they say, you should talk to your boss more than your boss's boss, but you should talk to your boss's boss a little. Right. And that's very important. And a lot of people miss this. A lot of people don't want to get involved at that level, but if you

ever want visibility and you want to understand more than just the task you're working on, that can be key to a lot of things. But the, but the way I also took this too, though, about the, the role instead of the title was that, you know, you may have a coworker who technically has the exact same title that you have, but yet that person, for whatever reason, they're acting in a capacity that's greater than, you know, that's, that's really above what that title is. But for whatever reason, you know, they have the same job title that you have. Right. And so, you know, that, that, that's a person that you should take, you know, you could talk, you should talk to differently than someone else.

You should value that person's time because they're, I don't know how else to say it, but other than they're doing more for the team. And that's true. I mean, that happens anywhere you go. There are certain people that have those types of tasks. They also take it down a notch too. They say, hey, if you're working with interns, this is important. Interns, if you've ever worked with any, and I know I have,

I'm sure you guys both have, they can be a time drain. But here's the thing. Everybody has to start somewhere. And all you can try and do as a mentor, and it's your job as a mentor to instill a certain level of, look, dude, I want you to go spend your due diligence and try and figure out everything you can before you come back to me, right? I don't care if that's an hour from now or a day from now. I want you to go do it and I want you to give it a good effort. Now, when you come back to me, I expect to have something in front of me to look at, right? When you do it, I may tell you that

that's not a great solution, but it's an opportunity to learn. And if, if that intern took that initiative and came to you and spent the time on their own to go figure it out, now it's your job as the mentor to say, excellent. I like what you did. It's not perfect. Let me show you how I can improve this or how you can improve this. And then, so instead of it becoming a constant him coming to you or she coming to you and asking nonstop questions, make them do something and then show them how to improve it and then tell them why. And then that way you kind of reduce the amount of time that they're eating up of yours, but they're both of you are getting something out of it because this guy might turn into

a rock star. This girl might turn into a rock star, right? So you're investing in them, hoping that it will pay off in the future. Yeah. I mean, there was another, uh, another point that he made here, which was that when you're, you know, talking, talking to the, you know, your teammates and, and, you know, someone is using you as an information source, let's say, for example, or vice versa, each person is learning something about the other one, right?

Like as the person answering the, you know, the, the quest, the question for information, right? Like that person's learning like, oh, this is what that person knows and I can go to that person anytime I have this question. And as the person who's doing the answering, then you know that like, oh, well, this is the type of questions

that this guy's going to come at me with or male, female, whatever. This person is going to come to me with either really strong, good, well-thought-out questions or basic questions. But the value of those interactions can diminish the more often it's done. Right.

Right? Totally. And so that's part of like you have to respect that. Right? And so I thought that was a very important point. Yeah, I used to work with a guy named Jim and it was always just so much easier to go ask him your question than it was to even Google

because he had the context, he knew the kind of stuff you're working on. So everyone would just kind of line up by Jim's door. This is a small company too and so the company actually instituted they called it open gym hours where you were allowed to bug jim from like 10 to noon every day but then you had to leave him alone so he could get some work done too and it was uh you know it was it was awesome because jim was awesome but it was also you know pretty bad that i would you know end up going to him to solve my problems rather than spending a little bit more time and learning about, you know, whatever it was and kind of moving on. But just thought that's kind of interesting. Well, you know, here's what Jim could, uh,

could learn from is how to document wisely. Oh, hold on. Before we go there, wait, wait. Yeah. Before we go there, one other thing that I really liked in here was as a developer speak to people that aren't necessarily just your boss so one thing that i really liked is he mentioned that you know hey if you have access to the head of sales oh right right you're working on this product you kind of know what this product does but getting somebody else's perspective on how this thing is sold or what it's being used for, how it's being used can be super valuable to how you think about things as a developer. So don't always just think about your direct report or who you're reporting to

or whoever they report to. If you have access to other people that are willing to share information, keep some open ears, right? Listen to them and you will learn. Even if it's just one little thing, you'll learn stuff that may be invaluable to you as a developer and maybe even to your team. Yeah, I liked that comment. It was kind of like just watching how stakeholders in other parts of the company work and operate and then you know give you more insight so yeah it was a good one so moving on to how jim can learn to document wisely sorry jim

um yeah i i loved like the first statement he makes here life's too short to write crap nobody will read. Right. Roger that. I do like that. It gets stale so fast. You make changes to the code every day. It's torture to keep up with documentation. It can be. For sure. I do like documenting the reasons behind doing things especially if you're doing something that's a little bit strange

or unintuitive. You can kind of write little comments about what the purpose is whether it's a hack, something that's a little bit strange or unintuitive. You can kind of write a little comments about what the purpose is, whether it's a hack, whether there's a really good reason, whether you're meaning to change it in the future, whatever it is. I like that sort of stuff. There was one important point, though, that I thought that he made here, and that is that writing good – this is his quote. Writing good documentation is, first of all, good writing.

But following up with that and i think this might even be more important if not on the same level do unto others as you would have them do unto you basically if you would come by and read this documentation and be like really really right and you're sitting there yelling at the documentation don't be that guy you know write documentation as if it was going to be you visiting this thing and say okay that was helpful i understand this right don't if you at least think about what what you would want to get out of it and you put it in there even if you're not the best writer on the planet, that can be helpful. Right.

Yeah. As far as documentation too, it's really nice to not need documentation. Like, for example, you know, one thing that's better than having documentation about how to say set up your dev environment is having a script that does it for you or having, you know, good variable and method names and having your code properly factored. Right. That's a great point. having good variable and method names and having your code properly factored. Right. That's a great point. He does go on to mention the importance of self-explanatory code.

But there was another great quote in here that I want to read that he says, which is that the documentation, if not written perfectly, can lie. Yes. And that is a thousand times worse yes and when i read that i was like that is such a true statement because how many times have you ever read bad documentation and it might not even be for your own so it could be for third-party stuff and you'll read that documentation you're like oh okay so all i gotta do is x y and z right oh wait a minute i know i'm about to get alan right here because i can give you a prime example anyone that has ever in the history of the internet worked with paypal's api can back me up that

that is some horrible horrible documentation preach on right and and it's so contradictory in like different sections that you read like yeah that that is a great example of just awful awful documentation it is not clear and here's the other thing too so he talks about coding documentation, right? Like documenting your code and why you should not do it. And this goes to what he just said about it can lie. Do not, your code should be readable. And most programmers can get it. The only time you should put documentation in your code is if you're putting a comment as to why something weird is happening.

You know, why you're doing some odd thing in there. Otherwise, it should be self-documenting. Because if you start trying to document your code, and then you have this other documentation, and they end up conflicting, you don't know what the truth is. And that becomes a big problem. Well, even worse.

And in fact, this is kind of funny, because I just ran into this today. Oh, you read one of my comments in code. No, it wasn't. code no it wasn't no it wasn't yours but but um i was reading through some code from another developer and there was a comment in the code that was no longer true ah yeah and so the problem the problem with writing overly verbose comments in your code is that, Whoa, sorry about that. Is that, um, you know,

as you go through refactoring it, it's, you know, we have tools that can easily refactor the code, but oftentimes those tools don't touch the comments at all. Right. So now you have these codes that are are these these uh this you know comments in the code that are no longer relevant misleading well or completely misleading yeah that's the problem if you read something you're going to assume that it's true right i mean that's going to be your assumption unless you get bit too many times or bitten too many times. So, yeah. So, which is a great segue into how to work with poor code.

Whoa, whoa, whoa. Now, I take major umbrage with this title, if nothing else, because it's all bad code. Sometimes there's the worst code well i i like uh i there've been a couple uh i think i think even a twitter follower that we got a while back had a statement like you know for their their little twitter status or whatever how the the slogan for that user i don't know what twitter calls that what do they call that byline maybe yeah okay fine your byline umline. He had something along the lines of writing tomorrow's legacy code today. Yeah, I love that. Right?

That's awesome. And it's so true, right? So your point about it's all poor code, yeah, I mean, it's the greatest thing. That code that you're writing right now that you're so proud of, that project, it is amazing code right now, and tomorrow it won't be. Well, you know the funny part about this is we've talked about solid and dry and all that and and joe went through and tried to torture himself and do a completely solid application at one point and you end up with like nine bajillion interfaces and whatever and here's the right? Like that's not even good because nobody can ever follow it. And so there's a fine line between what's good code and what's poor code.

And a lot of times it's opinionated. Like I, I'm friends with a guy who I would consider a very competent programmer. Very good. Thank you. And I'll never forget at one point, like what did this guy's all about patterns and good programming sense and all that and he was like too much

abstraction makes for bad code and I was like this coming from this guy right and it's because it becomes very difficult to follow yeah you're following all the best patterns and all the best practices out there, but it's impossible to read and it's impossible to get from point A to point B. And, you know, elegant code, but is it poor? But let's take the example of, though, let's assume that that's not what the author meant.

Right. I don't think that's what he meant. And let's assume that you're actually looking at just some horrible, horrible code, right? And the point that he's trying to get at here, though, is that you weren't there at the time that that was developed. Right. You don't know the circumstances. You don't know the skill set of the person who is doing the development.

You don't know the time pressure that the person was under when doing the development. You don't know the political pressures within the company of when that development was happening. So there's so many unknowns that for you to come in and be judgmental about it after the fact, it's kind of... Yeah, don't throw stones. Don't bother because you know what?

Somebody else is going to have to come back to your code and do the same thing i love it because both you and joe like if if i've ever had to inherit something you're working on like the first thing i'll hear is look i'm not proud of this yeah like here it is and here are my uh asterisks and conditions and caveats oh dude by the way here are the set of tickets that i have set aside for myself to later go back and refactor that look man i i will be honest i've never worked behind anybody like i have behind joe this dude will totally document all the pitfalls of everything that's happened and be like,

look, dude, here's the things to look out for. These are the things that I know exist, and this is the kind of stuff you have to be aware of. Dude, he'll have an entire document of, all right, man, I know that I'm not working on this anymore, and I'm sorry that you have to. Let me count the ways that I'm sorry. Here's my cliff notes of what you're going to have. Dude, it's actually kind of amazing because it's a good reference. I think you even talked about this at some point as having like a handoff document, right?

Oh, yeah, yeah. Right. It's been a while back. But, you know, again, to his point, though, you really don't know. We should do a talk on neurosesoses and anxiety uh as pros of being programmer you you you mentioned um the abstraction and uh i think you also mentioned encapsulation now those were two things though that the author called out as like uh two of the two of a programmer's best tools i thought that was an interesting uh

way to categorize those well here's here's an interesting thing it's so too much abstraction it's just insanity but one of the cool parts is especially programmers coming out of college like you're not really taught interfaces properly and we talked about this way back in our is for interfaces thing but i remember going to some conferences at one point and security was one of the big talks and they say how do you make something secure that's not secure you start abstracting things away by introducing interfaces and that way you can plug things in that will make them more secure so you can you can create classes that can kind of kind of of hot swap out what was there. And so that is how abstraction can help out and encapsulation as well. You know, you're not leaking global variables out and, you know, you can start

fixing problems slowly by, by going through. So let's move on to one of my favorite topics here how to use source code control by the way subversion version one came out in 2004 oh man man hey look i used the heck out of some subversion anything to get away from uh visual source safe oh yes yeah i was all on board with. Man, I was a fan of Visual Source Safe back in the day. I don't know why you're hating on it. I hated Source Safe. I never liked Source Safe, as a matter of fact. I'll never forget some places that I did work with. They were like, checking all your code at the end of the day, whether it's working or not.

And it was like, so that means when I go to check out tomorrow, this thing ain't going to work. But they're like, but if you keep it checked out, then everybody's going to out from that file and it was like okay yeah that was the downside yeah dude i hated source safe it it definitely uh fell on its on its face for large teams hello but you know for a for a beginner programmer though you really need to understand how you the ins and outs of source control and you don't have to get get too incredibly deep into the topic, but the basics of what value it's going to bring to you and how to use the tool, whatever your platform of choice may be

for whatever team you're working with, but you should be able to understand how to use it. That is key. At least the basics, right? Like, I mean, get the basics down. Even if you're not going into cherry picking and whatever else is available, get the fundamentals, please get the fundamentals. It will make your life easier and everybody else's as well. Yeah. I mean, he talks about staying up to date and, you know, staying current with, with whatever staying up to date you know staying current with with

whatever the uh you know master trunk is uh for your your given repository and and that that alone can help you uh you know stay away from a lot of of conflict type problems just from you know being out of date, right? So just staying current can really help. But he had this other thought in there that I thought was really good that he says in regards to source control systems that they encourage thinking about the code as a growing organic system. And I thought, well, that's really great,

especially in today's world of, you know, Mercurial and Git, where, you know, large distributed teams that are, you know, working on this thing. And I think specifically, we've referred to code as a living, breathing thing before too, right? Maybe back when we doing uh the first part of the 12 factor app you know so so i thought that was great and you know going back to the the points that joe keeps uh bringing up about how old this thing is you know like this was a this was a while this was back in the days of of um you know visual source safe and and what was the Rational one? Oh, shoot. Clear Case?

No. I don't remember what those were. Was it Rational or Rose? What was it? Rose was for doing design. That was design, but it was by the same company, right? Yeah, it was all Rational. I think it was Clear Case, wasn't it?

I forget. I hate it. There was VCS. Rhapsody? I don't remember. Apex? No, I don't remember. Apex? No, I don't remember. But my point being is that this was back in the days before the large distributed repositories exist, such as Git, for example.

But it was still encouraging you to think about it as a growing organic thing, right? And don't forget to check out episode three for our talk on source code etiquette, which really dives into a lot of things about distributed source control. Was it really that far back, episode three? Yep. Yeah, that we talked about source control etiquette? Wow.

Yep. Yep. We've talked about a lot of the things that they talk about in this episode. Yeah, we really have. Including unit testing. And it wasn't clear case because that was something else. I don't remember what the rational tool was for source control.

So, yes, unit test. You want to step us into this one, Joe? Yeah, so I didn't read this part because i know everything about it already wow i'm not kidding i mean i don't know what else to say about this we we've talked about we've talked about the value of unit testing before um you should definitely do it unit testing is awesome like there are times where especially i don't i don't know why i feel this way about compiled languages more so than others but uh like there are definitely times

where like i'll be working in some code and if i can't write unit tests for it then i feel i don't feel complete like something doesn't feel right well it's not even typed i mean like even if you go javascript or something you've got a bunch of there are test runners and that kind of stuff is or test runners there there are there are uh testing frameworks out there for that so i'm not trying to take that away but my point though is that for me personally right for some reason i guess you like dot cover is the problem I think you're in love with.cover. Well, I mean, I use.cover, but I think I would say that I'm more...

I would give that love more to NUnit than I would.cover. But, yeah, just the ability to see that, yes, this is working. Yes, my confidence is high because look at all these different parameters that I'm testing on. Yeah, it builds really good confidence about it. So I don't know what else that could be said about unit testing. It also informs good design.

It keeps your cohesion and coupling down. It forces you to, and it forces you to abstract out your dependencies or else you're not really unit testing. I will say, uh, one of my, my favorite books on the topic is the art of unit testing. And, uh, it's the examples in the book are specifically, um, in.net, but the, all of the concepts, all of the principles and everything that's discussed in that book, they apply to anything. They're not just limited to.NET. So I would highly recommend that book, The Art of Unit Testing. You know, artofunittesting.com is a site by Roy Asharov

who wrote the book that we're talking about and it actually has sections for Ruby, C Sharp, Java, and that's it. Yeah. who wrote the book that we're talking about and it actually has sections for ruby c sharp java and that's it yeah so uh let's get into a topic that alan should should uh learn from mr beginner and well this is take breaks when stumped so i'll i'll give you a break on that one that's not the one i was thinking of. I was skipping ahead to the next one. Sorry.

Yeah, but this one's probably a good one too. And this one's just take breaks when stumped. It really does help. I can't. It's so simple. I mean, like, that's the beauty of this one is the simplicity. But yet it's so true. Like, how many times have you been stumped on something and then you're like, you know what?

I'm going to go for a walk. I'm going to go to lunch. Whatever it might be, you step away from the code for some period of time. And when you come back to it, it's just you have this epiphany and you're like, oh, how did I not notice that before? Here's how I should solve this, or here's what the bug was, or whatever it might be. You suddenly see it.

You know, he doesn't mention this, but I would also say, try not to code up until you're going to sleep. This may sound really stupid, but your brain won't relax. If you're working on a problem that you don't solve, chances are you are not going to rest well. I mean, at least I don't like if I haven't gotten to what I considered to be a good goal, then I literally will stay awake all night

dreaming about code. And, and it's really frustrating, but you know, I mean, even nowadays, sometimes I'll just have to I'll just have to go out and shoot a basketball, you know, to get away from a problem. Or, you know, go to lunch. Do something to walk away from it because you're so tied into the problem that you can't, you know, zoom out to 10,000 feet and look at it differently. You get lost in the weeds. I know that I'm in trouble when I start trying, trying to prove that my language or framework is broken. It's like a little mental switch that happens where suddenly I'm like, no way,

this isn't me. This is you. This is you. And I'm going to prove it. Unfortunately, in some cases that is true. It's true. Some,

some frameworks more than others. Yeah. That's funny. So it was bug others. Yeah. That's funny. So it was bugging me. It was Rational Clearcase. Oh, okay. But it had so many different features that revision control or version control was just one of the many. Right.

Or at least back at the time that this was created. All right. So here's the one that I was thinking of that Alan should learn from. How to recognize when to go home or when to just turn it off and go to sleep. So to your point about not working up and not not working all the way up until the point that you go to sleep. Yeah, you definitely need to give the brain a break. But actually, to that point, though, I find that I feel like I'm more productive and able to think more clearly in the mornings than late at night. I think for me, the late at night is more about less distractions. You know, in the mornings, everybody's, you know, in the office or whatever the case may be. And so there's more people hitting you up for things or whatever, like the late night stuff usually is

just simply, I can focus, right? Like there's, there's very few distractions and that's probably the big thing for me. But yeah, I mean, what you're referring to is my late night the other night and that's just, know the framework there's a problem with a framework it and you've done everything you can think of and oh no way man i think you were just looking for an excuse to stay up till 3 a.m but i will say this though this this chapter had some or not chapter this section had some really, really great points in it. Like if you were working at a place that expects you or, or almost kind of forces you into 60 hour work weeks or greater, you need to really evaluate that, right? I mean, don't get me wrong as developers, there

are going to be those times. There's no question. You got some major deadline coming up or, or there's just a particularly challenging thing you're working on. It's going to happen. But if it becomes a norm, that's, that's abnormal. That's unusual. It should not be like that. It's not healthy. Yeah. I like that. You know, he, he makes the point of saying that, you know, the sad fact is that, uh, you know, know for the for the programming culture right um it doesn't value mental and physical health very much which is a crazy statement because like you kind of want to say you can kind of make excuses for the for the physical part because you're like yeah okay fine you're sitting behind a desk all day long like that one i kind of get but the mental health one you think well hold on like we're constantly studying new subjects you know better better

techniques and languages and and you know concepts like that doesn't make sense except it does when you consider that you know we don't give ourselves the rest that we should right and then the pressures and then um i'm pretty sure it was here where in this section where he was talking about like um oh yeah it was this section um you know he was talking about don't abuse caffeine right right like you know i mean obviously he goes he he mentioned some you know harder drugs too um you know that you should stay away from to to uh combat fatigue but but i i liked the the one statement about you know don't abuse caffeine because you know how many times have you heard programmers talk about like you know their favorite caffeinated cola right like

you know is it mountain dew is it jolt is it dr pepper like those are the three big ones how many times have you heard programmers talk about their favorite caffeinated cola, right? Is it Mountain Dew? Is it Jolt? Is it Dr. Pepper? Those are the three big ones, right? And then that was even before. Now you've got drinks like Monster and Red Bull and things like that. It's a badge of honor now.

Like, I drank six cups of coffee. Right. Yeah. But that's so true, though, because in terms of your mental health, it's not helping you. Yeah. And so, so, but that's so true though, because in terms of like your mental health, they're like that it's not helping you. No. And I mean, we've all worked long hours before we, as a programmer, it's going to happen. But he also said, if you get to a point of, or if you notice a team member getting to a point to where they're depressed or or something like that there's i mean he actually went into more psychological type things that you wouldn't really consider that much but if you're if you're working under insanely high stress environments and crazy tight deadlines you know this stuff is real and it can be a problem and that's where communication needs to kick in but that's also where he says you need to know when to stop,

know when to go home, and if it becomes too much of a regular thing, know when to go find another job, right? Yeah, although I must say that most of my working late usually has to do with failures in other areas like bad estimating or bad debugging skills. That's true. Estimations play a key role in that but

bad debugging skills i don't know man come on yeah it happens you know it's uh it's it's hard programming is really really hard it is and i think a lot of people don't understand that getting into it a lot of people really think it's a cakewalk they hear oh you can make x amount of money just you know sitting in front of the computer how hard can that be right and i don't know it's hard enough that essays have to warn you not to take cocaine not to abuse illegal drugs in order to get your job done isn't that crazy but but when you were speaking a minute ago, Alan, with, you know, knowing when to go home and everything. Like, at first, for a moment there, I thought you were about to say, like, you know. And here's a quote from the great Kenny Rogers. Oh, no.

You've got to know when to hold them. And you've got to know when to hold them. And you've got to know when to fold them. And you've got to know when to walk away and when to run. Man, you've got to sing this. You got to catch them. Oh, my God. I was not trying to get that. All right.

George is coming out. George is coming out. That's a perfect segue into this next topic, which is how to deal with difficult people. Jeez. Oh, get used to it, man. All right. which is how to deal with difficult people. Jeez. Oh, get used to it, man. All right, hold on. Programmers are difficult. Hold on. We're going to mute Mike real quick.

Wait, what? Yeah, this, hey, look, out of all the sections, this is probably one of the most important and one of the absolute most difficult to deal with, period. Difficult dealing with difficult people and that's i mean he hits a lot of topics in here and the crazy part is his his suggestion boiled down to try and stay calm and patient and hear them out yeah i mean he does make a great point you know like ultimately you you guys you have to work together as a team right like it's not going to happen by you know you're not gonna be able to do it by yourself right and uh you know these are people that you have to work

with so you you need to um you know there's boundaries there, but you need to be able to get along, right? So, you know, I liked that. And, you know, but he was also saying, like, you know, don't let a bully, you know, someone bully you around either, though, right? Like, you should be, I'm trying to say how to say this, like whatever your point is. Right. Like you should be strong and commit to that point. Right. But, but if, if the team decides that you lose, right, then yeah, then move on.

Right. right then yeah then move on right like accept what the team has decided and you know yeah i'm doing a horrible job of that joe your thoughts yeah disagree and commit what's one of the amazon's uh leadership principles uh basically it's kind of similar to what you're saying you know don't be a doormat be heard get your point across especially if you know you believe it's the right thing but you know you also you're a team player and you you know it's a democracy or you know it's some sort of governmental organization and uh you just kind of got to make your way and a lot of times the uh the arguments that are the fiercest are the ones that um the decision actually matters the least you know it's because they're both good ideas and uh you know that's just how it is so yeah you just got to be able to kind of

roll with the punches and keep going one of the good points he made in here talking about that was difficult people might have good ideas too right like it's that's one of the challenging things is if you're working with somebody who never listens and is always talking if if that's the type of difficult person you're working with, it's easy to want to shut them down, right? And it's sometimes it's difficult not to want to shut them down because you're so tired of not being able to get a word in, you know, edgewise or whatever the case may be. But if you close off your mind that way, you may lose out on some good information. And here's the other thing. Know if you are that person. Try and be introspective of things that you do.

I know in my earlier years, I was horrible about wanting to finish other people's sentences. And that was a character flaw that I knew about myself. Somebody would be talking, and I'd just want to jump in and finish it because I wanted to show how smart I was. Right. And, and a lot of people have that problem and it's something to be aware of. If, you know, maybe somebody talks to you about it, really sit back and think about it. Okay. How can I be a better communicator? How can I be easier to work with? What can I add to the team? You know, what can I take away from other people on the team? And, you know, it's such a balancing act. So yes, there are difficult people that you work with, but also be aware of things that might make you difficult to work with. So it's really twofold. And it's not easy. If you become a programmer, you're going to work with difficult people, period. Especially because a lot of programmers, they're very, I mean, not all of them are the most social people in the world.

They're not great at communicating. They like working on a computer for a reason, right? Like, that's their thing. And so you're going to run into, in this line of profession, probably a bigger variety of people than just about anywhere else. And as we've said before, it's an opinionated bunch. It is, extremely.

And it's because people that survive in this, they're a smart bunch, typically. And, you know, we all have strong feelings about certain things. So it can be challenging. I mean, I don't know. Yeah.

Well, that's going to be it for this, this first section of this, this essay. And we'll have a bunch of links in the show notes for some of the resources we like. We've mentioned there've been several books that have mentioned, we'll have the link to this particular book as well as, you know, we mentioned already unit testing. There's other ones that this book endorses that, you know, we also would agree with, you know, CodeComplete, Pragmatic Programmer.

All of those will be in the show notes. I don't know if there's any other ones that you guys wanted to specifically call out. Nah. Otherwise, then I think it's time we get into Alan's favorite section of the show. Yes. Tip of the week. It's the tip of the week. Yeah.

And I made mine a one-liner so that nobody would actually know what I was talking about. Oh, man. I was totally going to come in there and webstorm that. Can't believe he called me out on MSDevShow as stealing his webstorm. You totally did. He's got the ear of the public. It went to another show. Yes, that's right. It traveled with me.

I told you, man. You guys weren't showing me love at all. Oh, Yes, that's right. It traveled with me. I told you, man. You guys weren't showing me love at all. Oh, my God. All right. So my tip of the week actually has to do with my Kindle. And so I do not like reading articles and books and stuff on my computer. I really don't even like reading that kind of stuff on a tablet, although I will. My Kindle Paperwhite is one of my favorite devices.

And here's my tip. So if you find a PDF or a document or something that you want to be able to read and you want to be able to take it with you, download it to your Kindle, a way that you can do that is, okay, so it's not a book on Amazon. You can actually email that file to yourself or to your Kindle account. So typically like if, if your Amazon account is ABC, uh, you know, at, at gmail.com is your login, then typically your Kindle email account is abc at kindle.com. And so you can literally just email a document to that email address from an approved email address in your Amazon account settings. So probably whatever you logged in with and it will ship it to your Kindle device.

Now, here's the bigger tip on top of that. So there's a compound tip. If you do just a PDF and you send it, the thing that's really annoying is when it hits your Kindle, it's going to be like a page that you zoom in and out of, just like you would see on a PDF reader on your computer. So you can zoom in to 100% or whatever, but you can't scale the font. You can just zoom in on the entire page if you put the word convert in the subject line when you email that pdf amazon will actually convert the thing into a kindle book for your kindle format so you can actually scale your font up and down and so you can actually have page tracking and all that and then you can take notes and and all that otherwise

it comes across as an image that's that's not really what do you do about images so i think i don't know if this one had it in there i've seen it do some wonky things with images but for the most part it does convert it very well like this this is one that i did and i emailed the pdf and i put convert in the title and i've been able to take notes, highlight things, all kinds of stuff. It's absolutely beautiful. So if you have a Kindle device, and you do reading, and you find something on the web interesting that you like, email it to yourself. Put the word Convert in there. But there's no way after the fact?

You just have to cryptically know to do this email. Yes, and that's the thing that's kind of frustrating about it as I was looking at it because I first emailed it as a PDF, and I was like, man, this is horrible. I can't even read it because it was so small on my Kindle. I was like, okay. And then you'd zoom in, and it would chop off half the paragraph on the right or the left, you know, wherever you'd zoom to.

I was like, I can't read it like this. And so I did some searching, and sure enough, you just do convert. Now, the thing is, if it's a huge document, it might take a little while for it to make it to your kindle but still extremely useful yeah nice tip yep and for programmers this is great because if you find a good reference and you can take notes on your thing well that's why i was asking about the images because sometimes some of the books that i've read they'll have like um you know figures for example example, or tables or something like that to illustrate some

issue and sometimes that might just be straight up like, here's a screenshot. I'll try and do one real quick. Let me find a PDF. Alright. Well, while they're doing that, I'll go ahead with my tip of the week. Unless I should wait? No, I'm not waiting.

While I'm waiting. I'm not waiting yeah okay well I'm waiting I'm not making you wait my bad we'll update yeah so my tip of the week is stolen from at Ray Hammond thanks Ray he sent me a command fgrep is basically it's a bash command for searching in

files it's basically you know quicker than doing a find, do your file name type filters, and then piping that over to grep and searching for stuff. This lets you just kind of do things a little bit easier with some additional flags. But what I really like about it, and what kind of reminded me is how powerful your computer really is.

You've got this tool here that, you know, Windows, Mac, Linux, whatever, you've got great command line utilities that you can use to automate tasks. So a lot of times I'll find myself doing things that, you know, through the UI, double clicking, doing things basically the hard way, when a lot of times you can just type five little letters and get the information much faster. So, you know, you should use your command line and write some scripts and automate your life, yo. Yeah, I mean, the specific example that he was talking about where there's like where you do a find,

you pipe that to grep, that is so just ingrained into my brain that like if I need to do something, that's often the way I'll do it. And when he mentioned this F crap, I'm like, Oh wait, I didn't even realize that was an option. Yep. So that was an awesome little thing. All right. So here's, here's, uh, the, the closure to the teas from earlier. Um, we, we know that I like it right like we've we might have talked about that once or twice and uh you know as i mentioned earlier i am rather meticulous about you know when it comes time to put a commit together and i will you know review the code to uh sure that, you know, what I'm about to, you know, put in about to commit is actually what I want. So in other words, you know, did I leave, I want to make sure that I didn't

accidentally leave any console.log statements in there or any debug statements, or, you know, leave any, any commented out code that I didn't intend to, things like that, right? All things that we've talked about in this episode, right? And for some environments, if you're working, if your preference is to use a visual tool, then you can quickly click on those files and view what the differences are. But if like me, you prefer to work with the command line, then you can just use git diff to be your friend, right? And so typically, you know, if you had some file, let's just say it was foobar.txt, right? Then you could do git diff foobar.txt, and git will show you all of the differences in the version that you have that hasn't yet been staged for a commit compared to what is already staged

or already committed. So it will show you those newly introduced changes. And I say the already staged part, because if you do a get add on that file and then later make new changes, then get diff will show you those new changes since the last time you added it to be staged right before you've committed it. But here's the, here's the, the cool one that, that I wanted to mention is that that's fine and dandy if you want to go file by file and do that, right? And sometimes you might, you know, you might want to do it file by file, especially if there's a lot of changes in there. But let's say that like whatever your path is, you have multiple files that all have changes in it. You can just do,

let's say that it's in the current directory. Let's say you've got five files that have changed and they're all in the current directory that you're in. You could do, or even let's say that it was in a specific directory, right? That the specific directory that you're in and files that have changed in another directory, you don't care to look at just yet. You could do get diff period, for example, for the current directory and get will show you the differences of all the files in that directory, right? Now I say that the, you know, get diff period, because you could also explicitly state whatever path you're interested in seeing. So you could just say get diff and then, you know, a more verbose path if that's what you're

interested in. Or if you're not interested in any one path, but interested in all of them. So maybe you have, let's say two files that have changed, but they're in, you know, each separate directory, and maybe those are, you know, long path names, you can just do get diff, and get will show you the changes of all the files, right? So it's a nice and handy way that if you want to review your changes before you commit them, or before you even stage them, right? You know,

you don't necessarily have to go line by line with your get diff command. You could just, you know, specify a specific directory or not and, and see all the changes. So I'm back and I just found a PDF that had some images in it and I did a convert and it looks pretty outstanding. So here,

yeah. So the convert looks like it worked for a story, a short story with an image. It's been so long since I've used one of these. I'm like, I'm like trying to pinch and zoom. I'm like, why is this not working?

So looking at this thing. It's like going into an epileptic seizure whenever I. Yeah, redrawing the screen and all that. Man, I love that Kindle. The paper white, by the way, if you do want a Kindle, that thing is awesome. Because it has a backlight on it that you can read in the dark, in the day, whatever. Wait, this one has a backlight? Oh.

Yeah, dude. Turn the light off, you can read that thing in the dark. That is the only so i never wanted a kindle or a nook or anything until they had that edge lighting because i was like okay this makes sense now i can read this thing you know sitting in a dimly lit room or whatever so it's fantastic but yes the convert actually did the image conversion as well and it looks really nice but it won't let you like convert actually did the image conversion as well, and it looks really nice. But it won't let you zoom in on the image there. I don't think you can zoom in on anything on it,

so you can change the font size and all that. But that's kind of what I was getting at. When you convert something to the Kindle format, really all you're getting is the ability to make your fonts larger and smaller and to have locations that you can go back and forth to. In other formats though if there were images you could tap the image and then that would bring the image up and then you could and maybe i'm just you know because i use the kindle app on my phone yeah so maybe that's more what i'm thinking of yeah yeah you so maybe that's a smartphone or you know uh ipad you

know tablet or phone feature that they don't support on the actual Kindle. Yeah, I don't think that is. Because even if you tap on the image, it doesn't do anything. Yeah, it's not about images. I don't know if that's part of it being a Kindle device or if that's a part of the conversion. Yeah, I think that's part of the conversion. It's literally like really what you get on the regular Kindle reader

is just font sizes is pretty much what you deal with. But the images came over across well. Yeah, they did. They looked really good. So that's kind of cool. So, yeah, that's my extended, long, well-drawn-out tip of the week. All right. Very nice.

Well, this week we talked about the beginner segment of Robert L. Reed's book, How to Be a Programmer. We've got a link to that in the show notes. And we focused on the necessary personal and team skills you will need to survive in this industry. So hope you liked it. Yep. And as we said before, be sure if you're listening to this because a friend loaned you their device that had this on there or they somehow hooked you up with this or if you're listening to it on the web or you know some other outlet and you haven't already subscribed to us be sure to subscribe to us on iTunes or Stitcher more using your favorite podcast app and you know as Alan mentioned earlier be sure to leave us a review on those platforms too. We greatly appreciate it. And it goes a long way to helping us be found by other people.

Yep. And visit us at www.codingblocks.net where you can find our show notes, our examples, discussions, and more. And send your feedback, questions, rants, and Slack invite requests to comments at codingblocks.net. And follow us on Twitter at Coding Blocks.