Coding Blocks - The Pragmatic Programmer – Investing in Your Knowledge Portfolio

Episode Date: April 29, 2019

We begin our journey into the wisdom of The Pragmatic Programmer, which as Joe puts it, it’s less about type-y type-y and more about think-y think-y, while Allen is not quite as pessimistic as Joe, and Michael can’t wait to say his smart words. If you’re reading these show notes via your podcast player, you […]

You're listening to Coding Blocks, episode 105. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Oh, and I forgot to mention Spotify. Yep. Spotify is great, and you can visit us at codingblocks.net where you can find all the show notes, examples, discussion, and a whole lot of other stuff. Send your feedback, questions, and rants to comments at codingblocks.net. Follow us on Twitter at CodingBlocks and even Facebook. We just had a big giveaway on Facebook at facebook.com slash codingblocks

or head to www.codingblocks.net and find all our social links there at the top of the page. And with that, I'm Alan Underwood. I'm Joe Zeck. And 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. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast.

Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. So head over to www.datadog.com slash coding blocks to see how Datadog can provide real-time visibility into your application. Again, visit www.datadog.com slash coding blocks to sign up today. All right. And it's that time of the show where we love to give praise to those who have taken the time to leave us reviews. So with that, I think Jay Z, you've got iTunes. All right.

And I'm apologizing ahead of time. I'm just going to kind of blast through and hope that it works out. I apologize. Uh, does that could Jay angel file of DNS butcher, DNS, but the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the, the, the, the, the,

the, the, the, the,ins Eat Zombies and Strangulated Hernia. And from Stitcher, Razzles, Gray Math Technology, Vlad OS, and Sandwiches. Sandwiches. The first one's got to be Rawls's, right? Not Razzles. Rawls's. Oh, yeah, maybe. Well, okay, fine.

Razzles, I'm sorry. Yeah. So, thank you, everybody who left us reviews super duper appreciate that thank you for taking the time to do it and so i'll we have a short bit of news here so the first one is completely unrelated related to anything programming but i think i've mentioned on here before my wife and i love doing escape rooms and we found this place in Alpharetta, Georgia. And they actually have a location up in Schaumburg, Illinois. But if you're ever in the area and you want to go have some fun, go check out Odyssey Escape Game. They had some amazing rooms.

We had a really good time there. So wanted to give a shout out. I like it when they're small business owners that have a lot of passion in what they're doing. And they really do create some really cool experiences. So we'll have a link to that in the show notes. So give them a shout. And if you do go, mention that Coding Block sent you and you might get some love there. So we'll see how that goes. And then the other thing is I had done the Kafka talk at Orlando CodeCamp, which I think went okay.

So Jared invited me to go to the Atlanta Intelligent Devices meetup on June 24th and give the same talk there. So if you happen to be in the Atlanta area and you want to see some cool real-time streaming data stuff with Kafka, then come over there and don't kick me in the shins, but say hi. No one ever does it. It's fine. It's fine. All right. So finally, we're talking about the pragmatic program where we've been excited about this topic for a long time. We've given away a lot of books and talked about it quite a bit recently, and we're really pumped about it, and we hope you are too. How do you guys

like the book, by the way? I'm really enjoying it. I didn't know what to expect going into it, but it's written very well. You outlaw? Yeah. Yeah, I mean, it's a very easy read. You know, I like it. Yeah. Yeah, I always said it's very easy read. You know, I like it. Yeah. Yeah, I always said it was my favorite. I said it was my favorite programming book, although it's definitely on the softer side of things. Like, you're not going to learn any syntax tricks here or anything.

But I always thought it was really good. It's kind of like every chapter or every section is just chock full of wisdom. And the things that I find myself thinking about even years later. So, glad to be reading it with you guys. enjoyed it because it's written by programmers, people who've been doing this stuff for a long time, like the three of us that have sat down and thought about the garbage that they've gone through over their career. And it's not written by designers of a framework or language because those people are usually focused on getting you the information about how that thing works, that language or that framework or whatever, and not about the things you need to think about while you're using those, right? Whereas this whole book was written by people saying, hey, we noticed these patterns while we were doing our development. And it's just a,

it's a really refreshing read from just things that you'll focus on and you'll notice as you're working throughout your career. Yeah. I mean, some of it was just nice to like, Oh yeah, that, or it was like, like you said, a refresher, but I was also nice to be like,

to see something in writing too. Like, Oh yeah. Okay. That's a thing. I've definitely heard about that. And now it's in writing here and I have something to back it up. Yep.

I do like, even in the forward, they were like, Hey, there's no perfect tools. There's no perfect methodologies. Every situation is different, right? You have to pick the right things for whatever you're facing. And I feel like a lot of developers and a lot of companies miss that, right? They have a tool that they've used. They've had a technology. They've had these, these methods that they've always stuck to, and they're going to make sure everything fits in those boxes. And that can be detrimental to the project, to the morale, to everything. I thought that was a great call out. Well, so I don't know if we said this part, but you mentioned the forward. So the forward was

written by Ward Cunningham, but the book itself, Pragmatic Programmer, or as I think Joe tried to call it, the programmatic programmer, is written by Andrew Hunt and David Thomas. Yep. Yeah, and a couple of little pieces here. One thing I really like is they emphasize that you should use your own experience to help try and pick the right solutions for you for any particular situation. In a lot of ways, this book is kind of about building that experience and about kind of being aware of your situation, recognizing the types of things that you're thinking about,

why you're thinking about it. And so it's less about like typey typey and more about thinky thinky. Yeah. To put it technically. And they even say, don't fall in love with any particular technology or tool, which is hard sometimes, right? Like I would, I would venture to say all three of us somewhat love C sharp as somebody that's been doing some Java development lately. I certainly miss the syntactic sugar of C sharp. Uh, but yeah, no, don't, don't tie yourself to one thing. Yeah. That's so hard though, man. I mean, like you learn something and then that's the tool that you know well.

And so you're going to keep doing something like that. Like there was even a conversation in one of the Slack channels. And I think it was in our Python Slack channel where it was like, hey, is it cheating if I do this one thing in PowerShell? And it's like one of the answers came back was like, well, no. I mean, if you know PowerShell, then that's what you're more comfortable with. Like, go ahead and do it in PowerShell. That's okay. Unless it was required that it be done in Python, then it would be cheating.

Right. But it's so easy to like, you know, that thing that you know is the thing that you're going to go back to. If you know how to cut wood with a circular saw, then every time you have to cut wood, that's what you're going to use. Yep. And you're going to try to cut down a tree with a circular saw. Right. Well, it should be a factor. If you're coming up with a pro-con list for using technology, there's a major pro in knowing how to do it already. That has a lot of weight to it.

I think that's an important factor. Yep. And one last note from the forward, I think is a pragmatic programmer is somebody who gets a job done and they do it well, right? That's the important part. It's not about writing the absolute best, most pristine code on the planet. It's none of that. It's not about writing the absolute best, most pristine code on the

planet. It's none of that. It's solve the problem and do it in a way that makes sense. There's definitely some parts in here in this first chapter that we're going to cover where it's like, don't try to be a perfectionist, right? And that's tough. Like, I mean, you know, I know for me personally, like there's parts of me that like, I can remember even back when, uh, you know, in school as a kid, right. And like my art teacher being like, Hey, stop trying to be a perfectionist. Just like draw, you know? And it's like, no, that's not what it's supposed to look like. So it is hard.

Nobody ever told me that. They're like, Joe, put the marker on the paper. All right. Well, I mean, you know, maybe your problems were different. I don't know. It definitely had a lot of different problems there for sure. For sure. So who's the book for?

Who's it for? The book tells you it's for people who want to be more productive and effective developers. It's kind of what we said, that you want to be that pragmatic programmer who gets things done, done it well. And I think if you're listening to this show on your own time, then you're probably a pragmatic programmer. Yep. Okay. Now, we've talked about – now I can't remember. The thing where you're not as good as you think you are, but you are good.

It sounds like a Jack Handy thing the way I just said it. Oh, imposter syndrome. Oh, imposter syndrome. Yeah. I think you were mixing metaphors there. I was about to go with another one. Yeah, the way I was describing it, it totally sounded like a jack handy uh snl skit but um but yeah like in in that in that whole section though there was like this part that i love where they're like perhaps you feel frustrated that you don't seem to be achieving your potential or perhaps you look at colleagues who seem to be

using tools to make themselves more productive than you and i'm like in those are the people they're saying like this is who should read this book, right? It's like if you fall into this category, so I'm like, oh my god, I'm so guilty of that stuff, right? Yeah. So guilty of it. I remember when you watched a Pluralsight video.

I think it was a Pluralsight video where the guy was doing VI for everything and you were like – Oh, yeah. I want to be like him. You did a Pluralsight video? I think it was. everything and you were like oh yeah i want to be like him i think i've definitely seen some people rock vi that i'm just like in awe of it's i mean just just mentally mapping all the shortcut keys for vi is enough to melt your brain so uh yeah anyways yeah i remember seeing a video where someone was really um wielding a text mate really well they're doing these shortcuts and they would type and it would type in multiple cursors across the screen.

It was just amazing. Of course, I went out and bought TextMate and never forgot to do any of that cool stuff. But you spent the money. Yeah, I sure did. I mean, I remember coming back after a conference and having seen somebody who rocked adam that well right and like you know he had published his whole list of like here's the extensions i use and you're like you know oh yeah i guess if i could use adam as well as that guy then i would probably be up there on that stage too talking about that yeah you know that's probably not true though but yeah yeah we should uh

we should do an episode on like learning to an editor. I would like to research that. It may be crap to listen to, but I need a catalyst. I need a reason to research it. Could you imagine us talking about VI? Like, okay, now I'm going to – like, here's what – Oh, gosh. And then – Yeah.

I will say this, though, and this is obviously tangential, but it's funny you say about learning to use your editor or your IDE is when you've been using something like we've been using Visual Studio for years, you tend to not go read what comes out in the new version of it. Right. So so you don't even know the new features that are there. Like you don't know half the garbage that you've got available to you until you stumble across it one day like, why didn't I ever? Wait, I can paste this XML as a C Sharp class? Right. When did they introduce that feature? Right.

So, XML. Who uses XML? Yeah. Speaking of those programmatic programmers, they actually have quite a few lists even in the introduction here. So, I wanted to hit those real fast. They mentioned some traits of pragmatic programmers. As we go through these, you guys want to say like

which ones you are more or less of? Okay. Okay, I like it. All right. So early adopter slash fast adapter. I'm pretty good in that camp. On technology though? Yeah.

On like gadgets maybe early adop Yeah. On gadgets, maybe. Early adopter. Nah. Maybe. Fast adapter. I was thinking fast adapter on that one. Okay, fast adapter. Yeah, that sounds right.

Yeah. I don't know that I would say... Yeah, that's the thing. Early adopter of new technologies. I mean, I'd like to be optimistic and say that I am, but realistically, I don't know. I'm probably like, you know, it's probably been around for a little bit before I like jump on it. I'll put it like this. When I tried Angular 2, when they first switched to it, I got in there early enough to where the documentation wasn't done and it was painful. And then Kafka Streams, I jumped in there early enough to where it changed every day.

And I had to redo my code every time I opened it. So, yeah, I think I'm sort of there. It's not everything, but I'm there. Okay. I'm not there. I have a slow adopter. My people. He's just now coming around to JavaScript. Yeah, exactly. But now he owns it, though. He does. He does own it.

I wouldn't say that. So we're about inquisitive, asking a ton of questions, wanting to know as much as you can about what's being done. Oh, God, yes. Yeah, all of us. I'm going to say not very. Wait. For you, not inquisitive? Yeah.

Really? I'll say maybe medium. medium wait how'd you skip the previous one though i like the previous one the confident and grass that was the same that was part of it okay i got it yeah yeah okay yep yeah so i would say yeah i don't ask a whole lot of questions like if it looks like it's working i like to move on to the next thing well now just to make that other one not seem weird though related to the early adopter since you kind of like hinted at what we were talking about there, it was like, you know, the sub points there was that it was instinctive and passionate about trying new technologies and confident in grasping new things quickly. Yeah.

So, no and no for me. All right. So, what about critical thinker? You don't accept whatever is being said or claimed and use experience to think through the problem. I'm pretty good on that one. I wouldn't say like if we were going from one to five, I'm probably a four on that one. Yeah, I would say I'm in the kind of the medium high on this one. Yeah.

Yeah. I would kind of feel in that same range. Oh, that's garbage. Outlaws of five. Straight up. Yeah. I'm sorry, man. that same range. Oh, that's garbage. Outlaw is a five. No. Straight up. Yeah, Outlaw, I'm sorry, man. I'm going to have to go out on this one. I think you are a super high and inquisitive and critical thinker.

Yeah, yeah, no question. Really? Yeah, he's super critical. If I ask questions about like, if I don't accept you saying that, does that make me a critical thinker? He's proving the point right now. Yeah. I feel like you set me up.

That's not fair. Let's be realistic. See, something is realistic. You understand when something is complex and what that means for timelines. I think I'm medium high there, too. I would say I'm ultra pessimistic. Especially on timelines and things being correct and good so i'm gonna say yeah for me on that one yeah i want to say that i like it's a pendulum that swings from one extreme to the next i'm either like really pessimistic i mean like well we can't build that or it's like really optimistic

and like oh yeah no i'll have that done in an hour and then three weeks later we're still working on it like it's always one way or the other it's never like where's that sweet spot really optimistic and like, Oh yeah, no, I'll have that done in an hour. And then three weeks later we're still working on it. Like it's, it's always one way or the other. It's never like, where's that sweet spot. Yeah. Yeah. Uh,

so Jack of all trades is the last one. You keep your knowledge broad, even if your practice is very focused or narrow. Jack of all trades, master of none. Yeah. I'm a five on that. I'm all the way up at the top.

Yeah. I'm on top on that one too. Do you know the rest of that code by the way? Do I know what? The Jack of all trades master of None. Yeah, I'm a 5 on that. I'm all the way up at the top. Yeah, I'm on top on that one too. Do you know the rest of that quote, by the way? Do I know what? The Jackal Crane's Master of None? I didn't know there was more to it, but now I need to know. There is more to it. I only knew because Jess over

Dev2 responded. Let's see here if I can find the whole quote. Okay, here we go. And apparently this is like there's – it's contentious. Just like everything else is kind of controversial. But even the master of none has been added later. So first the expression was jack of all trades.

Someone tacked on master of one years later. And then even later still, but still back in the 1700s, someone added still better than a master of one. So the full phrase, jack of all trades, master of none, still better than a master of one. Okay. Yeah. So I like that because it lines up well with my particular strengths so that's what we're going with all right all right so um uh that was it for pretty much the kind of traits of pragmatic programming but they start getting into tips and this is kind of weird because they mention go uh 15 tips and then they give you a two uh-huh and then you're you go into

chapter one. So it's kind of like look for a missing page or something. But no, I guess this stuff kind of ties more in with the introduction. So they mentioned that the kind of tips that they have for you being a more pragmatic programmer, they give you two right off the bat. One, you care about your craft. And two, that you think about your work. So I think that basically anybody that's listening to the podcast sort of checked number one, right?

You wouldn't be listening to a podcast on development or software programming, any of that, if you didn't care a little bit about getting better at what you're doing. So that's awesome. Well, I mean, number one kind of like, you know, it was a soft spot, you know, in my heart, right? Because like that's the whole reason why we feel like we do this show to begin with is because we cared about the craft. We wanted to like personally, like the three of us wanted to grow there. Yeah. And then think about your work.

Adventure, this sort of goes back to what I've always said about the type of people I want to work with, right? Like I want to work with people that are resourceful and that do think about it and why they're doing it and not just, you know, how perfect the code is, but why they're making something, right? Because I think that's the bullet point that they have under number two there. Think about your work is evaluate what you're doing and why you're doing it, right? There's a difference of writing code just for the sake of writing code for fun. You're trying to accomplish, there's some sort of outcome, there's some sort of goal that you're trying to get to. And that's important. That's super important. But it is so easy though, to focus on the, what you're doing, like the technical part and to totally not even, and to totally lose focus on the why,

like what impact is this going to have on the customer? Why does the customer care? Like why should the customer pay for this feature? It's so easy to like get lost in the details of like, can I do it? How can I do it? What's the best way to accomplish that? Yep.

Rather than like, should I even be working on this? Totally. And I think, I think like personally that's, that's a fault that I have. Rather than like, should I even be working on this? Totally. And I think, I think like personally, that's, that's a fault that I have. It's like, I can get, I can easily get lost into the details of like, can I do it? How can I do it? What's the best way to do it? And easily forget like, oh yeah, should I do it? Yeah. You're like one of those conversations where you're talking about something you're struggling with. You talk about it, talk about it talking about a complaint complain and then someone kind of like asked the

right question or like well have you talked to the project manager about it or have you thought about just not doing this ticket or have you thought about pushing back and just closing they like ask the right question you're like well son of a gun that's another solution the problem is way better than me trying to do what it was like but you just get so focused on like grinding that ticket out or whatever that you don't realize like oh if i just have a quick conversation and maybe if i tell the project manager hey like five percent of this feature that you want is gonna take up 95 of the time they might say oh tell you what just split it off and throw it into next sprint or you know throw it off or like no problem i don't care and so rather than you go and spend a bunch of time trying to get this one last little detail,

it may turn out that they don't care about it or whatever. I know I'm certainly guilty of this all the time. It makes you feel really dumb, but also really good, relieved when suddenly you realize that a problem can just totally disappear if you just kind of look at it from the right angle. And if you keep evaluating, right? And that's the key part is it shouldn't become a black hole where you just disappear. You should always be thinking about what you're trying to accomplish. Yep. I do like this next one, which is embrace individuality and craftsmanship, even on large project teams. I've seen so many cases where this is completely avoided.

Like they don't want people thinking on their own and they don't want people going off and trying things. They want it to be group think and everybody has to adhere to a certain thing. And what they put here, and I love this quote that I pulled right out of the book is they compared it to the quarry workers' creed. We who cut mere stones must always be envisioning cathedrals. And that's so beautiful, right? Because when you start out with a little stone, it looks like nothing, right?

But when you put all that stuff together, you really have something that you can look at. And it's the same thing with a piece of code. It's the same thing with all the projects you build. And taking pride in what you're doing and allowing people to take pride in what they're doing will help grow that. Well, you got to bring up cathedrals right now. Oh, right. I forgot I even had that in there.

Yeah. So if you didn't see the news about Notre Dame, that's really sad. Is it on the cover of the book i forget no not on the cover of this book okay i don't remember what the cover of this book is oh yeah it'd be a totally different yeah that is not notre dame i don't know what it is though it looks like an iron with an elephant trunk it's a it's a hand planer oh what's that it's it's oh you don't know what that is it's like a manual planer it's, okay. What's that? You don't know what that is? It's like a manual planer.

It's a way to shave wood down to where you get it completely smooth. It's the way people used to do things in the old days to get flat pieces of wood. Wow, okay. You can put your whole elbow into it. It's got a good strong handling. Or flat. Flat is really what you're going for.

Or take some of the thickness off. I don't want to confuse it with sandpaper that's why i like when you said smooth smooths are all smooths are all one okay fun all right well that makes a lot more sense than i thought you're like man this picture has nothing to do yeah this is just a stupid looking iron it's an odd angle of the cathedral that's interesting hey if you want to uh see what that looks like we'll have a picture on the post here and if you click that link yeah you make us some dollars that's right if you like some if you go by the book make us some sense you're like really in uh you know talk about optimism yeah yeah we'll make sense and by the way like seriously after reading the the first chapter of this, it's well worth the read.

So, you know, we're talking about it. But if you want to go along with us, definitely pick up a copy. Are we doing a contest on this one? Well, no. I guess we are now. I guess we are. Okay. So I guess we are now.

So, hey, if you leave a comment on this episode, then you'll be entered to win a copy of the Pragmatic Programmer. I guess we should talk about these things before time, huh? Yeah. We should just talk about it in bulk. All right. So let's get on to it. So, you know, this one feels like something we've kind of talked about. Like this is a continuous process, right?

Like if you're trying to hone your craft, like you can't stop. We've talked about this before, like, uh, software development, that's one of those types of skills that you can't just like go to school. And then once you're out of school, get into a job and never again, try to, you know, have to worry about studying it, right? Like you're going to keep trying to hone your craft for the rest of your life in this career. Yeah. It changes so much every day that it, yeah, you're not going to get away from it. If you don't like learning all the time, you might've chosen the wrong career.

Yeah. Yeah. And, and I, you want to say something? Yeah. Oh, I'll go.

So, you know, um, there was this other thing this other quote though where they referred to the a japanese turn term of kaizen which was the concept of continuously making small improvements and every day work to refine the skills that you have and to add new skills to your repertoire. Right. Which is along the lines of like, you know, always trying to, uh, you know,

continuously trying to hone your skills and, and, you know, better yourself. Yep. And for anybody following along also, they have a website that you can hit up. It's prag,

prog.com. So pragmatic, prag, and then prog.com. And one of the cool parts is they have a tip of the day up there. And this one right here, I think, Joe, would be near and dear to your heart. Don't use a manual procedure. A shell script or batch file will execute the same instructions in the same order time after time. Yeah. You know, earlier today, I was doing a thing where I was copying some fields from one class to the other, and I was like,

you know, I'm going to write a little regex to make this easier, and I did it, and I was so happy afterwards. Not that the regex was hard or anything, but I just kind of felt like if I had just done this by hand, it probably would have taken the exact same amount of time. But I got to flex a muscle that I don't flex enough, so it was kind of like a nice, like Hey, look at me, dollar sign one. Hey, just to spell out that URL,

P-R-A-G-P-R-O-G dot com. Yes. Yeah, so on to the first, I think they called these sections. Yeah. But they kind of read like essays to me. Like they all kind of like little things about like a certain topic.

And so this section is called the cat in my source code. And it starts off with a quote that I absolutely loved. And so I wanted to make sure it was said. Again, keeping in line with the idea of the imposter syndrome, right? The greatest of all weaknesses is the fear of appearing weak. Yep. Yeah. And so when we're talking about the cat in my source code, it's kind of like a ridiculous statement, kind of in the vein of, um, it kind of, uh, let's say it highlights what it sounds like when you make a weak excuse for something, because you're maybe afraid of

the consequences or you're afraid of looking dumb. And so what we're talking about here is basically wanting to have an attitude, style, and philosophy of approaching problems and solutions, thinking about that big picture, and taking responsibility for your actions. And sometimes that's hard, right? So like in this taking responsibility, you need to commit to something being done right, even though you may not be the person in full control over everything that's being done, right? Like if you're working on a team or something like that, something doesn't mean you have to fall on a sword, right? If, if you're faced with an impossible situation, which I have, and I'm sure all of us have at some point in time, it's up to you to bring that to light, right? You need to let people know that, Hey, you are asking for something that's truly impossible and this isn't right, you know? So don't feel like you've just got to try

and get everything done regardless. Yeah, I really like the idea too that when you commit to something being done right, you know, and everybody knows that you don't have full control over the aspect most of the time. So if you're working with third-party code or maybe there's timelines and things that deadlines and the existing code base in a lot of ways is not really inside your control.

Like it's already there. It's got existing problems and you're trying to do some stuff within there. And so when you take that ticket or whatever, you accept that task, you are accepting responsibility for whether you like it or not. And so it can be really tempting. And I know I do this. I'm sure everyone does some of this stuff some of the times to basically justify kind of bad behavior or justify mistakes by kind of blaming it on the situation. Like, well, it was late at night is the one that I'm most guilty of.

Like, well, there's a lot of time pressure. It had to be done by Friday. There's some new big demo or some big release or something. And so I just did this. But you can't be mad at me because I was being a hero at the time. So you should be thanking me for even trying. You know, rah. And I think that's not really a fair way to approach it.

I mean, all those external factors, all those reasons are still valid. But I think that the right attitude is to say, you know, I'm sorry, I should have done this better. I'm going to work to fix it. And to me, that's what responsibility ultimately is. It isn't necessarily doing it perfect and committing to do it perfect, but you are committing to owning it and taking care of it. And so if it's messed up, then you're the one that's got to deal with it, whether that's talking to the customers or talking to your boss or, you know, whatever it takes to get that fixed. That's what responsibility and ownership means to me. And it's not blaming the cat for eating your source code. But the, you know, the way we're describing this so far is it sounds like it's more in that kind of situation where you're talking to a higher up, like you're accepting the responsibility to hire up but it could be you know being held accountable to your peers though too like you know don't say like oh well hey uh you know i fell on the sword to get this thing in but i didn't bother to write unit tests for it right right like that that's a pet peeve of mine i don't know if you've gathered

that throughout the show uh yeah like i don't have time to do it. Right. Yeah. Yeah, exactly. Like, yeah. Yeah. I can't, I, Hey man, I stayed up to fix that thing. And, uh, yeah, but I didn't bother to do a unit test for it. So I think the important thing that you said there is when you accept responsibility, you're also accepting accountability, right? So if something goes wrong, it's on you, it's, you're also accepting accountability, right? So if something goes wrong, it's on you. It's, you know, whatever good or bad may come, may come your way because you, you're now the person being held accountable for it. But there's a, there's an upside to this too,

though, is if you do make a mistake because of some problem or whatever be honest about it but offer options right like don't don't make excuses offer options on how you can solve that thing that's huge yeah i'll say that there are some kind of social contract d things like going on so if you're working in a rough code base or something that's like notoriously hard to test or it's difficult to write unit test for because the whole thing is kind of codependent or whatever, then as long as you've kind of expressed and you have an understanding with the other people you're working on in the area, I do think it's kind of okay to say like, listen, we all understand this is a rough area to work on. I'm going to do my best. I'm going to do my due diligence. But we all know that

there's probably going to be problems with it because of some of these factors. And we are saying right now that we're not going to address those problems. We're going to live with that technical debt because it's not worth me taking the time to make that stuff testable right now because you want this stuff done by Friday. And you don't need to have that big discussion with every ticket. I think sometimes you can kind of have a team and manage your understanding. You just have to make sure that you're on the same page and you ultimately have to be responsible for it. So if you take that risk, you do that stuff without, you know, thoroughly testing it

for whatever reason, because it's time prohibitive or whatever, you still have to eat it the next day if it's broken or if it didn't work right, or if it goes out of the customer and it doesn't work. But a lot of this stuff can really be kind of mitigated by just good communication. So if you can kind of say, I think I have a fix for the problem based on the description of it, but I couldn't see the environment. I couldn't get the stuff. I couldn't reproduce it. I don't have a good way of testing this. So I'm throwing it out there. And the next day it doesn't work. Then people aren't going to be as mad as you because they, they are kind of invested in that too. And you kind of brought them along for that ride.

And so that, I don't think that's not, I don't think that's you not being responsible. It's just trying to be real and be, you know, make it, make things work in the real world. It's easy though, to get caught up in like the drama of something about like, you know, Oh, the, the vendor didn't come through on this particular project or, uh, you know, the fault is like, it's in this code base, the fault is there, right? Without even taking a moment to think about the options first, right? It's easy to just get caught up in that kind of drama before you try to offer to even think of the options, let alone offer them up. Yep. It's funny too with the whole trying to blame something on a vendor. The book points out bluntly, you can't blame it on a vendor.

You should have had a contingency plan. Now, that might not be fair in a lot of cases, but it does point something out, right? There's almost always options, and you should be thinking about them. Yeah, you could be mad at the vendor. Right. Yeah, totally. It's hard for you to really blame them. Right.

So, yeah. Also, I want to mention you should be willing to change, but be cautious. And you should know how good your software has to be. And that's kind of another thing I was kind of mentioning there a little bit. It's rough to tell the line because we know that once you kind of start doing dirty things, it's easy to keep doing dirty things. And so, this stuff kind of snowballs. So, it's bad. But I do think it's important to understand with your team, with your boss, and whatever, like how good your software has to be.

And so if you've got that tight deadline and that's not enough time to do things right, which right might be refactoring, taking three months and slicing this thing up and whatever, then everyone has to be kind of on board and understand that. Maybe I'm just justifying bad behavior. I don't know. Pendulum swings. Well, I don't know. I mean, the whole thing of what is good enough, and they even say it in the book, is nobody writes perfect software. It's impossible. It doesn't exist, right?

But if you talk to the people that are going to use it and you find out what are they most concerned about or what are they looking for? That's really what you need to deliver, right? You need to be focused on delivering solutions to what customers want and need. You know, trying to come up with five million different validations for a particular takes field probably doesn't make much sense. So, you know, know what's good enough. Yeah, and someone comes to you and says, this absolutely has to be right. We got no second chance. Do not miss your opportunity.

You got to move yourself with the movement. You got to never let it go. Yeah. Whoa. Yeah. You got to, you got to get that right. And you got to understand that the situation you're in and just be responsible and make sure that everyone's on kind of the same page which brings us to our third tip yep offer

options not excuses yeah and i really like this i know we have all mentioned especially we were like when working with interns this is a common problem that we've kind of seen where someone might come back to you and say like doesn't work doesn't work doesn't work every five seconds doesn't work that you say like did you try of seen where someone might come back to you and say like, doesn't work, doesn't work, doesn't work. Every five seconds, it doesn't work that you say, like, did you try adding a semicolon? They come back,

like, if you're lucky, they come back five minutes later, not three hours later. And like, I had the semicolon. I don't know. It still don't work.

You go over there and you're like, yeah, it's the wrong line. Or, you know, you did, you didn't understand what you were doing. So,

um, I think, um, a lot lucky once you get to kind of more years in it, this kind of, uh, goes away a little bit. That's something that I definitely see more in kind of juniors. But the idea there is that you don't really ever want to go to anyone with a pile of excuses for why you can't do something.

You want to come with a list of what you've done, maybe a list of alternative approaches, like maybe splitting the ticket into easy parts and hard parts or maybe ditching the ticket into easy parts and hard parts or um you know maybe ditching the ticket or maybe bumping it to a next version or maybe rewording it in order to make it more solvable for you but ultimately you never just want to come with a bunch of reasons of why you can't do it yeah and they have a couple of tips for that yeah they called one of them rubber ducking it, right? Just say it out loud and see if it sounds lame.

See if it sounds ridiculous. Or if when you say it out loud and you hear it and it sounds like you're kind of complaining or just whining about something, you really need to think about another way to approach the subject, right? Like some of the options are, hey, could you refactor the code there? Could you create a prototype? Could you make it more testable? Could you automate things? Like those are solutions. Those are possible solutions to a problem.

Was I the only one, though, that was thinking like, wait a minute, rubber ducking is about debugging? Yeah. This is an older book. This book was written in 2000. We probably should have mentioned that. The first version came out in 2000. And then they started the whole Prague Publishing Company after the success of this book. I probably didn't handle it perfectly. Like one way to kind of handle that, like what we're talking about would be to say like, Oh, laptop's busted.

I'm going to go take a nap. And if anyone asks, you know, I can't do anything because my laptop's busted. Another way to approach that is to say my laptop's busted. Hey, I T can I get a VM while this thing's getting worked on? Can I work on tasks from another computer?

Can I, you know, like do you just have to think of a couple different options? Like maybe there's something you can do that doesn't require the laptop or whatever. Those are the kind of examples I mean when I say like come offering options, not excuses. Yeah. And it does not mean spinning your wheels. I think sometimes people think like they have to exhaust every little thing.

And this is something I know that I'm definitely guilty of sometimes too. We're all kind of good on a rabbit hole. I don't want to ask help until I've investigated this one thing. But by the time I really started getting in there, that one thing, it starts being one, two, three hours. And if I had just gone and asked the right person, sometimes that would have been a five minute thing. You also don't want to be the person that I am is every time you've bumped into something.

Yeah, that's what I was about to say. That's the problem, right? five minute thing. They also don't want to be the person that I am is every time you've bumped into something. Yeah. That's what I was about to say. That's, that's the problem, right? Like that's a slippery slope, right? Like you want to have done some research. Yeah.

That comes with experience, right? Like that. Hopefully there's enough communication within a team or, or an organization to where you guys mentioned things that you bump into. And so if somebody else bumps up against that thing, they're like,

Hey, I remember Joe mentioned that. Or I remember outlaw said something about it. Right. I, that's having that open communications key. Now that's also one of the most challenging things is we've talked about like putting all that kind of stuff in a wiki.

Would you call it the other day, Joe? The graveyard? Yeah, the graveyard mausoleum. Where information goes to die. Yeah, it's such a hard thing communicating information like that because if I tell you something about a problem that I saw on SQL Server, if you're not experiencing that problem, it's probably not going to sink into your mind at that time.

Right. And it may just go completely in one ear and out the other. But then a month later, when you hit that same thing, hopefully it triggers that thought maybe, but yeah, you know, who knows if you just put everything in the wiki, then it just gets so noisy. No one can ever find anything useful. And so no one ever goes there. It's so crowded with other crap.

Yeah. How do I search this thing? I't know yeah yeah uh so each uh each section here has a couple of challenges so i thought it might be fun to kind of adapt the ones that were easy to adapt to kind of ask uh ask us so um how do you guys feel when someone comes to you with a lame excuse when you're at a like a place. So if you're at the mechanics or something and someone gives you a bad excuse. I'm trying to think of one that's actually happened recently. But yeah, you're talking about if you walk up to a counter and they're like, I'm sorry, sir, but we didn't bake enough things today like well i know i'm like one i had recently where it's like i went to i

called and ordered some food and you know they take the number to take your name and i get there and i'm like you know hey here's my name and then five minutes you're sitting down you're waiting and uh finally uh you go up and ask and know, Hey, I ordered this 30 minutes ago. I want to just check, make sure you guys are working on it. Oh, well we're out of the fish today. And so we couldn't make your meal.

It's like, well, you could have told me 30 minutes ago or five minutes before that or something. And so it's kind of like, Oh, it's your fault for not knowing we didn't have the fish today. Right?

Nah, it's, it's definitely irritating. I mean, you try and be patient, but, but the whole point of this, right, is if you feel annoyed when somebody's doing that to you, how do you think the other people feel when you're doing it to them? I was going to say, there's probably something here that comes with age too, though, right? Because I picture a younger me in some of these situations you're describing. I'm like, Oh, that would make me, would have made me so mad. Now I'm like, I'd probably just be like,

whatever. I was listening to the latest Cody blocks podcast. Anyways, I was just going to say, I really wasn't hungry for fish anyways. Right. Nice. Yeah,

we're getting all that sums it up for the cat that ate my source code. Next one is software entropy. Yeah. So starting with, you know, entropy refers to the amount of disorder in a system, which I never like thought of it that way because I've always thought about entropy in terms of like complexity or, you of complexity or randomness or something. I don't know that I'd ever thought about it. I think it was chaos. Yeah, chaos. I think it's sort of, but that's sort of what disorder is. Yeah, I don't know. I don't know that I'd ever put that much thought into it.

Well, I guess when I typically think about the word entropy, it's related to like security and passwords like you know right yeah you you want you want more entropy so you want it to be you know you the complexity is there like yeah i disorder though yeah you said disorder i'm like okay yeah i'll buy that yeah i like it i like it the the part that kills me is they say it's also known as software rot yeah and you gotta say it like that much more you gotta say it like that too software rot rot it's gonna sound bad i gotta say this is probably the the section that stuck out with me the most even though i probably read this thing like 10 years ago maybe more and this was

the thing that kind of that i like years later i always think about and even though i think about all the time i'm still not so so good at it so when they talk about this particularly they're talking about um how things kind of degrade over time and systems towards tends towards that chaos since the whole i don't remember the physics law whatever entropy uh so you can yell at me later about that if you if if you want. The idea is that, um, it's easy to, to start letting things go and start making little compromises that end up over time making things actually really bad and really trashy. And so like for me, an example might be like, I hate, uh, I hate foldering laundry. So like maybe on Monday when I do the laundry, I decide not to put it away or maybe I like

put two shirts away and I leave the rest. And then I do that again on Wednesday. And like eventually I get to a point where I have no clothes. And I've got this massive heap that I definitely am never going to fold. And so I just made this giant mess. And it all starts with like me not wanting to put one sock away or getting lazy on one little thing. And before I know it, I've slipped in in this disaster and all of it was preventable at many points along the way.

But it's like, I never really realized that I was contributing to this disaster when I was doing it. It's a way of kind of making short term decisions based on your short term once and ignoring the longer, longer road. Big picture. So if we were to put this into, like, I mean, this is a segue into this whole section,

but where we've seen this happen, we've all seen this happen, is if you take a library, you know, a library of code, like, you know, DLL or something like that, right? Or whatever your language is equivalent is a package, whatever. The more well defined it is, the better the name is specific to, you know, the single purpose for that thing, the better you have tests that cover it, you know, things et cetera, et cetera, right? Then the more likely it's going to stand the test of time. It's going to hold up. But if you just have a dumping ground of some package, library, whatever, then everyone else is just going to contribute the same junk. They're going to contribute their junk to it as well because they don't know where to put it. And everybody's decided like, well, this is the garbage pit

where we just dump all of our utility stuff. This is where we put it, right? But that pristine little one over there that has like the very specific name, it's got a single purpose. It's clear that my string manipulation methods don't belong in the cache uh dll right like you know it's not going to get it's that that that cache one for example you know if it

has a better name it's going to stay pristine right like versus a helper's library or utilities library it's going to become garbage that's That's where the rot is going to happen. It does tend to lean that way. Speaking of rot, have you ever heard the expression that one rotten apple will ruin a bunch? Mm-hmm. Yeah. So the idea there is like one rotten apple, one starts to go bad and it emits chemicals and stuff. The next thing you know, they all start going bad.

So if you don't get that one bad apple out in time, then you can actually lose a whole bushel of apples too early. And all these things are kind of tied to the same point is that these little things end up having a big impact. And so if you don't take care of the little things, then things can suddenly go quickly, go bad before you even realize it. And this whole chapter is kind of based around this notion of broken windows, which is kind of a popular study and a set of papers that came out a long time ago. I think maybe even in the 70s. I forget. I don't remember. But the idea was that you would have... People are trying to study why good neighborhoods go bad. So you might have a city neighborhood that looks okay. And then

somebody goes back and checks on it six months later and the place is trash, trash in the streets. There's cars, you know, busted, broken into. And the idea was that all it would kind of take was like one broken window that goes unfixed. And the next day the other neighbor sees the broken window across the street and decides, ah, screw it. Well, I'm just going to leave my trash out here. And the day after that, someone else's car dies and they just leave it.

And so these things kind of build up because people start seeing culturally it's acceptable to let these little things go. And next thing you know, the whole place is trashed and has transformed. And a funny way of saying it is it's all because of that one broken window that didn't get fixed. That one compromise, that one thing that you let go eventually led to this big disaster. And it's amazing because the translation into code is exactly that. Yeah. Just what you said. Somebody's like, I'm just going to,

I'm not going to create a unit test right here. I'm just going to dump this in here right now. Nobody else is creating a unit test for it. Why should I start? And then the next person that comes along is going to do the same thing. And then you've basically just created this attitude and this culture of, yeah, he didn't bother. I'm and this culture of yeah he didn't bother I'm not gonna bother she didn't bother I'm not gonna bother right it's just the area where we

put our code that we don't care about exactly and and it has a it has a steam rolling effect like it just gets bigger and bigger and bigger I liked it because they're like this section it kind of felt like a blend of like you know things that we learned from uncle bob that were you know here right yep and they said this this goes back to the boy scout rule if you're in an area try and make it better right if you're gonna do something there now sometimes you get into it we've all done this where we're like a day in you just start backing out the code that you tried to do but if you can't fully fix something try and patch it make it a little bit better than what you got in there with because that will start creating that culture of people

doing the same thing right i mean it's a big deal and i love what they said next was neglect accelerates the rot it It accelerates it. It makes it go faster. You start going downhill quicker when you neglect those things. Yeah. So we mentioned the first person to kind of skip those tests and otherwise nice project. And then you imagine like fast forward two years and then someone checks in

something. Someone says, Hey, where the test you say, you kidding me? The last like 17 people who worked on here didn't write any tests and now it's untestable mess and you want me to be the one to start like screw man i didn't start the fire this is this this is the world we live in which is the thing i kind of said in the first section

and i i hate when i say that and i hate when i do it because i hate how i know it turns out based on kind of reading this and agreeing with it but it's still something i know i'm guilty of like i was just kind of preaching a minute ago you're like culturally it's still something I know I'm guilty of. Like, I was just kind of preaching a minute ago. You're like, culturally, it's okay because everyone has a tacit agreement that all those things that I said were basically furthering that notion. I was saying, like, it's okay to break more windows because everyone's breaking windows. And I know that's a bad argument. Even as I was saying, I was like, oh, crap, this is the same kind of thing that I hate about software entropy and the whole broken windows thing. So, you know, I don't know really what the right answer is. The pendulum for me swings back and forth,

but I do think there's a whole lot of value in kind of keeping this in mind and really taking it to heart and thinking about it whenever you go to make that first little compromise. Or really, I don't even want to say first. I want to say any time you make a compromise, you're worsening the situation. All right. Well, maybe not the answer, but like maybe to help.

Pro tip. Don't be afraid to shame somebody on a PR if you don't see unit tests to go along with it. I totally agree. Or if you're like, oh, that code probably shouldn't belong in that library. It's going to be so hard to add that. And yeah, it's definitely awkward when you're like the first person to say like, all right, so this would be a new guy on a team and new person on a team.

And she came in and you're like, whoa, whoa, whoa. I met you guys in an interview. You seem nice. I keep seeing guys. So I met you people in an interview.

You seem nice. So here's the thing, right? This is just as quickly as you can make things go downhill by not caring or skipping on just those little things here and there, not introducing a good pattern or introducing a bad pattern or something. You can do the inverse as well. If you are somebody that goes in and takes care to clean up code, like you said, naming something well and making sure that that has one defined thing, right? That can lead to other people saying, Oh, you know what? I don't want to be that guy that messes this up, right? Like I don't,

I don't want, I don't want this to be called out in the next PR that I did this. So creating that culture of making things clean and keeping them in a good shape can also help drive others to doing it. Well, but also to like, I mean, honestly, mean, honestly, between the three of us, right? We've each introduced new libraries that have been, you know, had a single purpose, right? They were covered well with tests. They were, you know, well-structured, well-organized, whatever. Now think back to like, just pull out one example of your library or Joe's library or whoever's library, right?

Now, how many PRs did you have to see go to that since initially being developed? Almost none. So, I mean, if you take the time to, you know, it doesn't have to be perfect, right? I mean, there might be things you're like, well, if I had to do it over again, I'd probably like, there's some lessons learned. I would have changed some things, right? But, you know, it was clean enough that it survives the test of time. Yep. Typically, the PRs that you'll see to things like that are in addition to functionality for what you needed, right?

A new piece that's added instead of, I'm just going to throw some random code in here because it's well-defined. Like, you know, going back to the clean code days, naming things well and breaking up pieces into their proper existence matters so much because those things won't get touched much, right? If you have some good unit tests written around them and you break them apart cleanly, then it sort of keeps this whole thing going where people will want to do the same thing because, hey, you know what?

I didn't have to mess anything up and I kept this clean also. I mean, I remember, Joe, there was some stat that I remember you referenced. I think it was you referenced a long time ago. It was like Google did some study where it was like the files that tend to change the most were the ones that... How was it? It was something about like a correlation between bugs

and how often a file changed. Do you remember what I'm talking about? I can't remember exactly how it worked. Yeah, I love that study. Can you say what it was again? I can't remember exactly how it worked. Yeah, I love that study. Can you say what it was again? I can't remember. If I don't link for the show notes here, I'll find it. But that was the gist of it, that they could predict where the bugs would be based on the commits because they would just look at the history, look at the most common, I think it was like 10% of files that were being touched in the last X days and those would be a good predictor for where the bugs were going to be because what would happen is

the files that were touched over and over and over again would kind of keep out at the top there and the files that were only changed once every couple of months would kind of disappear. And it's the ones that didn't change often that were the problem. So you could find these hotbeds so if you could kind of attack these hotbeds split them up into these smaller parts you could actually reduce the total number

of regressions. That's really cool. Yeah, I'll find that. That was one of my favorite studies. One of the things they say here, if you don't have the time to do the things properly, maybe just consider boarding it up or commenting out the code, display some sort of warning, you know,

do something to call attention to it. You know. But how do you come out? Like, okay. So you don't like the code and you don't have time to do anything about the code, but you can't necessarily comment it out. I've seen it done.

You could write a to do statement. Yeah. But you can't comment it out. Yeah. If it's working, like it might not work at working. Like, it might not work well. Yeah. I was kind of confused by the comment it out thing because I wasn't sure exactly what that meant.

Yeah. But, you know. Mark it as obsolete. Right. One thing I want to bring up, too, is this particular study, at least since I read the book, I've heard about it a few times kind of being mentioned controversially, I guess. There were some other, particularly some police departments and whatnot that kind of

took this lesson to heart too, and they started doing things like cracking down on more minor crimes, which then very quickly got associated with some really bad stuff like racial profiling and whatnot. So you can read about that. We'll have a link to that in the Wikipedia. We're not going to go into into that here but i just thought it was kind of interesting to bring up and i could also kind of see how even in code like if you really attacked

you know all those little tiny things it's kind of like writing tickets for sort of speeding for speeding is that really going to decrease the murder rate based on this article the answer is yes but you know it may not be worth it for you. And so, if you're spending a lot of time really arguing over spacing and files or whatever, those little things, then maybe it's not necessarily effective. You just got to, just anything else. And this whole book really preaches that you should be taking everything with kind of a grain of salt, thinking about it critically, evaluating how well it's worked for you and give it a shot. We do have another challenge here. So the question they asked here was, can you tell

when a window first gets broken? What's your reaction? And if somebody else broke it, what can you do? I think Outlaw already said you publicly shame. Well, that's if you notice it, right? So can you notice it? Well, that depends. If it's a dumping ground, then it's definitely going to be harder to tell. But if you have some library that has a very specific purpose and somebody puts code into it that clearly has nothing to do with that, then yeah, you know, it'd be easy to just see the like, Hey, that, that doesn't even fit here. Why, why are you putting that here?

Yeah, that's, uh, that's true. But when you have libraries that like have, you know, every purpose under the sun, then yeah. the only other thing you could i don't even like you can't really have a reaction to it other than like hey we got to change this we got we got us we got to break this habit right we got to break this thing apart and but that's not when a window first gets broken right no it's not yeah it's already walked yeah you walked into a neighborhood that's broken down now. Yeah, I guess in fairness, I was thinking of the situation where you're the new guy on the team, right?

And so it's like, oh, this is already. So, yeah, I can't tell you when it got broken because it was broken when I got here. Yeah. Yeah. I want to mention, too, when you've got a nice, say, isolated library that's all doing one thing and it's all tested, if you go in there and hack a bunch of stuff in, it feels like a crime against nature. It feels horrible to get in there and just kind of hack something apart and know that you're doing the wrong thing. But if you're in a code base that's already kind of been doing that sort of thing, then cutting a couple corners doesn't feel like anything. It just feels like par for the course.

Yep. So I think that's really what it's emphasizing and i know for me um like i it's really easy for me to kind of get caught up in my own head so i could be like super self-critical about anything and everything and that includes a lot of coding so i know sometimes um i'll think about like two or three different ways to solve a problem and i won't be happy with any of them so i'll kind of think about it and start with it i'll end up going with one but but I still won't like it. But I won't be sure that there is a better route. At least if there is a better route, it usually involves like rejiggering a whole bunch of stuff in order to kind of make some new use case fit.

And maybe I think that isn't something I'm going to be able to sell or isn't going to make sense or whatever. So I'm not really sure what to do about it in cases like that other than just kind of like check, go with the least bad option well sometimes you just got to pick it and move on right this goes to the whole is it good enough and you're writing things that are effective and they're they're good right like you're not introducing something bad you're just not exactly as happy with it as what you want to be right yeah and i don't mean it sounds so negative that's that's just those are the things that uh i really like fixate on and those are things i remember the most but i think kind of Right. more technical debt instead of taking it away. As long as you thought about it and made a conscious decision to do one thing or another, then that's good. And it may not be the best.

It may be controversial. Maybe people will disagree with you. But at least you did a good thing by evaluating it. Yep. Yeah, again, hard to not be a perfectionist, right? It really is. All right, so this next section is Stone Soup and Boiled Frogs.

Which is such a tasty title. Seriously, there were so many good stories in this book, and I think that's why I enjoyed it. It's very story-backed, right? There's the tips, and then there's stories behind them. Yeah, go ahead.

I was going to say, I like how this one dovetailed from the last one because the question with the last one was like, don't let things get bad. Well, the obvious question there is like, well, what if things are already bad? And you're like, well, let's tell you, stone soup and boiled frogs. Yep. Be a catalyst to change. And this is one that I actually feel very strongly about is, you know, talk is cheap, man. It sort of drives me crazy sometimes where people talk about things and, you know, we need to do this or we should be doing that or we should be doing that. And the thing is, and I've been guilty of it, right? Like, oh, I'll tell my bosses, hey, we're doing this wrong. You need to do this. You need to use this technology, whatever. And the problem is if they can't see, if they can't see it, if they can't touch it, if they can't feel it,

it doesn't matter. I don't care how much you talk about it, it doesn't matter. So, you need to be the catalyst to change, meaning you need to be doing something to help push that change. Yeah, the thing I really liked about this was it was basically by that catalyst for change and not just talking about it, they're basically describing like giving people a hint as, you know, giving them a taste to like what could be and then letting them question you about like, oh, well, what if we were to do this? Or could could we also make it do that? You know, so eventually it's like you get that thing that you wanted to do, like whatever that change was that you thought would make things better, right? Without having to just talk about it, you can get them excited about it and interested in it. And they actually had a statement for what that is, which is people find it easier to join an ongoing success. So you create that change and then they look at it and they're going, oh man, that's awesome. Hey, what if I do this or what if I do that? Because it's

a whole lot easier for people to jump on that bandwagon to get behind something that they haven't seen. And it's so true. I've seen it happen so many times. Yeah. I wanted to mention the, the story behind stone soups. So that was kind of cool. I don't think we really hit on it. Nope.

But, uh, and you may have heard, have you guys, have you guys heard this story before? I don't think so. No. Okay.

Uh, I don't know where it originates, but, uh, I think I've heard it once. I think I had a kid's book with it actually. But the idea is a couple soldiers come to a town, and there's food problems going on. People are kind of locked up in their houses, and one person has carrots, and one person has potatoes, and one person has meat.

But nobody's sharing because there's a famine going on, and so everyone's kind of trying to stick to their own stuff. But it kind of stinks that this family, all they got to eat is a bunch of carrots. And over here, this guy has only got meat. These things are better together. These soldiers have an idea. Like, tell you what, let's grab some rocks and throw it in a pot and start boiling it. And this villagers kind of come around to see what's going on.

They say, oh, we're making stone soup, but it'd be better with carrots. And the villager with the carrots says, oh, I got a couple of carrots I can throw your way. So it comesager with the carrots says oh i got a couple carrots so i can throw you away so it comes back some carrots and then next you know then the the potato guys come in with the potatoes and then the meat person is coming in because they all want to contribute to something because they see that it's looking good and that soup is sounding really good much better than them eating potatoes for you know 11 days in a row and so after they get this kind of ball rolling it snowballs and everyone works together and then everyone gets to have like a really great square meal for once rather than living in their own little silos because they're kind of afraid. And I think this is like the complete

opposite of the broken windows where like you start with one broken window and things just get worse and worse. This is like you just get the ball running, you throw some stones. And actually, I read that in other versions of the story. Sometimes it's like nails or like even act soup. They just throw some tool in the water and start cooking it. And that's enough of a catalyst to start getting, getting things moving in the right direction, getting everyone to work together. Although I think Mark Watley might be happy to survive off of potatoes.

It's Mark Watley? I don't know. No? No one? No. You've neither seen nor read The Martian? No. Oh, gosh. I don't remember names for that. Uh-uh. What a miserable book. Why you gotta go there? What? Miserable?

Oh, my gosh. Yeah, it starts off miserable and it gets worse. I don't like books like that. So check this out. On this whole thing about talking goes nowhere, we've seen this happen. All of us have seen this happen, right? Hey, we should improve the code base. We need to do this.

And then the next thing you know, there's a meeting, right? And there's five people involved. And then the next thing is, oh, well, we need to get the managers to get behind this too, right? And there's five people involved. And then the next thing is, oh, well, we need to, we need to get the managers to get behind this too, right? Because, you know, if we're going to spend time improving the code base and doing all that kind of stuff, then we need management to sign off. And then before you know it, before anything ever happens, you have all these barriers, right? Because now management's like, no, we don't have time for that. And then, and then all of a sudden your boss would be like, no,

we can't do that right now because management said we can't do that. Oh, and then by the way, we've got these other. So by going that route and not taking the small little steps to try and just start just inching your way towards a better end state, you've created barriers when all you were trying to do is get the ball rolling, right? So. I just wanted to use some aspects in my project. Oh, my God.

And suddenly you need five things to go right to even consider it. Right. Yeah. So, that's what we're saying here is being a catalyst to change isn't talking about change. It's taking it upon yourself to actually be that person that takes those steps. And that matters a lot. I mean, for those who are probably questioning what that joke was about,

I mean, that's a real life example that we hit where we wanted to use some examples. I don't know if you even remember this, Joe. Obviously, Alan remembers that I could see by the look on his face. But it became like a whole big conversation. Like literally, we had a developer meeting with developers from multiple parts of the organization, not just the ones that were going to be using this code base at all or even write in that language. But everyone to discuss like, well, should we? Like, what's the value? And then, well, which one of the frameworks should we use? Like pros and cons and, you know.

Yeah, it was a thing. All to use, you know, a third-party aspect library. Yeah. Got blown way out of proportion. Yeah, but the alternative is to kind of be a little political with it. Like, by kind of starting things going, you're, you're being a little tricky there.

Yeah. It depends on your approach, right? Yes, it could be. We're kind of saying there's a proper channel here, but don't do that because you're going to get stuck. Well,

I mean, the thing is there's, I think some people want to get, they want people to get behind them in what they're trying to do before they even start doing it. And that can be a problem, right? Because someone would be like, why are you focusing on that? We have these other things to do, right? So I don't think that taking the right steps to do something has necessarily got to be politically motivated. In some places, it might have to be, which is sad.

And if you're in a place like that, then I'm sorry. And maybe you should consider other places. But that's not what we're saying, right? Like, we're not saying go behind somebody's back to do something. We're saying take little steps to improve things. And then as that happens, then other people want to get on and do the same. I think I emphasized on a little bit. I'm sure you've been in a situation

too where something you didn't agree with got slipped in. You're working like ho-hum and all of a sudden someone's like, hey, by the way, I ported some stuff over to Vue, so now we're a Vue and Angular shop or whatever it is. You're like, whoa, wait, who said that was okay? Now you're taking things in a different direction that I didn't want to go to. You're like, well, wait, who said that was okay? Now you're taking things in a different direction,

a direction that I didn't want to go to. You're bringing in a library that I specifically didn't want and just kind of snuck it in there, back channel, and now it's got to be a meeting to take it up because we've got a conflict. Well, that's different, right? Being clear here, I think there's a big difference between trying to introduce fairly massive architectural decisions or infrastructural decisions versus, Hey, let me improve the code base we have. Right. Like there's,

there's a big difference. So yeah. SQL server shop. Someone's like, now I added a MySQL database because it's free and I put three of the tables over there. So just, you know, like, Oh no, Oh no. Yeah. We got to talk about that stuff. Yeah. That's a little bit different. Yeah. You might be thinking that you're helping improve things. Right.

So, that was tip five. You might be fine for proof of concept. Yeah. That's true. That's totally true. All about perspective. There's a fine line. Fine line.

So, stone soup table. It's tail lined up with the tip number five, be a catalyst to change. And tip number six is remembering the big picture. And the tale they gave there is a tale, a story that I've always hated. Have you guys heard this one before? I think I actually had heard something like this before. Let's have a horror story. I've never tried it. I want storm. I've never tried it.

I want to. I've never tried it. In fairness to the authors and ourselves. Yes, and the frogs. We've never tried it. Yes. Yeah, gross. So the idea is that if you put a frog into boiling water,

it's going to hop out and it's going to be a big mess. It's not going to go well. But if you put a frog into regular water and slowly's going to hop out and it's going to be a big mess. It's not going to go well. But if you put a frog into regular water and slowly turn up the heat, then it'll just kind of calmly sit there until it's cooked, which is a gruesome tale. But the idea there is that you want to constantly, you don't want to be the frog. You want to constantly review what's happening around you. Otherwise you lose sight of the big picture. And so just because something is only a little bit different and a little bit different and a little bit different doesn't mean you're not heading in a horrible direction. Right?

Yeah. You don't, you don't want to be sitting there while the buildings are falling down around you thinking that, Oh, everything's good. Right? Yeah.

Yeah. I think this whole book is kind of about taking that step back and thinking about it. But I did want to bring up the book. Actually book actually had this kind of a challenge in there. How do you know whether you're making stone soup or frog soup? And that's what we kind of alluded to with the library. It's like if it's a good change, it's stone soup and you just got the ball rolling and everyone's happy. If it's a bad change, then you started the frog boiling and nobody realized that you did something horrible until it's too late and everybody's frog is cooked man i would love to believe that the stone soup is good for all

and and everybody walks away with a smile but i think there's varying degrees of what you're doing that you think is good other people disagree with and vice versa like so i don't know. There's going to be that library that you write. Okay. And it's going to be a single purpose library. You're going to take your time to give it good names. It's going to be structured well.

You're going to have unit tests on it. And somebody is going to not like something about it. Right. But they're not going to like it enough to change what works. Right. Like what you did solves the problem. It checks the box is good. Right. Like they might have something nitpicky that, you know, they would have done different,

but they're not going to go and rewrite their own thing. Right. So the soup is good. Yeah, you might have wanted steak, right? But if the soup is good enough, it provides enough nourishment, then it checks the box. Yeah, yeah. That's still a tough one. I mean, sometimes it's hard to get people on board with what you think is the right way. And the issue is, is sometimes it's feelings involved or it's personal preference involved or whatever.

And so sometimes whether you're doing good practices or whatever, like there's some people that think you're being dogmatic about it. Like this is the way that you have to do things. Right. And that's not necessarily it. So it's really hard. Like this question sort of frustrates me because I've been caught on both sides of it. Oh, we all have. Right. And I don't like being caught on both sides. Look, if you haven't been caught on both sides of this question yet,

then you just haven't been in the career long enough. That's true. It's so true. And it's frustrating, especially when you're trying to do something that you think will help make things better for everybody and you get pushed back or even on the on the other side of it where you don't realize that you're going down a bad path because you've just been following suit with everybody else like it kind of sucks right so um yeah i'd say i've been there yeah so the answer is it depends yeah it does it really does but the important thing is just just to kind of ask yourself if you catch yourself kind of getting involved or starting up one of these kind of grassroots kind of not wholly above the board initiatives and you need to just be careful to ask yourself like, am I doing this because this is the easiest way to do this and it's right? Or am I doing this because people aren't going to be happy about it and it's going to be contentious? Am I making stone soup or am I boiling a frog?

That's actually – Make your best decision. That's an interesting insight though, what you just said is – and I'm curious what you guys do about something like this. Do you back off something just because people don't want something? Even though you know it's right or you believe it's right, do you back off just because you don't want to fight with somebody about it? Oh, yeah.

Yeah, there's lots of things I do agree with. But it's one of those things, like I mentioned earlier, I'm so self-critical about everything. I'm constantly kind of waging this war for myself. So there's constantly stuff I see in other pull requests or someone will start a library and I just flat out won't like what they did. But they'll feel strongly about it. And the way I kind of think about it is like they really feel strongly that this is the right way. And I feel 65% that it's wrong.

So I'm going to let them win this one because I'm wrong all the time anyway. So, you know, in this case, I'm willing to live with what I think of as that mistake in order for the greater good of them kind of having something they believe in and just sending this one out. What about you, Outlaw? I mean, I'll say my piece, you know, I'll say my part. And then you know, depending on how passionate I am about whatever the particular thing is, will dictate like how long I might talk about it. So you do, what's it called when they stand in Congress?

Filibuster. Oh, no, no, no. You filibuster people. No, I don't know that I've ever tried to filibuster anyone or any particular topic. But now that you mentioned it, I'm going to like add that to the repertoire. I'm going to do that. No, but I mean like, you know, if you don't really care, then you might just like, you know, say your one or two sentences about it in 30 seconds and you're done. Right?

Versus if it's something that you're a little bit more passionate about, you might talk about it for five, ten minutes or whatever the conversation warrants, right? You're going to voice your opinion an appropriate amount of time for what the particular situation warrants, right? Or inappropriate in some of my cases. There's no doubt about it. Yeah, and I'm sure I've been on that side too, right? Yeah. That's honestly, I mean,

I guess this is the hard part, right? Is knowing when to just be like, you know what? I've said my piece. It's time to move on. There are some times that some things are just hard to let go. But yeah. I can grab forever.

Even if the person did say, okay, you know what know what i'm gonna go change whatever you say i i agree and they come back like i'm still gonna be able to pick well i can pick holes i can find bad things about anything so it's just a matter of me kind of trying to decide like whether it's worth that fight or not so i and i'm sure i do that to you guys all the time where you're upset about something or disagree with something. And I'm like, is it worth the fight? Because that's the angle I'm always coming from. And I don't know that it's the right angle,

but it's definitely a way I have thinking about things. No, it's a good way to think about things. And, and sometimes it is right. Sometimes you, you're like, yeah,

this is absolutely worth the fight. And then there are other times that you have to look at it and be like, yeah, this doesn't matter that much. Right. Um, but times that you have to look at it and be like, yeah, this doesn't matter that much, right? But I think it all goes back to the, you know, the broken windows type thing. You know, don't start breaking windows in the neighborhood, right? Don't be that guy that lets that happen.

Don't be that girl that lets that happen. You know, do your best to make sure that you're moving things forward. That brings us to the next section, good enough software which is something we kind of hit on earlier um and one thing they were advocating here which i thought was kind of interesting was just uh having the users participate in determining if something is good enough especially when we're talking about like software quality that definitely uh kind of like hits me wrong because like they're just gonna say it's good enough as soon as it looks good enough yeah there was an interesting you know point in here like you you often like ask for requirements and have a conversation about what the requirements are but

you don't really talk about like well how good do they do the users want the software to be right how how good do they want the end product to be? I feel like they don't care, but maybe I just never asked. Like they want it to be fast. They care about their user experience by it. Maybe, maybe they do care if they can't get their changes in quickly. Yeah. But if, if, if it comes at the cost of like, Hey, um, I could give it to you today and it might take you three steps, you know, two, three total steps that you have to click on.

But if you can give me two weeks, I can make it in one step, right? Like that would be fine. I can do the three steps. Like who cares, right? Right. You know, sometimes it can be good enough. Yeah. I think that I'm probably pretty good about keeping my head straight about this sort of stuff.

When it comes to tickets or whatever, maybe I'm too good at it. The effort I'm putting in to do this feature doesn't seem like it's worth the value you're going to get out of it. So let's see if we can find a common ground. Maybe I'm compromising too early or maybe that's just right. I just spent a ton of time. That's what I went back on a ticket and said. I don't know if you realize what you're asking for, but it's four days and I can get you 90% of what you want, or maybe even 100% of what you want in another way. That's going to take me four hours, right? Sometimes they go for it. And sometimes they

say no, and I don't fight it. I'm not trying to get out of work. It's just sometimes I hate when I'm, I feel like I'm doing something that get out of work. It's just sometimes I hate when I feel like I'm doing something that isn't very important. There's other things I should be doing instead. You want to let them make the decision on the value of your time, essentially. Yeah, it's funny because that leads into this next thing, which is sort of, I don't think I'd ever thought about this, but it's pretty interesting. Tip number seven is make quality a requirement issue. Like you think about you have QA teams and you have QA people and all that, but is it ever a

requirement? Suddenly you didn't realize you were reading a test-driven development book. I mean, that's the thing is you, when you say make, make quality or requirements issue, that means you're going to be assigning time and value to quality, which is usually just an assumed thing, I believe. I know for releases and stuff, it's pretty common to say, like, we're not going to let this go until all criticals are done, but we're going to live with the highs and mediums or something, you might cap that off. And so I can understand it for release,

but I would love to hear more about places that say like 80% code coverage or, you know, the obvious ones like no warnings or whatever, stuff like that. You might have some, like some hard rules around what you kind of let go or not. And so you may not even let it get checked in if it's below a certain

threshold. I do like this quote here. Great software today is better than perfect software tomorrow. I've definitely been at companies where they would go through the waterfall thing where they'd plan out the software, get all the requirements up front and then say, it's going to be a two-year project. Right. Well, I mean, that's how it used to be though.

Right. But then by the end of that two years, that project and that software was no longer relevant because the business changed or the requirements for what was there changed. So that's where this part is super important is if you can put out something that's useful to the customer, whoever that is that's going to be using the software, and you can get it in their hands faster, then you'll not only win for the customer, but you'll also help shape better software. Because as they use it, they'll find other things that will help it make it better as time goes on. It goes back to the MVP. Yeah.

Yeah. time goes on you know yeah it goes back to the mvp yeah yeah uh yeah so um i think that's about it for this one uh there's a couple other things like uh don't over embellish or over refine we talked about gold plating being an anti-pattern before we mentioned some tooling too around like um you know setting those thresholds for like say a a QSONAR test coverage. The challenge here is, is it easier to split apart – or, sorry, is it easier to get a monolith or a modular design to a certain quality level? I kind of felt like it was a no-brainer. It was kind of a weird question.

I would think modules. You think it would be harder? Is it easier to get them easier yeah sorry yeah easier no i think yeah modules yeah because you can it what outlaw said earlier you have a single purpose right or you have a well-defined purpose on a module it's a whole lot easier to make sure that module works in a vacuum. You know? Yep. It does that one thing. Yes.

Yeah, I totally agree with that. 100%. It's almost like, it's almost like a, oh man, what would be the term I'm trying to describe here? Like, like a factorization. Like if you have the more things that it has to do, then it's like, you know, it just starts to increase how difficult it is to verify it, you know? Yep. This episode is sponsored by Clubhouse.

Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products their customers love. While designed to be developer-first, the UI is simple and intuitive enough for all teams to enjoy using. Clubhouse is truly built for developers by developers. And you can tell because they've sprinkled Git tips throughout the UI and they even make a point to highlight open-source projects that integrate with them.

Yeah, and they're always introducing new features. So now they're introducing a new clubhouse for Android. So if you have an Android phone or tablet, you can get a brand new experience on that device. And it's easy for people on any team to focus in on their work with a specific task or project while also being able to zoom out to see how that work contributes to the bigger picture using the fast interface. With a simple API and robust set of integrations, Clubhouse also seamlessly integrates with the tools you already use every day like Slack or GitHub, for example, getting out of your way so you can focus on delivering quality software on time.

Sign up for two free months of Clubhouse by visiting clubhouse.io slash codingblocks. Again, visit clubhouse.io slash codingblocks to get your two free months and see why companies like Elastic, FullStory, and LaunchDarkly like Clubhouse. Hey there, coming up on survey time. But first, you know, we got to ask you to please leave us that review if you haven't already. We really appreciate it. It helps us out a lot. And we really enjoy reading them, especially the names, as you know, from listening to the show. So if you could, go to codingpox.net slash review.

And we try to make it easy there for you. So there's various links. And you can go to something like Stitcher if you don't want to install iTunes or you can go to iTunes and leave it there. It's a big deal. We've also got Podchaser links and a few others. So if you could leave a review there, it really helps us out a lot and we love you for it. All right. And so like Joe said, it's survey time.

No, I'm just kidding. Time for survey says. All right. Survey time. Come on, Joe. Get with it. Survey time. All right. So back in episode 102, we asked, how many conferences do you go to per year? And your choices were, I usually average one to three conferences a year, or somewhere in the range of four to six, or more than six, but nothing crazy. Or I go to all of them that I can afford or my company can afford, or I travel all over speaking at conferences, so I go to too many, and lastly, zero. I don't like them. They're too expensive.

They take too long. They're too far away or some other similar reason. So, Alan, let's start with you. Which one and what's your percentage? So, I think that people are going to say zero. I don't think it's because I don't like them, but I think it's probably the two expensive or they're too far away or that, you know, that kind of stuff. And I will go with 40%. Zero at 40. Wow.

All right. Well, thanks for that, Alan. Was that your number? No, I'm going to go under that because yeah I still think the answer is going to be zero unfortunately

really like for me and I think for you guys we've got a lot of conferences that are like free or cheap or that are Saturdays or convenient

but I don't know that that's the case for most people in the world so I'm going to go zero and I'm going to say we got six options. So 17%. 17% for zero.

So 040 for Alan, 017 for Joe. Price is right rules. Yep. Hey, you guys are so pessimistic that nobody goes to conferences. No, no. I would love for people to go to conferences. I'm just choosing what I think they chose.

Well, you both got it right. Sorry. Your pessimism won out. And it was higher than 40, apparently. But Alan wins. Whoa! It was 63%. Whoa. Yeah. Wow.

It was 63%. Whoa. Yeah. Wow. Well, we were going to do coding blocks con, but you ruined it. Thanks everybody. So coding blocks con is off now. It's done.

Yeah. No one's going to show up. If you've already booked travel, I hope you got a refundable ticket. Man, that makes me want to do a follow-up survey one day and be like, hey, why don't you go? Is it because they're too expensive? Is it because they take too long? Is it because they're too far away, et cetera? You know what I'm saying?

Well, your wish is my command. I will make a note of a follow-up survey. Because I fully expect that a lot of it, I mean, dude, like Microsoft Build, I would love to go to Build. But, man, that's like $2,500 for the ticket to get into it, not to go flight, not hotel, not like you're talking a good $4,000 to go to that event, you know? And Hey, you know, uh, you're leaving a comment on this episode to, uh, enter into the contest for the book. Anyway, don't you let us know why, too? I know we'll do a contest about it or a survey about it, too.

But I would just like to know. And if it is too expensive, then we frequently talk to people who run conferences. And so that might be something we're not going to be able to help all the listeners. But I don't know. We'd be interested to hear what you have to say and see if there's anything we can do about it. Yeah. Cool. All right.

So for this episode survey, we ask, did you improve on the things that you wanted to for 2018? And your choices are, I did as well as improving on additional things, or I was able to focus on my 2018 goals and improve on them. Or I crushed some, failed at others. Or no, dang it.

Or lastly, wait, I was supposed to set some goals? I wonder what the pessimism would be this time. No, you got to be optimistic. I don't need to start with that. This episode is brought to you by Stellarez, the AI-powered talent agent for top tech talent. Do you hate your job or just kind of meh about it? Stellarez will help you find a new job you'll actually be excited to go to.

Stellar Res knows that a job is much more than just how it sounds at a job description, so they built their AI-powered talent agent to help you find your ideal job. Now, Stellar Res does all the work and screening for you, scouting the best companies and roles and introducing you to opportunities outside of your network that you wouldn't have found otherwise. Combining deep AI matching with human support, Stellarez pairs things down to a maximum of five opportunities that tightly match your goals, like compensation, work-life balance, working on products that you're passionate about, and team chemistry.

They then facilitate warm intros, and there's never any pressure, just opportunities to explore what's out there. To get started and find the job that's just right for you, visit stellarez.ai slash codingblocks. That's S-T-E-L-L-A-R-E-S dot A-I slash coding blocks. All right. Next up is a section on the knowledge portfolio. And they've got another great quote here from my man Ben Franklin here.

An investment in knowledge always pays the best interest. And what we're talking about here is basically uh all the knowledge that you've gained programming both in the technical and also in the domain specific bits that you've picked up over time and one thing i always thought about kind of interesting there is like as you're at a company longer and longer over time it definitely has always seemed to me like your value to the company becomes more and more about your domain specific knowledge and less about your technical skill doesn't matter if you're like a technical wizard or whatever it's just that your domain knowledge becomes so valuable as you've been there for a long time you become this like

historian that uh so anyway i just i just like that i wanted to kind of highlight that and i also like the fact that they mentioned that both of these are expiring assets and the example they gave was like a warehouse full of bananas that i was like dang i didn't know like those things go bad in a week come on uh i mean i thought like throw me a new car you know we're like well you know as soon as you drive it off a lot, you lose 10%. And then over time, you know, next couple of years, it dribbles down to zero, maybe after like 20, but a warehouse full of bananas. Yeah. That kind of puts it into pretty sharp, rough perspective.

Right. But it's true. It's what we said earlier, right? This particular career path that you chose is, you know, learn every day, all the time. Yeah, apparently that Angular 1 experience I've got now is a putrid fly-soaked banana. But it'll be popular in the year 2050, just like COBOL was when the year 2000 was rolling around, right? That's right. Yeah, there you go. And they brought in some

really nice tips from finance and they brought up a bunch. I really like this. I don't know if this is where I got it from or what, but I always like to think about where I spend my time. Development is like an investment, so you'll only stay stupid things like where I put my dev dollars or whatever. And so maybe I picked it up from here, maybe not, I don't know.

But they definitely are talking about your knowledge and investing in yourself in the same kind of financial terms that I'm comfortable and I like. So they give us five tips here from finance. Number one is invest regularly as a habit. I could definitely see that for knowledge too, like trying to learn, keep up with the latest stuff. Diversify. When they say diversify, they're talking more here about having like a widespread of stuff. So T-shaped. Yes.

Yeah, T-shaped is good, but you definitely want that upper part of the T too. You don't want to be an I. And they've got manage risk separately here. So when we're talking about managing risk, we're talking about things that are either high risk, high reward or low risk, low reward. You want to have a mix of both of those. And that's different from diversify because diversify means just having like that wide net. And this is more about making sure that that wide net has a good mix of things that are risky and things are not. And the deal is like, if you go out and like, say you, uh, some new languages announced, like, uh, I think Microsoft just announced a new language called bougie or something today.

You know, like you go out there and learn that if that ends up being the next big thing, then you're in a great position and you're, you're, you're poised to really take advantage of that. And that's awesome. Although if you put all your eggs in that basket and it doesn't go anywhere, Microsoft's kind of drifts away from it. It goes on it two months from now, then you've lost a lot of time there. So you just want to kind of balance out your new hot, sexy things that you're learning with like the old boring stuff that people are

always hiring for, which goes along well with the next one, which was buy low, sell high, which they use the example of like, hey, if you focused on Java when it was taking off in the 90s, right, then, you know, now you're set pretty well, right? Like, you know, you're pretty knowledgeable about the subject, right? But, you know, what if Java didn't take off? Right. Right. It reminds, you know, what if Java didn't take off? Right. Right?

You know what else it reminds me of? I know you guys remember Flash and Silverlight. People that were in those technologies, hopefully they were diversifying at the time, right? Like looking at dynamic HTML and Canvas and all that stuff that was coming out later because Apple single-handedly killed. I mean, Silverlight's a great example.

Yeah. I mean, Flash had a long, had a much longer life. It had a longer tail on it, yeah. Right? But, I mean, Silverlight's a great example. It came in, it was super hot for a minute, and then it died, like, fast. Yeah. And so, yeah, diversify, you know, manage the risk, all those.

It's super important to not just get tied into one ecosystem and that's it. I wish we could think of like a Google example there because we always joke about how like Google kills things fast. Oh, man. And it seems like, oh, man, why can't we find like a Google example to fit here? Like what would be the developer equivalent of like a reader or wave? Dart. Yeah, but that's still around, sort of, right? I know Go is still popular, but Dart didn't really take off.

So that's the funny thing. So Dart came out. Some people got excited. They put a time in. They wrote books. They gave presentations on it. And it just went nowhere. And it stank.

And that sucked. And it wasn't good for anyone. And then all of a sudden, years later, Fl flutter comes out yeah it's all based around dart and all of a sudden that knowledge wasn't so bad after all all that time that you put into darrow suddenly as but you in a good position there was actually someone that we talked to now that like did write a book on a subject i don't remember if it was silverlight or something. And then literally the week or the month before the publishing before it was released, the company that was behind the technology

like Microsoft or whoever was like, yeah, we're killing off this technology. It was John. It was John from the Six Figure Dev. Yeah, he had written something. It was Angular, I want to say, something Angular. And right while he was in the middle of it, they changed. And he was like, that's it. I'm done. I'm not. But the book was published, though, but it didn't sell.

Yeah, yeah. If I remember right. But, yeah, I mean, Flutter is one of those ones that's potentially, you know, manage risk. It could be highly risky, but, you, but it has the potential to pop. And so if you get in it early and you distinguish yourself as one of the leaders in that space, I mean, a perfect example of this is Julie Lehrman. So she is, and if you don't know who she is, then you probably don't care about entity framework

at all. But she, I listened to a podcast interview with her. I think it might have been with the Six Figure Dev. And how she got started was she always liked data stuff. And she got into Entity Framework early on. And she started writing the articles. And she became sort of like one of the forefront people that talks about this. And, and so she's made a huge name for herself by being one of those people that hit a tech that got hot.

Yeah. So, yeah. If you were to start today and say, I'm going to start a blog and we'll be the JavaScript guy, you've got some competition. It's going to be tough. But if you want to, I keep saying guy, if you want to poise yourself as the flutter person now, still a very good time to do that. And it's good.

But then again, you know what, like we mentioned, like that is kind of a, the anti diversification. Like if you ever like, like if you get the blog and say like, you know,

flutter person.com, whatever, then you're very much tiling yourself to that technology. And it could be awkward five years from now, flutters gone. And you're trying to write about whatever's next. And people are still going to flutterperson.com. But that doesn't mean that's where you put all your eggs either, right? Like that doesn't have to be the only basket.

You can start your flutterperson.com, but you could also still be investing in learning JavaScript and whatever else. Maybe don't use that as your email. Me at Flutter. Not only at flutterperson.com. and learning JavaScript and whatever else. Yeah, maybe don't use that as your email. Right? Yeah. Me at Flutter. Not only at flutterperson.com. Yeah, for years I used joeatcfhow.com as my main email address because I own like C-F-How, like ColdFusion How.

Oh, I'm sorry. I was writing like little ColdFusion articles. Let me tell you, that blog is gone now. You didn't back it up? No. Well, no, I just dropped it. I stopped working ColdFusion. The, no, I just dropped it. I stopped working with confusion. Like the jobs kind of evaporated on me and you know,

a confusion is still alive and doing really well, I guess. But, but that's not a space that I'm into. And so like all those investments in that space are, are just not valuable anymore. Yeah. Really?

Well, I feel like you're, you're, you're fudging numbers a little bit yeah yeah sorry it's it's it's doing well for some people how about that i'm gonna try not be so negative i tend to kick certain languages and i want to not because the world's big enough for all of us it truly is yes all right yeah and so uh the fifth tip was you just you should review and rebalance if you realize that like hey i'm spending a lot of time here and say elm or elixir or something that's more risky

then you may want to balance it with something that's kind of you know boring and stable like i don't know bash or docker or something that's probably going to be a safer java yeah great right the big ones that you know aren't going anywhere anytime soon. I'm not saying don't let your love of Haskell, don't pursue it, but also know something else too. Yep. Yeah, and don't pick too risky. Yeah, yeah. Spread the love out. So tip number eight, invest regularly in your knowledge portfolio. And who put goals somewhere a bit dated here? Oh, me. Okay. So they've, they've got a list of hard goals here that, uh, they give you. And some are just kind of funny and don't really make a whole lot of sense anymore. It's just kind of the book shows it age a little bit here. I just thought it was kind of funny. They do mention learning at least one new language a year, which is something I used to really believe in, and I don't anymore.

What do you guys feel about that? Man, I was going to say, when I first read this section, I think I was internally mentally screaming at the page. Like, that's ridiculous. Learning a new language a year? Yeah. But then at the end of the chapter, they said, hey, learning a new language doesn't mean actually going and writing stuff in the language. It can literally just mean, hey, getting familiar with, you know, hey, I'm an O guy.

Let me go learn F sharp so that I can get acquainted with functional programming. So it was more about learning how things are done in new languages so that you could take those same ideas and apply them maybe differently in what you do every day. So once I read that, I was like, okay, I shouldn't have been yelling at the book. Yeah. And this is what I'm just not choosing to do. Like I've, at this point, I've got experience in like a handful of languages and I'd much rather spend my year of free time on one of those other languages that I've already got some stuff built into. But if you only know one language, you're only really familiar with one, then I think that's a good thing to book up on. But one a year, it doesn't seem valuable to me. I only have X amount of hours per week.

We do the podcast. We do other stuff. I'm not putting adding earling to that list what about you that's just me well i mean i'm kind of i kind of hear joe on this one though too like i mean like think about it in web development like you already have there's a staple of things that you already have to know right so there's already like html and css and javascript and then you know, you have back end technologies, you're gonna have at least one. So let's say it's C sharp, and then at least one database.

So let's say that that's SQL Server. Alright, so already, there's a handful of things that you got to do. Now you're going to learn other things. And so like to Joe's point, it's like, well, okay, specific to JavaScript. I mean, yeah, you can know JavaScript, but React is a different flavor than Angular, is a different flavor than Vue, is a different flavor from the next one, right? Like jQuery. So it's like, okay, well, is that a new language? No. Or is that a new framework?

Framework. Right. Right. So, yeah, I mean, I don't know, man. It's tough. You know, I've definitely at least gotten a taste for things like Haskell, for example, without going overboard and being like, okay, I'm going to dive deep into this until that's all I do in my free time. Right? Yep. What was that website where I learned Ruby? Anybody remember? I learned. I used that loosely. The one where

it was something school. Oh, Code School. Was it Code School? They got folded into Perl site now, though. Oh, really? So something like that I think is worthwhile. right? Like just kind of going through doing some examples on, you know, hey, what's Ruby like? And, you know, maybe Python or like I think that's all kind of useful. But yeah, I'm with you. Actually learning an entire new language is a lot to bite off. You know, and as far as like going back and managing your risk in the buy low, buy low, sell high kind of thing, like you can use, there are, you know, a variety of different sites out there. You could go and Google like what are the top languages, you know, to look at. And if you see something that's in like the top five, top 10 that you don't know,

right, then, you know, that's one that you could go and look at, right? And like some of those, like once you know a concept in one, it's going to be pretty similar. Like, you know, that's one that you could go and look at, right? And like some of those, like once you know a concept in one, it's going to be pretty similar. Like, you know, if you already know Java, you could transition fairly easy into C sharp. And if you know C sharp, you could, uh, you know, uh, transfer fairly easy into Java. I'm not saying that they're exactly the same, but I'm saying like conceptually you, you have the ideas, right. Versus, you know, Pearl might be a little bit different, right. Haskell is going to be different. In fairness, be careful about these Googles because I do recall a previous episode where we pulled up a top list and VB was number two. Oh yeah. So yeah.

You know, yeah. I mean, you guys didn't like it, so that's why I didn't bring it up, but yeah, it was the Tybee index, which we've referenced in the past. It was always acceptable until BB.net, which you don't know. Maybe it became a big thing. Hey, man, don't go attacking my research result. It got hot overnight. It could have. You don't know.

Maybe some other part of the world. It's like really the big thing. They're like, this is so much easier. Yeah, somebody accidentally, there was this bottle that was floating out in the ocean that had this stack of CDs in it. They installed it. It was VB6. They were like, dude, check this out. No.

Sometimes the language sits around for a while before it becomes popular. It has a slow popularity growth curve. Look, look. Let me just say this. Don't be hating the language. Code is not a fine wine. It does not get better as it ages. I mean, language could.

I don't know. Why are you hating? I will say, though, I've seen a talk on Flutter and Dart. I've seen a talk on Go. I've seen a talk on other languages I'm just not that familiar with. And I really like that because I feel like I get some of the exposure and I get a glimpse at some of those things. But yeah, just the idea of saying, all right, four hours a week into LanguageX, I'm just not going to do it. I'm going to learn Scala this year.

I'm just not interested in that. Yeah, not doing it. The next one, though though is pretty good. Yeah, the rate kind of bothers me, but they say read a technical book each quarter, so every three months. Yeah, I'm probably more like every

two quarters. I feel like that's a good rate. It would be great if I just picked up more, say, C-sharp books or JavaScript books and I just read through them. But I'd rather spend that time somewhere else. You know what, though? And I've said this in the past.

I've seriously gotten to where I enjoy watching videos on subjects way better than I do reading the books. I still think books are fantastic references, but man, watching a polo site video or, you know, a LinkedIn learning video, or even going to YouTube and find it. Like, those are just amazing.

Cause you can put that thing on 1.5 or 1.75 and just blast through it. And it's like, you're just getting so much so quick. Yeah. It's going to be, it's going to vary. Like, you know, fine, fine. No, no. How you're going to much so quick. Yeah, it's going to be. I think that's true. It's going to vary. Like, you know, know how you're going to learn, right?

Yeah. But I actually found this one and the next one interesting because the next one is read non-technical books too, right? And so I'm like, okay, well, when they say non-technical books, are they meaning like, hey, read for fun, like read some fiction? Or are they referring to like some, you know, self-help kind of books, like, you know, learn people skills or something like that, right? And I was like, well, it's kind of, I found it curious that in both of those sections, they never refer to like, like this book, you know? I'm like, well, which one does this book count as? Does it count as the technical book? Because we've already said, you're not going to get into like the curly, you're not getting between the curly braces necessarily in this book. Like this isn't going to teach you

like, you know, you know, naming like how you should name something or like, you know, there's other books for that, right? Yeah, this is definitely the non-technical variety. But it's not, but yet it's, is it the non-technical variety?

I don't know, man. Do you see any code? Do you see any code? Yeah, actually. Yeah, there's some. There's some code. There honestly is. I don't know. I don't remember seeing it much. Well, I mean, you know, get later in the book. Later in the weird chapter one, man. Yeah, well, I mean,

you know. I think they interpret it as like those business those business self-help books that i'm kind of addicted to and uh kind of feel like a scumbag reading so see i didn't want it i didn't want i don't want to interpret it that way i wanted to be like oh also like read something for fun yeah i do that too yeah and by read by the way i mean audible you know i i do want to point out that we didn't we didn't call this out. But, you know, the one thing that I found refreshing and unique about this book compared to any other book was it was like this book is written in such a way that you could read any particular chapter that you want to read in any order that you want to read it. This book is not one of those books where you have to start from the beginning and then work your way to the end yeah you can literally skip around and it has

like great uh references so like when you get to the end of any one chapter uh or section no was it section or the chapter no it's the the section um no no no where's the chat? Whatever. There'll be like references to like, hey, here are the other sections and pages where these relate or that are related sections. Right. Yep.

Yeah, I really like the style of this book. There were a couple other books I read that were kind of similar like them. There were some Joel books. I forget what those were called. Joel and Software? Yeah. But they were written by different authors. It was like a collection of essays and it was just any order and you could skip around. If you weren't feeling

like you could just go ahead. I really like that style, this style. So these are definitely some of my favorite books. But then again, stuff like Clean Code and Clean Architecture has really improved and changed how I thought about day-to-day, minute-to type, type, type. Um, so I don't, I don't know. I like it all. It's all good. So you like the, you like the next one also, right?

Well, I'm kind of curious to see if this is the one that Joe was thinking was dated. Uh, take classes. No, I was fine with that. Um, uh, I don't, Oh yeah. I see which one I thought was good. Uh, so take classes. No, I was fine with that. I don't... Oh, yeah. I see which one I thought was good. So, take classes? No, I'm fine with it. I like courses. I've been kind of doing a set of Udemy courses lately, and it's been really nice. I even like answering the stupid

little quizzes at the end of the sections. Like, sometimes they're really stupid, though. It's like, here's three obviously wrong answers, and here's the answer that I guess is right. Yeah, I mean, this book was written before you had Pluralsight. Right. But so when it says take classes, they're literally talking about going to your local university and taking some continuing education type of classes.

Yeah. And no, I'm not doing that. Yeah. I was like, man, should I feel guilty? Like I've,

the only types of classes like that that I've ever taken in my career were because the company paid for them. Yeah. Like I've never, I've never paid for any of those on my own. Yeah. Yeah. When I went to school for any of those on my own. Yeah. Yeah, when I went to school, like so much of it was really geared around the degrees.

I don't know that there was anyone in any of my college classes that wasn't there specifically for a degree. Like there's nobody who just wanted to learn Spanish or wanted to learn Communications 1, you know. Well, continuing ed classes were things that you literally sign up for separately that you could go for like a six-week program. I i know our buddy way more specific yeah like our buddy john that was on episodes 100 101 he did an art uh continuing education thing where he went and painted you know paintings for you know six weeks or whatever so yeah i don't i've never done them

but i don't think it's a bad idea. I didn't know that existed. I never really thought of that as continuing education, but hey, maybe. No, in continuing education classes, though, it'll be something more very, very specific, hyper-specific. So it won't be like, hey, I want to learn computer science. Instead, it'll be like, hey, I want to learn Adobe Premiere. Or Excel. Yeah, exactly. Okay. Yeah. They're very focused.

You can take a class on that. But this is where the dated part comes in because I'm thinking like, okay, well now you got Coursera, Udemy, Pluralsight, Lynda, Code School. There's so many online courses where you could get to, you could study, you could take a class on a specific, you know, technical topic without leaving your house.

Yep. Yeah. And, you know, here lately, my personal favorite is just YouTube. Yeah. There's so many great courses that you could just find on YouTube. Yeah. You don't have to pay for a membership to something. Yeah, it's nuts. I hyper-focused, it's got

a great search engine too. So if you're interested in Kubernetes or whatever, you can just watch tons of hours worth of stuff on Kubernetes and just absorb it. Yeah, I don't know if you know, their parent company is really good at search. I will say this though, about YouTube, there is one part that frustrates

me is you find something and sometimes it's complete trash, right? Like at least when you go to a place like Udemy or Pluralsight or whatever, it's almost like cultivated type content. And so your quality is almost always guaranteed to be higher as opposed to you can find some great stuff on YouTube, but you got to wade through some trash to find it sometimes. Well, the big difference in my mind though, too, is that like on like a Udemy or Coursera,

Pluralsight or whatever, you're getting things in addition to just the video portion of the course. The exercise files. On the YouTube ones, you know, sometimes you can get lucky and you'll find like oh hey there's also a you know a link to my github that covers all this but then there's a lot of times where you know there is no such right i can't copy and paste this code man exactly well

i didn't mean it like that by the way thanks That's my inner thoughts. So the next one is participate in user groups. We don't call them user groups anymore. We call them meetups. Yep. Yeah, so this one felt very similar to things that we've already said in the past. Like if you were new or trying to learn a subject, like get out there and network with people and talk with people and, you know, see what other people's experiences are and, and listen to what they're doing.

Yeah, absolutely. And that's always a good, I just get so many different ideas and even just, um, talk or actually mostly just talking to the people before and afterwards, you just hear what people are doing. Sometimes it's really cool,

like out of left field stuff that you never would have thought of or never thought was happening in your area. So it's really nice. Now it was interesting though, like out of left field stuff that you never would have thought of or never thought was happening in your area. So it's really nice. Now, it was interesting though because I actually almost thought that he was going to go somewhere where he didn't with this section because he was like, hey, don't just go and listen, but actively participate.

Now I'm like, uh-oh, he's going to tell me to also actively speak at these meetups. But he didn't go there so yeah i should have bullet i think you'd be fine at it man uh next one is experiment different environments and i forgot what i was talking about was it talking about computer environments like linux or windows yeah yeah okay yeah like so if you work if you know windows day in and day out, you know, that's your bread and butter. Like, have a Linux system at home on the side that you just play with every now and then and, you know, destroy.

And then you're like, oh, man, how did I get out of the situation? Okay, format, reinstall. Dude, you want to know what's so awesome about this? So our buddy Ryan, Ryan Williams, Ryan Monster in our Slack and on Twitter, I just got him started messing around with containers and Docker. And a lot of it is Linux based, right? Like Ubuntu or Debian type stuff. And I told him, I was like, look, man, I promise you when you get in here, you're going to feel powerful when you start doing things with Linux.

I said, I don't know what it is about Linux. Once you start getting in there and feeling comfortable with the command line and shell scripts and VI, or I prefer Vim, but I said, dude, once you get in there, he wrote me back the other day. He's like, man, you were so right. I don't know what it is,

but I feel like a wizard now. You can give Ryan a You were so right. I don't know what it is, but I feel like a wizard now. Yeah. I was like, Ryan's awesome too. Like you can give Ryan like a nugget and like, he'll come back a week later and like be like teaching you all sorts of stuff. Yeah. Yeah.

He, he digs deep on this stuff, but yeah, it is true though. Like if you diversify and you, you'll gain an appreciation and you'll actually get a deeper understanding of environments that you've been working in for so long, right? Like why they do things and how it's different than somewhere else. So definitely, definitely do that. We could even micro these environments too, because like as you were talking about that situation,

I'm like, well, you know, you'd feel the same way in Windows if you mastered PowerShell. Oh, dude. So like if command prompt is your thing, or if you know Bash, like give PowerShell. Oh, dude. So like if command prompt is your thing or if you know Bash, like give PowerShell a try. Dude, I've been forcing myself to do PowerShell here lately just to make myself learn some of it. Like, did you know you can tail files in PowerShell and all that? I mean. Get content. Get content and then tail and then wait. Yeah. Well, it's no, there isn't a tail. It's just get content, the path and wait.

No, so you can do tail. So it'll get the end of the file so that you're not getting the whole thing. And then, and then if you do wait, it follows the file similar to a, a tail in Linux. So, so yeah, I mean, definitely go across all these things because you're going to learn things that will make you more efficient. Everyone. I found another one. Dude, I can't tell you how many times that you get into a customer environment and is the port open to something?

I don't know. Do they have Telnet installed? No. Oh, crap. What am I going to do? You can actually PowerShell a command that gets into the Windows operating system, like its networking stack, and you can actually tell it to connect to a port just using a PowerShell command. So you don't have to install new software. There are actually commands out there in the tools already available. So just really cool stuff.

Wasn't it cheap and easy way of that, though, to just Telnet to the port? If you have Telnet installed. Windows doesn't have it by default. You have to install the Windows feature, and that's what I was saying. You can actually do it without installing anything. All right, but everybody knows to do curl or wget, but in PowerShell. Oh, I don't know what it is in PowerShell. Isn't it just GC?

Git content install? What is it? Git content and so on? What is it? Git content would be for a file, but invoke web request would be to make a call out. Invoke-webrequest. One word. Hey, that's kind of newer.

That's like PowerShell 3 and up. I ran into something. Oh, PowerShell 5. I ran into a Powerhell five one with uh compress archive if you wanted to create a zip file but it had like a two gig limitation which was kind of nasty because the way the documentation read is you would think that you were going to like max out the output at two gig, but it was the input would max out two gig way off topic here. So let's talk about staying current as your next goal.

Yeah. I recommend you subscribe to some trade magazines and journals. Well, so this is what you thought was a, it was old, old school. Yeah. I mean,

everything was pretty, pretty old school kind of base. But yeah, there's not like subscribe to the Reddit, I guess, is the closest thing now. If you like JavaScript, R JavaScript. Yeah. And then the next one, the Get Wired news groups, you put LLL next to it. I mean, that's going to be more like your Slack communities and that kind of stuff, right? And podcasts.

Yeah, podcasts. We know of a podcast with a decent community. Yeah, some of the goals, the undrawing principles are still the same. But yeah, some of the specifics were kind of rough there. But one thing I wanted to mention too is just being on the lookout for new opportunities. I mentioned that with the meetups and a couple of these things. And they give you the advice, if you can't answer a question, don't let it go. Track it down.

Figure it out. Don't just kind of throw your hands up. So that was a kind of nice thing. But it depends on how many questions you run into in a day. But I guess once you start answering those, the idea is that eventually you're going to run into stuff that you're going to remember. Although remembering is hard. I feel like, I don't know, maybe I'm wrong, but I feel like 19 years ago,

the things you were expected to know was much less. It's like jQuery and these are the things you can't do in IE. And that stunk, but it wasn't like a big list. It's just there were things that were much harder to do when we were in the browser. Now I feel like you have to know like 80,000 JavaScript libraries and C Sharp and all the third-party libraries and the way you interact with those things and the different ORMs. And it's just I feel like you have to be responsible for a lot more. And so you don't get to really dive as deep on those tools.

That's true. But, again, you want to be a jack of all trades. So that's probably fine. Yeah, that's me. Yeah, that's true. But again, you want to be, you want to be a jack of all trades. So that's probably fine. Yeah, that's me. Yeah, that's me. So,

well, I need to get in there fast, figure it out, move on. And that sometimes means not remembering stuff. As long as you can remember the bigger principles, I think that's the most important thing. So you can remember the reasons why and,

and how you ended there. And I don't care less. I care less about the syntax. Well, there's things that I look up all the time. I stack overflow, the same stupid things, like different flags on certain commands and stuff like that i just never remember let's be honest there there was a like on programmer humor on reddit

there was like a you know first year as a computer uh as a software developer and it was like a screenshot of google and you're like typing in how to do something 10 years later as a software developer. And it was like a screenshot of Google and you're like typing in how to do something 10 years later as a senior software engineer. And there you are on Google. How do you do something like the same exact statement? Yeah. Yeah. Like we become an index of like pointers to like resources.

Like, okay, I don't need to remember exactly how to do this because I know that conceptually how it works. And if I need to find the exact details, I can go look at this Wikipedia page or I can Google this phrase or term. Dude, I find that my memory for how to find something has gotten very good. Yeah. That's really what we're indexing, right?

What did I search for to bring up that obscure little thing? Yeah, it was a purple ink hit it. Exactly. And don't delete your history, man. I'll never find it again. Yeah. Today I looked up how to – oh, yeah. I was like C sharp ignore case, which is something I've done a million times.

But I just – like I wasn't sure of the syntax. I wasn't sure exactly the commands. So I just looked it up and said, okay, there it is. And I've done a million times. But I just, like, I wasn't sure of the syntax. I wasn't sure exactly of the commands, so I just looked it up. It's like, okay, there it is. And I've already instantly forgotten it. I figured out that it was, like, the minimum things I needed to type to figure it out. And sure enough,.equals. That's awesome. Yeah, they also give you the advice to think critically about what you read and hear, which is

something we try to pitch a lot here, too. Don't take anything for truth and just kind of evaluate whether it's right and whether it's right for you, which can be two different things. Have you ever heard the expression, if you meet the Buddha in the road, kill him? No. This took a

dark turn. I have not heard this. It's an awkward statement i guess there's some book that came out in the 80s or something that was had that title that was kind of popular but the idea was that um like you you are responsible for your own enlightenment so if you run into someone along your path to enlightenment that seems to have all the answers and is perfect and is just like this representation of everything that you want and everything you need to know then you should dismiss it or kill it because it's an illusion it's fake it's not really because that stuff comes from within but really what what they're trying to tell you there is like just be aware of anyone that comes to you with the answers

or the way or the one way things should be done and should work. So if you see a presentation or hear a podcast or something where someone's talking about how, you know, Elm is the future of web development. It's just the best. It solves every problem that's ever been had. And people are, that's all people are going to be talking about five years from now. Those are like red flag, red flag for a red flag. Because anytime someone says they found the way,

and this is going to be what things are going to be like, then you got to be skeptical, especially skeptical. So if you find that Buddha in the road, you should kill is a little strong. Maybe, you know, scooch to the side and move on. So we're creating pessimistic listeners here. That's awesome. Which is a great tip for number nine. Critically analyze what you read and hear.

Yes. So, you know, don't kill Buddha. Yep. And we talked about that. So finally, the challenge for this session, there are a couple of them that basically point out to like learn a new language, read a book or talk tech with people. There's a great way to do that. Do that.

The coding blocks, the coding blacks. Yeah, there you go. The coding blocks. Slack is a good way to do that. Do that. The coding blocks, the coding blacks. Yeah, there you go. The coding blocks. Slack is a good way to interact with people and talk tech dev stuff, all kinds of things. We had a great conversation today, as a matter of fact, about just,

you know, if something was secure or not, I mean, and ton of people involved in that conversation. It was good. Yeah. So, uh,

although like I kind of hated on some of those tips up there, like that's kind of stuff that we do and talk about on the show. I just replaced the language with like tool or framework, like, you know, whatever it is. And we're, we're pretty much doing that sort of stuff all the time.

So I can't hit on it too much. So our last section, section here is on communication. So communicate. And we had a call out here that ideas are worthless unless you communicate it. Is that true? I mean, it's written. It's got to be.

Is that true in there? It's kind of like, I always say like ideas are worthless without execution, but I kind of thought it was like, well, what's the difference between communication and execution? And I kind of thought even if you go off, you have a great idea for the next Uber or pizza or whatever, and you go off and build it, it's still kind of worthless unless you can express to other people what it is that you've built and what it's used for and yada, yada. So, it doesn't even matter if you do the thing if you're incapable about talking about it. And I think it's just ultimately stressing the importance of the communication. So, I'm going to agree with this. Ideas are worthless unless you can communicate it. All right.

I want to talk more about this Uber of pizza. Clearly, it's got bacon on it. You pull up the phone and you see what all pizzas are flying around. And you go for the bacon ones. Yeah. All right. So, meetings, tickets, wikis, code are all forms of communication. We've already identified that wikis are where information goes to die. That's good.

Scratch that one off the list. Well, I mean, you know, maybe not Wikipedia. No, that's a pretty big wiki. Yeah. Also, we mentioned with the stone soup on the boiling the frog sometimes if you're having a problem convincing people or co-workers of something that you think is right and maybe uh then chances are very good that is communication problem on your side maybe you're not saying things in the way that makes sense to them or you're not addressing and you're

not hearing what their true concerns and hitches are. And maybe if you can figure that out and then reevaluate and figure out if the message you're trying to pitch there does address those or doesn't, then that's important and all roles are on communication. So there's some tips here. So that's true, but I do want to say that not all the time is communication the problem. Like I said, sometimes people need to be able to see, touch, feel. So keep that in mind. Yes, communication is super-duper important, but you're not always going to be able to convince people with words and slideshows and all that.

Okay. Well, I mean, keep that in the back of your mind. Yep. Because as far as how to communicate, there's some guidelines they have here. So one is understanding what you want to say, right? So jot down some high-level goals and have a plan for how you plan to get this across, right? But to your point, Alan, the second point is knowing your audience, right? Knowing the type of person they're going to be like, do they need to see a proof of concept

first? Or do, are they a visual person? Or maybe they want to know the numbers behind it. You know, like what's going to be the return on this? Like how much more improvement is this going to make it? Things like that. That's probably the most important thing. What you just said is knowing your audience and knowing what it's going to take to push them. Some people are visual. Some people need to put their hands on it. Other people just need to know what the return on investment is going to be.

And the funny thing is like these are things things that i do good really good at sometimes and really bad at sometimes and i would say that all my major successes with any sort of communication has been because i understood the message i was trying to portray and i understood who i was talking to and my biggest failures with communications have been because i didn't understand the message enough to say it well and and I didn't understand who I was talking to. Yep. And then they make a point to say like, hey, choose your moment when you're going to do this. Like, if you know that you need to have a conversation with your boss about something, and he just had a bad day, right? Like, maybe he just got, you know, had a, a bad conversation with his boss.

Right. Or, or maybe he learned some bad news, you know, in his personal life or whatever. Like that's going to be a, not a really great opportunity to be able to try to sell him on like your idea about why you need to be given time to do some new project.

Right. Or why you think some new project is going to be great. Like that, you know, pick a better time than that. Yep. I think there's something to be said for waiting too long, though. Sometimes if that moment isn't coming, sometimes you got to make that moment and just say it wrong and get it out there. Yeah, but okay, fine. But, you know, it could wait overnight. Right, yeah.

Waiting a month doesn't make a ton of sense, but waiting until your boss hasn't just gotten chewed out by his boss or her boss is probably a good idea. Yeah. So then there's choose a style. Communicate with them. This is, again, to your point, Alan, about communicating to them with how they want to be communicated with. So knowing your audience, right. And then making your message look good. Like, think about this. Like you got, you guys have been on the receiving end of some of my emails, right? Like, like how many boring emails do you get where nobody bothers to change? You know, there's no,

there's no formatting about the message. Right. But sometimes it could just be like, if you are going to write a, you know, decent body of text in an email, right. I mean,

at least make it easy to where somebody can like kind of get an idea of like what it is, right. Like, you know, have some section headers or something too. I'm not saying that your email should be a book by the way way. Well, that's what you're getting at is there's a difference between you could write the most content packed summary or document ever.

Yeah. It can be completely dense. But if it is just a wall of text, then people will probably dismiss it right out of hand, right? Whereas if you make it look good, if it has some pizzazz, it has some headers, has some bullet points, some interesting white space or whatever, that stuff could matter as much, if not more, than the content itself because it'll draw somebody into it. I mean, sometimes those headers are just like transitions to like, and here's where we're going, right? Yep. Huge, huge difference. It's even the same thing like even if you're giving a presentation, right? And it's not just a document you're giving.

You're doing a presentation. Make it interesting. Somehow bring them in. Draw them in, draw them in. I feel like, too, if you've got more than two paragraphs in an email, you need to have an intro and an outro. Yeah, a DLDR. Because a lot of people aren't going to make it through that whole thing. Yeah, you're right.

It needs to be skimmable. It's like set them up, let them know what to expect throughout the rest, and even give them the conclusion there in the introduction. Tell them where you're going completely. Don't try to write this big, long email and have like the surprise at the end because most people aren't going to make it to the end. That's so true. Yeah.

And involve your audience, you know, get, get, get people involved in your documents early and possible. Now this one, uh, I don't know.

I guess it would depend on like what kind of, what kind of documentation, you know, what kind of documentation you're writing here. What kind of communication you're doing. I was giving people a chance to sign off or dispute, especially if I'm speaking for somebody. If I got a status email that's going on and involves multiple people, I like to give an opportunity. I'm not always good about it. Sometimes it might be five minutes before i send it like hey anyone have any problems but i i like to i like to get everyone's kind of stamp approval like sometimes

i say things in a way that people aren't happy with and so i like to kind of at least give a give an opportunity there i've been pretty happy with how that goes and i feel like that gets a little bit more invested in that process but that can also be really tedious if you're doing it all the time. But if I'm going to write, say, an email to a higher-up about some project or whatever, I don't involve them in a draft and be like, hey, what do you think of this draft for the email that you're going to be getting later? I might go back and forth with some peers on it. Like, hey, what do you think of this idea like hey what do you think of this idea or like how where you know how what do you think of this wording yeah so i don't know that one that one i guess your mileage is going to vary the situation is going to depend yeah totally like if you're if

you're getting ready to work on the next phase of a project getting the business owners involved in creating or drafting that document makes a lot of sense. Yeah, we do that for the show too sometimes. There's definitely been times we said like, hey, how's this look? Send a draft of an email. Yep. We do it a lot. And here's a skill that is like ultra important is be a listener.

What? Yeah, if you don't listen to others others then they won't listen to you and honestly there are times that i know we all struggle with this right because we have i know i do we have in our heads how something needs to be or how it's got to be or what or the direction we want to go and and when somebody's getting ready to try and tell you otherwise or something different, you're like, no, I don't want to hear it. Right. Like this isn't I know how it needs to be. And it's it's super important to step back because they might have thought about it in a different way than you did. They might be approaching it from a different angle.

They could bring something else to the table. And the part in this book that I really liked about this was even if you know everything about what's about to be said, listen anyways. You know, in this one, like I know I'm guilty of this, man. Like it's definitely like sometimes you'll just have in your head what you want to say so bad. And you're just waiting to let someone else speak that they're talking and you're just kind of like it's in one ear and out the other right because you're like i can't wait to say my part that's right it sounds so smart when you hear it when you hear the things the smart words are going to come out of my face right it's like really bad though it's it's hard and i think this is really prevalent with developers in general

because good developers are super smart and so they think that they know the answers to almost everything before it's even asked and so it's it's hard to turn on that listening mode right but man this is so important like this is one of my favorite things in here. And I, and I have to, I have to practice it all the time because there are definitely some things where I'm like, you can't convince me. I don't care what you say. I'm not even going to hear what you say. And it's something that I have to work on to where it's like, no, no, no, let them say it because they're going to say something that's going to matter a lot. Now, this next one is also one that I'm really bad about. And it's get back to people.

So if someone sends you an email or something like that, just reply back. Thanks. Even if you can't give a lengthy reply. And I am awful at this. Awful at it. If I read something and I'm like oh my gosh i do not have time to reply to this right now but i really want to i will immediately mark the emails unread so that it will annoy me by like hey you have something you haven't read i'm like oh dang it

i gotta go read it oh dude there's people that have written us some emails on coding blogs and yeah sorry we've talked about it we we want to reply, but it's one of those. Oh, it stresses me. Right. They'll send us a two-page email, and we'll be reading it on our phones. And none of us are going to reply on a phone because who knows what's going to come out of that. And so you're like. Have you seen auto-correction?

Right. But, yeah, you look at it and you're like, I can't just give him a three-word reply he took like 20 minutes to write this then it's like oh man i forgot he wrote that a month ago yeah so yeah so sorry if you've written us an email we haven't gotten back chances are it's still in the inbox it's flagged respond to and i know we're like we've got stuff going back months that i know i haven't responded to that i've been meaning to so i definitely apologize and it really is like it's the longer the email the the less likely i am to respond in a timely manner that's really not fair but that's totally what i do because because we feel like we're doing a disservice if we

if we write back we're like that's cool yeah and so many times it's because i check my email when i've got an idle moment. I try not to check my email throughout the day unless I can help it. So it's like I'm in line and I'm like, so let me open the email. Oh, what's this? Oh, hey, it's long. I read the first two sentences like, Mr. Zach, your order is ready. Okay.

Well, you know, mark for follow-up. And I just never get back to it. Or the next time I check my phone, then I've got 10 other emails that are kind of urgent and short that I can deal with immediately so I just do that instead so we just took some weights off our chest thanks for yeah thanks for listening thanks for letting me vent

there I just hate the confirmation emails oh my god do not man I feel indifferent about them confirmation emails. Oh my God. Do not, man. I, uh, I feel indifferent about him. I'm, I'm bad.

I like, I get him and I'm like, okay, well, I mean, you know, fine. You know,

you got it. But then at the same time, there's definitely times where I'm like, I should probably just send a thank you or a, you know, Oh, that's great. I think I kind of like them.

I wouldn't say I'm indifferent. I'm slightly warmer than indifferent on those. I kind of like them. Stuff goes missing all the time. I hate when you're like, the last thing is like, okay, we're deciding to do this and you're going to do it. And then you never hear back. I love just hearing the done

or got it. And not that it ended up in a trash folder somewhere. And I hate to go ask about it again. It's just really awkward. But hey, have you ever done anything where you respond to an email that you already responded to? Like, thanks. And then you do

thanks later as if you forgot that you sent the first one. I might have. Yeah. So I wanted to mention too with the the listing um i know that um as the day goes on if i've had a lot of skype conversations my ability to listen kind of runs out and and uh that's not really fair i think i need to do better there i'm just saying like no someone like i am so wants to talk or something just saying like unless it's like super important i'd rather just do it tomorrow because like so if you're caught up in it, probably like, oh, I'm trying to get this ticket done tonight.

And it's like sometimes happens like late at night. So it's like I'm working extra hours, like seven o'clock and someone's like pinging and wanting to talk about something. It's like, oh, but I've got this thing in my head that I want to get done before I go out for dinner. And now you're wanting to like take me on this like total detour about your problem for 30 minutes. I don't want to do that. But I feel like a jerk saying no. You're nicer than I am. So many conversations don't make sense.

Yeah, sorry. All right. The later in the day it gets, definitely my chances of saying no to Skype increases dramatically. It definitely happens. I mean, whatever. We're all human. All right. So tip 10, which will be the last one for this episode, it's both what you say and the way you say it.

So true. Yeah, and they have a big section on proofreading emails, which I also feel is totally outdated because nobody cares anymore. I mean, no. Totally you got to proof proofread your email what are you talking about i i mean it goes back to just earlier in this episode right like which which is better like in in regards to this both what you say and how you say like which is better it's survey time or survey says i mean come on it totally matters. Survey. Yeah.

That's true. I just thought it was funny to have such a big thing. It definitely felt like, oh, this is a pet peeve of one of the authors. But no, I get it. I mean, you got to have – I think about emails like they got to be searchable. And I do try to be good about it. But man, especially in Slack, Slack has really changed my communication style. I used to always be really big on grammar and whatnot. And cell phones do.

Cell phones came around and suddenly I don't care if the I's capitalized or not. I'm not going back to delete that. Oh, my God. No way, man. Not in an email, though. That's fine. If you're going to IM me, then fine. Yeah.

But. Yeah. Yeah. No, I agree. Email is more proper. Yeah. But what Yeah. Yeah. No, I agree. Email is more proper. Yeah. But what if you're on a phone? Yeah.

No, on a phone, look, you get what you get. You might not even get the word that I. That's why I leave this sent from my Android. Because you got to know, you got to understand. Yeah. But. Yeah. I mean, that said, in an email, like, it's use acronyms like BTW for by the way or TLDR.

Yeah. But you better spell their right. If you're talking about their computer, you better spell that properly. And if it's over there, you better spell that properly. And if you don't know the difference, you need to go look them up right now. Yeah. That's important. Yep.

Yep. All right. So I think that's about it for the tips. We do have a challenge for this one. And they didn't really – I don't think they had – I think I wrote this challenge. How important is wisdom? And wisdom, we didn't really go over too much. But it's basically there's like six uh six questions to ask about your audience and somehow they like weirdly map to the word wisdom like one

per letter but it's not it's like the worst acronym ever it's like what is the interest is like the eye for interest you know come on guys yeah anyway i wanted to ask like have you ever had something where you actually went through like formal audience kind of study and you wrote out your answers like, this is what I want them to learn. This is their interest. Yeah. I do too sometimes. Yeah. And I think I've gotten good success because a lot of times I'll really spend a lot of time thinking about the audience.

And by the time I've answered those questions, how I write the email or how I phrase my message changes dramatically based on what I thought there. So I don't think it's ever been a waste of time whenever I've done something more formal like that. I feel like every email I write is a waste of time sometimes. Oh, man. I spent way too much time writing this email. The shorter, the better. That's where I'm messing up. All right.

So you might have guessed it already, but obviously as a resource we like is going to be this book, The Programmatic Programmer. There. We done did it. Yeah. Don't forget to leave that comment there. Oh, yeah. That's right. Leave a comment on the episode for a chance to win a copy for your very

own self for either what Kindle or paperback or whatever they provide. So yeah. Yeah, and with that, it's Alan's favorite portion of the show. It's tip time. It's the tip of the week. Well, I mean, if we got a survey time, then it's

tip time. All right. So, I mean, if we got a survey time, then it's, you know, it's tip time. It's tip time. All right. So what you got, Jay-Z? All right. So. I don't think he's listening. He's fading faster. Yeah.

Yeah. And well, so this tip will seem like a great idea when I put it in there. And now I don't know. Well, you're really selling us on in there. And now, I don't know. You're really selling us on it there. I blame ITAdder from the Slack for helping me out here. He sent me a repo, which is a gold mine of source code

for older games, including what I think looks like maybe all the Leisure Suit Larry games, at least the older ones. But it's actually got a lot of other repos in there too, so there's like Zork and a few other things. The SIT is in here! Heck yeah, man.

So this is just a great collection of old source code. Including Leisure Suit Larry. So if you ever want to know how something ended and you didn't want to actually play through the game, now is your chance to look up how things could have gone if you had made the right decisions. Oh, that's really cool. This is a good tip, sir.

Thank you, ITAdder. All right. So I've got two only because I think Andrew Diamond threw this one out. It's probably been a month ago now. And this one's really good. So we talk about design patterns on occasion. So there's a website called refactoring.guru. And he's got a design patterns catalog.

And it looks really nice. Like it's laid out nice. And I went through and looked at these. And this kind of goes back to the presentation part of what we talked about today, where just some of these pages are really, they're just kind of fun to look at. And they're, they're visually engaging and hopefully it'll help drive the point home. If you have any design pattern things that you want to work through. And then the next one is actually one that I stumbled on because I was just looking for like cool Visual Studio Code plugins and stuff. And there's a site called VS Code can do that dot com.

Man, there are so many great things on here. And it's a page where they've just numbered a bunch of them. How many do they have? Like over 30. They have 36 different plugins and stuff. And if you like click to learn more on them, it'll have like little videos and stuff next to them. But just really cool things that you can do. So, oh man, right? Like number two is the GitHub pull request extension from GitHub allows you to view and interact with your pull request directly in VS Code.

Sweet, right? That's great. Toggle sidebar focus, breadcrumb, Slack chat in VS Code, soft undo. Game changer. Now I'll never get any code written because I'll be in Slack the whole time I'm in VS Code. Dude, they have a JavaScript scratch pad. I mean, come on, man. So yeah, at any rate, definitely check

that one out. I know that all of us here are big fans of Visual Studio Code, and this just makes it even more awesome. Man, I gotta keep going through this list. I can't. Can we pause for a minute? I'm not done.

I'm only at 20. This is amazing. I'm getting there. I'm not done. I'm only at 20. This is amazing. I'm getting there. I'm getting there. I promise you. I'm scrolling fast. All right. No, I'm kidding.

All right. So I didn't realize that we were going to double up on the Andrew Diamond tips tonight. Oh, nice. But so thanks, Andrew. I called dibs on this one. He, he shared this. So let's say you want to, uh, get your cloud on and you're trying to learn more about Azure. So there is some nice links to a self-paced labs where you can up your Azure skills, right? So I'll have two different links for that. Um, so that you can, you can sign up now you will need to be in one of two situations. Either you are a, or one of three situations, I should say. You are either already a Microsoft partner or you are a Microsoft customer or the third one. I can't remember and it's not showing me the option right now.

So there was a third one. Dude, there's 148 of these labs. Wow. And these are not short. This is amazing stuff. 120 minutes for the first three labs each. That's really cool stuff. I've never seen this. Yeah, it's pretty impressive, like the whole catalog there. Let me find out what that third option was.

It's bugging me now. That's super awesome. Nice tip. You had to be. Oh, my gosh. Now, like, I hate these. Are you a robot thing? Click on everything that's a car.

You're like, oh, really? There'll always be like one image that has like a corner of it. Yeah. You're like, is that a car? Well, I didn't see that corner. I didn't know that. Yeah. Whatever. Forget it. see that corner i didn't know that uh yeah whatever forget it it's it's like walking me through a whole bunch of things now like um i guess i'm a robot because i keep oh no i passed

the checkbox so maybe i'll get to find out nope all right so so yeah we we just went over the uh wow that spilled all kinds of whack we just went over the – wow, that spelled all kinds of whack. We just went over the Pragmatic Programmer Chapter 1, and I know that was pretty lengthy, but hopefully it gives you an idea of what's in the book. So definitely the tips real quick going through them. Care about your craft. Think about your work. Offer options, not excuses.

Don't live with broken windows. Be a catalyst to change. Remember the big picture, the frog in the boiling water. Make quality a requirements issue. Invest regularly in your knowledge portfolio. Critically analyze what you read and hear. And tip number 10, it's both what you say and the way you say it. I'm really hoping that one of you wrote that as a joke because I'm going to pronounce this because it's funny.

Like however you wrote it. It's the pro-go-matic prag-mammer. Prag-mammer. Yeah. So you know if I typed it for real because there would be too many T's in pragmatic. I always spell that one wrong. I want to mention too that even though we've been talking for like the last four hours here, it's only been about

the first 18 pages. Yeah, that's kind of ridiculous. If you like what you heard so far, then you should definitely check out the book because there's a lot more pages. Yeah. And with that, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app.

Be sure to leave us a review. You can find some helpful links at www.codingblocks.net slash review. And while you're up there at codingblocks.net, check out our show notes, examples, discussions, and more. Send your feedback, questions, and rants to Facebook. And make sure to follow us at Coding Blocks, where we totally recently hit a milestone that I forgot about on followers, which makes me feel good about my internet points. And you'll find all our social links at the top of the page. Did you level up?

I think I was dreaming. I don't know what happened.