Coding Blocks - The Pragmatic Programmer – How to use Exceptions

Episode Date: August 20, 2019

After 112 episodes, Michael can't introduce the show, Allen pronounces it "ma-meee", and don't make Joe run your janky tests as The Pragmatic Programmer teaches us how we should use exceptions and program deliberately.

You're listening to Coding Blocks, episode 113. Leave us a review, subscribe to us. Well, I'm saying that all backwards, so I'll start it over and just say subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more like it's the first time I've ever said it using your favorite podcast app. And check us out at codingblocks.net where you can find show notes, examples, discussion, and a whole lot of other stuff. Send your feedback, questions, and rants to comments at CodingBlocks.net.

Follow us on Twitter at CodingBlocks, Facebook at Facebook.com slash CodingBlocks, or head to www.CodingBlocks.net and find all our social links there at the very top of the page. And with that, I'm Alan Underwood. I'm Java Jozak. And I'm the new guy, Michael Outlaw. Wait, you're not Java? No, you're not Kotlin Joe Zach? No, I couldn't figure out how to make it rhyme.

If it was Kotlin, that'd be another thing. See, I told you that Java Joe review last time was him. I forgot about that. Thanks, Java Joe, by the way. This episode is sponsored by Datadog, the monitoring platform for cloud scale infrastructure and applications. All right. And in this episode, we're continuing on with the pragmatic programmer, although we kind of broke this one up a little bit. So we're going to be talking about programming by coincidence.

And we've also got when to use exceptions, when to use exceptions. So that's what's on tap for this episode. Yeah, but first off, let's start with the big thankful reviews. It's like Thanksgiving over here. On iTunes, gotta say huge thanks to Matt Carla, winner of the race condition,

and Michael Mancuso. And from Stitcher, we have Run Dev Cycle, Can Michael Pronounce This, Winner of the Race Condition Remix, C Flatfella, Uncle Bob's Nephew, and Alex Unique. Huge thanks.

There were some really awesome reviews in there too some like that like like tickled or pulled at the heartstrings a little bit so thank you very much for taking the time to write those everybody yeah and uh uncle bob's definitely i still owe you a couple emails sorry i've been slacking i'll get there eventually i'm terrible with email that's awesome and so we've got a few little bits of news here. One, there was in our developer shopping spree from last November, one of the things that we recommended was the Autonomous Ergo Chair 2. I finally got around to getting the review done for that.

I had to go find all the audio and stuff. That's why it took me so long to get it. So at any rate, we've got a link to the YouTube video up there. So if you're curious about it, go check that out. Also, we will be having a booth at the Atlantic Code Camp, which is Saturday, September 14th here in it's basically in Marietta is where it's held. It's at the Kennesaw State University Tech Campus. So definitely come check that out. We'll have a link to that in the show notes here as well. Excited for that one. Yeah. Mike is going to be our booth, babe. Oh yeah. I'm so good

at it. It's Mike. Mike is awesome with that kind of stuff. So definitely if you're in the Atlanta area, come meet us, come say hi, uh, you know, hang out with us. I mean, chances are we'll be going to the after dinner and party and all that kind of stuff. So we'll be hanging out there too. And Joe's that you'll be up here too, right? Yeah.

I submitted a talk to, so I'll be a nervous mess. So come up and, you know, try to kick me in the shins. That's right. And I'll also be given a talk there. So,

so definitely come out here, meet us, talk to us, you know, maybe listen to us. I don't know. Whatever. All right. And they also, I want don't know. Whatever. All right.

And also, I want to say a huge thank you, Jamie Kaprogman, Waffling Taylor,.NET Core Show Taylor. Huge thanks for sending me some Jaffa Cakes. We all got to try these things. And if you're not familiar with Jaffa Cakes and the controversy that surrounds them, then I recommend you run to a computer. Rush to a computer right now and type in Jaffa, J I recommend you run to a computer, rush to a computer right now and type in Jaffa, J-A-F-F-A, J-A-F-F-A cakes and learn all about them because they're really interesting. They are debatably either cakes, cookies, or biscuits.

Debatedly. Debatedly. Easy for me to say. No one's really sure what they are is the deal it's very important uh legislatively and also spiritually and uh they may or may not be cakes cookies or biscuits and apparently they're maybe not even apricots either so the whole thing is just shrouded in mystery and they're delicious and they came a long way and so we want to thank you jamie for sending those because we all got a lot of fun out of it. And our families and friends also got a lot of fun and intrigue in their lives.

Now, we're not going to like later learn that this is basically the equivalent of Soylent Green, are we? Gotta Google it. Okay. Hey, on the spot, did you like them? They were good. Very reserved. uh they were good very reserved uh so personally i did like them but my wife did not at all like like she she basically was almost going to spit them out and i was confused by this so um yeah i don't know i thought they were good so huge thank you that was that was a lot of fun and the letter that accompanied

it was really awesome oh god wasn't that awesome massively massively fun so thank you guys we had we had mixed reviews over here in all honesty like uh my my wife and youngest liked them and my oldest was like um no so you know my kids my kids said that they didn't like them, but I think that they were trying to follow mom's lead. So I'm excluding them from the polling results here. Cause I feel like that was tainted. I looked at the carb count on it and I'm like, uh, I'm going to have to pass, but I'll let you guys weigh in for me. So two out of three in my household that, you know, that wasn't bad. I thought that, I thought that represented well. That's excellent. I did not try to eat them all at once.

I looked at the stack and thought that would have been dangerous. I ate a whole box before going to a meetup. I ran in there like Bustleman Randy Savage. Oh, yeah. Coolie, man. Good time. I was a little excited for that meetup.

Oh, yeah. Sorry time. I was a little excited for that meetup. Oh, yeah. Sorry to anyone sitting around me. All right. So, Joe, you've got the first one on tap here. Yep. And the first one, what we did here, I should say, before we get started, we're worried about the series dragging on. So if you agree with that or don't agree with that, let us know in the comments for a chance to win the book because we're still doing that but we're worried about just taking

like another 12 months to get through the book and so we did is say like hey each of us we're gonna go pick out a section that we uh want to talk about and then we're gonna make an episode of that rather than like continuing to uh trudge on so uh i picked the the the chapter on when to use exceptions. This is something I think about a lot. And in another chapter that we didn't talk about called Dead Program's Tone of Tales, they basically recommended checking for every possible error in your code. The downside of that is that it gets really ugly, right? You've got suddenly suddenly like a five line method that's now 25 because you got if else's tries catches throws all over the place especially in certain languages can be really verbose and so they said you know that stinks but it's really important that you basically crash your program rather rather than kind of covering over a mistake and

possibly being an inconsistent state that like turns out more errors. That's kind of the worst thing that can happen. Your program gives wrong errors. So it's better to crash than be wrong for most use cases. Like, for example, you debit the customer's credit card, but you never actually save the order that they placed. And so you don't know that you're supposed to ship them anything. Yeah. So I couldn't write to the database. So I just kept shipping them stuff or charging them and not shipping them. But you know what though, in that case,

the error doesn't save you, right? Like to be clear, if that were to happen, even if you were to crash the program, if it debited the card and didn't create the order, you're in a super bad state. So that's where you need to kind of be aware of transactions and being able to roll things back, right? So there's more to the story, I guess, is the point. Well, but hold on though. I mean, in fairness though, they were saying like, it's better to, they were favoring crashing rather than being in the inconsistent state. So the inconsistent state that I was describing is that you did charge their credit card, but you didn't save what they ordered. So you have no idea that you're supposed to ship something, right?

That's the inconsistent state that I was describing. So in that case – That's more like you imagine a server where it's not able to write to the database or write to the service that says, like, hey, we got to order. So it charges the card, doesn't write the order, doesn't crash. Next customer comes in. Right. Next customer comes in. So the idea is, like, like if it crashed the first time,

then it wouldn't have kept making bad errors. And so you would add one thing to clean up and not however many. Yeah, and you're thinking like how could this ever happen? But imagine that database drive is full. But the credit card processor, that's a whole different service, set of servers, whatever, right? So it's possible to get in that kind of state. That should have been my tip there.

Keep your logs on a separate drive. Hey, and a random side note here too, because people are like, well, you know, that's what we do first. But if you're writing directly to databases for things like, you know, orders and that kind of thing, that's the reason why things like queues exist with X and whatnot, right? So that you can reprocess something instead of, you know, hey, part of my database transaction died. At least with a queue, you can actually go back and rerun the thing when everything's back

in a better state. So just be aware that there are technologies out there that are made to help with that kind of stuff. Definitely and uh like we kind of said if you've got a bunch of throws or catches or just kind of error handling code that can really mud up things and so you know the five line method can become 25 and uh this is especially ugly if they mention here if you do the one return on the bottom i don't know if we've talked about this before but you guys do that where you like try to only have one restate return statement in the function or you just buck out whenever you feel like it no i try to i prefer just the one i used to i wouldn't say that i'm crazy diligent about that because i will favor easy to read flow as opposed

to dropping on you know dropping out to the bottom after some criteria is met. Yeah, but if you're following a clean code kind of approach, then that method should be small, so it should only need the one return. But that's the thing that sucks. So I completely agree with that. When you start wrapping in these try-catches and logging and all this other cross-cutting concern crap, it starts muddying up methods really fast. And so it's really easy to get lost in stuff that doesn't even have anything to

do with the method. Right. So that's fair. I mean, okay. Now that you're saying that I've done with definitely thinking of examples in a try catch where like the trial will return, you know, uh, a zero and the catch will return a one or something like that, right? Yep. Instead of doing it in the finally, right? Instead of having some sort of variable that was set outside the try catch and then get set inside there and then doing a return later. And that's what I'm saying. Like the logic can get convoluted. So I used to be way more dogmatic about it. Nowadays, I probably favor readability over the single return.

I don't know. Even as you were saying that, I was thinking of some simple three-line methods that I'll do too where I'm like, okay, well, if this is the buck out early and just return something like an empty list or something. Yep. What about you, Joe? Which do you favor? I'm an early bucker for sure. Okay. Yeah.

All right. I hate nesting. Long nesting. And then having a return fall for sure. Okay. Yeah. All right. So I hate, I hate nesting long nesting. And then having a return fall out at the very bottom. Yeah. Yeah. I prefer to get that stuff out of my face and move along. So if I,

if I don't need to keep reading that function, I can get out of there. Yep. Agreed. Uh, so they mentioned here, you can accomplish the same type of thing as kind of having all those catch,

uh, those different kinds of statements, checking for various things. If you just kind of let things roll and then throw an exception, you can catch that and kind of wrap it or kind of explain what might have happened with your own kind of custom exception

that wraps that and passes that up. Which, you know, I thought it was kind of weird. It kind of like, because that kind of assumes that those things that you're looking out for, we're checking the statuses for, are even going to throw an exception. And that's kind of really the meat of this chapter is really just talking about like well when do you throw an exception and when do you just return some sort of status like what's the criteria there when you decide to do one versus the other man that is such a good

question i remember back in the day when i was doing cold fusion people would be like throwing an exception every time every time you know something doesn't update in the database that you wanted it to and it's like wait a second that's not an error guys that's that's a state that you didn't want to update a record in that's not an error yep yeah i definitely um i go through phases uh i tend to favor throwing exceptions i like throwing custom exceptions for things I don't think should happen or instead of doing a comment that's like, this should never happen, I like to see actually a throw there just to kind of get that stuff out of there. That's kind of like returning early to me too. It's like I prefer that than kind of having a bunch of statuses.

And I think depending on the language I'm working with, Go makes it really easy to return more than one thing from a function. So it's easy to return an than one thing from a function. So it's easy to return an object and also a status code. It kind of just goes easily. C sharp now with name tuples, it's really easy to add a status column without really breaking anything else. JavaScript

is a language I've never really done a lot of throwing in. So I don't know if you guys have the same experiences where depending on the language you're working in, you may throw more or less exceptions. I, Hmm. I think that probably I did,

I did more error stuff in C sharp early on, but I guess as my practices got better there, I think it carried over into other languages like JavaScript, right? Like I probably used it more. I know in C Sharp too, like there's definitely things where I decide not to explicitly handle errors. Like if somebody passes a null as an argument, I might, you know, maybe the first line I have is like take that thing and lowercase it. I may not explicitly check if there's null and then throw an exception because they're going to get an exception anyway.

So that's probably a bad habit of mine because it doesn't signal to anyone else who's reading the code that I ever even thought about the situation where someone might be passing a null. It doesn't inform anyone of anything. So kind of reading this chapter, I'm like, oh, you know, that's probably not a good idea to just kind of rely on this underlying behavior that I know throws an exception to throw an exception because no one else knows what I know. No one else is thinking. And besides, this stuff might change anyway. So why not be more explicit in that? I don't know, though.

That seems to get like overly verbose, though. Yeah. Sorry. Because then if you start throwing like custom exceptions or even like what exception would you throw? There would be any different that wasn't the built-in exception in that case, right? Like, you know, the null object for that particular thing, right? Like, or, you know, you're going to throw like a null argument exception or something like that. Like, I don't know, man,

I'm, I'm probably equally as guilty as doing what you said that you do as well where you know if you know that that string that null you're expecting a string to come in if they happen to pass in null then you're you already expect like okay well the system's going to take care of its own exception handling I'm probably as guilty about that as you are

I have a slightly different take if it's something that if it's something that's programmatically happening, like a method didn't get the arguments that it was supposed to because another piece of code called something, then I'm more likely to roll my own null argument exception with a friendly message to give back, right? Like, hey, you didn't put in last name here and you're filling out the contact form. Well, yeah, but in that case, it would never get to that backend system.

Like you would never get past, like as soon as you would click the submit button, you're like, no, you can't, you got to fill this in. Well, so let's take it a step further right so hopefully you do have validation in the ui right but what if somebody i mean a stupid stupid example but what if somebody had javascript disabled right just just per se i mean if it's steve gibson on your site right did you say the same i have said, then they can't surf the internet. Right. They probably can't. But like Steve Gibson, I think he said a long time ago,

he turned off JavaScript on everything, right? Like he even made a site without JavaScript so it could do it. But I guess my point is this, even anytime you're writing like a client server type application, you should have validation on both sides, right? One on the UI to make sure that you're trying to enforce things there, but then also on the server side to make sure people aren't trying to slip things past you because, you know, somebody like one of the three of us doesn't mind cracking open the Chrome dev tools and trying to slip by some garbage, right?

Like, so, so I guess that's where I'm saying is I would still have something on the server side. If I knew that it was feeding some sort of feedback loop to, to somebody using the app, I might have a friendlier message in there. That's not just, Hey, you passed it in a little argument.

It'd be like, Hey, last name is required, you know, something like that. So just, just my take on it. It's a good point,

especially if you're taking a complex object and like, it's not clear what's required and what's not. And so you may get down pretty far into some computations and one of those things might be null that you weren't expecting. And so you didn't have that guard up front and now you kind of let this monster in and now you're in an inconsistent state. I guess a better way that's selling me on this is that if you're going to make this API available, right? And even if you don't intend to make that API available, like having the check there, uh, I don't know, either way you're still throwing the same exception or similar exception. So, but yeah, I don't know.

That's the only thing is that at least handling the, you know, quote crash gracefully. Yeah. And, uh, I'm, so I'm willing to consider that a minor, a minor sin. Like I, uh, certainly I'm not going to hate on anybody for,

for letting some stuff like that go. I mean, I'm still not going to do it. Especially if you have tests around it. Right. But I'll, I'll still approve that PR. That's too much.

That's too much code, man. Forget it. That is a lot of code. Yeah. I'm more likely to hate on too much error checking than not enough. That adds in at least two to three extra lines. Yeah, and plus you're probably going to be copying and pasting it,

so there's chances of you goofing up on those checks is pretty good. Yeah. So, yeah, the author's advised, don't make exceptions for unexpected, like truly unexpected events. And that made sense to me so you know if if i really expect like a file like sc passwords to be there and it's not there like i can throw an exception for that because that's really weird but if it's something where i'm like pulling looking for a file that may be there maybe isn't or maybe hasn't come in yet but it's not the end

of the world if it's not there then they kind of advise basically just doing a status for that but they had one weird question that i copied verbatim just because it was kind of strange to me. But they asked the question, will the code still work if I remove the exception handlers? Okay. So will the code still work if I remove the exception handlers? If the answer is no, no, the code will not work if I remove the exception handlers. Then maybe you should be returning statuses for that stuff. So I think, yeah, sorry, I didn't mean to interrupt. You had a weird pause there.

I think that what they're saying is if you're catching the exceptions and you're letting it roll on anyways, then maybe you shouldn't be capturing that exception. Oh, right, right. Yeah, if those aren't truly, yeah, okay, I see. it roll on anyways then maybe you shouldn't be capturing that exception oh right right yeah if those aren't truly yeah okay i see if they don't if these aren't important enough to crash your application then why are you catching them in the first place okay yeah yeah that makes sense to me yeah so yeah and it i mean the answer is probably 30 parties that's so that's why i think i was kind of like because someone else is doing i don't know but i guess if you're thinking about all being your code then yeah that makes sense yep well i think part of what's like skewing my thought process here though is that i'm also thinking of it from the perspective of like a you know developing a web app and you're using something

like an iis to you know to host that thing right and so if an exception gets thrown that you didn't you didn't explicitly throw it could still like something could still bubble back up to say like, hey, things went wrong, right? You didn't necessarily crash IIS, you know, majority of the time, knock on wood. But, you know, so the application didn't quote crash, but that request died, right? Because IIS already has handlers in place to catch, you know, an exception of anything and then say, like, no, no, no, return a 500 error and, you know, something happened on the server. Yeah, I think the big ones that jump out to me that you'd be thinking about is any kind of external connectivity, right? Like you're trying to connect to a database and for some reason you can't get the connection. Like that's probably the kind of thing you want to capture. You know, I can't think of,

at least in terms of how they're defining it here, right? Like if it doesn't truly just crash everything and stop it all, should you be capturing it? Like I can't think of much outside of that, right? Yeah, you can see like a good program. So it's basically say, and I want to have like kind of more normal approaches like, hey, does the file exist? No. of that right yeah you can see like a good program so it's basically say and on one hand like the kind of more normal approach is like hey does the file exist no okay let's go ahead and create it with default settings another way to program that would be like hey does this file exist

no throw an exception and then it didn't go ahead and create it with defaults right and i definitely prefer i guess the first case but i guess in the second case you can kind of see how like well what if you can't create that file, for example, because of a permission error, then it's kind of bad to assume that you did create it or that, you know, you're okay to move on. And you kind of wish that maybe you were giving the authority to whoever's calling your code to kind of make a more informed decision on that based on, you know, getting that exception back rather than just kind of paving over the problem yeah i see too many exceptions is almost like the the boy who cried wolf right like you just stop believing most of them like and if all you're doing in your exception is logging that stuff somewhere then you just have really noisy logs too so it's yeah i i sort of agree with this i don't know that i quite understood the point that you're making alan with like what they said there though like with because i i didn't i don't know that I quite understood the point that you're making, Alan, with like what they said there, though, like with because I didn't I don't know that I interpret right because I want to restate what you said if I understood what you said correctly, because they were because they said, OK, will the code still work if I remove the exception of handlers? And if the answer is no, then you're throwing exceptions that you don't need to throw.

And if I understood you correctly, you were saying if you're catching the exception and just kind of swallowing it, then why was it thrown to begin with, right? Yeah, why are you capturing? What are you doing there that's all that important if it's just going to keep running like nothing ever happened? I think that's what the point they were trying to make was. If the flow of the program wasn't

bothered at all because that exception was thrown, then why are you capturing it? So that's more about making the case to not catch exceptions than it is about throwing them. Right. But I thought this was about throwing. Crashing, right yeah oh yeah for sure okay maybe that's yeah they're just maybe you're throwing exceptions for non-exceptional circumstances yeah i think they're all kind of assuming it's all your code and uh sorry it's 2019 and now like most code that i interact with is not my own code

it's all it's all left pads and crap i mean like one thing that i was thinking of too maybe this is why like i don't do those exceptions for like that null thing, you know, check that you were talking about Joe is like, I will sometimes have code, you know, in methods where like, if you were returning lists or like passing a string in your example, where I might just say, okay, Hey, if this is null or empty or white space or whatever, then I'm just going to go ahead and like return out an empty string. If, if string is what I'm returning, like in your uppercase example or lowercase example, I forget exactly what it was. Like I would just return back an empty string. Now that might not work for every use case because maybe returning back an empty string would then cause future logic problems, right? But sometimes I do like to just prefer like, hey, you know what?

I am not, I'm going to play dumb. I'm just going to assume everything's always going to be golden because then that way when there are those edge cases, like I can find them sooner rather than if I were throwing exceptions and logging it, like if I had some logging framework in place to like capture and log them or whatever, like now I got to know to go look for those things. Right. But if it blows up, then, hey, I know that there's a problem. How about this rule of thumb? You shouldn't use or maybe you shouldn't throw

an exception if you expect anyone to ever catch it explicitly. That's kind of what they're saying, I think. Which flows right into your next tip. Yeah, and tip 34 was use exceptions for exceptional problems.

So if these are things that people are expecting, then those maybe shouldn't be exceptions because those are just kind of routine, normal course of businesses. So yeah, I like that rule. You should never throw any exceptions that you expect people to catch. Yeah. Which sounds ridiculous. It does sound kind of ridiculous,

but expected things aren't really exceptions. There are no business flaws or business branches, right, is what it sounds like. I don't know. You're not arguing an example, though. It's hard to relate that with that example. Right. It kind of is, right? I mean, then that brings up the question of should you have some sort of request and response with the response saying, hey, you didn't give me everything you're supposed to versus a request and saying blow up because you didn't send me last name. Right.

It's two different schools of thought. And I've seen it done both ways. Yeah, I'm pretty happy with my silly rule of thumb so let us know in the comments if you want a chance to win that book i guess from an oas perspective uh you know if you would have stand a better chance of avoiding leakage if you uh threw it yourself right yeah because then you have control over when it stops and it like know that exception isn't going to be kind of uncovered somewhere down deep after database calls have been made or whatever. Right. Yeah.

So, question. Is it dangerous to rely on implicit exception throwing? And that's kind of what we're talking about. But basically, we're like, you know, I might be letting stuff kind of fly if it's null or not. And, you know, I guess we kind of already answered this. Basically, we said there's no signaling to your coworkers that you did something intentionally or that you kind of were relying on the implicit behavior. I don't know. Yeah.

I mean, like the example you had there was opening a file that isn't there, right? Yeah. I don't know. check if file exists. Then the second method is open file, right? Like, so, so you go through these steps of processes so that instead of just jumping right into open file and it throwing an exception, because, you know, you never checked if it was there. I think there, there are cleaner ways to do that, that, that don't throw an expected exception. Like you said, right? Like the problem is, you know that if you just go and try and open a file half the time, it may not be there.

So that means you expect that circumstance. So then why are you coding it that way? Well, just because the file's there, it doesn't mean you can, you have access to read it. Well, that too.

Right. But I guess going back to that, right? Like if you know that permissions may be a thing, then that should be another check down that you have before you even try and open and access that file. So, so like known conditions for your business case should probably be checks that happen first. Right. And I mean, I've seen the way you guys code.

That's I've seen code that you've written that's just like that. Where is this going? No, but I mean, you'll see that. Like you'll see, hey, it's valid, it's available, it's there, it has rights. And then, okay, you passed all those things. Go ahead and do the next one, right?

Yep. I guess it matters how critical it is too. Like if it's something on the critical path or involving other people's money or something, then I might be a little bit more careful than signing up to the mailing list or whatever. Right. One thing I thought that's interesting too that the book mentions is that exceptions are kind of a coupling and they're harder to see because they kind of break that normal input- contract. So, you know, if we're talking about like, say functional program with pure languages and pure functions where you're passing in stuff, there's no side effects and you're passing out stuff,

then you think about the opposite example we're talking about where it's like, yeah, there's the inputs and outputs, but I'm also potentially throwing stuff. And like, you know, in Java, you can actually see exactly what's potentially being thrown. And that could be several layers deep.

So the function that you call it doesn't throw anything, but maybe the doesn't throw anything but maybe the one that it calls the one that it calls the one it calls does throw something then that's something that that's a signal from that deep collie to you that you may need to interact with or make a decision based on so that might be something you catch explicitly and you just broke this whole freaking chain that we worked so hard to set, you know, chain of abstractions and encapsulation. And now here we are kind of cheating that whole system that you, you know, put together so tirelessly. So I thought it was kind of interesting take on it. That's something I hadn't really thought before. You're cheating those lines.

One other thing I wanted to mention here is um they mentioned some languages or frameworks allow you to register an error handler and my first thought was kind of like something like asp where you can kind of say like you know if there's an error take them to this page kind of thing or you can kind of intercept these things that are outside the flow of your your page and so they're they're not things that are inside your flow where you know it's kind of like a traditional try and catch where then you can make a decision based on that. But there's something you say like every time that this type of error happens, do this thing with it or log it or ignore it or do whatever like that. So I thought that was kind of an interesting pattern to kind of bring up where you can kind of configure

an error handler for something. Yeah. So like global error handlers on web applications, right? Like you probably want to log every single error that happens. So you do that and then maybe that's like the last line of defense. Yep. And you usually want those to be pretty simple because you don't want those to fail. Right. All right. You know, I love these challenges usually, but this one is particularly challenging.

I can't do this, but maybe someone else can. They say the languages that don't generally support exceptions have another method often to transfer control. They mention in C, long jump and set jump, which are ways of jumping to a different instruction. Say, what are the benefits and dangers?

And then, what do you have to do to make sure that the resources aren't orphaned. And both of those scare me. I've never done those. Yeah, I mean, I can kind of guess a little bit. Like if I just kind of jump to a random function, then yeah, I might be losing handles. I don't know where I'm jumping from, you know, depending on the situation. So I can imagine it being really hard to kind of keep control of everything and make sure that everything is kind of tidied up unless i'm just crashing the program yeah that makes sense yeah so i would

prefer not to do that so i prefer not to work with a language like that if i'm trying to do kind of normal businessy kind of things like if i'm using a language like that i'm probably doing something low level that needs to be low level and i think I would probably just avoid, you know, avoid situations like that. Or try dealing with basically everything in line, line by line, very procedurally.

And bless the compiler gods for giving us languages that can deal with this stuff in another way. Yes, sir. All right. Well, it's that time of the show where we ask

if you would do us a favor and leave us a review. If you haven't already, you can find some helpful links at www.codingblocks.net slash review. And, you know, maybe the your application of choice to get your podcast doesn't allow for feedback or comments or things like that, you know, but maybe they allow for like, you know, thumbs up or plus one or, you know, start or whatever the platform allows for like that equally counts. We appreciate it. You know, it helps to, you know, for more people to find us because it adds to the relevancy of and we appreciate it. And with that, we head into my favorite portion of the show survey says all right mommy well did you don't see that was random you did uh oh oh yes yes this the steve harvey mommy right name something i think it was something along the lines of name something, name a nickname that someone might call their mother. And it was someone said mama, someone said mommy. And then Steve Harvey gets to the next woman and she goes, mommy.

He's like, well, mommy's already up there. She goes, but no, I said mommy. Oh, okay. Oh, and she doubled down on it for like a good 10 minutes. No, it's different. Mummy. Every time you say Survey Says, that's what pops into my head. It's hilarious.

I got to find the mummy. I will have to find the mummy reference. Include that in the links for this show because it is hilarious if you've never seen it. We're doing the world a favor. Yes, I believe so. All right. So back in episode 110, we asked, what's your structured text format of choice?

And your choices were XML, JSON, YAML, or the old school CSV? All right. I think Joe went first last time, so I'm going to go with Alan this time. Alan, what's your pick with a percentage? What percentage do you think it won by? JSON, 65. JSON, 65. That's a strong choice right there, my friend.

Joe? I'm going strong as right there, my friend. Joe? I'm going strong as well. I think that. I like it. Got to have strength. Pretty sure that XML took this at 83%. 83%. All right.

I like where your head's at. XSLT, XSD, it just makes sense. Yeah, it's got more letters. They have JSOND. Get out of here with that crap. Postgres has JSONB, so it's a war of letters. How many letters do you have? That's going to dictate the winner here.

All right, so we have Alan's pick is JSON at 65%. Joe's pick is XML at 85%. Is that right? 83. Oh, was it 83? I went too high. 83%. I can bump it up.

I can bump it up. Whoa, whoa, whoa. Don't talk me out of it now. All right. We'll stick with the original answer. That would seem fair. 83. And the answer is Jason.

I thought you said Jay-Z for a second. I was like, what percentage? Jason. It was, uh, 72%. Dude, I was even close. How about that? Jason, far and away the winner. So what, what, what are you guys' picks?

Because I'm curious. I have my own here. Toml. Will Massage showed that to me. I hadn't seen that before. No, I mean, definitely Jason because I can actually read it and I dislike YAML. Wait, hold on, hold on. Jason or Jason?

Jason. Yeah, Jason. Okay, it sounded like you said Jason. I was about to be upset. That always bothers me. Like a little bit of my, you know, like you ever feel like, do you remember in the movie something about Mary and there's the hitchhiker, you know, he'd always have the twitch, you know?

Like that's the way I feel whenever somebody says Jason and I feel like, you know, it's like seven minute abs. Like why would you do that when you could have six minute abs, you know? That's the way I feel. It's like, no, abs. Why would you do that when you could have six-minute abs? That's the way I feel. It's like, no, it's not a name. It's not a person's name. Yeah, but JSON for the win. That would be my pick as well.

So I think I'm also in the JSON boat, but Kubernetes made a strong vote for yaml because it's simpler and and i like that i like the fact that it's easier to read and format so you get all the same features with a prettier format i kind of get it yeah see this is where like i can't agree with you here man when you say like it's easier to read because like it's also okay number one like python right we've talked about yeah but we've talked about this in the past though where like why is that minus sign there like because it's an array. I know, exactly. But it took a minute, right?

Like at first you're like, what? Why? That implicitly means it's not easier to read because if you looked at JSON and you saw the square brackets, you're like, oh, it's an array. But that's only because you're familiar with the language, man.

That's not fair. I mean, who's looking at this thing? A second grader of course of course you had some familiarity with programming that's why you're looking at it to begin with yeah again i'm probably more in the json ballpark but but the yaml one's interesting like i can see that one creeping in on me no and then white space also matters in the yaml too well like i said you like python well i know but hey don't don't hey this isn't a python don't start we were talking about text formatting we're not talking about languages oh man yeah as long hey wait how low was csv please tell me

there was zero percent on that okay so here's here's where it gets crazy. It was definitely far and away JSON. CSV, I guess people just really... The only reason why I could think that this one was so popular was it was definitely last. Okay, so let me go ahead and make sure I don't you weren't getting your hopes up for anything. It had almost 7 percent of the vote right it's good and the only reason why i could think that it was as popular as it was was for like okay well i like to get csv because i can easily import it into excel or something like that right right it's like

i mean it's the library anyway so i don't really care about the format i just like pump it in i mean even even yeah Cause even if you were going to like bring it into a data frame in Python, since you know, you're going to pick on Python, right? Like you could easily do CSV in that case too. So I'm like, those are the only kinds of reasons I'm thinking of, right? It's like, I got it out of a database. It was easy to like, just get that data out from a select clause that was concatenated, you know, with commas, and then I could bring it into something else. So it was JSON, XML, YAML, CSV.

That was a good guess. I don't know if you were guessing, but that was a good guess. I figured that's what it was. How did XML do? XML was like 11%, and YAML was like 9%. Oh, okay. So they're all right there. I'm so glad that XML beat YAML, at least. No, sir, man. I would much prefer YAML was like 9. Oh, okay. I'm so glad that XML beat YAML at least.

No, sir, man. I would much prefer YAML over XML. Yeah, I'm kind of with you there. I kind of hate XML. It should have definitely been last. Like I would pick CSV over XML maybe. Not by much. Whenever I pop over to Maven file, I'm like, oh, thank God.

I know what's going on here. But man, every time I paste into a Docker Compose file in VI, I hate YAML so much. Oh, that's fair. Yeah, for whatever reason. But I think that should be hatred on VI, not YAML. VI hasn't changed since like 1950. So how are you going to hate on that? Dr. Grace Hopper was still using VI back then, right? And it still stayed the same?

Yeah. When was YAML invented? Because it didn't really solve anything. It just muddied the waters. It just added to the problems? Yeah. That's a good question. I wonder when was it?

Let's see if there's a Wikipedia. Its initial release was May of 2001, so it's 18 years old. Oh, it's been here a minute then. It's been here, yeah, a minute. It's catching on. I think part of the reason why I hate XML, though, is that I don't like XPath. Oh, God. Oh, well, yeah.

Yeah, if you're trying to search it or find things in it, I'm just not a fan of it. And what's a.node or what's a.txt? It's garbage. Yeah, so that's why I've never just not a fan of it. And what's a dot note or what's a dot text? It's garbage. Yeah. So that's why I've never just been a fan. It carries with it too much baggage in order to use it. And that's why I never was a fan of it. Yep.

All right. Well, so we could do today's survey, or if you would prefer, I will treat you with a joke. I like a joke. Can we have both? We could do both. Well, I meant the joke first. Obviously. Okay, let me rephrase this. You're going to get the joke, right?

You're going to get it. You're going to like it. All right. Right? You're going to get it. You're going to like it. All right. So, since Alan feels the need to pick on Python tonight, why does Python live on land? I don't know. Yeah, I really can't think of anything. Because it's above sea level. Oh, boy.

Oh, boy. Very nice. Very nice. All right. So, that one took a minute. I love the Jeopardy. We're going to have to get an official Jeopardy theme so that we could, from now on, any joke quizzes like that, I could play that, have that ready on the mixer. We'll have to do it at Alvin and Chipmunk speed, though, because any more than five minutes and everybody else is like, come on, guys, move on.

Oh, I don't think that was too long, although we'll probably get some feedback that it was. So you can put that feedback for a chance to win the book in this show's show notes. It can be found at www.codingblocks.net slash episode 113. All right. So for today's survey, we ask, when you want to bring in a new technology or take a new approach when implementing something new or add to the tech stack, do you? A, ask peers if it's a good idea before implementing it. The voice of many carries more weight. Or B, ask the relative team lead if you can implement it. If the boss doesn't like it, it doesn't matter. Or C, implement a proof of concept and get stakeholders to weigh in because they don't know about it. They need to be sold on it. Or D, just do it.

I can't waste precious time checking if others like my idea. Or lastly, E, abandon it. It's already too much effort. My strategy is to get Alan on board. Let him take the heat for the fallout. That's a sound strategy. Better, yeah. Just get him on board with it and let him do it.

Well, it's your idea. I heard you pitch it. Oh, man. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today

by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. So go over to datadog.com slash codingblocks to see how Datadog can provide real-time visibility into your application. Again, that was datadog.com slash codingblocks to sign up today.

All right. And so for the next section, we're going to hit the one that I chose in the book, and this was programming by coincidence. Wait, that's our daily lives, right? It sort of is, right? Wasn't there some joke like that that Joe made a few episodes back? Do you remember what I'm talking about? I don't know if it was a joke. It might have just been the truth.

They had a story in here and I'm not going to do that one because you can buy the book and read the story, but I'll give my'll give like my own little antidote. So imagine that you're going skating for the first time in like a roller skating rink. Right. You get out there and you're just easing back and forth, you know, just just trying to stay up. And all is good. And you're like, I got this. And then you go out there and you go for it

and you're on your butt, right? Like it's that whole false sense of security that you get when you think you've got it, but you didn't really learn everything you needed to learn before you went all in and it smacks you right in the face, right? But isn't that how we learn to ride a bike or roller skate or skateboard or snowboard, ski? It is totally right.

But the lessons learned there are the amazing ones is just like you said, just like anything that you've actually learned to master. You did because you made that mistake and you're like, OK, let me back up and figure out what I don't know, right? And that's how you get better at things. And that's exactly what's going on here is don't get lured into thinking you know what's going on just because things look obvious. Get familiar with the stuff, right? So they say to avoid programming by coincidence, you need to program deliberately. Don't rely on being lucky, right? Like I'm sure it actually, I think I even did it today and I'm kind of irritated with myself. So I found this bug in my code or in code to where the, uh, the code was using the keyword default

and it wasn't working in the UI like I thought it should. I was like, wait, the default is supposed to be 30. How, why am I seeing zero? The keyword was supposed to be default value, right? So you switch that out and all of a sudden you get that, the right number there. And I was looking at the code and I was like, well, there's a bunch of these that are wrong. I'm going to change them all. Right. So this is where I screwed up. I don't know what I might've messed up by doing that. Right. That code maybe was working incorrectly, but properly it was doing the wrong thing, but it was working doing the wrong thing for a long time.

And this is what programming by coincidence is, right? And I was actually really irritated with myself because I was like, man, I just wrote the notes on this last night. So and this is where I might get lucky on this, but honestly, probably in the morning, I'm going to go back and test. And I might even unwind some of those changes that I did to those other things that I was not intentionally trying to touch. So basically, you had something like int i equals default instead of int i equals default value. And because you had it as a default, it was like, oh, I'll just give you the default value for an integer. And there you go. Right. And I changed them all because I was like, well, obviously somebody messed this up, so I need to make it right.

Well, I don't know what I potentially broke by doing the right thing there, right? It's been working this other way, so I may have just introduced some sort of regression by doing this. Yeah, but it's a good regression in that case, though, right? Because it sounds like it needed to be fixed. But then that means I should be, it's upon me to go in and make sure I test all those cases now, right? And that's where I failed.

So I'm really irritated with myself about it. But hey, just real quick, I want to like backstep for a moment. Episode 110, Joe made the joke about that's how he programs. He programs by coincidence. So I don't know if he was thinking ahead that we would later talk about programming by coincidence or if that was just a coincidence, in which case, Inception, but 110. Word up.

That's awesome. Nice Googling or searching or whatever. I was reading. Oh, yeah. I want to mention that. It's awesome. Nice Googling or searching or whatever. I'm just reading. Oh, yeah. I want to mention that. It's not that fancy. Yeah, there's definitely times when I'm more coincidental, and configs are one of those.

Like if you've got some sort of thing where you've got third-party integration, and sometimes the documentation is terrible, you're like, security method, and you look at the documentation, it's like the method for which the security is string. You're like, well, okay, well,

let me try, I don't know, basic. That didn't work. Let me try basic uppercase. I don't know. Yeah. I mean,

it sounds like it could be really rough and it just be hard to kind of find out what the real answers are. And then like you get kind of deep in that stuff. And then next thing you're like changing four or five things, you're trying to get to work. And then when it finally works, you're just so happy that the thing got through. And then you're like changing four or five things you're trying to get to work and then when it finally works you're just so happy that the thing got through and then you're like back away yeah you back away but then you may not realize it's like well one of those things that you changed that didn't even actually affect your outcome broke something else that you

didn't think about because yeah whatever and we're gonna get to that because that's actually an excellent point with this that falls into this chapter. So here's the next, the next point that I wrote down here was writing code and seeing that it works without fully understanding why is when you program by coincidence, which by the way, is what happened with whoever put default in there in the first place, right? So it was working, but it wasn't working the way that they thought it should be working. So it was working by coincidence. It wasn't working because they did something right. Now, I screwed up and came and made it right. It probably broke it potentially. But but that whole writing code that wasn't understood was the original problem.

I got to say it because somebody out there listening is probably screaming this into their car stereo, but it also sounds like there's some missing unit tests that might be a button here. Well, this is on a UI. Good luck. This is on an EXTJS UI. Yeah.

And if you're talking about integrations too, a lot of times it's like those are literally, I can't unit test it because this is a configuring some other system that is just beating me up. It's beating me up so hard. Wait, what are we talking about? I think he's living in – what is it? Not Sassl. Is it Jassl?

Sassl? I don't know. Sassl, Jassl, Jaws, JKS. Heck, yeah. That's where the Joe Java. I'm trying to embrace my pain. I'm trying to make it work for me. We have two masochists on the call now.

Yeah. That's awesome. Welcome to the party, pal. Yeah, man. We're going to have a little group, Pain Anonymous. So the next thing here is this really becomes a problem when something goes wrong and you can't figure out why because you never knew why it worked to start with, which is similar to what Joe's saying, right? Like you stumble in, you make 50 config changes and it works and you're like, commit it. I'm done. And so when you go back and you actually have to reproduce this later or figure out why something's not working, you're right back in the world of pain because you never truly understood what was happening in the first place.

Okay. So I just thought of a funny way to, like, as you're describing this, I'm like, okay, have you ever like made a bunch of changes? And you're like, okay, well, let me just see like the state of things, like where things are at. Because, you know, I mean, you know that it's broken, right? But you're like, okay, well, let me just see the state of things, like where things are at. Because you know that it's broken, right? But you're like, okay, I can accept it, at least as I can see, well, how far along does it go? And then it works. You're like, well, that wasn't expected.

Right? Yep, ship it. That's what ran through my head when you were like, just commit it. Well, actually, I have something that all three of us have experienced, right? So, so we've mentioned that we do development in EXTJS. It's essential product. None of us are really fans of it, but remember back to the days when you were trying to figure out how to get layouts to work.

What in the world did you do? You would find yourself nested with 15 layouts deep to get one thing to render right on the page, right? And you're like, oh, my God. It works. So painful. I just looked up, by the way, there are whole books written about joss which is like java authentication like ah sometimes if you just want to know a simple configuration it's so it's so hard to google for your situation it really is frustrating but the the thing about the extjs layout thing that i want to point out that i had that i personally went on like a crusade

to help people and to stop doing this is one of the biggest problems with the hdjs layouts is the more you nest them the more problems you have right it fixes your immediate problem but there's a root level issue somewhere that you're not aware of and then when when you go to add another layout later everything's back in a whack situation and you're like what's going on and so this is a perfect example of programming by coincidence oh man i got 10 nested layouts it works now the next time that you go to do something in there it stops working and you didn't actually understand what you did in the first place to make it happen right and and that's probably anybody that works in the xdgs by the way so right so i think that the

takeaway there is that that 11th you lay the 11th layout breaks it, right? And it's because you need even multiples of layouts. So as soon as you have that 12th layout, you're probably good. Probably. Oh, man. Power's a two, man. That's how computers work. Oh, dude.

I've definitely spent more time in my life than I'd like to admit trying to make layouts in the XTJS work. Somebody's got to scream that 12 isn't in power too, right? So the next example, we may not be innocent, right? What if the code that you write adheres to some other code that was done in error? Like that default thing that I was talking about earlier, right? So you just used it because that's what was there. That's what you have to work with, so you just do it. Well, you are now relying on something.

What if somebody comes back later and realizes that what they did screwed up, they did something wrong. They change it. Now the code that you wrote that was based on that code, you've now had this chain reaction effect. And so you just exacerbated the problem. Yeah, you're frustrated. You're trying to show someone a bug or you're trying to work with them on something. You're like, look, this thing is happening.

It's not running. You're like, yeah, well, it worked yesterday. You're like, yeah, well, your stuff's still wrong. You don't just get to buck out of this problem just because it worked yesterday. That's right. Doesn't mean I was right. Oh, man.

It worked. Go ahead. But it worked. Right. It worked. Well, it worked yesterday. Just pull your change out. That's not the issue.

Yeah, man. It's so funny. And we get passionate about that stuff too, right? Yeah. You know, it's the people that are the problems so often. So this is funny. I'm going to go back to the EXTJS well because there's so many problems that arise from coding against the EXTJS framework. And one of them is if you have, so let me back up.

If you do any kind of JavaScript development on UI type stuff, there is what is called the event loop. And if you are not fully aware of what the event loop is, I need to find a link and place it in the show notes. I've put it there before, but there's somebody that describes the event loop very well in JavaScript, right? Like everything feels like it's asynchronous, but it's not. There's things that happen behind the scenes that make these work, right? So now backing up to EXTJS, there have been problems that we've seen where it's like okay you have a tree with a thousand items on the page and you hit the expand button and it locks the ui thread for 30 seconds and you're like well what in the world so naturally what people do is they go dig

into the extjs docs and there's like well there's a suspend events call. I'm going to pop that there. Right. And so they put that in there. That doesn't fix it. It was like, well, all right, what now? Now I'm going to forcefully call do layout every time you do anything. Right. And so, so essentially what you have now to just make this expand work, you've written 50 lines of calls that are calling various methods inside the framework to try and pause this stuff so it won't crash the UI thread or hang the UI thread. This is a problem because you don't actually understand what's going on. You have to go back and figure out what's happening in the

event loop, right? And this kind of sucks because that means you have to dig really deep into how the rendering engine and the browser works. And so it's way further than what you have to dig really deep into how the rendering engine and the browser works. And so, so it's way further than what you intended to go. But if you truly want to get to the answer, you've got to go that deep sometimes. Right. And that, and this is an example of where, you know, this whole suspend, do layout, um, you know, on unsuspend, redo layout, refresh, render, et cetera. Set timeout. Yeah, set timeout. Oh, my God.

Set timeout is the one that everybody does thinking it's the silver bullet, right? So this is what I'm saying. Like, this is a perfect example of programming by coincidence because you eventually get something to work, but you've probably also written a bunch of unnecessary calls that are actually adding to the load of the browser at this point. So don't go searching too far for that event loop conversation because we discussed that in episode 87.

Wow, that's been a minute. I will have a link to that in our resources we like section for this episode. And in that, there were actually two links that talked about the JavaScript event loop. One is a link to how JavaScript works, event loop and the rise of async programming plus five ways to learn, sorry, plus five ways to better coding with async await. That was a blog article. And then there was a YouTube video by Philip Roberts called what the heck is

the event loop anyway? Dude, that YouTube video is worth every second you'll spend watching it. It's amazing. Yeah. It's from the, the JavaScript conf EU. Good stuff.

So let's get back to what Joe said a a minute ago he's like he made 50 configuration changes and it works right this is where people do exactly what we just said is dude it's working don't touch it don't breathe on it and don't look at it sideways, right? Commit that thing and be done with it. But here's the problem, right? So if it's working, why would you go back and mess with it again? Well, it might not actually be working. That's hard to swallow. But you might have done something else that might have actually done something that you didn't expect. And it seems like it's working.

It's so easy for pressure to be put on you though to where like oh yeah if you this is where like understanding the problem fully matters because if you don't understand the problem fully and there's a lot of pressure on you to like just get the thing done because we got to move on and do something else right and this might be like in a you know a customer environment or maybe you're getting ready for a demo or whatever right and you know they like, okay, fine. It's good enough. Don't touch it again. Move on. And to your point, maybe you made things worse and you haven't touched the other...

Yeah, you fixed this one use case, but the other nine you broke and you haven't checked it. You don't know. Yep. And it's easy to do, especially when you're in a hurry and under pressure right like i'm not making excuses but but those things are real oh yeah a lot of times this is like around integration points like i mentioned those third parties were like hey you just need to pull something out from the wordpress database and then do this thing to put through the biggie flop uh mutex semaphore there you go it's in our system now and then uh, by the time you get that stuff working through the firewalls, networks, users all set up and, like, you know, a password changes and everything falls completely apart. And, you know, it wasn't even the right account.

But there's so much pressure because it's such a little thing. You just got to do it and move on. And it may be a long time before anyone even thinks about that system until something goes wrong. That's so frustrating. I like your technical terms there. I feel like you just got out of an interview. Like you just dropped a bunch of keywords that I haven't heard since CES. That's right.

Oh, man. So they actually had something that I thought was a really relevant example in the book here. So this whole thing where it might not actually be working, like, can you think of an example of that? What about the UI? You change the resolution. Think about apps on Android phones or iPads back before when there was one resolution on an iPad, right? How many developers had to go back and tweak their applications to work because now there's a retina display and now there's a different resolution or there's a different aspect ratio. Right. Like these are all things that are easy to miss if you think you did something right and you weren't able to fully understand the problem.

Another one that I thought was interesting is don't rely on undocumented code. I've definitely done this in the XTGS world because I can't figure out how to make something work, right? So I just go find how they wrote it and then I hook onto it. When you do this, you run the risk of them changing that because it wasn't a documented feature, and now you're at the mercy of whatever they do, right? And by the way, that's what you do in EXTJS. Yeah, because they have the – I think if I remember right, specifically in EXTJS, it was the override concepts, right? Uh-huh.

You provide your overrides, and every time we would do an upgrade to the next version, it was like, okay, first delete the overrides. We have a pile of – Then do the upgrade. See what's broken. Add the necessary overrides back. I'm so much not a fan.

I don't think we'll be getting a sponsorship from Sencha. Our third masochist has joined the team. Welcome aboard, Alan. I don't know. I don't willingly go after that stuff. I seem to land those that's right um so the the thing that i said also about the whole you know hey render suspend do layout whatever like you do potentially add a bunch of unnecessary calls because you didn't

understand what's going on and so you could actually be adding a performance hit to whatever application code you're writing. So getting away from writing against undocumented code, try and write against code that is well documented and that adheres to a contract, right? So if you can code to an interface, if possible, depending on if you're in a type language or whatever, but those kinds of things can help protect you. It's not bulletproof, but it can help. So the next section they had was accidents of context. And this happens when you assume that certain things are a given. And I thought this was interesting.

What if the code you're writing, you assume that there's a UI? Maybe there's not. Maybe it's a CLI. Maybe it's something that runs in a background process that you never see, right? If you make assumptions without actually understanding the context of the code you're writing, you could be potentially making really big mistakes. So that one was really interesting. And another one is you might be writing this assuming that everybody speaks English. You know, if this application is something that's used around the world, it's a financial type thing. That's probably a really bad assumption, right? Like, so be aware of the context, not only of the code, but of the business as well, how that code is used.

And then this section I absolutely love, and this is where I'm mad at myself about the thing that I did earlier today, right, is implicit assumptions. Don't assume something. Prove it. Like, I knew when I made that change. Like, there was a little thing going off in the back of my head. Like, don't be a moron, Alan. Don't do this. You should, if you are touching code and you're making a change, you should prove it.

Period. Don't be that person that's like, oh, I'm just going to make this change and commit it. I'm not even going to run it. I'm not going to build it. I'm not going to do anything. I'm just going to ship it. Dude, don't be that person. Yeah, the person who didn't even take the time to see if it compiles. Man. That person bothers me. I don't mind going on record to say.

You might have said that more calmly than what I think you actually feel that I'm you know I mean I'm trying to keep things peasy keep things clean you know there might be some kids listening see I actually feel myself getting hot thinking about it like I've definitely had people that have worked with me and for me in the past where it's like, what, what, why are you even talking to me? Right.

Like I know that that can't work and I don't even know how you don't know that it doesn't work. Right. Like, I mean, it's not even like that. We've all been there where like suddenly you pull the latest from master and you're like,

wait, it doesn't compile anymore. How's that even possible? You told me in episode 3 how to do partial commits and so you know, you kind of did this to yourself. I didn't tell you that you should

commit broken code though. I've been pretty consistent in saying don't do that. In fairness, you can commit that broken code all you want. You just don't PR that into a branch that anybody else is going to get. Don't make me run your janky tests.

Okay, wait a minute. Okay, wait a minute. I'm on my soapbox now. Sorry. You brought this on yourself. Listen, if you're going to commit that broken code, you can't say it's fine to commit it

as long as you don't PR. If you're going to do that, you better squash it. Because if I have to do a get bisect and now suddenly it doesn't compile, I'm going to be a little bit upset. I can get down with that. You don't even have to squash it if you don't want.

You can even amend the previous commit, right? Like there's so many ways to get around the problem, and I'm fine with that. But I'm also a pragmatic guy, right? Like if I'm in the middle of something, I don't mind committing it while it's broken, knowing that I'm going to get back to it later because that's my backup. I'm just saying commits that make it to master better compile yeah i mean i look i checkpoint my stuff and and when it finally gets in there you know i'm just so happy it's working i'm like throwing that thing and walking away oh we know we know your

checkpoint stuff your checkpoint stuff is like well i want to go upstairs so i'm gonna like exactly commit this push that and then i'm to go get on a different computer and pull it. I've got to get on the Nintendo Switch. Commit. Done. I would say a few things we talked about tonight that I consider kind of minor sins. I would say that broken commits and not kind of cleaning it up by yourself. I would say that's getting into medium territory. And, man, I do it.

I totally do it. I do it on my own stuff. I do it at work you know grin on your face it's a problem and i'm not working on it i think he feels good about it i think it's kind of funny when i see the commissar it's like i don't know i feel like there should be like a committer's anonymous you know just for people like joe that they should have to go into like Like, hi, I'm Joe. I commit too often.

I know. I know. I'm a jerk. I'm a big meanie here. You pull my branches. The last five commits are like, hey, compiled. Looks like it works. Hey, this part works. Dude, it's so funny to me because I am definitely that guy that will put in comments that are just like, man, this is freaking whack.

I don't know how we got here. Right, right. This is freaking whack. Right, right. This is freaking whack. I don't know why. I mean, when a buddy that you work with, heck, you guys heard him on one of our episodes, Will Madison, when he text messages me after I've left the company

with a picture of my code saying, dude, really? Right. Where I've got a comment like, i don't know how i got here like you know i mean it happens and i find that as comic relief on yeah times now now leaving you treasures before i get off the soapbox though i want to be fair i'm not saying that it has to be a thousand percent amazing you know like it can still you can still iterate on it but like i just don't think you should break others in the process hey 70 is still a c in college

it's passing how do you 70 compile your application to run it hey i've got so many hundreds that it averages out to be you know oh in the bees okay all right so back on the tracks here let's see assumptions that aren't based on fact become a major sticking point in many cases and that just drives the point home right like if you don't know for certain what this thing's doing then you're making assumptions and that's probably going to be an issue yeah but it might eventually become fact so it's probably okay right unfortunately that does. Yeah, but it might eventually become fact. So it's probably okay, right? Unfortunately, that does happen sometimes. Like, why is it like that?

I don't know. It's been like that for the last 10 years. So don't change it. That's the way it is. That's right. If you touch that, the building will fall. There's probably some system out there that's like that, like a nuclear reactor system or something where it's like, listen, I don't know why we initialized the variable that way, but dear God, man, don't change it. Right. Right. We don't need another Chernobyl. So tip number 44, don't program by coincidence, right? Let's live by this rule.

Looking at you, Joe. That's right. We're looking at you. So we just talked about what it was to program by coincidence. How do we program deliberately then? Right. Always be aware. And by the way, most of these seem like common sense, but it's probably nice involved than what that little sentence implies right like for you to understand what it is like with joe and the jazz and and all these these certificates and everything he's got that's hours of research for five variables right like it's not a small thing yeah it is and it truly can be, but it will make you a better programmer. And when something happens, you'll be able to answer that question. So be aware of that. Knowing what you're doing can be painful.

Don't go blindfolded. Make sure you understand what you're doing. Hold on, hold on, hold on. That sounded like such a negative way. You definitely didn't sell anyone on becoming a developer if they weren't already like knowing what you're doing can be painful that's the way you want to end that point this is the wrong profession to be in everybody you should probably change yeah no i totally don't believe that honestly i love what

we do because to me do you guys i know we've talked about this before you remember in school you'd have these logic problems where it'd be like annie did lunch on this day and bobby did lunch on this day and so and so ate slimy has a blue car yeah yeah yeah and you'd have these matrices these grids that you had to fill out. That's what programming is to me, right? Like it's this constant logic problem that is fun for me. I like it. I like seeing how the pieces fit together. But it is tiring at times, right?

Like there are times that it's just like, God, I can't learn anymore, right? Like I can't possibly try and learn anymore. I think Joe said he forgot how to make coffee this morning. Yeah, because of Kotlin. Kotlin made me forget how to make coffee. I need that stuff, Kotlin. Come on. Wait, I think you were talking about you were trying to make a cup of Java.

Ah. I knew that Java was a language and something else. Sorry, it's coffee. But now now great. Now I think I just forgot how – I forgot the difference between Val and Var and Kotlin. So thanks for that. You're welcome. That's amazing.

But, yeah, I mean don't get me wrong. If you're truly going to do it right, it's both rewarding and painful. And somehow the reward – I swear it's not the takeaway. It's the takeaway. It's the takeaway. It totally is. It's supposed to be rewarding, man. All right, let's move on.

Yes, moving on. Speaking of forgetting stuff, you know, I don't forget the dumb stuff. I still have miles, just hours of Specially Pumpkin song lyrics memorized. I can't remember how to make coffee. Come on. Did you just pour the coffee grounds at the top of the thing? You're like, something's missing.

I was like, this doesn't look right. Did you change something? Why is my coffee so gritty? Yeah. Oh, wow. I don't remember it being chewy.

What happened? Exactly. I was like, is this supposed to be so fine? It looks like it's going to go right through the filter. I don't know. It's like, haven't you been doing this for the last 10 years? We're like, well, yeah. We'll try it.

I don't like making coffee by coincidence. Oh. All right. I'll try and speed through these. I know we've got to blast through these. I don't like being coffee by coincidence. Oh, uh, all right. I'll try and speed through these. I know, um, we gotta, we gotta blast through these.

All right. So don't go blindfolded. Make sure you understand what you're programming in. This was kind of interesting, right? Like if you're in a new language, don't just go making a bunch of assumptions, right?

Understand what you're doing. This is kind of important, Kotlin, um, or anything else that we're doing. So, you know, take the time. Code from a plan, you know, whatever. Right? Like, this one I thought was interesting. I don't know that I've ever gone into anything with a full-on plan, but I guess it's nice to have something there. I think Joe's way better at that than I am. Planning? Dude, I've seen, like, yeah, you plan things out to the end.

I'm good at being inconsistent. Sometimes it works out for me really well. What about you, Mike? Do you do plans for anything no okay yeah me neither like even even when i do my talks like i barely have a plan going in there i have some slides and i expect that they'll show up but outside of that it's basically well i think this will work i'm more like you know here's an idea. Huh. Can I make that thing do that?

Let me try. Let me see. Exactly. I'm going to try this. That didn't quite get it. Let me try this. Oh, okay. That's looking better.

And I just, it's like, it's basically the way I program is put a piece of stone in front of me, and I'm just going to keep chipping away at it until something looks reasonably like it was supposed to. And then there's nothing left to remove. I like it. I like it. Yeah. Now see, I have like eight different plans and they all conflict and I start with one and end up with another.

Yeah. I can't say that I have a plan. So, um, the next one is rely on reliable things. So don't code based on assumptions. We already talked about this. If you can code to a contract and it's a well-defined contract, that's probably your safest bet. Not always the only thing it's not always available, but do that if you can, um, document the assumptions. So if you're not coding to a

contract and you see something that looks off, you should probably put that in writing somewhere like, Hey, this doesn't look right. It works this way, but please, you know, big red, bold letters note, this looks wrong, right? But it's working. Now, the only problem that I have with this is I go back to our clean code series. Documentation gets stale, people ignore it, and it gets out of date really quick. So I have an issue with this. I don't know how you actually solve this problem fully. But if it's assumptions, though, like that's kind of a different thing there, right?

Like you're assuming, I'm assuming the application is going to talk to Postgres. If you try to make it work with Oracle, I can't promise it's going to work. This is a little bit different. This isn't like assumptions of what's my database engine. This is, hey, I coded it to use this thing over here, but that thing doesn't look like it's really doing what it's supposed to be doing, right? It's assumptions based off other methods or other calls or something like that. Not necessarily, you know,

you know your infrastructure or your stack. It's crap that you just really don't think is what it should be. Yeah, I can see like, I took a shortcut here because I can assume there will only ever be a one-to-one relationship here. And then someday that may not be the case. You say, like, this only works.

I'm only able to do it this way because we don't have negative transactions. And then one day if there's a negative transaction, that's a problem because you don't support that. But there's no good way sometimes to kind of log that anywhere. But then if you put in tickets, say, like, hey, this only works for positive transactions, then no one can get mad at you. Okay. Right.

I got an example where this would make sense. And let's go back to our friend, EXTJS, and that override conversation, right? It would make sense to document why that override was necessary in the first place. Oh, yeah. Yes. And needing that is an assumption, right? That you assumed that you needed it for whatever the reason was. Maybe – technically, maybe there was some other way and none of us found it, right? I'm trying to give them the benefit of the doubt.

You're very nice. I'm being – it's a nice day. It's nice weather. So that would be an example of like if you had to do something unusual like that, like's nice weather. So that would be an example of like, if you had to do something unusual like that, like do that override. That's a perfect example. And that's where you would document it at the top of it.

Like this override exists because blah, blah, blah, error happens if you don't have it right. And now you could take that a little bit further too. And you could say like, okay, what if you, we've talked about PostSharp in the past and how you could apply an aspect to a namespace in post sharp so that might be another case where you're like okay i had to do this to this namespace or the classes of these types that are that's code that i don't own and here's why yeah that's a great example you're wrapping it for some reason yep i like it like it. You know, a controversial opinion.

I am totally fine with seeing ticket numbers in source code. Amen. Oh, yeah. Yeah. Like, if I see a ticket number, I've never been like, that shouldn't be here. I'm always like, oh, thank you. Right. I can go see why.

This is set that way. No, I agree. But not log messages. No comments and no ticket numbers in comments? No ticket numbers in log messages. Yeah, I agree with that. They would make it in production. Now, here's the one problem that I do have with the comments, the ticket numbers in comments,

is that eventually that code will change. And if the person coming behind you materially changes whatever it was that you had the ticket number there for and they leave the ticket number that's where the problem so like i'm fine with it the first time but then as soon as you change that code again you got to remove that that number because it's meaningless which yep that goes back to the clean code and the fact that comments get stale as code changes if that comment's not changing, then it's misleading and it ultimately becomes a lie. But also don't just litter the code with those either though. I mean, I don't know.

Man, now I'm kind of like talking myself out of it because like there better be a really good meaningful reason that you're bothering to put that comment in there and include that ticket number because otherwise, you know, using Git, I can figure out why that line changed and if you put your ticket number in your Git commit message, you know, using Git, I can figure out what, why that line changed. And in what, uh, you know, if you put your ticket number in your Git commit message, which is my preference of how, how it

should be used, then I can trace it back down to figure out like why. That's true too. Yeah. I'm not opposed, but I also agree. You shouldn't litter your code with it. And if you're using my favorite extension for Visual Studio Code, which is GitLens, GitLens will just show you right there what the commit message was. And again, if it has the ticket number in it, then you can see exactly why. Yeah. Okay. I think you talked me out of it, too. Yeah, I talked myself out of it.

Cool. Got to get Joe on board. I'm still into it. Dang it. All right, so the last three I have here are test and code your assumptions. I think that's fairly straightforward, right? If you're not doing unit testing, you should test your code and whatever you're basing your code off of if it's something that is an assumption. This one seems really obvious.

Prioritize and spend time on the most important aspects first. Right. It seems obvious, but I'm sure as developers, there are sometimes we're just like, man, that one's going to take me days and I just don't want to deal with it. So I'm going to go knock out these easy ones first. Right. So, again, obvious, but, you know, whatever, worth calling out. And then this one I love. Wait, that means going after the harder problem first before going after the low-hanging fruit. Is that another way to say it? Not the harder, the most important.

And if that most important happens to be the harder one, then yeah, sure. It might be that the most important one's an easy one, but prioritize it. Make sure that you know what matters the most for whatever the success criteria is. And then the last one was don't let old code dictate new code. And I love this one. And all three of us, I know we all do this. Be prepared to refactor that old code if necessary right don't write your code to be exactly like that old code or to follow suit or to use it if you know it's wrong right but i will also say the three of us were also guilty of if we see the code is written in a particular pattern we're like well

okay fine this isn't the way i would format this or whatever, but to make it, to keep the readability the same with all the other 18 classes or, you know, a hundred files that are like this, I'm going to keep it in that format. I'm going to use Hungarian notation, even though I'm not a fan of it. I'm going to do it because that's, what's being done here. I won't. Oh, but, but have not the Hungarian notation. Maybe not that example but you know you have definitely you're correct you're absolutely correct i mean if it's if it's a pattern type thing then yes but if there's something inherently wrong in the way something's being done don't just accept it right yeah that's why I'm making the point. Like it can't be like,

don't let it be like a formatting thing. That's not what we're talking about here. Right. Right. It's gotta be something that's, you know, blatantly, obviously wrong.

So that's it. That wraps it up. I actually liked this section on programming by coincidence and how to avoid it. All right. Well, we will have a plenty of links in our resources. We, we like section for this episode.

And with that, we head into Alan's favorite portion of the show. It's the tip of the week. All right. And so with that, I'll go first with a tip that was shared to us by Mike RG, if you are familiar with him and our Slack channel. And if you aren't, that's probably a tip that you should join our Slack channel. You can head to www.codingblocks.net slash Slack, where you can find out how to join that. And, you know, he shared this link for 33 free icon sets that you can use in your next application. And there's some, there's some awesome ones in there. I don't, I don't know if you've clicked on the link, but, uh, you know, you can, you remember like back in the day where, do you remember having the Adobe

CDs that would have like all of the fonts that, you know, somebody paid a truckload of cash to have, right? And it's crazy to even think about having to purchase a font, right? And it's definitely less nowadays. And it's examples like this where there's so many great fonts that you could choose from that are just here. It's freely available. Yeah, it's amazing. I like it. Excellent tip. Yep, so's amazing. I like it. Excellent tip.

Yep, so thank you, MikeRG. I was just screwing with the show notes here because I wanted to go second because I wanted to tell a story about MikeRG from today. Uh-oh. I had a ridiculous situation where I had a unit test, and the unit test was failing, and it was basically saying, like, test failing because 5.4 doesn't equal 5.4 so i took a screenshot and like cropped out like the little bits of the code that would actually you know

show you why that would make sense and why the error message might make sense and i paste it in slack and within two seconds he's like oh you deserialized that like what the heck, Micro G? That was such a specific and correct answer to my little like, look at Java. It's dumb. And he was so right. And yeah, it was ridiculous. And yeah, there was nothing wrong with Java there. I had done something. So it was basically two different classes that the output looked the same.

You two stringed it, but they weren't the same. But it was just so funny that he just nailed it instantly. I was like, oh, man, this is a guy who's seen some things. It gave me hope that I would be able to come out the other side of this. He is one of the reasons to truly join the Slack channel, man. That guy has more information and tips and just awesome things that he shares. And he's a contributor to the whiskey channel in Slack, which is,

which is a nice bonus. There's a whiskey channel. Oh yeah. Yeah. Join it. It's amazing. All right. Well,

since I went ahead and, and this thing's up here, might as well go on ahead. I wanted to pitch Envato elements, which is a subscription plan that where you can subscribe and it basically gives you access to a whole bunch of assets and you can get all the assets that you want uh on that monthly pan you just kind of have to associate with the project so you can kind of track it it's kind of that's kind of weird but it's really easy it's seamless

you don't have to worry but you basically sign in you pay your like 12 bucks a month or whatever i think i paid for the year that's's why it's not $20 a month. And let's see. I can search for space. And now, just searching for space, I've got access to 6,500 stock video of things like shuttles or sci-fi backgrounds or whatever. Just videos. I've got 450 video templates uh music 399 songs related to uh space 4 000 uh sound effects it goes on uh powerpoint presentations

100 photos 116 000 so that's stock photos 116 000 stock photos that i have access to and yeah it's expensive you know 12 dollars a month but if you're the kind of person who's doing like a lot of side projects or like maybe you've got like a little boutique website or even like one of the main reasons I got it was for PowerPoint presentations because I do kind of a lot of those in a year. And it's got access to really high quality PowerPoint themes. And for $12 a month, you can download this stuff. And even after you cancel your subscription, you still have access to all that stuff. So it's just a great plan. I've been super happy been super happy with actually i keep using it for all sorts of things

the graphics are just amazing uh just if you search space on my cute animals in space super colorful just really cool stuff in it yeah it's just amazing this is all vector stuff too so i've been really happy with that and so if you find yourself needing art or other assets or media or powerpoint presentations then I definitely recommend checking this out. That's an awesome tip. And by the way, I'm going to correct you on something. $12 a month is not expensive for stock photography or video. Yeah, that's like one photo. No, dude, that's less than one photo typically for any kind of commercial expense like you can you can easily spend way more than that on one one photo so yeah no that's that's that's a bargain

so excellent i like it all right so i think the real reason he went before me is because i have a whole list of stuff that i'm going to share here um and you know i always debate whether i should like bag these and just do them over time. Cause every time we go to record an episode, all three of us are like, oh man, I got to find a tip. Right. So just know that I'm doing this out of the goodness of my heart because I really wanted

to spread this out over like five episodes. Oh, so the first one, our friend Nick Kustak had sent me something that was really interesting. It's a site called everylayout.dev, so every-layout.dev. And I both like this and kind of hate it. Every good recommendation starts out that way. Right. And I'll tell you why I like it. It's got some truly amazing stuff.

If you're a JavaScript or an HTML front-end person and you've ever dealt with layouts in CSS center something, you know, vertically on the page or, or whatever, have clustering layouts or grids or anything like that. It can be truly like mind boggling and numbing to, to learn all this stuff. Well, they've got like really, really good documentation on how some of this. So like if you click it in the first one's a stack, it'll tell you the problem and then they'll give you an in-depth solution. They have like little graphics to show you what's happening on each one of these things. It's just really done well. Now, the only reason I hesitate to fully recommend it is not all of them are included by just going here, right? So like the center layout that I just

mentioned, if you want that one, you got to pay a hundred bucks and a hundred dollars seems a little steep. Now I say that as somebody who has done a lot of stuff and I get it, it takes a lot of time to do what they've done here. So I'm not saying it's not worth it. They do have something for if you're a student or if you're somebody that's unemployed or if you're looking for work, they also have like the honor program here to where you can basically say you can contact them and be like, Hey, you know, I'm out of work or whatever. And they'll basically give you the entire thing. So it's good for the honor program. I think you still get value here, but definitely worth checking out because they've got some great information on there. So that's dev-layout.dev.

No, no, every-layout.dev. Sorry. So that one's good. Then Andrew Diamond has just been killing it with some tips here lately. There's another one that's just awesome. So Microsoft just did. So if you follow me on Twitter or you follow Coding Blocks on Twitter, I griped not too long ago about how there will be pages of documentation for code with zero examples. And I'm like, man, take your code page and burn it. Give me some samples so I can figure out how this stuff works.

It's great that you gave me 500 properties. What do they do? And Microsoft has heard us, and they are amazing people. So if you go to docs.microsoft.com slash samples, I'm going to read you a little snippet that comes from their announcement, which we'll also have a link in the show notes here. But they said, and keep in mind, it's not today, but starting today, docs.microsoft.com slash samples is the place where you find the most up-to-date code samples relevant to your workflows. We've made sure that we powered the hosted content and search by code hosted on GitHub. You can contribute to any of the samples by going to the repository and opening a pull request. There's a novel idea. Found a bug in the sample you're running? You can open an issue

in the repository where the sample is as well, and the team managing the code will be able to look at it. So check this out. If you've written something using code, you can go up there and put in a pull request and help everybody out, and they'll get to see live samples of code that's hosted on GitHub. And you can help improve their docs and samples by putting in your own pull requests. Fantastic way to contribute to open source. You know, we've gotten questions from people in the past, like, well, how do I, how do I get my code out there? This is an amazing way. You're helping out the community and you're getting familiar with GitHub and you're actually contributing working code that runs on the web. So killer, killer resource. So thanks, Andrew, for that one. I love that one.

And then I think, okay, I've got two more. I've got some gripes about documentation though, because there's definitely some, like you You could take the Dapr approach and just not provide documentation. Oh, yeah. Which is crazy. I mean, their documentation basically consists of the readme on their GitHub page. It's terrible. And there's so many other questions. You're like, well, wait, how does this work in Dapr?

How does that work in Dapr? And it's like, hmm. I don't know. Documentation is so hard. I saw someone complaining on the Elasticsearch Reddit about documentation being terrible and they didn't understand why Elastic wasn't working and they said something about Java Home

being not set. Most people on the forum who are used to dealing with Elasticsearch were like, well, obviously, you need to install Java because they were kind of in that. But it's so hard when you're writing the documentation to know what audience you're serving. It's like if you've got an audience of people who have installed this thing 100 times

and they don't want to be bogged down with the very small minutia of, well, now you need to go do this and right-click on those Windows Start button and go to Explore because that's really painful. But if you're not familiar with that sort of stuff and those load-level details are really nice to have. So you got to kind of know what articles are targeted for what audiences

that's, it's really hard. And so a lot of times people complain about documentation. It's just, it's really tough because they're kind of in either in the middle of those two audiences or they're looking at something that just wasn't written for them. Yeah.

But I'm, I'm sorry. No, go ahead. Well, I was going to say like another example though, is like if you wanted to write like a example though, is like, if you, uh, wanted to write like a C sharp application to connect to Postgres, right? Like one of the libraries that you might use would be NPG SQL. Even if you don't use it directly, uh, like,

let's go back to Dapper. If you were to use Dapper, Dapper under the covers would use it, right? And NPG SQL will leave you questioning things too, because it does exactly what you just described Alan, where there'd be like, okay, here's a class. It's got 85 properties on it, and it'll give you like a little verbiage about each one. You're like, okay, that's great. I don't know why I want to use any one of those. Like you're explaining it does something or it sets something that's not any more meaningful really than what the name of it already was. But like, why?

Like, what's the use case? Like, where's an example of some of this stuff? And, you know, it's just not there. That's one place where I always have felt like Microsoft did things more right than most people, right? Like, if I'm looking for a function in SQL Server, right? If I'm looking for date add, if I go to their page and I scroll down to the very bottom, there's probably going to be 10 examples of how to use that thing. Right. And and as a developer, I want to fast track it. Right. I'll get it working and then I'll go back and look at all the details of why and that kind of stuff. Right.

But but that's always frustrated me to Microsoft's credit. Their documentation for their SDK has always been like that for as long as I can remember. Do you remember way, way back that you had the option of you would get the MSDN CD along with Visual Studio? And one of the install options was, do you want to install the documentation, all of it now, or do you just want to like hope and pray that you will never need it and maybe you'll find some other way to get to it, right? And like that was a serious decision back then that you had to contemplate back, you know, because it would, once you uncompressed it, it was, you know, several gig and, you

know, you didn't have that big a drive, right? You only had 10. Right. You know, so like you're like, okay like okay well am i going to take up a third of it for this yes absolutely and it paid off always yeah and it's just gotten better and better over time so yeah this samples one awesome awesome reference so this one i gotta credit will madison again second time in the show and also our buddy ryan williams as well so cotland we had an awesome discussion earlier today i think me and joe zach were in the episode discussion

um channel on slack and we just had a killer discussion like people are curious about various different things so will's the one who introduced me to it i went and looked at it and i was like oh this looks amazing right this this looks like c C sharp for Java is basically what it felt like. And it basically, in a nutshell, we ended up moving away from Java and using Kotlin because they're interoperable. But Kotlin gives you so much on top of Java. And I won't go into all the nitty gritty details of it. I've got a link in the show notes on the language itself. So you could go look at that stuff. But if you want to fast track it, and this is what I wanted to tell you, if you wanted to see what it looked like,

what Kotlin could be in a project that you're already doing in Java, you can simply add a file to your module with a.kt or a.kts extension. If you're running IntelliJ Community or Enterprise Edition, if you do that, then IntelliJ will be like, hey, I see you added a Kotlin file. Do you want us to add support to this module for Kotlin? You can say yes, and it'll set everything up and bootstrap it all for you. And then you could as easily as right clicking on a folder and saying convert to Kotlin, you can have it rewrite all your Java code to Kotlin. And then now not everything may work perfectly, but it's probably going to get you 90% of the way there, and you'll get to learn what's going on along the way when you do it. So I wanted to give that to you as a fast track.

If you've never heard of Kotlin, go check it out. It truly is excellent. And, Jay-Z, for me, it took the almost like, God, I really don't want to deal with this today with some of the Java verbosity and turn it into a more pleasant experience. Oh, yeah, for sure. There's a couple things I still haven't gotten, but I haven't really – it's been such an easy transition. You know, we talked about programming coincidence. It's kind of hard sometimes when you like know a lot about something kind of going in because it's so familiar because it's it's easy to not see the things that you don't so like the generics are definitely different and things like companion classes and inline functions and just the way the generics have been working it's been kind of weird

to me but it's like i'm like okay well let me go learn kotlin from the beginning let me go fire up a course on kotlin and this is an if statement and and it's just so mind-tumbling that next you know it's like you've faded out. You're not paying attention because they're going over stuff that's not for you. That's stuff that you know that you miss the things that you don't. Yeah. I mean, anything that's going to call their functions fun has to be good, right? That's right. That's right.

So, yeah, it is – for me being a being a C sharp person who really enjoys C sharp, the transition to Kotlin feels very natural. Um, and, and there was a question that I actually want to answer here that we got in the Slack channel earlier today was like, why should I go do Kotlin? And my answer was, if you are working in Java applications or anything that is supported by the JVM, then go look at Kotlin. If you're a.NET developer or you're a Python developer or you're a Ruby developer, the only reason you should check it out is if you're curious, right? Like, there's no pressing issue. But if you live in the Java world, check it out. Do yourself a favor. It might be

something that can really increase your productivity. Like no lie, there's a lot less code to write. Like auto properties that we're used to in C sharp, you get that in Kotlin. Like there's, you're not writing a bunch of getters and setters, you know, basically boilerplate code for things that exist in Java. So, so, you know, I'm not trying to sell it to everybody,

but if you live in that world already, check it out. Oh, it's so good. And you know, uh, IntelliJ, uh,

JetBrains knocked it out of the park. I pasted in Java code so I can go tweak it by hand. Oh, wait, it's prompted. Oh, it pasted it as Kotlin. What the heck?

It's amazing. Why would you do that for me? It's so nice. It's too nice. JetBrains does care about its developers. Honestly, that's the best way I know how to describe it is the reason why we made the decision to move from Java to Kotlin

is because it's like the language that cares about its developers. Like that's it. They want to make a more productive. They want to be able to make right, more terse code and code that makes sense. And the type checking and safety in it is just beautiful. Like it might be better than C sharp in some regards, which is really kind of hard for me to say. I know. I know it hurts, but Hey,

you know, competition is good. It is. So, um, yeah. So Ryan's the one that gave me the tip about adding the Kotlin file to the, to the IntelliJ and Will's the one who introduced me to the whole thing in the

first place. So definitely super cool stuff. And then the last thing I found out as I was reading through my Google news feed tonight, while we were sitting here getting ready for the show, I've never heard of this and it was mind blowing type stuff. Okay. Do either of you guys remember the AT&T Axiom or Axon phone that was like the phone that was supposed to plug into like this laptop looking dock that would become your computer? I don't remember that one. I remember there was various Android based ones from long ago. So that's kind of it. samsung has done something that i

didn't even know existed so i have the galaxy s8 plus so it's two years old now right the s10 is the new one well starting with the s8 series on up through now with the s9 the s10s and all their variations and then the note 9 and the note 10 I don't know if the note eight it's included. There's this thing called Samsung decks that I've never seen, never heard of. I can plug up an HDMI output to my phone. So I have a USB-C plug.

I can plug up an HDMI to that thing and it will basically act like a laptop computer. So I can use my phone as sort of like a touch input device, or I can do mirroring to the monitor. But the beautiful thing is it truly operates like a desktop operating system. So if I have, if I want to open up Excel up there, then I can use it like I'm on a regular computer. So for people that typically have an iPad for doing something like that, this is kind of like a really cool alternative to where, Hey, if you just have like a USB-C to HDMI output device, you can plug up to a monitor and you've basically got a laptop type experience, right? Which is super cool. It's really interesting. I'm assuming it's probably

something similar to Chrome OS is, is what the experience is probably like. So now there are things to be aware of. They actually make accessories for Samsung decks to kind of keep your device cool because when you're doing this, you're actually using quite a bit of power from the phone and it's going to get a little bit hotter. And so it's got a thing to charge it and keep it cool. But man, I was blown away playing with this before we started this episode. So man, definitely check it out. If you've got a way to plug up like a USB-C to your Samsung S8 Plus or S8 and on up device, check this out. Really neat. I'm going to have to assume though that like you would have to use like a Bluetooth keyboard for

like especially on your phone because like if you scroll this site, if you look at this site, like every example that they show, the only time you ever see a keyboard being used that isn't on the device, the phone, right. Is if you're talking about the tablets, right. They never show you using a keyboard with your phone. And in fact, they show a woman using the phone almost as like, as if it was a Wacom tablet and she's got like a pen that she's using to draw on the thing. I'm like, okay, I love, I've always loved the idea of, you know, the phone being the only computer you carry around and you just plug it in, you know, or have some other inputs. But I'm kind of curious why they didn't show anything. And I kind of call a little bit of BS on one of

these because I'm like, there's no way that would ever happen. Because if you scroll through some of the images that they have of this thing, one of them is like, it says, do double duty at home. While your child watches a YouTube video on the TV, you can continue using your phone. And I'm like, yeah, that sounds great. Except both the father and son are sitting within like arm's reach of the tv i guess because of the cable limitations but they're both sitting on the floor and the dad's like text messaging while the kids watching uh tv and i'm like oh come on like no one's no one's gonna do that like if you can't do it from the couch then it's game over so i will say and i haven't tried this because

i don't have the accessories but to your point about a Bluetooth keyboard, yeah, that's one way. But these docks that they have, so they have, if you scroll down towards the bottom, they have this deck station and the decks pad. On these things, they actually have USB 2.0 inputs and USB Type-C ports. So my guess is you'd be able to plug up like a mouse and, and a keyboard through that as well. Now I haven't proven that cause I haven't, I don't own that thing. Like I just found out about it tonight,

but I might be buying that deck station because it's like, man, that's really cool. Like it was, you could truly still use your phone and be using the desktop experience over there. Granted, I don't have a 90 foot HDMI cable. So to your point, I'm not going to be sitting on the ground right next to the same, but, but, but no, I mean, I'm totally, I'm totally all in on this idea. Like I'm surprised that it hasn't happened because like there've been, um, you

know, Android devices have been playing around in this kind of concept for a long time. This isn't new. I mean, this goes back, you know, many years, right? Yeah. And I'm surprised that it hasn't become more mainstream. And I guess it's only because, you know, the processing power of the phones just hasn't become enough to, you know, sustain people's wants, right? Especially that, you know, when you consider that you're going to have to charge at the same time. And so, you know, the wear and tear that you you the excessive wear and tear that you might be adding to the battery life of that phone or taking away from the battery life of that phone. Yeah, it's it's definitely an interesting thing. And when I plugged it up, so I'm on my ultra wide. Right.

So it's 3440 by 1440. I think it went full screen. Up and down, but it didn't go out to the edges. Right. So there's definitely some sort of limit to what the resolution is that it'll support. I mean, like, am I really thinking this thing's going to drive a monitor like that? Yeah. I mean, basically, you got a 2K monitor, so it's fair that it's not going to drive a 2K.

I've got a 3K. No, no, no. That monitor's a 2K. That LG, those are considered 2K. I thought they were 3. Uh-uh. Because 2560 by 1440 is a 2K. I'm pretty sure that.

Okay, maybe I'm wrong. Whatever. Yeah. I thought that they were considered 2Ks. But yeah, it's a lot of pixels. That's the point. Either which way. It's a lot of pixels.

Okay, fine. If it supported, like I would expect it to be support 10 ADP, right? Like that, that seems anything beyond it's supporting 10 ADP. I'm going to be surprised at, right? But totally, if you have a Samsung device and you have something that will allow you to do USB-C to an HDMI, try it out. It's on your phone. It just starts up. It works. Like it was so cool. Anyways, it out. It's on your phone. It just starts up and works.

Like, it was so cool. Anyways, that's all I got. So that wraps my tips. All right. Well, with that, we hope you've enjoyed the show. Oh, wait. Joe, you want to do your favorites? Oh, yeah. My favorites? The tips? Yeah. Oh, wait. Joe, you want to do your favorites? Oh, yeah.

My favorites? The tips? Yeah. Okay, yeah. This time we did tips 34 and 44. So use exceptions for truly exceptional problems and don't program by coincidence.

Yeah, good enough. So with that, subscribe to us on iTunes Stitcher Spotify more using your favorite podcast app like I said before if you haven't already we would greatly appreciate the review it always puts a smile on our face you can find some helpful links at

www.codingbox.net slash review and while you're up there go ahead and check out our extensive show notes our examples discussions and more and send your feedback questions and rants to the slack because And while you're up there, go ahead and check out our extensive show notes, our examples, discussions, and more. And send your feedback, questions, and rants to the Slack because there's people there a lot smarter than I am. And you should make sure to follow us on Twitter at CodingBlocks or head over to CodingBlocks.net. We can find all our social links there at the top of the page.