Coding Blocks - The Pragmatic Programmer – Is Your Code Orthogonal?

Episode Date: May 27, 2019

The dad jokes are back as we learn about orthogonal code while JZ (the 8-mile guy) has spaghetti on him, Michael's Harry Potter references fail, and Allen voice goes up a couple octaves.

You're listening to Coding Blocks, episode 107. Subscribe to us and leave us a review on iTunes, Stitcher, and more, and Spotify 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 Coding Blocks, or head to www.codingblocks.net and find all our social links there at the top of the page. And with that, I'm Alan Underwood. I'm Jay-Z. Oh man, I was going to do I'm Michael Mizzle

or something, but now you messed it up. It's called back to the previous episode. All right. Well, I'm Michael Outlaw. 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. You can 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. Head to www.datadog.com slash coding blocks to see how a Datadog can provide real-time visibility into your application. Again, visit www.datadog.com slash codingblocks to sign up today. All right, and tonight we're continuing on with the Pragmatic Programmer book, and this time we're talking about two big sections, orthogonality and reversibility. Orthogonality, that was my favorite part of Harry Potter. What?

I don't remember that one. Oh. All right. So it's that time of the show where we like to thank all those that have taken the time to write us and leave us a review, leave some kind words up there. And so it looks like I have iTunes. So I'll start with this. I have not looked at these. So if there's anything bad in here, I won't know.

There's Marathon57. What is that about? Sometimes there is. Sometimes we have to filter some of these things, so I'll just have to do this all to fly. IndieIndian2019. Steve. R Holloway4. Ogre14T. Skometzker, Knack of Flying, and VikingsFan421. All right.

All right. And from Stitcher, we have Zach Ingritson, Lewis Hendricks. Oh, help me pronounce this. And Omnominus. That's pretty good. All right. I want to mention, too, that we're doing another book giveaway, so make sure to leave a comment on this episode. And I wanted to call out a particularly great comment that we got last time.

So, in my best Jay-Z impersonation here, I'm going to try and read it. So, thanks, Verso. All right, bear with me here. He said, I won't from being a masochistic, nihilistic, sadistic, and sometimes archaistic, but mostly acting autistic, deployments going ballistics, errors with no heuristics, went from simplistic to becoming a statistic, killed a server. Now becoming a little bit more altruistic.

Not so much egotistic as being euphemistic with a big dose of being pessimistic hoping to one day be a pragmatist. I loved it. There you go. That was my Jay-Z. That's not Jay-Z, man. That's Eminem. That's really good. Yeah, I was going to say the same.

Yeah. No, the 8 Mile guy. Jay-Z. That's not Jay-Z, man. That's Eminem. That's really good. Yeah, I was going to say the same. No, the 8 Mile Guy. Jay-Z. Oh, my God. Okay. Yeah, the 8 Mile Guy. Detroit represent. Okay. Yep. You got spaghetti on you.

It's okay, Rabbit oh that's amazing so yeah like you said we're doing another book giveaway so definitely comment on this that one was fantastic so um thank you for leaving that and uh coming up pretty soon i've got um redoing my kafka talk at the Atlanta Intelligent Devices Meetup. That's on June 24th here in the Atlanta area. So if you're there and you have a slight interest in Kafka and real-time streams and all that, come and hang out that evening. And we'll have the meetup link there on the show notes. And you all got a meetup for everything now.

We have lots of meetups up here in the Atlanta area. You got meetups for your devices, man. What the heck? All right. All right. So now we're talking about, was it Outlaw's favorite Infinity Gem, I think you said? Orthogonality? No, the favorite part of Harry Potter.

You don't remember Diagonality? No, the favorite part of Harry Potter. You don't remember Diagon Alley? Who? Nobody remembers Diagon Alley? Oh, gosh. So I was trying to make a reference to that, but it failed, obviously. Man, that was a stretch. Obviously it failed. A stretch?

I don't think it was that far a stretch. Okay. You know what? Never mind. All right. Start over? Show's over. We're done. Tip of the week. Here we go. So, orthogonality,

it's a geometric term meaning two things that meet at right angles, which means nothing to me. Can someone explain that better than I can? No, that's exactly it, right? Like, things that at right angles, the two lines that like form a square corner or something. Yeah, so in software, orthogonal is if it changes one thing, it does not affect the other thing, right? So then those two things are orthogonal.

Like, yeah. No overlaps. They're not going to intersect. They're orthogonal. Like, I guess the whole... No overlaps. They're not going to intersect. They're separate. Right, right. Like, I guess the whole idea is if you have, like, this T, nothing on this line is going to affect this other line. Okay.

And so, like, an example would be changes to a database doesn't affect the UI and vice versa. Oh, the book gave the example of a helicopter controls not being orthogonal. And I have never controlled a helicopter, so I'm going to take the word on it. But I guess the idea is like if you move this joystick a little bit, then maybe it's going to go up and to the left. And you move this other joystick and maybe it pitches forward and moves backwards. I don't know how helicopters work.

There's the two foot pedals plus there's the two hand controls, right? So you can't just – you have to move – everything's got to move in unison with each other. And that's why they're saying like you can't just change your left foot without also having to impact what your hands are doing or two. Like I don't fly helicopters either. So I'm speaking out of my something uh but based on the book yeah i'm more of a quadcopter kind of guy don't you have to imagine that your nose is always going to itch because you have to have both your hands on the controls and your feet are on the pedals like that's going to be when your nose

itches right yeah it's terrible and doesn't one of the controls on the helicopter like one of them's like a joystick kind of the other was like almost like a rotator kind of thing i think yeah i don't know it sounded really complex and that's kind of what their whole point was right non-orthogonal systems are way more complex than orthogonal systems right if if you've got to keep changing one thing to keep it working with the other then then you've got higher levels of one thing to keep it working with the other, then, then you've got a higher levels of complexity. Hey, just real quick on this whole helicopter thing though. Cause I'm like thinking back to like movie references here.

And I thought like one of them looked like an emergency parking brake. Oh, right. Like one of them, one of them is the joystick, you know, like your, your thrust master,

you know, gaming joystick, you know, and then the other one is like the parking brake so that you can drift the helicopter. And then there's the gas pedal and the brake pedal. Oh, man.

Forza in the air, basically. Well, that's for all the helicopter pilots who live their life one quarter mile at a time. This is another reference. Very nice. Oh, man. Hey, good news. We got to tip number 13 already. Like, last chapter, last episode, I think we did the whole episode. We got to tip number 13 already.

Like last chapter, last episode, I think we did the whole episode and only got to tip. We only did one tip. But we're already at one. And that is tip 13, eliminate effects between interdependent things. This is something we talked a lot when we talked about like – Between independent things. Right. Yeah. What did I say?

I thought you said interdependent. Oh, geez. That's the opposite. Oh, my gosh. Okay. Yeah. Totally different. But we've talked about this sort of thing in a lot of other episodes, like clean architecture is the one I think about a lot. Actually, I think about the 12 factor app a lot. That's something that I think about almost daily these days. Yeah. I mean, clean architecture was huge on this too, right? The whole point of creating

modules and components that had clean interfaces between them. And then that way you can change the one thing as much as you want. And then the only thing those other ones rely on are the interfaces, right? They don't care about the implementation of the underlying details. And that's a big one. Yeah. Like I've got a couple of bullets here and said design components that are

self-contained. Like, yeah, I like that. They have a single well-defined purpose that sounds pretty singly responsible. I don't think the solid principles were invented yet when this book came out. No, that can't be. Is it?

That can't be. It seems like that would have been a long time ago. I mean, this book is like 20 years old. Yep. And actually, the beta just came out. Oh, for the newest one? Yep, not that long ago. And you know what, man, getting back to this design components that are self-contained, like we've talked about this before, and I think we might have, or I might have gone on and ran on this previously, but that does mean creating typically well-defined assemblies, right?

Or if it's not an assembly, or if your language is Java, then a jar or whatever. But having those boundaries so that when you bring that thing in, it's the only thing that cares. You know what you're implementing. It's not like your logging is mixed with your database stuff. It's mixed with your application stuff. Like they're all separate and they have their own well-defined interfaces. By the way, I looked it up.

Pragmatic Programmer was released in 99, so call it written in 98. And Solid was first penned in 2000. Yeah, I was about to say the same thing. Yeah. I wouldn't have guessed it, but yeah. It was right there. They might have been talking to each other. Yeah, they were probably friends and then also too like one here one quick callback too like if you were you at you mentioned

the 12 factor app uh dang it now i don't know what the number was oh forget it we can't have nice things like for the episode number yeah i was trying to find the episode number but now i don't know what that is we should probably talk about the three-factor app soon yes that has been brought up yep was it dave that mentioned it i think i don't know dave i don't know yeah well i'll be gonna mention him later in the show so i don't want to i don't want to talk about him now all right fair enough save enough. Save it for later. Stop hogging the show, Dave. I'll find that episode number. Hold on.

Cool. So the next part we have is when components are isolated, you can change them without worrying about the other components. And that's really the beauty of it, right? That's when we talk about testing and setting those things up. If you do it in a way to where you're testing that particular component and it's exposed features, then you're kind of guaranteed that that thing's going to work without having to worry about, hey, if I change something over here, did it have some sort of trickle down effect? Yeah, I kind of wonder how I would have felt about this in 1999. These would have been totally new concepts to me, but now I feel like I listen to a lot of podcasts and videos. I don't know if it's so much experience. It's just the way we've talked about software has changed.

It has a lot. And it's hard too, right? Like the whole, the name of this book is Pragmatic Programmer. And this is where you kind of have to be smart in business, right? Like everybody, as you start getting better at your craft and you spent time in it and you see the pitfalls of some of the things that we've talked about over, you know, the various 106 episodes prior to this, it's easy to want to get into that perfect world. But we all know that that's really hard to do, right? Because typically you're writing software for a purpose, right? To serve some sort of purpose. And so you really do have to be pragmatic, right? Like take what you can build, build it as best you can, but know that you still have to deliver a product, right?

Like you could sit there and spin your wheels for years creating the most perfect piece of software ever. And, you know. Yeah, it's rough reading it. Like part of me wants to be like, you know, listen, book, you don't have to try so hard to convince me. Like I'm on board with you. I'm with you. Well, orthogonality is a good thing. But the other part of me is like, you know what, Joe, you still struggle with this all the dang time. So just read the book.

Right. Right. So one of the key pieces here is obviously if you change the external interface to your, your isolated component, then all the bets are off, right? Because you just changed the public signature and everything's going to have to change downstream from that. Hey, real quick, before we move on to the next topic here, just circling back to that 12 factor. So that goes back further than I thought, like way further back than I thought. We're in the thirties.

Yeah. Good guess. Episode 32 through 36. No kidding. Yeah. And that was before we did the How to Be a Programmer series, too. I thought that it was

after that, but nope. So if you're wondering what the 12-factor app is, there's the episode numbers that you can go back and hunt for. Very cool. Yeah. And it's still relevant. I still think about every single one of those things today, and I don't think I disagree with any of them. I think at the time

I was particularly skeptical of a few, but I need to go back. We need to revisit it soon. Let us know in the comments. A few primary benefits of writing orthogonal comments, comments, components. You get a productivity boost because you're not so tangled up in the other stuff

that needs to change because things are localized and development and testing time is greatly reduced because you don't have to worry so much about side effects. Simple components are easier to design than complex, large components. That's something I definitely agree with. It promotes reusability because it's easier to

reuse something that just does one little tiny thing rather than some big giant piece. Oh, there are others others when you have simpler well-defined components that they can be reused easily and that's what i just said in today so that's yeah it promotes reusability but they're saying that when you have the well-defined components that what they said and i can't remember the text now they said that it can be used in in unexpected ways so what they were kind of getting at, and maybe one of you guys can remember was, you know, you designed it with one particular purpose in mind, but because you designed it in such an isolated way, people are able to take it

and plug it into other use cases that you may be not even planned for, but because it's so well defined and designed, you know, people can expand upon that without worrying about it breaking anything else. Yeah. They get in kind of like to a math formula part with that, where it was like, uh, you know, in times in things can be created with your orthogonal components.

Yeah. Yeah. Uh, mentioned a slight predictor came to when you, uh, use two orthogonal components together, which, uh, I guess so. Yeah. You mentioned a slight predictability came to when you use two orthogonal components together. So I guess so.

Yeah, I'm guessing what they're getting at there was just when you use when you write a bunch of complex code, then it's a lot harder to work with. But if you're using two very simple components together, then orchestrating, that's probably not as bad. Well, OK, so here's the math formula that I was talking about. So they say, like, let's assume that you have two orthogonal components. One does M distinct things, and the other does N distinct things, which for the purposes of radio, maybe it'd be easier if I said A and B to make it a little bit more clear. So one does A distinct distinct things and the other does b distinct things and so now you have these two orthogonal components and if you combine them then the result set is a times b distinct things that can be done right so they're that's what they're talking about when you have this slight productivity gain when you use the two components the two

orthogonal components together if they're attached they only do one thing, A, B, AB, or BA. Right. I'm losing it. Also – Well, I was just going to say that it reduces risk. That's another one of the benefits to orthogonal components. You keep your bad code isolated, your system is less fragile overall, and it promotes testability, which that one's huge in and of itself. I mean, we've covered that one

countless times. You know, I was actually talking to our buddy Ryan Monster, and it's funny, until you get into places that have larger code bases or were several developers all working in the same code base, this might not seem as big of a deal to you, right? Like I know there's definitely been times when I worked on projects in the past that were my, I might've been the only, the only programmer.

And so tests weren't that important to me back then because it was like, man, I know this code. Like I know what it does. I know everything about it. Like I'm not worried about it, but as you get more cooks in the kitchen, that's when that stuff really starts to matter, right? Because everybody has different coding styles. Um, you don't necessarily know how all

the pieces fit together because you've had five or six or seven people working in the code base. And that's when this stuff really starts to matter. And that's what he said, you know, Hey, I didn't even think that this was that important until I started working with, you know, a larger group of people. And then, and then it's like where it lands on your radar is way higher than what you would have ever imagined prior to. Yeah, that's a good point. I was using a kind of larger tool earlier today and it didn't have some of the common options that I'm used to having in curl and it's so frustrating because I don't want the larger application to have to build in every little feature that curl has I'd rather just be able to use curl do my thing ignore my certificates or whatever and then kind of pass along the applications actually doing

the work so it was really frustrating and you don't want to have to reproduce all that stuff and you also don't want to be missing features that people are used to. So if you can leverage other programs to do work for you, then yeah, I totally agree with reducing risk and productivity boosting. There were a couple of points, though, that I had here that, you know, because there was the one point about that the orthogonal system will probably be better tested, right? So when we say that it promotes testability, in the book, they were saying like, Hey, it's probably, it's probably going to be better tested because it's easier design and run tests on its components because of the isolation, right? It's kind of where they're getting at. But then they also made this point of saying that you, you might not be tied to a particular vendor. Um, you know, so meaning that your coupling is smaller and more defined components, but I kind of made this like side note here in the book where I was like the the facade pattern i believe no no

no yeah the facade pattern where you were trying to like hide some other interface something else like like if you wanted to hide uh you know like a uh your specific database implementation right if you didn't want anything else to know that but but then whatever that bit of code is now, it's tied, it could be tied to that vendor that you chose to use for your database. And yeah, it might have some tests or maybe it doesn't because they're all integration tests instead of unit tests and integration tests. The frustrating thing about integration tests is they work great while you're writing the code and in it, but you know, you come back to it three years later and you're like, Hey, why don't these still work anymore? And it's like in it. But, you know, you come back to it three years later and you're like, hey, why don't these still work anymore?

And it's like, oh, yeah, because, you know, we don't keep up to date on the integration test as much as you do on your unit test because they're a pain. Yeah, I was just thinking about the A times B thing. Like when you say it like that and you think about the multiplication, like it's a really big deal. Like if I have one big application that does A and B, and it's doing everything that those two programs do separately, that's a hundred things I need to test.

If I, if each one does 10, if I break those apart, that's 10 things that each vendor or each program has to be responsible for. And who cares about the combinations? Because as long as they do their 10 things, great, that's all you need to test.

So I would say that it's probably easier to test things when they're smaller, more modular, but yeah, it doesn't necessarily mean that they are. There was another point here that I wanted to test. So I would say that it's probably easier to test things when they're smaller, more modular, but yeah, it doesn't necessarily mean that they are. There was another point here that I wanted to make too, which I thought was kind of an interesting way to, to phrase this because, you know, we said that it's going to reduce your risk because you're going to keep your bad code isolated, but their specific wording for it, I loved because they referred to it as deceit, diseased sections of code.

Right. loved because they referred to it as deceit diseased sections of code right and and they make this whole analogy of like hey if a module is sick uh it's less likely to spread uh if a sick if a module is sick it's less likely to spread uh symptoms around to the rest of the system you know if you're keeping it isolated right so um they just they make this whole analogy of it being like alive you know like you're going to transplant it and cut it out or something like that. I don't know. I thought it was interesting. Yeah.

They do a good job in the book of making the reading interesting and fun for a lot of these things. I will say this was probably my least favorite section though. Oh, really? Yeah. Every other section, most of the other sections have some sort of cool theme or some kind of novel way of thinking about things I thought was really neat. And this one I just kind of felt was retreading like similar concepts of things I've heard other places. It's not that it's bad. It's just like stuff that I felt comfortable with already.

So the helicopter went downhill for you pretty quick. Oh, but the helicopter was cool. I was going to say. If they had brought the helicopter back up a few times, then I might have felt differently about it. Well, I mean, what do you do? Where do you go from after boiled frogs and whatnot? I know. But I mean, in fairness, though, like you pointed out, this book was these were probably written before some of the things that you're referring to. Oh, totally. Some of the other books that you're referring to.

It's all good stuff it's all i agree with all of it so all right so how do we apply harry potter's favorite part of code diagonal diagonally no orthogonality so yeah one of them and this one's this one's sort of near and near to my heart because uh i've had people bring this up a lot in the past and it's project teams. You know, you can, if you split up your, your project teams properly,

then, then maybe you have a better, you have a better cohesion of these things. And they put it like, if you organize your teams in a well-defined responsibilities with little overlap, how do you do that? Right?

Is there a good way? I mean, I loved this point. It was like one of the, you know, it's always interesting to me like how we, the three of us will like highlight similar portions of the book, you know, to like bring to the table, like things that we want to discuss. And this was definitely one of the things that I was like, oh man, I love this, this sentence here where they're like, you know, uh, when teams are organized with lots of overlaps, members are confused about responsibilities. Right. And, and they were referring to it being an orthogonality issue there that the teams, if the teams, uh, are changing together, you know know all together at the same time and that's where this confusion comes in is like you know how do you start what is a good the best way to structure teams and i i think that that's just like a a problem i mean we we've referenced like um even in like the last episode we referenced the uh spotify um teams and, you know, how they broke, how they, or at least at one time,

uh, had their teams organized. Right. You know, I think this is this thing that like a lot of development teams struggle with is like, what's the, the best, what's the optimal way to organize the teams so that you don't have a lot of overlap, but yet how do you deal with communication problems? So, yeah. I really like that. I think a lot of books don't really talk about the team organization. I always kind of wondered about that. I've even read books like Mythical Man Month and People Where.

And I didn't think – at least I didn't remember anything really talking about how to, like, any strong guidance for how to structure a team. And so it was kind of refreshing to hear some thoughts on it. And I did like that they said that there's no great answer. Yeah. They did have a couple suggestions, though. And they talked about basically doing it kind of by layer or by application, so middleware, UI, database, or trying to do it kind of more vertical. But you know what sucks about that? And this is where it's always really frustrating, right?

Like if you have a bunch of specialized people, right? Someone that is nothing but a UI expert and a team of people that are just database experts and then a team of people that are middleware experts. And that's sort of easy to draw those lines, right? But then when you have what this book recommends, which is like more of the T-shaped developer, right? Like they even said, or maybe we haven't gotten to this point yet,

but I think it was in the last episode is, you know, they recommend that you learn a lot about everything, right? Be a jack of all trades type of thing. And for those people, it makes designing those teams a about everything, right? Be a jack of all trades type of thing. And for those people, it makes designing those teams a lot harder, right? Like if you're trying to slice things up by the layer, then you get a full stack guy and you're like,

yeah, you're just working in JavaScript today or you're just working in C sharp for the next six months, right? Like, and that's sort of a turnoff to a lot of people that are in that. Like, I think a lot of people that become the T shape developer or the full stack people, those are the ones that enjoy being all over it. Right. They want they say our preference is to start by separating infrastructure from application. So each major infrastructure component gets its own sub team. So they were thinking like, hey, all the DB team is over here.

All the middleware team is over here and all the front end team is over there. So they're not thinking full stack. And that got me to thinking like, when did the term full stack, you know, developer, when did that predate this book or did it come after like, which came first? No, but that's what I'm saying in this book. And I don't know if it was in a previous chapter or if, or if it's later in this chapter, they actually talk about, I think it was one of the previous ones where they said, be a Jack of all trades, learn a little bit about everything. Don't be I think it was one of the previous ones where they said, be a jack of all trades, learn a little bit about everything. Don't be, don't be one of those people that specializes. And that's, what's, that's, what's kind of odd to me is they're saying separated by that, but then that kind of pigeonholes people in, into one, in one particular, uh,

tier. Well, that's fine to learn it, but they're saying, as far as how the team is organized, you can go learn whatever you want, but your day job is like your JavaScript all day long, or your T-SQL all day long. There is no full stack dev in at least by preference now, preference as of 19 years ago. JavaScript was huge back, not really. Yeah. I mean, they, you know, that might have, they might have a difference of opinion then because I can definitely think back to that timeframe. And yeah, you know, I, I remember being on teams.

If you think back to like the teams that you worked on in 2000, the teams that I worked on were definitely structured like this. Like you just did, you know, if you were like a C or C++ or C sharp developer or Java developer, guess what? You were the middleware, 100% middleware. We had other people that would write the HTML and the JavaScript and the CSS. Like you didn't have to worry about touching that. Yeah. Do you want to know when the term full stack started kicking around?

I would like to hear it. 2008. Interesting. Yeah. So you want to hear something really interesting yeah i would so yeah 2008 isn't too bad the term web development was uh popularized in 2004 what but it was initially sounds wrong. But it was coined in 1999. Okay. But still, this book came from 1999. So, when this book was written, we were just deciding to call it web development. Okay.

That's interesting. Yeah, because back then it wasn't so much. It wasn't as much of application development on the web, right? It was more about websites back then. Yeah. So think about what DBA administration was back then, front and back work. Like things were very different. Yeah.

I mean, I can definitely think back to like when I first started hearing the term web application, I'm like, whoa, whoa, whoa, whoa, whoa, whoa. There's applications and then there's websites, man. Come on. Right, right. Come on. Stop this. You and your GeoCity site, you go over there it's at the corner and i mean like it was you know you go you rewind back 20 years ago and it was a different feel like the the front end guy didn't have the as

much of a role you know as as the other members or the other teams did. Not saying that they weren't important. Right. It definitely feels like it's been flipped on its head, though. Oh, for sure. I totally feel like when I first started doing stuff, people were like, the real programmers looked down at me because I was just doing websites. And now I'm

looking at the people doing ReactiveView like, hey, let me come to the party. I make stuff, too. Like, oh, Hey, let me, let me come to the party. I make stuff too. Oh, you're in C sharp. Get out of here. Yeah. That's awesome. So what I do want to point out, so we talked about splitting things up by layers.

You could do it more by features, right? Like we've had several discussions on the side about this before where, you know, maybe, maybe you have a customer service feature in your application, right? And you got an accounting feature in your application. You could totally split those up by, you know, functional teams saying, hey, you're responsible for all the customer service application, right? And you're responsible for all the accounting application. But I think the key here is, is when everybody's in everything, then it makes it incredibly hard to, it's not orthogonal at that point

because everybody's stepping on everybody's toes, right? Everything you do affects what I'm doing and et cetera on down the line. Yeah, that's a great point for, if you want to measure the orthogonality of your team, then you can basically look at the number of people required to make a decision. So if you need a company meeting every time you need to introduce a feature, then you're not very orthogonal. I love that measure, by the way.

Yeah. Yeah. Hold on. It started out with three people, and by the time you're done, there's like 20 people on the call and nobody knows what's going to happen after it. It's so hard to change when like 20 people need to come in consensus to it. It's just so much easier to stick with the status quo and not actually change anything or do anything differently. Yep. Stuck in the mud.

All right. So talking about design, layers to only be coupled by the abstractions below it. So the idea is like the front end is only going to talk to the middle layer, middle layer is only going to talk to the back end. And they didn't say do abstractions above or below it. They specifically said below. Which is nice, but when I think about things like signal R,

long polling, whatever, push-pull, I think those rules are a little kind of iffy. So my definition, I think, in a perfect world, it involves a little bit of iffy. So I kind of, my definition, I think in a perfect world, it involves a little bit of back and forth. Like I'm okay with the DB job that he's called C sharp and vice versa. I'm okay with C sharp pushing stuff to front ends.

See, I don't know, man, I'm kind of more on board with this because this goes back to clean architecture where they say that your dependencies should, uh, your one direction, one flows out and the other flows in.

You know what I mean? So it's one of those things where you inject the things you want and the dependencies are actually kind of going outwards. And I like that because if you have that level of direction in your code, then it really does make it easy for the stuff to be decoupled. Right. So I don't know. I like it. I totally agree that when you, when you start talking about some of these other technologies like signal or something like that, it makes it a lot harder to, to draw perfect lines. But I like that. There was a comment though, that I felt

it was a little late in, in this portion of the book though, where they they were talking about like most developers are familiar with the need to design orthogonal systems. And like, you know, when you start this chapter, you're like orthogonal systems. Like, what is this about? Orthogonality. Right. And they say, look, you're familiar with the need to create those. But we use words such as modular or component based or layered to describe it. Right.

That should have been the first sentence. Right. That's my point. Like, you know, you're like, OK, it. Right. That should have been the first sentence, right? That's my point. That's my point. Like, you know, you're like, okay, good. Yes. Now, why didn't you say that to begin with? Hey, show of hands here. When anybody saw the word orthogonal, did anybody know what they were talking about?

It's one of those words I feel like every time I read a book like this, like every couple of years, I like look it up and kind of get it and then move on and forget about it. Okay. Yeah. Good. I honestly was like, Harry Potter. All right. Good.

We were all in the same boat there. It's almost like for a long time, every time I heard heuristics, I was like, huh? Yeah. Go Google that. I finally Googled that one enough to where I can use it in a sentence without anyone hitting me or calling me on my crap. So there was a, there was a really awesome test, an easy test that they gave for deciding if your design is orthogonal. All right. So if you have to dramatically change the requirements behind a particular function or module,

how many others would be, how many other layers or modules would be affected, right? The answer should be one. Now, how realistic is that? You know, I mean, even they point out in a footnote that the reality of this is naive. Yeah, it's good to have a plan. It's a good target. It really is.

And if you have it abstracted properly, then that really kind of is it, right? Yep. Is it? I'm not saying it's perfect. Is it possible? I don't know. For a trivial app, sure. Yeah, that's the thing.

Yeah. If it's buzzed, no problem. A good thing to keep in mind. Toolkits and libraries I want to mention, too. And this is another thing. I bet this has changed in the beta. I really want to get my hands on the beta because I bet the word framework is going to be in here because that is such a big thing to come around in the last couple of years that isn't so much around at this time, 1999.

So the idea is you just want to try and isolate those libraries for your own code. And that was a lesson I really could have used in 1999 that I definitely didn't. So the idea is just that an update to the library shouldn't require you to change the signature of your interfaces. And we've talked about this a little bit before, like how likely certain things are to change.

But it's really hard to predict the future. And if you can just do things like this, not only is your code, if you can keep those third parties out into like a humble object, keep your logic that's unique to your domain in one spot, then not only is your logic more testable, but you're also insulated from changes to those third parties, which does happen sometimes. Sometimes really big ways, too. Man, this one's so hard for me because I can't remember his name right now, but he actually commented on the episode where we talked about that abstraction where it was like, hey, you know, save was a method. Right. And, and it was uncle Bob Martin talking about how he had, you know, they, they delayed their decision to the very end and then they had it to where it was just a file. Right. But it didn't matter

because it was an abstraction. Right. And then somebody wanted to come in and do a MySQL driver for it later and they could do it. Right. My biggest problem with this, and, and I probably lean more on the opposite side of the fence now to where it's like, if you chose a third party, you probably chose it for some particular reason. Right. Um, I don't know what that reason is like SQL server. If you chose SQL server, it's probably because your company's using a lot of SQL server. So should you be coding to an abstraction? And this is a hard one for me, right? Because there is a lot of features Server. So should you be coding to an abstraction? And this is a hard one for me, right? Because there is a lot of features in Transact SQL to make it faster, more efficient, easier to deal with, whatever, right? And if you go to Oracle with PLSQL, they've got a lot of

features that make it easier, faster, whatever. If you're coding to, in the case of we're talking about databases right now, if you go to ANSI SQL, like you are coding to a very subset of what's available to either one of those platforms. And so you're probably writing a lot of code that's inefficient, that is not going to be all that easy to follow.

And it's like, man, should you really be coding to that abstraction at that point? Or should you leverage that third party that you chose to use? And that's a big decision. That's one that you can't take lightly, right? I think the thing is, though, because you're speaking to my pains right now that I'm dealing with, In that situation, the ideal here is that nothing would know whether it's Oracle or SQL Server or not. And then the question becomes, okay, that's a huge task. How do I take advantage of those features of SQL Server or Oracle or whatever your system might be, MongoDB, whatever, but at the same time not let my caller know or be aware of the specifics of it, right?

So that means, for example, the caller can't be passing in any kind of specific query because then they might write like T-SQL, for example, like you you know, he, the caller can't be passing in any kind of, you know, specific query, because then they might write like T SQL, for example, like you mentioned, right? Like they might write a query that won't run under Oracle. So yeah, I mean, it's, you have to draw the line where it's like, okay, that, that repository can take advantage as much as it can. But other than that, you have to trust to let it do its thing. Yep. Right. And I think this is where like the models come in, you know, like if we go, if we, if we kind of mix in some worlds here, right. We mix in, uh, uh, domain driven design where the model might know how to best read or write itself or whatever, or query for itself. And, and,

you know, using some kind of pattern, it might be able to take advantage of that. I don't know, even as I say it, I'm like, no, they probably, it probably shouldn't. It should be abstracted there. But like, I, here's, here's an example. And I think Joe might be able to speak to this a little bit better because I know he's been involved in a certain project. But it's like Elasticsearch, right? It is one of the things that they have done with Elasticsearch that has kind of helped it grow amongst the various search engines. Is this aggregation functionality is amazing compared to a lot of other search engines out there, right? And even compared to a lot of other search engines out there, right? And even compared to like databases. And so the thing is, if you're writing your code based off a very stripped down search engine,

like let's say Cloud Search from AWS or Azure Search, you're going to write your code a particular way, right? But if you know that Elasticsearch is going to be the product that you're using, you're probably going to go ahead and take advantage of some of its ability to aggregate and bucket things for you. And so the way that you would probably write your implementations would be very different. And even knowing how to call that kind of stuff, like just knowing how Elasticsearch does it, you'd probably say, hey, well, I know that my objects sort of need to be formed this particular way in order to take advantage of it. Whereas if you were just coming from a straight background of maybe SQL or even Azure Search or something like that, then you might have a very different approach because you're going to be like, well, I'm going to need to two or three pass this thing.

And that's what I'm saying. It's really hard to say code to an abstraction because now you might be throwing away a lot of functionality. Yeah, and I want to mention that was Paul Spoon that brought that up to us and kind of talked about kind of how we discussed this before. And I think his point is still really valid is that he was saying that you should try not to think so much about replacing a whole tier of the application because ideally the interfaces that you write around that third-party service are going to be more about the way you're using them. And so you're not trying to swap in Elasticsearch for a database. It's not usually a one-to-one replacement for third parties.

A lot of these things are kind of built around your business needs, so it should be domain first. And then the way you interact with those third parties should be governed and interfaced around how you're using them. So in the case you mentioned, though, that is also still valid because, you know, what we've seen with, like, depending on the tool, GraphQL is another one. Like, if you're swapping in GraphQL for a REST API, now you're replacing what may have been five or six different calls at like kind of different layers in the logic with one big call to GraphQL. And so that's a case where you might have to reorganize your code around a tool that's got a special ability. And if you were to go back to REST, then you don't have that ability to do one big chunk. And so, you know, you'd have to kind of rearrange how you do things a little bit. So ideally, in a perfect world, everything is going to be driven from that domain first,

that domain-driven design, and then kind of fall out from there. And if you can kind of get away from that idea of the end-tier application, which is something that clean architecture is really pushing for, then I think there's going to be some benefits there. But man, that is hard to do. And here's the thing, though. And maybe this is just my misfortune, but I have yet to be in an environment where it was domain driven first yeah like ever in my career like it sounds

amazing and i want to do it it sounds awesome right like you know i've seen you know code that that does follow it i've i've you know watched courses on it, everything, and tried to incorporate that in some of my stuff. But overall, big picture for the code bases I've been in, that hasn't been the reality. Yeah, the reality is typically more along the lines of your middle tier is a pass-through for your data storage tier, right? It's forming stuff that your storage tier knows how to interpret. I wouldn't even say it's that specific. No, every place that I've been in, it's just, you know, you have management up above.

It's just like, oh, we want this done. And, you know, you get this amount of time to do it. Yeah. And that's it. It sucks. I mean, there's no doubt it sucks because I think ultimately, and this is, it's so hard to prove, right?

This is, this is probably, I guess for me, I'll have a little soapbox moment here. The one thing that frustrates me the most about software development is as people that have been doing this for a long time and anybody who's listening that hasn't been doing this for a long time, just look back in a few years and you'll realize that this happens is you'll know in your heart that what you're about to do is wrong because you know, it's going to introduce pain. It's going to introduce a longer development life cycle when you just start doing things fast, because they say that you're under time pressures. And you know that if you had put in some tests and you know that if you had separated this thing out and like a domain driven type design thing that you'd have these

well oiled, well running things that are fully tested and all that kind of stuff. And ultimately in the long run, you'd save yourself so much time, so many regressions, everything, but you can't prove that out, right? Unless you do it. And unless you were able to take that same project, do it in parallel and say, Hey, team one, go over here and do this the fastest, crappiest way you can possibly do it, right? Get it done. Team two, I want you to go over here and take the test driven approach. And I want you to break these things out into well-defined domain models and do everything. And then at the end of it, let's see who finished faster, right? Chances are the crappy team's going to finish quicker.

But then when they come in and they say, okay, now we want you to add this feature to the product. What's going to happen is I think you're going to see that team two is going to start pulling away and they're going to have a more quality product. And it's going to start happening faster at that point. And you can't prove it. And to me, that's the most frustrating thing is you could talk about it all day long to management and they're going to be like, yeah, I don't care. Get it done. Right. But you know that you're looking down the road just even a month out from when you're starting and you're like, man, we're going to be right back here. Yeah, we're going to get the feature done in a month and then we're going to be right back here. Yeah, we're going to get the feature done in a month,

and then we're going to spend the next three or four weeks trying to figure out how to fix it, right? And that's so frustrating, and it's hard to get past. I just took a Google around and said, what are some good examples of clean code in open source? And the number one result on Google is a link to Quora, which has zero answers. did not zero i just tweeted it but i also i looked at a couple of the you know the ones all the way on page one

and for the most part like people are saying well there's not really we can point to sections we can point to trivial apps but it's really hard but so it makes me think that like maybe it's just super hard no one's quite doing it right because everyone has deadlines but then i I thought the high scalability blog, we've talked about that a few times. I don't know about seeing clean code, but I've seen some really nice architectures where I can look at a system and say, oh, that's really well done and it fits their needs and that looks good. And it's small enough because of the diagrams and surfaces. I understand how they work, that it makes sense to me. So that's been really nice and like if i look at the diagrams and stuff for stack overflow how they set things up like okay this is really nice clean design everything makes sense but when it gets to the actual code level like oof right and

i and i'd even imagine even these these high level designs are beautiful but i guarantee the devil's in the details right like all all the little things that have to happen in every single box that's drawn on a diagram. There's a lot of man hours wrapped up in, or woman hours, wrapped up in making all those things work, right? Well, it makes you wonder, if we can't point to one example. I mean, that Quora answer, there's no idea how long that question has been out there, at least that I saw. 2017.

Oh, was it? I didn't see that. Okay, fine. So is this all just a pipe dream then? Is this not really a real thing? Does this not really exist? All these books that we read that talk about this clean code, clean architecture, and domain-driven design, and it's like, well, yeah, on small projects. Sure. That works great. But in big teams, big projects, no way is, is the source code for windows just a mess?

I think coding is just a mess on actually, but I do think that there's a lot of value in trying to understand it. Cause I do feel like I can write better code and the things that I know and have learned helped me write better code because I've seen some mild code. Trust me. It's way worse than my current code because I've seen some mild code. Trust me. It's way worse than my current code, which is also terrible. Yeah.

Man, I just found something on Y Combinator that I'll include in the show notes here that somebody asked the question, what are examples of GitHub repos with high quality code? And there's some links to some good stuff here. So, you know, it's actually a pretty long thread. Like projects that we would know? There are some listed. Like there's one here. I haven't heard about this one before, but it's aosabook.org. That's one.

But then GitHub slash Golang is one that people are saying is pretty good. So, yeah, I don't know. I mean, it's probably worth clicking through some of these and just seeing if it truly is a pipe dream. I think the architecture point is kind of interesting, too, because it kind of makes me think like, okay, be messy, do your best, try hard to keep it clean and fail, but try to fail small so that it can be this composable little orthotical little units that can ultimately be arranged in a little orthotic little units that can

ultimately be arranged in a higher level diagram to make sense and so what if things are a little bit messy and each of the individual pieces if you can keep this stuff modular and reusable and as long as this stuff does its job it works it's tested then you're doing all right yeah they actually pointed out as like uh aspect oriented programming as a great example of orthogonal uh code because you could implement like for example you could implement logging throughout your application without actually touching it in your code so we i know we've talked about this with like um post sharp for example you can with post sharp has this really cool feature to where you can apply an aspect at the namespace level. You can just say, Hey, every class in this namespace that I don't

even own, it might be like system dot drawing or, you know, just system. Right. And, and you could apply some, some method, some aspect, you know, method to it, uh, to everything in that, which is an amazing thing, right? And that's a prime example of orthogonal. You know what's funny? Oh, go ahead. No, go ahead. You know what's funny that you bring up the AOP thing? It wasn't too long ago. I was actually, I go through these cycles where I'm like, there's got to be a better way, right? Like, after you've been writing a method and you've got 20 debug outputs in there and you're like, this is awful. My method is 20 lines long and 12 of those lines are debug calls, right? And I sat there and that day I was like, okay, I got to Google this. There's got to be a better way to do this. And there's not, right? Like truly the only other thing out there is aspect oriented and that gets you half of the

way there, right? Like you could have an entry level debugger and exit level debugger and a midpoint type debugger. But all those things were like, you're trying to create timers around one particular thing, unless you were to break up your method into multiple other little methods that you could log those. But it's just, it's amazing to me that I'd venture to say on a lot of code bases out there, there is a lot of crap code for just cross-cutting concerns. A lot of it. Well, one could argue though, that if you needed to time individual pieces within your method, that maybe those individual pieces should be individual methods. And, you know, I actually thought that too, but in some cases, not really, you know, I mean, it really depends on how complex the thing is, but it's just, it's funny to me that

all these years later, like people have been logging since the beginning of time, and there's still no good answer, right? It's just ugly, useless, not functional code. I mean, to that regard, though, it's amazing. Logging has existed forever, and yet it's not like there was – okay, for those of us, for the.NET listeners who are listening, it's not like there's a built-in, you know, system.logging namespace that we use. Instead, we all use log4net. And same for Java developers, right? Like, you know, it's not like there was a Java when built into the framework to the language that that's the de facto one that you use. No, you go download like log4j or Siri log or something else, right? Like it's not, you you know but here's this common thing that's

been there forever and it's not the language then the framework doesn't provide for it not the language the framework but i didn't want to like point out there was one interesting point on the the design uh piece you know just rewinding for a moment, where they were talking about like, don't rely on properties. Don't rely. Wait, let me say this right. Don't rely on the properties of things you can't control. Right. And they were talking about like, if you were to use a telephone number as a customer identifier, right? Well, what happens if the phone company reassigns the area codes, right? And it got me thinking about like, oh, well, here's like a real world example that everybody could probably relate to.

It might be a few years dated now, but you could easily envision like, okay, in this logging example, right? Let's say you are logging events that are coming in and you're using the IP address as the identifier. Okay. Well, we went from, you know, a few years back, we went from IPV4 to IPV6, the whole format of the ID just changed. Right. So if you had, if you had in your, you know, if you designed your system so that you were expecting, what would the maximum be? Like 15 characters long? Maximum for an IP address? Is that right?

Sounds right. So if you design your system with that being the maximum length of it, well, guess what? Your world got rocked when you switched to IPv6. Right. Hard to see some of those things coming. IPs are such a pain, too. If you even converted it to a number to store it, like, good luck storing IPv6. Well, but again, the point, though, is like, yes, you're right, Alan.

You can't predict that that's coming, right? Right. We can't even predict. IPv6 is still so new to us that we can't even imagine a V7 or eight or nine or whatever. Right now, you know, it'll probably happen. Right. But, you know, the point is that they're making here is like you can't control it. So don't rely on that. Right. And in this specific example, they're saying like you wouldn't make that your identifier because you can't control it.

Yep. That makes sense. And heck, even if you go back a little bit further, right. IPs used to be static. And then they realized that, you know,

Oh, well, well, we have a lot more people coming online now. So, so now they're all being dynamically assigned and you have blocks. So yeah, it's even changed within that.

So, I mean, it wasn't, but like maybe 10 years or less though, there used to be entire blocks of within that. So I mean, it wasn't but like, maybe 10 years or less, though, there used to be entire blocks of IPS, it was like, oh, this isn't a public block of IPS. And then suddenly it is like, I remember like the five dots, you didn't used to be public. And there was a VPN service that they used that as their workaround of how they would, of how their system could work.

Right. Because they knew that, Hey, you know, this isn't a publicly routable IP address. And then suddenly it was, and now all of a sudden their system was broken. Yep.

That's an argument against natural keys and databases too. It kind of is, which really stinks because that's, that's a whole episode on its own, right? Natural versus surrogate keys. Good luck winning that battle. And that's the point. That's honestly the point that they're making here and why I thought it was interesting to call out, though. Is it like they're really saying, like, you shouldn't rely on it.

I'm sold. Make everything strings. Pragmatic program or JavaScript. It's all UUIDs, man. That's everything going forward. Yeah, I don't need tiny n's and longs. Just give me a number. Number and string. Date. Done.

It's on coding. So every time you think you write code, you run everything. Every time you do write code, you run the risk of duplication, which requires attention to detail and duplication. I think we've talked about it a few times, even like I think last episode, right? So we won't spend too much time there. Just know that there's, you know, there's real duplication where you're duplicating the idea. And there's also a coincidental where it's not really the same thing. It just looks that way. But just try to write less code, I guess, is the message there.

Yeah, I mean, and I don't think I called it out in the show notes exactly perfectly. But they said every time when you create that duplication, you're reducing orthogonality, right? That's the whole point is every time you write a piece of code, you're potentially making it less orthogonal. Yeah, and if you can keep your code decoupled, then you're a friend of the law of Demeter. So I always forget that one too, but the idea is just to write shy code. So only the classes that are close to you should be able to know really

anything about you. So you don't want to expose anything that, that need be and object state changes should happen from the component being used, not your use of the component, which I like. So you should be managing your own stuff. Nobody else should be managing your business. That goes back to your domain driven design thing outlaw that you liked, right?

Like having the aggregate root or whatever that that is the only thing that can touch the state of that object. Right. Basically, what we're saying here is you shouldn't be able to reach in and change the length of some sort of shape, right? Your changes to the shape by calling, you know, set width or set height or whatever should give you the area. You shouldn't be able to touch that crap yourself. Right. So it's not the length. The better way to phrase that would be not the length, but like you can't directly set the area, but if you can call a method to set the length or set the width, and then that would force a recalculation of the area is what we're doing. Set length.

You're right. No worries. Yes. But I wanted to clear that up in case anybody was listening that might not have heard the previous episodes or where we've used that kind of example before. We would have gotten a lot of comments about it being wrong. I shouldn't have said it. I should have just let it go. Yeah.

So a few other tips here. We got avoiding global data, which is something we've talked about a few times too. Sharing data globally just causes problems. It's better to pass that stuff around in a component so it can kind of stay contained. Also reduces tight coupling to a particular implementation,

which is always nice. We talked about that with the I and solid, the interface separation principle. Be careful now. Easy. This one's going to hurt right here. I can't say it. I think we need to let Outlaw read this one. No. It's got something to do

with his boy. We could just not talk bad about singletons. Ah, Jesus. We can manipulate the ears of our listeners. Yeah. Have undue influence on programmers around the world. You know, yeah, this design pattern is the only thing that I like to joke about it, right? But it's just like, I feel like this design pattern gets the worst of everything.

But so they say that you have to worry about singletons because they're basically a type of global variable in disguise and that, you know, it can create type tight coupling, but which I get, I mean, I understand where they're coming from with that. It's just,

it is. I mean, that's really what it is. I mean, I still like singletons. If you, if you've got dependency injection going on then man i don't care create all the singletons you want as long as you can manage them there and manage their life state so their um their life length what's the word their life cycle

the life cycle from outside. Yeah. The, my point though, with the singletons is that as long as like, I get a lot of the, the, you know, the, the, the, the negativity that the pattern gets, right? Like you can totally abuse it just like you could abuse anything else. Right. I mean, that's why there's the joke about the, the hammer factory, factory, factory, right. Um, you know, with the joke about the factory pattern. Um, but there are definitely places where it, it, it is necessary. So like the example that comes to mind for me is like, Hey, if you're writing, you know, if you wanted to create a logging framework, right, then you only want one thing to actually have the handle to that file. Right. So, you know, there are limited, you know, special cases where, you know, you, you do need that

singleton. Um, now whether or not it creates a tight coupling to it, see, that's the part where I'm like, well, it doesn't have to know what the implementation of that is, right? Like if you have, if you have your, your logging singleton, it doesn't have to know, like your code doesn't necessarily need to know that it's being written to a database or to a file or, you know, to a queue or to whatever, right? You don't need to know that. And the same, like another one that comes to mind might be like a caching system, right? Like you, you might only want one entry point because you can't like, I'm trying to imagine like how would a cache system work if you actually were able to, if you let it spin up, like, Oh, I'll, you know, every time you call it, I'm going to spin up a

new instance of the thing. Like, well, that's not going to work. Right. The whole point is you have like the thing, the one memory spot for it. Yeah. I think the answer to avoid that kind of stuff would be using DI or some sort of dependency injection. Right. Because really when you're doing singletons, you're typically doing like a service locator pattern, but you know, I agree. It's not the worst thing ever. Right. I mean, there, there's probably patterns to get around it that are maybe a little bit better. But definitely, it's the abuse that most people do of it where they're just like spinning up a bunch of global variables is really what they're doing. Well, I guess here's the takeaway of them maybe. Because like both the way you put it and the examples that I gave, we were describing like it's encapsulating some type of a service

for the caller, right? And maybe in that world, it has its place and it's okay. I'm not saying that it's the only way that could be done, but it might be a good way of solving that problem, right? But if you're using it as they phrased it here as a glow as a kind of global variable if that's all it is then yeah that's bad right i think we could all agree on that yeah a boy single 10 survives another day just barely so they mentioned here here avoiding similar functions. It's kind of the same deal there with things that need to change. When one thing changes and you have to change multiples, not orthogonal.

And they also mentioned looking to a strategy pattern, which I'm a huge fan of strategy. I don't do enough of it lately, but I'd like to get back to it. I'm looking for strategy problems. Let me know if you got one. Oh, man. You're going to get plenty. Yeah. The looking for strategy problems. Let me know if you got one. Oh, man. You're going to get plenty. The template pattern, too. Of course, the Hollywood pattern, also not as

like, don't call us, we'll call you. I like that. Be willing to refactor your code. I think that's more for the management and not so much for the programmers. I don't know. I can be pretty lazy sometimes. Yeah, I think this goes back to the Boy Scout rule.

Just do the best you can while you're in there, right? Like, if you have an extra hour that you can sweep under the rug, do it. Have you heard the old adage that you shouldn't visit the doctor in the afternoon? No. I actually just saw an article the other day.

I think the idea is that doctors just get kind of tired. They lose a little focus. And so by the end of the day, they're less likely to catch stuff or they're more likely to make mistakes with prescriptions or whatever. So it's kind of like the same thing. It's like maybe you should try to write your most important code early in the day before you get all disgruntled and meeting doubt. But then what if the doctor stayed up too late the night before and then he's tired the next morning? I feel like it's a no-win situation.

You're going to die. One way or the other, you go to the doctor, you're going to die. That's true. All right, so we can't go to doctors anymore. That's right. That's the takeaway. Singletons can be used sometimes and don't go to the doctor. Don't go to the doctor ever.

Oh, yeah. Lunchtime. I found the article. They call it decision fatigue. It's one of the explanations they gave for some of the mistakes that they found that were happening as the day wore on. I can believe it. I mean, it makes sense. Couldn't that be said of every job, though? Yeah, pretty much.

Well, that's funny. They're talking about the same thing with car salespeople and judges that all the studies keep showing up. Decisions get worse as the day goes on. I was actually going to say car sales is like that's when you should go buy your car then. It would be late at night, right? Is that what the decision was? Yeah. Okay.

Yeah, they just get a little bit more lax and they just want to sell something and go home. It's closing time. You walked in five minutes before the place closes. They're like, I'll sell it to you for whatever you got. If the song Closing Time is playing, you're there at the right time to buy your car. That's awesome. Probably not.

Probably not. That's a pretty rockin' car sales place. Rockin'? If it's playing Closing Time, that's rockin'. Alright, Rabbit. Alright, that's rocking. Yeah. All right, Rabbit. All right, Rabbit.

We hear you. Yeah. So we touched on this earlier. Orthogonal systems are much easier to test because you've got these things componentized, smaller, more focused. You don't have to test all the various combinations. You just test those pieces and you trust that it works better together. Although we've also seen those things on twitter whatever those pictures were like you test pass and then you can't open the door or whatever because something else you know each piece works

fine but not so well together bug fixes are a good way to identify the orthogonality of the system as well does a simple change fix everything or do you have to sprinkle changes throughout the code base now this is i thought was really interesting here's one thing I didn't think to look at recently. I grabbed the source code for dev.to and I imported into Elasticsearch and I had necessary records so I could tell with each commit, whether it was like a bug or a fix or, you know, feature and how many files were changed. It'll be interesting to say, hey, let me take a look at the bugs and how many files were changed per bug. Because that would kind of tell us a little bit about how well our system is doing.

So I just thought it was kind of an interesting metric I've never heard anyone really talk about before. Yeah, that's pretty cool. I thought, though, it does seem like it is similar to something that we have talked about, though. Like Indipend? Like, independ? Well, no. I mean, definitely the one that comes to mind is the Google research where they were showing, like, which files changed the most are the ones that likely had the most bugs in it. But it seems like we have talked about something similar before. And now I'm losing it. But whatever. Yeah, this is slightly different because this is more along the lines of for one bug, right? Like there's one ticket. How many files have you changed for it? And that is kind of an interesting metric. I mean, you would

hope to see one, maybe two. But I don't know. Yeah, we'll have a link to that study in almost every episode because it's just so cool. We'll have it here too. Now, here's an area that we never bother to think of when it comes to our code, and that's our documentation. And with orthogonal documentation, you should be able to change the – wait, I'm saying this wrong. We should be able to change the look without that content. What?

Yeah, so this had to do with style sheets and stuff. Oh, right. Change the appearance dramatically without changing the content. Right. So basically, the style of it shouldn't be tied to the content, right? If you're a web developer, you're probably pretty familiar with this, right? Put all your stuff in divs, and then you can make web developer, you're probably pretty familiar with this, right? Like, yeah, put all your stuff in divs and then you can make it look however you want.

And heck man, put it in markup and suck it in when you're jam stacking and you can arrange it however you want. Oh man. All right. Uh, developing orthogonal and dry components make for more flexible, testable,

understandable and easier to debug systems. Uh, if we say yes, are we at yes, yes, yes? Wait, say that again. Developing orthogonal and dry components makes for more flexible, testable, understandable, and easier to debug systems? No.

No, you don't think so? No, I'm just joking. All right, we're yes, yes, no. I was just making sure you're paying attention. From the top. Yes, yes, yes. All right. Now, wait, just real quick.

Going back to that documentation, though, have you ever done that with your documentation? Have you read it or looked at it ever again? No. No, no, no. Where they were saying, make your documentation orthogonal, too, to where you can just change the look without the content. I've never had a style sheet for any of my documentation. No. But I,

you know, if you're using some sort of document generator, like swagger, well, okay. I'm not counting. You could make it prettier. I'm not counting that.

I'm talking about like, you know, usually documentation is either going to be in a wiki or, you know, I do, I do mark down, but you're, you're not in control of how that presentation looks.

Right. Yep. I love Markdown. There's no way to center images in Markdown, though, is there? At least not in like vanilla Markdown. Centering images in YouTube embeds are like the two things that I wish Markdown had. Side note. Once again, we've got

challenges, so I think these are going to be pretty easy. So they say first challenge is which is more orthogonal? A GUI-oriented Windows tool or a Bash command line utility? Bash? Yeah. You can just pipe those

things together. I thought it was pretty obvious, but yeah. I assume you're pretty obvious, but yeah. I assume you're on board with that, Allah? Yeah, yeah. We got another one here. So C++ supports multiple inheritance, but Java and C Sharp support multiple interfaces. We've talked a little bit about the difference between those two, but do you have any opinions on which one might be more orthogonal than the other? Interfaces.

Yeah. Yeah, totally. So I thought those were both pretty obvious, but I just thought it was kind of cool to look at two examples of things that, like, oh, hey, bash utilities are much easier to chain together and use together than Windows Util. I'm like, yeah, Java and C Sharp kind of went away from multiple inheritance because of these reasons. So it was just kind of nice to see like, oh yeah, that's

orthogonality even though I didn't know the word. But wait a minute, we're skipping over the why. Why do you think that the C Sharp or C++ multiple inheritance is less orthogonal than the multiple interfaces that languages like Java and C Sharp support? Well, it changes the parent and changes other things, behavior, right?

So we've got things that are, you know, possibly in totally different, separate, whatever, just inheritance in general, I think is pretty nasty and not very orthogonal just because by definition, anytime you change one thing,

you're changing some other class, right? So you're changing, you're changing implementation in other classes that you might not intend to be changing. So this is where we talk about favoring composition over inheritance. Yep. And that might not even be in your DLL. It could be in some other executable. It could be something you have no way of knowing about. It might not even be something that, like, if you're just writing the library right and someone else is using your library it might not even mean code

that you even know the person yeah the C++ have sealed or like a final type thing where you can prevent it from being inherited outside of my wheelhouse yeah it's been so long like well now with like you know the later versions of C++ maybe

let's see yeah to the Google Well, now with the later versions of C++, maybe. Let's see. Yeah. To the Google. Looks like the answer is kinda. There's actually a stack overflow for just this. There's a CX extension for C++11 that has the final keyword to support it in Visual Studio. So maybe if it's Visual Studio.

So is it a syntax, syntactic sugar type thing then? I don't know how they would enforce that. I mean, it's definitely not a standard C++ thing. So I guess the answer is like mostly no. And maybe if you're in some specific library, like in this case, you know, Visual C++. This episode is sponsored by the O'Reilly Software Architecture Conference. What sets the O'Reilly Software Architecture Conference apart is that it's the only conference that focuses exclusively on software architecture and the evolution of that role.

This conference is in the weeds with tech that covers complex topics from microservices to domain-driven design. It features different styles of learning from 50-minute sessions to two-day training courses. The O'Reilly Software Architecture Conference also focuses on soft skills. O'Reilly knows that architects are having to communicate complex technical topics and their merits compassionately to both upper management and technical teams. This conference can help you navigate different communication styles like in the architectural elevator course. O'Reilly knows how siloed software architecture can feel. At the conference, you'll have countless networking opportunities so that you can meet people who are working on the same tech as you and can offer personal experience and learnings that you can apply to your own work. Many of the attendees

are either aspiring software architects or doing the work of a software architect without the title. The conference offers a special networking experience called Architectural Katas, where you get to practice being software architects. Attendees break up into small groups and work together on a project that needs development. Visit O'ReillySACon.com slash blocks20. That's O'ReillySACon.com slash blocks 20 to sign up. And listeners to this show can get 20% off of most passes to the O'Reilly Software Architecture Conference when you use the code blocks 20 during your registration.

Once again, that's blocks 20 B-L-O-C-K-S 2-0. And that's O'Reilly S-A., the letters SACon.com. All right. So it's that time of the show where we ask you if you haven't already and you feel like giving back to us, please do take the time to go up and leave us a review. And, you know, write us something, put a smile on our face. You know, we super appreciate all those that have taken the time to do it. And we sincerely, sincerely appreciate it. So if you haven't already, and you'd like to head up to codingblocks.net slash review, we'll have the link in the show notes and it'll be in your podcast player of choice. So, you know, please do that. And if you haven't already share us with a friend, you know,

help somebody else get a jumpstart on their career, share it with your college buddies or friends and, and, you know, help somebody out. All right. So with that, it's time for my favorite portion of the show. Survey says. All right. So back in episode 104, we asked, what's your favorite time to listen to podcasts? And your choices were during my commute, what else am I supposed to pay attention to? Or while I work, I need an escape or while I exercise, nothing better than staying physically and mentally fit or every waking moment. And lastly, I wish my schedule was that routine. All right.

So I think Joe went first last time. So Alan, you go first. What's your choice? What percentage? I'm shooting for the moon here. I'm going to say during my commute, 45%. Okay. I like how you say you're shooting for the moon and then you come in under half.

Hey, usually we're in the 20s and 30s. I stepped it up by a good 20% there. Okay. So, during the commute at 40, wait, 45%? 45. Okay, 45%. Yeah, I think it's so boring driving, so I'm going to have to go with that. And yeah, 46%.

Oh, you suck. Go big or go home, man. 47. 47. I blame John. I blame John. Episode 100. Ever since episode home, man. 47. I blame John. I blame John. Episode 100. Ever since episode 100, man, this was never a thing for five plus years.

We behaved like gentlemen when we played this game. Now it's cutthroat. Now we're like, you know what? I'm going to one-up you. Literally one-up you. All right. So dirty. All right. And the winner is... You know what? I'm going to one-up you. Literally one-up you. All right. So dirty. All right.

And the winner is... You know what? I made the mistake of saying drumroll last time. I'm not going to do that this time. Yeah. So, Alan with during my commute at 45% and Joe with during my commute at 46%. Both of you playing by Price is Right rules. Keep that in mind.

And the winner is... Joe. It's Joe. Doggone it. What was it, like 60-some-odd percent? On the head. Doggone it, man. 60% yep.

So close, yeah. I mean, I wanted to be optimistic and say it was you know while i was exercising but come on man ain't nobody doing that you know but i mean we get a lot of people that write in uh you know i mean whether they write in by email or it's in discuss or it's a review i mean that's definitely one that we hear about a lot. Right. I would imagine that was the second one, right? You'd be wrong. Really? Every waking moment. Was it during work?

Work was second. But in fairness, they were all, the rest of them were all like close. I mean, they were like, you know, within a point or two of each other. There wasn't a lot of separation between them. But exercise was the last one. Oh, wow. None of us. I don't know if that's good or bad.

Yeah. Well, it's not fun. What, exercise? You need to listen to stuff to pep you up when you're exercising, you know? That's when you put on like the Whitney Houston or whatever. Oh, good Lord. You just said pep you up with some Whitney Houston. Yeah, man. That's's hilarious that just happened i don't know what was better the fact that he said it or the dancing that went

along with it as a video feed here it's it's a shame that most people aren't going to see that like one i believe that women heard when i believe that it's the last song Children are the future too Them being a three Well I would say Do you want to joke next But I think we just had our joke What the fact that there were only three repetitions Or

It was such a good workout song well i was thinking i was just thinking that like whitney houston was his go-to exercise music but yeah you're right the three repetitions was probably better i did the greatest love last time i did karaoke and after i did it it was terrible uh i thought it'd be funny it was not funny and uh someone said like you're so brave for doing that. I really appreciate it. I was like, wait, what does that song mean? I don't know.

Oh, man. All right. So do you want a joke? Yeah. Sure. Yes. All right. A sans serif font walks into a bar and the bartender says, sorry, we don't serve your type here.

Love it. All right. I got one more. I don't know how well this one's going to go over because this is more of a visual one, but I'm going to try it. Okay. So if you don't like this one, then I suggest you jump on Slack. So you can head to www.codingblog.net slash Slack and find Mike RG and you can blame him. Cause this one comes courtesy of him from Twitter. And I'll include a link to this in our show notes as well. So the two people talking, there's you and your professor.

So me, I'm so sorry. My dog ate my homework and your computer science professor professor says, your dog ate your coding assignment? And you just kind of look at him, and he looks at you. And then you say, it took him a couple bites. Lovely. B-Y-T-E-S, I take it. Yes.

Yes. Was it Micro-G that told us how much a bite weighs? How much a bite weighs? I must have missed that one. Yeah, you can convert bites to kilograms. What? Yeah. Where's the link for that?

Bites in a kilogram. I don't know how they did it. I need to see this Bites to Kilograms conversions. I think he might have been pulling our leg. I can't get it to pull up. I got to imagine this was a joke that you fell for. Was this coincidentally

April 1st? No, no. This was this week. We're all heading to Slack right now. By the way, our Slack is amazing. I don't even want to call it our Slack because we are the least interesting part about it. It hurts to laugh

because it's true. He searched 6MB over 3G. Wait, what? Yeah, I got the same thing. So search that exactly exactly 6mb over 3g 2 million bytes per gram yeah they got that by those 2 billion by 3 grams what in the world is that that's got to be like a google mistake so this is a google this is you

know using google calculator to just like enter in any kind of search so three m six mb divided by three g and it does spell it out six megabytes divided by three grams equals two billion bytes per kilogram. Hey, do you want to know what 6 ounces are? 6 ounces over 3 gigabytes? It's 5.66 bunch of stuff times 10 to the negative 11 kilograms per byte. Wait, what was that one? 5 ounces over what? 6 ounces over 3 gigabytes.

You know what's so awesome about this is somebody was trying to find out how long it took to transfer six megabytes over a three G connection. Yeah. And Google calculator came to the rescue. It was like, that's going to weigh a lot. Yeah. I just want to let you know,

it's a lot. I just got to imagine that that was somebody at Google having fun with the Google calculator project. And now I can never trust Google Calculator because I can't trust it. What I'm actually putting in is real. Wait, it's not wrong though, is it? You can't prove it. Well, okay. So I guess there's that. If you can't prove it's wrong, then it must be right. Is that what we've evolved to now? I think that's where we've led.

Okay. Well then in that case, let's discuss today's survey, which is what is your preferred type of language to spend your day in? And your choices are dynamically typed languages like JavaScript or Python. I can't be bothered to compile. I catch my errors at runtime. Or statically typed languages like Java, C or C Sharp. I'd like to say that my errors are caught at compile time, but sadly that's not always. Or functional languages like Haskell or F Sharp. Here's a quarter, kid. Get a real programming language. Or lastly, SQL.

If you're not working in sets, you're wasting your time with one-offs. I like it. I'm sort of surprised we didn't put TypeScript in there with the typed languages. I feel like that would start a nice little flame war. I want to know if people actually care about TypeScript. Like, real people doing real work. I care. Deeply.

I like how his voice went up like a couple of octaves when he said, yeah, that makes me doubt that was, that was really shows how much he cares. Like how, how many octaves his voice goes up. That's how much he cares. That's right.

I had a Justin Timberlake voice for a moment. It was good. This episode is sponsored by discover.bot. Discover.bot is an online community for bot creators designed to serve as platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their stories, and move the conversation forward together. Built by Amazon Registry Services, Inc., Discover.Bot is an informational place for novices and experts in the bot development space. Discover.Bot regularly publishes how-to guides and the latest bot building resources, such as how to design a bot personality, how to set up payments through your bot, or how to stop shopping cart abandonment. Discover.bot also shares expert advice and provides insights on all things bot-like. What KPIs are worth measuring? What emojis may be breaking your bot? Or how to write an engaging chatbot dialogue? For newcomers in this space, Discover.bot will teach you

everything there is to know about bots with articles such as the beginner's guide to bots. Do you already have a bot of your own? Discover.bot can help you choose a framework that's there is to know about bots with articles such as the beginner's guide to bots. Do you already have a bot of your own? Discover.bot can help you choose a framework that's aligned with your business goals and needs. Head to discover.bot slash coding blocks. That's discover.bot slash coding blocks to learn how to get started on your next great bot. All right, next up, we're talking about reversibility. And what they mean by that is basically the ability to undo stuff.

So they started talking about how engineers tend to like objective solutions to a problem like 10 is greater than seven. True. And they plug in nicely to a spreadsheet. So people like managers and stuff like it, too. But most problems aren't really that easy. The solutions that we come up with aren't like binarily right or wrong you know we've talked about how coding can be a real mess and how there's not really there's no two bones or about it in most coding you're doing there is no prescribed right way to do it there are only lots of wrong ways less wrong ways but i like the

metaphor they gave in the book is that as you make critical decisions, you're committing to a smaller target. So the more critical decisions you make, the target becomes smaller. And so in order for you to achieve success, given all those decisions you've already made, you've got to hit this smaller thing. And so it becomes harder and harder. And so an example that I kind of wanted to give for their example was, what do you think is easier to deliver? A simple brochure website, period, built however you want, or a brochure website built on Hugo version 8 with SQL Server 16 and Vue and IAS v6 on running on Ubuntu 17.3. Were you able to use Yeoman? That's right.

Do people still use Yeoman? I don't know. Well, I mean, it definitely sometimes is definitely nice to have some of those decisions made for you and you don't have to think about it. Right. That's true. Like there's just something about the stress being taken off your shoulders. You don't have to worry about it. That's true. There's just something about the stress being taken off your shoulders. You don't have to worry about that decision point.

You can move on. Because we've jokingly referred to this, too, before the decision paralysis that can happen when you do try to like, okay, I'm going to go off and create this side project. Oh, look at this rabbit hole I found over here. Let me go and like, how do I do this? And should I need to worry about this? And then before you know it, you know, you'd never get the thing started, you know, but if you ever needed to log in, you know how you would do it. That's true. So I guess having the prescribed solutions at least limits your

Googling, but yeah, if someone came to you and they wanted a brochure website, like, all right, square pace, square space now pay me yeah done i did have a you know note here for myself though like there was this example that they gave about switching databases and i was like oh man that that that hits a little close to home yeah it happens people it really happens yeah not yeah not that frequently but it does yeah this one's interesting because I mean, what they're getting at is when you make these critical decisions that it's way harder to, to make a change, right.

Or to even potentially introduce something different in the future. And so you're kind of stuck with those decisions you made, like which database server you chose or which framework you chose for UI or whatever. So it is interesting. Like your targets become smaller because you sort of bought into this and this is what everybody expects. Now they, there was this one great line that I,

that I highlighted here, which is that the problem is that critical decisions aren't easily reversible, which this whole section is about reversibility. Yep. Yep. Totally. So does that mean that you should have no critical decisions? I think this ties in nicely with the orthogonality too. Like if you can keep your stuff tidy and separated,

then it's not so bad if you need to do a big change on one of them, because theoretically all those other pieces aren't going to be related to it. So you don't have to change all that stuff. You can just swap out one piece and you should be okay. And then, you know, it's funny. Go ahead. No, no, no. You finish.

I was going to say the one thing that I always feel like this doesn't work with is the UI. You can swap out middle tiers fairly easily. You can swap out databases. I say fairly easily. I mean swap out databases, I say, fairly easily. I mean, there's work to be done. But if that's modularized, you could do that. If you abstract away your data storage decently, then your database money would not be a big deal.

But the UI, that's always so hyper-specific to whatever implementation those use. I disagree. Really? Yeah, strongly.. I disagree. Really? Yeah, strongly. Strongly disagree. Really? I think you're coming from a spa world, and that's why you say that. Maybe.

If you were just going from one page to the next page, right? If it wasn't a spa, then you wouldn't care if Blazor was serving one page and React was serving the next page. I mean, I'm not saying it would be great. It might not be the best experience. Well, what about mobile platforms, right? Like, even if you're trying to do something for Android versus iOS, I always feel like the UI is way more involved than every other tier. You mean like native mobile development? Yeah, native mobile, a Windows application versus an iOS application, or not iOS, a macOS application.

That's what I'm saying. You could make your business tier portable. You could make your database thing abstracted. But your UI thing, if you decide that you want to go to a new platform, you're probably redoing the UI on that platform. But that's exactly one of the decision points that they're referring to here in this chapter, this portion of the book, right? Because you designing or you developing for iOS or Android, that's a critical decision. You are now locked in to that platform, right? And if you decide that, you know, if you create some amazing new feature in your iOS version,

that, and you're like, oh, I now want that, you know, that was a great feature in my native iOS application. I need that also over here, even though, you know, you might have an Android and a Windows environment and an iOS environment that are all using the same backend, but they have their different UI parts. I mean, those were locked in decisions, right? They go against the reversibility. And that's where, like, things that are becoming more popular, like, you know, PWAs, for example, right? Yep. I mean, there, there was an going back to our previous discussion about, um, what were we referring to now when we were talking about the databases in the last,

uh, section, I don't remember how it came up, but, um, you know, they were talking about how, like a lot of the times it's calls to third-party products are entangled throughout your code. Right. And even with the, the, when we were talking, you know, a little bit ago about the database abstraction, and, you know, you can't, you can't, you even got to, you need to, you know, you should take care of even like the data types that you're returning, right? Because the data types that you're returning might be, for a lack of a better word, a code smell as to what the implementation is, right? That you don't mean to leak, right? So in a C-sharp world, like maybe data table is okay, or maybe it's not.

Like, yeah, I guess I'm trying to think like off the top of my head. That's part of the SQL data thing, which is part of, or not SQL, it's part of the data,l data thing which is part of or not sql uh uh what's part of the name it's system.data yeah which is tied to sql server what well what i was really thinking what i was trying to think though is that like if it was.net core friendly on a linux world but i i don't recall off the top of my head if that one is but um but yeah you see where i'm going with that though is like if you you know like the point that I made earlier was like, if you were to allow your user to pass in like a specific query, you know, that they, that they might've created, forget

string injection kind of problems that you might have with that. But, uh, you know, now, now they can, you know, tailor that query specific to the kind of environment, right? And as well as the data types that might be passed in. So for example, you mentioned the system.data namespace, right? If your user is calling your library and they're saying like, oh, hey, this parameter to this stored procedure that I want to call is dbtype.string or int or whatever, right? Like that's another namespace or type that's within the SQL Server world. That's a very subtle leakage of the implementation that you may not have intended, but when have you ever seen someone wrap their own type system

around the database in the application that you were working in, you know? But if you're truly, if you're truly trying to, you know, uh, you know, adhere to the, to these books that we've read, right? If you're trying to adhere to these ideas and these principles, then you shouldn't let those kinds of ideas leak through. That's where something like a repository pattern would come in play, right? Like, instead of returning data tables, you return Ion numerables of a particular model or something like that, right? That's kind of where all those things fall in. Exactly. Exactly. And to what you just said is kind of where I was thinking earlier when I brought up the idea of domain-driven design as part of that, right? Because like you said, bringing in a list of models, returning back a list of models.

Yep. I was thinking, too, with the data table thing specifically, I've absolutely written code that converted an IEnumerable to a data table because I had some piece of code that was expecting stuff from the database. And the right answer there should have been to take an Enumerable and convert the data double to the list. I'm sure we've all done stuff like that before. And it's because those things leak. Somebody had a function that would take stuff from the database. They just left that as it was. And that worked it was. And, you know, that worked from then, but it's when I made the mistake of saying,

okay, well, I'm just going to convert my thing to the data table rather than the other way around that the bad thing happened. I think. And, and if we're going back to this, this,

this stems to something that we talked about years ago is a lot of times people develop database first, right? Like they look at the database and then they're coding from that, right? Like this is how my tables are structured. This is how I have to build stuff for the application. And that's how it kind of leaks through, right? Like they start at the database and they're like, okay, well that's going to get into a data table. Okay. Well, I know that I need to get things into this, this way. And that's kind of how it happens,

right? Instead of coding from the, what's the requirement for this application? Let me isolate this thing and then create the adapters for the different layers. It's like a Drake song. We started from the bottom, now we're here. There we go. No, there was another great line I had in here too that I made a point to comment on, which was that this mistake lies in assuming that these decisions are cast in stone too that that i made a point to comment on which was that you know this mistake is lies and then assuming that these decisions are cast in stone and then not preparing for these contingencies might arise and so you know the database has like been our go-to example for years on this podcast

right that we've talked about like you know even while reading books like uh clean architecture or clean code right like you know, Uncle Bob's example is great, but it's like, okay, well, how often is that really going to happen, right? And I mean, but it does, it happens, you know? And so, if you're not prepared for it, when it does happen, it is going to be painful, right? And I really liked the way they phrased this, because they were like, you know, you should think of these critical decisions. Instead of being cast in stone, think of them as being written in sand on the beach. Yeah, that's nice. Which is a nice segue into the next tip from this book, which was there are no final decisions.

Yeah. So what was the tip 13 that we hit earlier? Eliminate effects between interdependent things. And so tip 14 is there are no final decisions. And yeah, I totally agree with that. I've seen things change that I never thought it would have changed. Like a database. Yes.

Oh, my gosh. Yeah. And so everything's kind of pointing back to just having a flexible architecture which is something we've talked about a few times you want to keep your code and your architecture flexible um book mentioned things like corba which is definitely old school but we have a lot of better tools and conventions now and so i wanted to say that things have been made so much easier for us to be programmers like in 2019 than ever were before so like you, you know, ORMs aren't exactly new, but package managed utilities, things like NPM and NuGet or whatever, CPAN, containers, Docker, Kubernetes. I just wouldn't name a bunch of old stuff.

CPAN was definitely it back then. Yeah. Oh, my gosh. CPAN was so nice. Why else would you use Perl? But so the tools have gotten a lot better and also just the convention so we mentioned 12 factor apps earlier pwas or other things there's just better techniques for doing stuff so if you just kind of coming uh you know out of out of school or whatever you're just kind of getting into the workforce and you're looking around or like best practices for things like

how to do login forms or security or whatever. There's so many articles and so much good information that life's just gotten a lot easier for all the people that have to maintain the crap code that you write. That's good. It's just another example of like how much we have to stay on top of this craft, right? Because the way that we did things 20 years ago ago it's not the way we do it today yeah don't remind me i was uh looking at a couple websites like oh how these websites do this thing i'm trying to do i want to see some new patterns of how people are doing i went and looked and they are so good i'm like looking at css like i don't even understand why this looks so nice like what those animations and there's drop shadows. Like when I hover,

I'm what? It's overwhelming. I want to know what this amazing thing was. Yeah. All right. Oh, is a West Bostock. Oh no.

Uh, Scott Tolinsky. Actually, I think it was his side. I was looking at how he's laying out his videos. It's just really good. Anyway. Oh,

he's got a video of him breakdancing. So, if you're a fan of syntax.fm, you should head to his website and see him breakdancing because it's amazing. Awesome. So, a couple other things I mentioned here. Poor encapsulation, high coupling, and hard coding logic parameters.

These are all the types of things that you want to avoid because they reduce your flexibility. We mentioned that database centric view, the problem with that is that it reduces your flexibility because you're basically casting that stuff in stone and making it really hard to change. Yeah, or you're sprinkling it everywhere so that when you do decide to change something, you're like, oh, well, I didn't realize I was using this data type that's all over the place. And this data type is tied to this one specific technology. And now I've decided to get rid of that technology. And, oh, man, I have to change everything. And think about what that sounds like to a business owner.

Be like, hey, we're going from SQL Server to Oracle. And you're like, what? That's going to take years. And why? Why does it take years? You're not doing it right, bud. Look at the code. You know, all those times that you told us that there's two weeks to get this thing out?

That's why. Yeah, take that. So it's just to try and make all your decisions reversible. And they did give one other piece of advice, which I really like. And I should do more of this. And I've always been happy with the times that I have. If you can use metadata throughout your code, then that basically helps you kind of separate your data from the logic. And it's just really nice.

And that means you can make changes to how things behave by altering like a config file or something rather than actually having to make procedural code. So I'm a big fan of that. And it takes things and moves them to like the declarative space, which we've talked about the advantage of that before too. So I really like that and definitely like to promote metadata whenever I have a chance. You know, the only thing I don't like about the metadata thing is that always seems to get spread out all over the place. You end up having metadata stored in like every tier of everything that you have.

And it's like, man, how do you clean that up? Right. Not saying it's not the right approach, but it definitely seems like you end up repeating a lot of garbage all over the place. Yeah, and it's hard. I've seen places like, oh, let's just throw it all in the database. And then you've got stuff that can't really access the database. You're like, oh, crap, let's just put it in files. And then you've got files everywhere because you have multiple boxes.

And yeah, it's just not a great way to do it. And how do you use ReSharper to do your refactorings of metadata? That's a good question. You don't. That's a problem. That's a bummer. So there's a challenge for this one, and I hate it. Anytime I hear about Schrodinger's Box, I'm just, ugh.

But it's 1999. Maybe this hadn't been so played out and you haven't heard the authors hadn't heard every single science and economics and news and pop culture podcast have a Schrodinger's box episode. We haven't yet. You want to have one? Oh, no. Anyway, I personally, Joe Zach hates Schrodinger's box.

We should probably describe what it is, but it's the whole thing. I'm sure you've heard it before. Basically, there's a box of the cat and a uranium ion or something. And so when the box is closed, you can't see into it. Nothing can observe it in any way. Then you don't know if that cat's

alive or dead. First of all, I hate that it's got animals dying in it. It seems totally unnecessary to me. I hate that. And also it's just the way they've used it. So nothing against the book. That's just my own personal rant that I abused your ears for. Sorry about that. The idea is if you've got Schrodinger's box and you know in there is a cat that is maybe alive, maybe dead.

And they are basically alive and dead at the same time until you open that box. And when you open that box, you basically split two realities. So now you've got this kind of split in the space-time continuum. And you've limited your options ever more. So after all that, the question is, do you open Schrodinger's box? Is anyone else picturing Brad Pitt? What's in the box? Come on.

What's in the box? Wow. I see about all the bad sci-fi movies. I've explained that exact situation so many times. Yeah, I don't know if I open the box. I guess it depends on how long. Of course you open the box. There might be an alive cat in there.

Right! You gotta feed the cat. If you don't open the box, it's not gonna be alive. Wait, wait, wait. If there's uranium in it, am I gonna get poisoned? You're too late. A little bit of cardboard isn't going to help you solve that problem. You're past that problem. So I do think in terms of

what we just talked about with reversibility, I think the argument here you're supposed to say is, well, don't open the box because then you've got your options open and you don't even need to know what world you're living in. As soon as you open it, there's no reversing. You can't make, well, you cannot make one of the things

reversible. So kill the cat is what you just said. I think that's the answer they want, but there's no way I'm ever going to say that. You're not killing the cat. No, I love cats. And that's why I hate Schrodinger's stupid box.

You don't want to kill the cat. Well, it's not that way. Wait, wait, wait, wait, wait.

It's not that by opening the box, you're killing the cat. No, you may not even may be saving the cat. It might be dead already, but you're just confirming whether it is or not. You're just confirming which universe you're in. So we're just saying,

turn a blind eye. No, we're saying open the cat, open the box. Well, okay. Joe and I are saying, just saying turn a blind eye. No, we're saying open the box. Well, okay. Joe and I are saying, Oh, let's be clear.

This is a yes, yes, no. Joe and I are saying, yes, open the box. And Alan is saying, no,

if you don't open that box right now, I'm going to Hulk out. And that box is opening or else I'm going to be, you know, dad, basically. No boxing kitties around here. Anyway,

we just stay there talking about the box for like 15 minutes. I don't know, dude, should you open it? No, I don't want to. Alan's like happy and ignorant. Like I don't need to open the box.

Right, man. This could ruin my day. If I open this box and something bad's in there. Something bad's going to be in there. If you don't open it. You've got to open the box. Alright, well I can see what the title of this episode

is going to be. Oh, no. Alright, well with that, we'll have plenty of links to some resources that we liked as we were putting the show notes together for this episode. Obviously, a copy of the programmatic or the programmatic programmer will be included in that. Blame Joe for me pronouncing it that way forever.

And with that, we head into Alan's favorite portion of the show. It's the tip of the week. Yeah, come on. All right, I go first, and I had one this time thanks to Dave Follett with two Ts we mentioned briefly earlier. Wait a minute, you always have one, but is it a good one? This one's good, I think. Wait, and how are you going to say Dave Follett with two Ts and not two Ls? Is one more important than the other? All right, all right yeah super good dave oh uh he introduced me to mdx slides

and what that is basically i'm sure you've seen like some javascript um kind of presentation things like powerpoint kind of but in a basic website and they do things like i don't know if this does but they'll do things like support like the little clickers that you can get that you can do the shortcuts for the up, down, left, right, whatever. So it's just a nice way of doing like a slideshow in HTML and JavaScript that looks really nice. Well, with MDX slides, not only are the slides marked down, but you also can pop your React JSX components in there. So if you've got some sort of cool components that you've got on your website, well, heck,

why should I try and do even a screenshot or why should I try to recreate that in my PowerPoint? So why don't I just use the component? Oh, it's just a pretty cool thing. So I like that it's already looks like it's got a nice interface. It's a markdown so I can make slides. So keep that stuff separate. And it's in a language that I understand, not this weird binary format of PowerPoint or whatever the Mac one's called.

And yeah, just use your react component. So I really liked the idea of that. So I want to give that a shot. It's got presentation mode notes, you know, shortcuts, all this stuff that I like,

and I can, you know, keep it all checked in and get hub and it'll actually be sensible when I look at the diffs. This is like slides.com, but rather than creating an account, you're just going to do it your own. Roll your own.

I'm going to roll my own Jamstacks. That's pretty nifty. Although I will say I had a little bit of postpartum, or maybe it is postpartum. When I saw MDX, I thought it was SAS code. I sort of shivered and vomited a little bit when I saw that in the tip section.

Doesn't it make you a little happy, though, to think that there's people out there that didn't even know there was another kind of MDX? Their life has never been touched by it, and they're just pure. That is a happy alternate universe. Very nice. All right, so I've got a couple here. That's going to make my next tip awkward, then, when I talk about analysis services. Oh, man. No,. All right. So I've got a couple of awkward then when I talk about analysis services. So, um,

no, you're not. All right. So I've got a couple of here. One, this man, I stumbled across this one the other day. So I,

I've been trying to get some auto fact learning going and I decided I'd attack the Amazon product marketplace API. So there's an article and I need to find the link and put it in here, but where how Amazon signs URLs so that they know you are who you say you are when you're sending a request over to them. Dude, they have the steps on how to do it on their website. And and like a good citizen, I did the TDD approach, right? Like I put the stuff in there and I said, all right, if I run this test and it passed and everything's good, I could not get the signatures to match. And what I found was there are differences in if you go search on Stack Overflow or on Google,

which will take you to Stack Overflow for any good code answer, how do I encode a URL? You're going to find http utility.encode is the one that comes back most of the time. However, it doesn't encode things exactly the way you think it would. You don't have that much control over it. There's another class in C Sharp called system.uri, and it has an encode data call that you can use. And it actually does things a little bit different.

Things like changing something to percent2f might be capital versus lowercase. I even include a link to the Stack Overflow where this dude took just an amazing amount of effort to say, okay, if you do unencoded versus URL encoded versus data encoded, and he shows you what the output of each one is, whether it's uppercase, lowercase, what the characters were. Lifesaver. In a nutshell, know that there's a difference. If you're actually trying to do something like where they're hashing, have some sort of hashing algorithm that's doing this, and you have to have this thing in a particular format, you will need to know the differences here. That took me way, way longer to do than what I had hoped it would.

Man, this answer isn't even like the selected answer. And it should be. Like, no question. Three times the number of upvotes. I hate that so much. Yeah. It's kind of ridiculous. It even says, like, check out the answer below in the selected answer.

Yeah. Yeah. I mean, this guy puts a table in Stack Overflow. My God, how long did it take to do that? But it's a beautiful answer. So just be aware of that. It might save somebody some headache and some heartache out there. You know, ironically, after this, I thought, you know what? I bet Amazon has this in their SDK code. And I went and looked and their implementation wasn't nearly as pretty as mine. So I was kind of proud about that. And then the next thing that I want to share,

just because we were talking about, you know, or doing styling documentation or whatever, and this might've been something that I've even said in the past, and it's just a really cool site that I used a lot a long time ago. It's called csszengarden.com. And the cool part is the markup on this page is the same for every page. And if you click in the upper right, you can say view all designs. And I mean, they've got pages and pages of this stuff. But no matter which one you click on, the only thing that's changing for every single page is the style sheet.

All the markdown is exactly the same. And these designs are just nuts. Like you'll find things that you're like, wow, that's really awesome. And it's just a style sheet. That's all it is. So pretty nifty stuff. If you ever want to see the power of style sheets, go check this out. It's pretty neat. Yeah, it's up to date. I think I've known about the site for a long time, but it looks like people are still submitting and still doing new ones. And Yeah, it's just incredible. Yeah, I mean, the garbage

you can do with CSS is mind-boggling. There's some weird ones, too. Yeah, totally. Why is she crying? Because she's sad that her code doesn't work that well, where all she has to do is change the style sheet. Oh, dude, go to

csszengarden.com slash 219. This one is so cool. Slash 219. Okay, so to the Chrome we go. Yeah, look at this. I'm actually in Firefox. And what this thing looks like is like a theater thing. This looks like an industrial kind of world. You can see some cranes, and when you hover over a specific area of the page, the crane will lower a billboard in place and rotate the billboard.

And then on some of the billboards, you actually have marquee text. So this is definitely current. I'm just kidding. Oh, it looked different for me because i guess my resolution i didn't open it full screen ah oh wait is this uh well i didn't have mine open full screen oh dude is it different full screen responsive i had it half screened like vertically and it looked totally just kind of boring oh yeah this one's responsive too man yeah it works amazing man i must have to have like

a gigantic well no i'm on like a 40 inch 4k no shrink it down like shrink it down like responsive style and it goes to like a phone mode and then it goes to like a half mode like it's just i see this thing's cool as hell yeah then you lose then you lose all the uh the fun crane moving the pieces around. Yeah. So, at any rate, yeah, if you want to see what the CSS could do. So, here's the tip that Alan's trying to get at. Go buy like a 40-inch 4K and then go to csszengarden.com slash 219 and you can see what we're talking about. There it is. Cheapest tip ever.

Cheapest. Absolutely. And don't click on the one where the lady's getting like shot by the bow and arrow. Wait, what? Someone's getting shot? Which one's that that what's the number in the url i lost it let me see if i can find it all right well while you're looking for that i'm going to go on with my tip of the week which is hang in there with me while we learn some kubernetes so uh if you haven't already explored the world of kubernetes and Docker, hey, learn along with us. But Kubernetes is a cool orchestration layer on top of your containers.

So we've talked about Docker in the past. Actually, no, we only talked about it in the YouTube talk, right? The community talk. No, we did. No, no, no. We did do a talk specifically on just Docker. On Docker, yeah. I think it was like in the 80s.

But so Kubernetes is a layer on top of that so that you could have some layer of orchestration of like containers that might exist on different machines. But there's a real simple tutorial on kubernetes.io where you can learn the basics of Kubernetes. So I'll include a link to that. And then for the main command that you're going to use to enter in all your commands, which I pronounce it kubectl. I don't know if there's something else, but it's K-U-B-E-T.

No, I can't say that wrong. K-U-B-E-T, no, can't say that wrong, K-U-B-E-C-T-L. I'll include a link to the cheat sheet for all the commands that go along with that thing. So think of, you know, like how Git has a bunch of sub commands that you might use. Well, this is the same way for Kubernetes. So I'll include a link to those two. I've heard them called burbs. I don't know if that's the official term. What's called burbs? like whenever you have like a two-parter like get commit the commit is a verb i don't know if the same for a cube cuddle apply or whatever is it always a verb oh a verb i thought you said verb oh no sorry verb just by convention like i know a couple libraries will refer to the options or the flags, and then they'll have the verbs.

Uh, like if you look at the documentation, that's a good question. Um, I, I don't know. I don't know how they're, how they,

I'd have to look that up and I can't at the moment. Yeah. I just thought, I don't know. So maybe in the future there will be more EXEs that have verbs. That's very cool. I didn't know about the cheat sheet. I like cheat sheets. Well sheets well i mean it definitely seems to be like the the pattern though right i mean uh gets definitely a good example but docker also follows that same pattern yeah you know if

you look at all the different docker commands so and does it install update node yeah we got i think the the nomenclature of the verbiage for that we found based off one of your favorite NuGet packages outlaw is the command line utility or command line options I think is what it's called. Command line parser? Yeah. Command line parser.

And that's what they call them verbs versus you know whatever. By the way I found the bad design. It's not necessarily bad it's just disturbing don't go to this anyone don't go to 169 don't go to it we'll leave a link in the show notes

oh man she's really upset yeah maybe already shot her I love this site I go to it every couple years Did someone maybe already shot her? I love this site. I go to it every couple of years. So, yep, all good stuff. I'm kind of bummed out now.

Let's wrap it up. All right. So with that, I hope you've enjoyed our continued discussion of the pragmatic programmer. Oh, man, I messed it up. I was going to say it the weird Joe way. The Parmesan programmer. There you go. And don't forget the tips that we've talked about so far from the book in this episode.

Eliminate effects between independent things and there are no final decisions. And with that, be sure to subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And be sure to leave us a review if you haven't already. Like Alan mentioned before, we greatly appreciate it. It puts a smile on our face every time we read them. You can head to

www.codingbox.net slash review where you can find some helpful links. Yep, and while you're up there, go ahead and check out our copious show notes, our examples discussions and more and send your feedback questions and raps to facebook or the comments if you want to win a book and or if you want us to read your raps on air and make sure to follow us on twitter at coding blocks or head to the website where you find social links at the top of the page