Coding Blocks - The DevOps Handbook – Anticipating Problems

Episode Date: August 17, 2020

We're using telemetry to fill in the gaps and anticipate problems while discussing The DevOps Handbook, while Michael is still weird about LinkedIn, Joe knows who's your favorite JZ, and Allen might have gone on vacation.

You're listening to Coding Blocks, episode 139. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, I don't know, wherever you like to find your podcasts. You can probably find us there. If you can't, let us know. Probably ping Jay-Z on Slack would be my best advice to you. Awesome. If you've never been to the website, it's super good.

Looks really nice. It's got a lot of social links there at the top and uh lots of show notes so you can send questions feedbacks and rants to an email address that you could probably find on there somewhere so we just had to live in this whole thing you forgot to mention what the website is though you sure did yeah you you talked about it but you never said like the http colon oh wait https colon forward slash forward slash www dot coding blocks dot net yeah net yeah there you go very good well we're off to a good start so you can also follow us on twitter at coding blocks or head to www.codingblocks.net and find all our social links there at the top

of the page. With that, I am Alan Underwood. I am Joe Zak. And I'm Michael Outlaw. This episode is sponsored by Datadog, the cloud-scale monitoring and analytics platform for end-to-end visibility into modern applications. And Secure Code Warrior, build your security posture and defend your organization from cyber security threats by empowering your developers with the skills and expertise

they need to write secure code from the start. All right, so we're back talking about the DevOps handbook. And I got to tell you, so I finished the Unicorn project, guys. And we need to talk about that too at some point. Spoiler test.

Let's do it. Yeah. Wait. You wanted to talk about that now? Because we're still talking about – guess what part we're talking about. We're still talking about the second way in the Devs. So I think we should do a spoiler test where we do an episode where – and first of all, Alan's got to read it. We just talk about the books full of spoilers.

And then we either put it up on YouTube or do some sort of big disclaimer. We just go ham on talking about it. So that people hate us, basically. No, no, no. So the people who have read it can enjoy it. Okay, that's fair. And the people who haven't can stay away. Yeah, they would be warned that, hey, there's spoilers in here.

Yep. Cool. Yeah. I will read it at some point. I will actually get the audio book just like Allah did. Cause that's, that's the way I roll. It's really good.

It's really good. Which one do you like better? Ooh, good question. Which one of the three of the trilogy, the DevOps handbook, the Phoenix project and the unicorn project, or just Phoenix versus Unicorn?

Is the answer different? Well, probably not. So let's go with either. Yeah. Well, I didn't know that until you asked. Don't be a jerk about it. Yeah, so tough crowd. Which one did I like the best?

Well, okay, of the three of them, the DevOps Handbook is great. But I definitely really did like the storytelling aspect of the Phoenix Project and the Unicorn Project. So I like them a lot. And I said this before, that maybe having already gone through the DevOps handbook and then doing the Phoenix Project and the Unicorn Project, it was kind of like you kind of like, as you're listening or reading the story,

you're like, oh, I know what you should be doing. I know what part's coming next, right? So that definitely might have influenced my decision a lot but i really did enjoy the phoenix project a lot so that that needs to be my first listen then is what we're saying here yeah all right uh definitely between the the unicorn project and the phoenix project because the two stories happen concurrently in timeline wise but uh i think it's I think there's references to the Phoenix project in the Unicorn project that

have the assumption that you've already read the Phoenix project. That works for me. That's what would be my next listening. That's good. Comparing DevOps Handbook is kind of not fair. One's like a textbook and one's like one of those really good after-school specials

that you turn on for two minutes and somehow watch the whole episode. I'm all of a sudden not excited about this. Because was there any such thing as a really good after-school special? Oh, man, come on. It's basically like watching an old episode of G.I. Joe, and Roadblock comes on at the end and tells you, like, now you know. Knowing half the battle. You're like, yeah, I do kind of know now.

Yeah. Yeah, it's really good, though. But you're right. It is unfair because the DevOps Handbook is more textbook. But that said, though, I have really enjoyed the case studies that I know you hate, Joe. But that is one of my favorite parts of the DevOps handbook. And even in the Unicorn Project and the Phoenix Project, they do make references to some of those case studies, but they don't go into the same level of detail. So the level of detail of those case studies in the DevOps handbook are awesome. Cause then I guess what I like about all of it is that like seeing how some of

these things are put into practice, you know, and like being able to have a story about that, it, it, it helps to, uh, to solidify your understanding of it and whatnot.

So that, that's part of what I've enjoyed about it. For sure. Excellent. Oh, Hey, real quick on that too. I, remember I mentioned Scaffold is my tip of the week a couple episodes back or whatever. And Andre actually said that he was getting ready to start using it. He sent us a tweet on it. I'm really curious, man. Let us know how that's going for you because it can be super powerful in trying to get your entire environment working locally as well as pushing on forward to other environments,

which is kind of in the whole vein of what we're talking about here anyway. Well, in fairness, how do you know which scaffold he was talking about using? Because you mentioned like three scaffolding tips. It's true. Three different tools that were all called scaffold in the same episode. Well, you know. It was spelled different. Oh, yeah. I don't... Well, you know. Well, they're spelled different. Oh, yeah.

They were spelled a little bit different. That's right. In fairness, I think it was only two, but yeah, still fun. Yeah, yeah, yeah. I do think Scaffold is... It sits in the middle of some things. It runs a bunch of Kubernetes pods and services

and puts it all together. So when any of those services go wrong, it always feels like Scaffold. Right. So I feel like Scaffold, it's so easy to blame for so many things and when you check on it, it always feels like scaffold. Right. So I feel like scaffold, it's so easy to blame for so many things. And when you check on it, it is always your fault. Yeah.

Yeah. Yeah. Well, don't forget Helm in there too. Oh yeah. Yeah. Helm is also the same thing. It's like sits in the middle. It's so easy to blame and it's never the problem. It's never your local Docker desktop.

That's the problem. Of course it's scaffold. Man, I actually need to do a little video on, on some of that just to show some of the problems that you run into there so that you don't waste hours of your life trying to figure out why your stuff isn't working. But you'll waste hours. All right. So let's jump into the news. Who's got iTunes here? It looks like Jay-Z.

Hey, so big thank you to Abizambra and Tracer. I really appreciate those excellent reviews. Thank you very much. Huh. I thought Abizombra and Tracer. I really appreciate those excellent reviews. Thank you very much. Huh. I thought that would have just been Tracer. Yeah, probably. Maybe that's just because I've played too much Overwatch. So from Stitcher, I'm going to go with a Toy Story reference here,

and Andy is taken. So thank you, Andy is taken. That's excellent. Yes, thank you. Andy is taken. That's excellent. Yes. Thank you for those. And then I had one that I wanted to bring up because Snorri wrote me on LinkedIn and we get this question periodically over the years, right? Like we've been doing this now for close to seven years, guys. That's crazy.

But we get this question a lot. Wait, we've been writing code for seven years? Not quite that long, but we have been doing. We've been writing code for seven years. Uh, not quite that long, but we have been doing this podcast for that long. So it was just the way it was the way you like said that though. It's like, we've been developers for seven years, man. Really? It's been a bit minute. It's been a long minute more than that. Yeah. Yeah. Slightly. But we get this question quite a bit from people all over the place email slack uh you know linkedin whatever and it's usually from people that are new to the development field and and

they'll come up with questions and be like hey i'm trying to land a job my first job as a developer what do i need to do right like and and some of the things that he threw my way were like hey should i start a pet project you know so that i can show that I can code this? Should I do this? Should I do this? And my suggestion back to him was, and the reason I bring this up is because maybe it'd be nice to get you guys' point of views for him as well. And anybody else out there, you know, in the same situation is don't start a pet project. This is my opinion. Unless you just have something you are super passionate about,

don't start your own project because you're going to learn more by pulling somebody else's project, a project that already exists on GitHub that maybe is something that maybe you're more interested that you might be interested in, but you'll get to see the patterns and how people are coding things and, and how they're doing their unit tests and how they're doing these other things, right? Like, I feel like just getting your hands on something that's already established and working, installing it, learning how Git works, learning how all these other pieces work and interact together, give you a much broader overall picture of the entire thing than you just sitting down and writing your own to-do list, right? So that was one. And then my other thing was too,

I think a lot of people, and this isn't just new people getting into development, trying to go land a job. A lot of people don't treat the interview like they should. Like to me, if you're going to interview at a place, you should look at whatever the job description is. Right. What are they coding in? What frameworks are they using? All that kind of stuff. Right. Then you need to treat it like a test like you did when you were in school. Right. Go Google interview questions for C Sharp. Right. If that's what you're doing, interview questions for Web API, interview questions for this. And then if you want to take it a step further, we've talked about this book, Cracking the Code Interview.

Like that's not lightweight work, right? Like if you really want to get serious about it, go through that thing, do the challenges. And then something that Jay-Z does a lot is like these code challenges, the code katas or the leak code challenges or whatever. You'll learn a lot because you will struggle through getting to a solution. And then after you do that solution, you'll get to see other people's solutions. And then you'll get to see, oh, well, they did that there. Huh? I didn't think about that. Right. So those were my things that I gave back to them. So I'm curious, what, what would you guys, and keep in mind, this is during a pandemic period. So it's, you know so it's a little bit tougher to give advice.

If you're not landing a job, it might not be that you're bad at it. It might be that we're just in a really tough market right now, economy, because there's a lot of companies suffering out there and a lot of people suffering from this. So yeah, I guess with that, you-Z or you Mike, I got, I guess I'll go first. So, um, one thing I'm a big advocate of is, you know, of course, everything you just said, but also having a list of companies that you want to work for you. I feel like everyone should have a list of three companies right now that if you got, you know, laid off or that you know you're looking for a job like these are the three places you would most want to work and then from there you can take a look at the kinds of problems they're using the technologies they're using

the kinds of problems that they have uh the the types of uh stuff that they have available on the internet and be make yourself familiar with that stuff go do projects in the area if they have open source projects go look at them try to get involved try to do that sort of thing if they have people in the area doing meetups or um you know that's all kind of off the table now but if they're um doing any sort of virtual meetups or they have an api or something they have a slack group for go join it right now and i really think um having at least three, whether it's in your area or remote or whatever, like knowing who your first picks are, because it's really about finding a place that you want to work at, not just any developer job. So if you're looking for just any job,

because you just need to get that first year of experience, and that's kind of, you're kind of in a slightly different position, but I still recommend knowing where you want to work and if you don't know where you want to work get on google type in you know your city orlando florida tech companies sit there and go through look at the top five six seven eight and see if there's any of that interest you and if not keep looking for you know search some other way but i think it's really good just to know like where you would go if you could just pick all right I really like that wow that's gonna be hard to to follow up uh okay so my answer is gonna be well are you still in school and looking for a job or not because if you are still in

school then my first advice to you would be to uh to try getting an internship or a co-op job. Because A, those jobs might be easier because of lower expectations to get. So it might be easier to get your foot in the door and gain some experience. And Alan's favorite part of it, the networking, right? So, uh, you know, if that's still an option, if you're not in school, then, uh, I still, I liked the ideas that you guys were throwing out there, but I would add to it that, um, we've talked about this before when, you know, as Alan was talking about, like trying to get up to speed with, uh, you know, like you mentioned the cracking the, uh, code interview or, or I forget who wrote that, Gail or something. I don't remember.

But Cracking the Coding Interview, I think, is the name of it or something like that. But we've talked about Educative.io, and they have several courses that are all like grokking the object-oriented design interview or grokking the system design interview or you know whatever like they have a whole series of those kind of things so like there's a bunch of resources out there that are like that i think um jay-z didn't you previously mention one that was more like a interview dot something oh yeah um so it was interviewing.io they don't do free interviews anymore though oh really okay so yeah they're quite pricey too which i So it was interviewing.io. They don't do free interviews anymore, though. Oh, really? Okay. So, yeah, they're quite pricey, too, which, I mean, it was really valuable. I think it's like $100 or $200 now per interview. But I did like five or six of them for free.

It's pretty awesome. So those are our thoughts on it. You know, hopefully out of that, you know, something will at least come into you and resonate with you and with anybody else that's looking right. The one, the one thing that I, the last thing I was going to add to that though, is I was really surprised that you said to not focus on like any side projects, because like, you know, if you, I think that there would be value in you having a portfolio that you could be able to share, like, Hey, here's, here's some examples, you know, projects that I'm working on now. Do you need

to like, you know, make it the only thing you work on day in, day, day out, you know, for the next, you know, six months? No, I mean, I don't, I don't know unless it's like, unless it's something like you're super passionate about, then sure, go for it. But you know, I do think that there's value. There's value in what Alan was describing in like trying to figure out somebody else's code. And then there's also value in you being able to put up your own thing to solve those same kind of problems because you're going to have to solve those same kind of, you're going to end up solving those same kind of problems, right? So I think there's value in both. Yeah, I definitely don't disagree there. I think

my biggest, my biggest thing for people that are new to coding, like if you just got out of school, right? Like you've learned the concepts of object-oriented a lot of times, and you might have even done a school project where you hack something together. The only thing is, we all did it, right? When you first start coding, you code a lot of things wrong, right? Because you're just trying to get them to work. And it still happens even as a professional, as somebody that's been doing it for a long

time. And I guess my whole point of grabbing something else down is you get to look and see how groups of people are coding something. And so you could see those patterns and then you can start emulating those patterns, right? As opposed to, hey, let me just go make a connection to a database and every single one of my files and put queries in them all because that's what everybody did when they first started. Right. And so you kind of got, you, you get to see how people start separating these things and abstracting these things. And, and so now you find out why they did it because, Oh,

I see why they did this. They didn't have to go change 50 files over here when they just needed to change one connection string. Right. So, so totally agree. That doesn't mean don't do a side project, but there is a lot of value in seeing how, how people that have coded together in a get project where there's multiple contributors and seeing how that flow works and what their thought process is. So yeah, hopefully that helps multiple people out. Like I said, we get those questions, you know, frequently and and we don't answer them all the time because I don't think we want every single show.

Like, hey, let me tell you how to go do this. So, you know, hopefully that helps somebody out, especially right now in the world economy. That's sort of crazy. So, you know, hopefully that helps somebody out, especially right now in the world economy. That's sort of crazy. So, you know, best of luck. And oh, also, by the way, that that was a message that came to me on LinkedIn. We've mentioned it before. Definitely hit us up on LinkedIn, right? Like if if if you want to friend somebody, go go find us.

Right. You can go to coding blocks dot net slash about. And I believe all three of us have our LinkedIn links there. So if you want to find us without having to try and search through 5 million people on LinkedIn, you can go directly to it and friend us. And more than likely we'll accept. I still think that's weird, so don't be offended if I don't. Yeah, Mike will eventually.

He will cave. It's totally a posi scheme. So it's in your benefit to just friend everybody. Yeah, that's right a posi scheme so it just isn't your benefit just friend everybody yeah that's right it's just it just feels so weird to me like yeah it's like it is weird it is weird totally so come be weird with us on linkedin all right so i think with that then uh let's go ahead and jump back into where we left off in the second way in the second second way so part uh this part we're talking about uh finding and filling any gaps in telemetry specifically right so we were talking about telemetry in the past episode

and we're picking back up in the middle of that i totally remember that yes for sure so finding and filling gaps in telemetry. So, you know, we've talked before, even though we're talking about DevOps, it's really about the whole organization. It's kind of like a holistic approach. It's about culture. So, specifically here,

there's a couple different levels that we can kind of look at when we're talking about filling gaps. And the first is a business level. So, these are metrics on business lines, things like sales transactions, how many new registrations, how many people downloaded the trial, stuff like that. Those are all really important. And obviously if those numbers change dramatically,

then there's something going on. And then, of course, there's application levels, which is the things I normally think of, like how long things take to complete or number of errors, things like that. Infrastructure. So our pals over at Datadog, I frequently kind of associate with this sort of thing, like keeping track of the number of databases you've got, the operating systems, the versions that you're running, how well your storage, CPU, your networking is doing, things like that. I feel like I'm talking a lot.

Someone else want to say the next one? All right. So client software, right? Any errors, crashings, timings, or anything that happens on the client. And then your deployment pipeline. We talked about this in the last episode. You know, your test suite status,

deployment lead times, frequencies, and all of that. Like, this is all super important things to be monitoring, getting telemetry on. By the way, so we've mentioned Merle many times on the podcast since we started talking about the Google pull request and all that. He mentioned something that, man, it's so good. He's like, one thing I hate seeing when people are logging, specifically logging, is if there's a failure and it keeps going into a failure loop, is logging that same thing every time. So over a 12-hour period, you got a million log entries that are all the same failure. He's like, there needs to be something like when you're doing logging, don't do it brainlessly, right? Look at it and maybe

have some sort of counter. Like if you're in some sort of crash fail loop, if this happened more than three times and let's stop, right? Let's not log that thing anymore. Just say, hey, we see that this is continually happening. And maybe after it gets out of it, say, hey, it stopped doing it, right? So you keep track of this somehow. That's a really important thing. You're logging? Yeah. Yeah.

So just another little tidbit that's just amazing because we talked about in the last episode, too, where most people or not most people, a lot of developers will log with the wrong level, right? Info versus warm versus error versus whatever. So that's another one to keep in mind. Al, you want to take the next one? Well, I would. That was a good survey. Except I'm having all kinds of networking issues, so I don't know where you guys left off.

That's why you haven't heard from me for a minute here. I was like, uh... It's the best one for you. Yeah, so I'll start us off. You're listening to... Honestly, I don't know where we are. Line 48. Line 48.

Oh, okay. Hey, now they know there's lines. All right, so we'll talk about application and business metrics as it relates to telemetry. So you want to gather telemetry, a tool such as core metrics, you're able to like attribute clicks and, you know, things like the actions that the user is doing. And then you're able to like associate that to an actual like cost, like what, how much money did you earn based on like, you know, sales conversions and things like that. Right. And so this is an example of like gathering that telemetry for that, for those organizational goals. Yeah. And some of those types of goals, right? Like there's something happened, but that doesn't necessarily equate to a goal, right? So you might have, we want new users as a goal, right? Like maybe you launched

some sort of ad campaign and you're trying to create new users in your application. Login events, the length of the session, right? Like a lot of times in e-commerce, this is a very important metric. Like how much time did they spend shopping on the site? Active users, abandoned carts, all these kinds of things, right? Like these are business goals that you want to track and the telemetry will help you get there. And then the next thing that they say is you need to have these metrics not just be things that you read, but they need to be actionable, which is really important, right? Like if you see that abandoned carts are happening, like for whatever reason, the last deployment that went out on Wednesday, the abandoned cart rate went up 10%. If something happened, you should be able to action that. went out on Wednesday, the abandoned cart rate went up 10%. Something happened.

You should be able to action that. You should be able to look at what changed and then figure out what you need to do to try and fix it. If they're not actionable, I love this one. If they're not actionable, they're vanity metrics. They mean nothing. Yeah. See, this is, this one's tough for me, man, because like I, I, it's tough only because like I haven't been in an environment where I've seen it done, you know, or like I, I, it's tough only because like, I haven't been in an environment where

I've seen it done, you know, or that I've been in an environment where I've, I've done it, where I've implemented, I've been in environments where we had telemetry, but we never had those things like tied to a specific commit so that you could go back. I mean, I could tell you, like, if you were like, Hey, what point did you add that thing? I go, oh, well, let me go look through the Git log. I'll tell you exactly where I added it. But in the telemetry itself, you know, you didn't know that, you know, like it wasn't it would take a developer to go and backlog, which I don't think is what they're describing there. I don't think I think what they're basically saying is if you have business goals that you're measuring, like like abandoned carts. Right. Then if you see that go up or down, then you need to be able to action it somehow.

So I don't think that they're trying to say tie it to a commit. But more than likely, if you see that there was a significant jump or dip in some particular metric, then you should be able to look at the point in time and say, hey, what changed then, right? Which is exactly what you just said, right? Like now I'm going to go back through and see, hey, what changes happened in this particular change log, right? Airbrake used to do that. They used to sponsor the show and we had an account there for,

well, we still have an account there. That's awesome. And they had an API. So whenever you did a release, could mark a you could uh mark a deployment basically and you can actually uh add notes there too so like if you knew there was a aws outage or something you can go and mark it there and then all your graphs will always show like your little note that you kind of put in there it's just super cool that's excellent well jira has a similar capability too if i recall where you could like version,

you could create a version in Jira that would like group up like, Hey, here's all the tickets that you did. Right. But that's not then tying it back to the telemetry piece. Right. Right. So that's where, that's where like, I haven't seen anything that makes that connection. Like I, as a person, I can make that connection, but I don't, right. I, I, I guess I kind of took it to mean that like they wanted something, you know, automated. There would be like this, this, this version is tied to this set of things,

you know, product that needs to be created or a service that needs to hook up those things. Right. Well, I mean, honestly, it reminds me of like change logs,

for example, you know, where you, and, and, you know, you might have like some automated tool that creates your change log and then that change log might reference

tickets but again that's still not the telemetry part of it though so i don't know you still got to hook it on to the graph basically it's hard i give up we're done uh all right so the next thing that they said is by radiating these metrics. And if you remember right from the previous episode, this whole radiating the metrics means just putting it out there for everybody to see. Right. Like putting it up on screens, on walls, whatever. Just get it out there so everybody can see you're not hiding. You're enabling the fast feedback with the feature teams so that they know and you know what's working and what isn't. Right. Like if you had some sort of feature flag that you toggled on in the latest release and you see your telemetry on something going up, then maybe that's a positive thing. If it was going up in a negative way, then you know that, hey, this didn't work. Let's turn that toggle off and then let's see if it gets back to normal or better, right? I like the idea of it going up negative.

It can happen, right? The number of failures going up is not good. Yeah. I mean, it was like immediately I thought of like a negative number, but I'm like, well, negative numbers don't go up, though. So how's that work? So Pat Flynn, we've talked about in reference on the show. He's not a developer, not a coder, but does a smart passive income blog, empire, podcast, whatever. I know, Alan, you're a fan.

So, tell me if you remember this. He did a thing a couple of years ago about his favorite metric, the one metric that he pays attention to. He said he's got metrics on all sorts of things, YouTube subscribers, subscribers to his products, web traffic, podcasts. That's just tons of stats. And he, for a while there, he would like kind of look at one and try to focus on it and improve it and then, you know, maybe get bored or kind of move to another one once he kind of hits

some sort of like, you know, diminishing returns. What I'm saying is that it was kind of driving me nuts and sometimes it was leading him to optimize for the wrong things. So what he tried to do instead was come up with like one metric that he felt really like represented kind of everything that he was going for. And he would try to focus on that one metric. And you know, this is kind of tangentially related,

but I thought it was kind of fun to bring up anyway. So the metric that he ended up kind of deciding that he wanted to go after and that he wanted to kind of track was actually thank you notes. So he put up – he had an address on his website. And he's like, you know, if I get three this month and seven the next and 11 and then two, then that kind of tells me that I'm letting people down or I'm not making as much of an impact. And that's more important to me than number of subscribers and amount of money coming in. I think if I make that number better, if I help more people, I think it's going to help all my other numbers too. So of course he didn't stop tracking all that stuff. He didn't turn it off, but it was just kind of cool to think that he had like one number every month that he kind of focus on and go after. So I was just kind of thinking like, if you had one metric to put on a dashboard or something in your office, like one number, one something to represent the state of your organization, what would it be?

How about you? You go first. I saw you throwing the question out there. It's a terrible question because you know there's no context to it but um you know i i think of like um basically uh card abandonment rate is uh something i always thought about like an e-commerce kind of um system but really that's you know that's not a great number because i put stuff in my car all the time that just because i kind of almost want to keep track of it while i'm thinking about stuff and then I have no intention of buying it.

Bounce rate is really big for content providers because they want to know, like, do people come to your site and then stay there or go to something else? But even that's like, I don't really have a problem if people just come in and get what they need and bounce out. Like, I'm fine with that. Bounce rate was one specifically mentioned in the book because it would depend on what type of site it is so you mentioned like a content provider but if you were a search engine you don't you don't want them to stay around on your site long if they're lingering around your site that means your search isn't working right that's crazy okay i don't know if there is a right answer i just thought it was kind of interesting to think like for your biz or your org like if you had to pick one number what would

it be yeah that's that's actually really good. I mean, I would imagine it depends on the industry too, right? Like if you're a service industry, you probably care a lot about how people rate your service, right? Like did they have a good experience, bad experience, whatever. If you're, if you're a hardware provider and Apple or something like the number of returns you get, you know, or the number of quality control issues that you get. Like I think it's very industry specific,

but I did like the fact that Pat Flynn was like the thank you notes. I mean, that's, I don't think that's something you make up as somebody that's in these industries. We said the reason we like reviews is because it lets us know that, Hey, we're, we're helping, we're reaching people, right? And when somebody writes us and says that we've changed their lives, which is still mind-blowing to all of us, because we helped them get their developer job and change from a career that they hated to something that they love now, right?

Like, that's real stuff. And so the metric that you pick has to be important to what your core needs, beliefs, values, and, and really what you're trying to do as a business. That's, that's really cool. And I kind of wonder like, you know, a lot of times, um, as a developer, depending on what you're working on, you don't necessarily have direct influence on like new customer signups or something. Maybe that's more marketing or whatever. Like you don't work on the login page or, you know,

you're kind of detached from that. So that metric probably doesn't make sense for you. But at the same time, if you're the metric that you realize if you ask yourself and think about deeply and the metric you come back is is like my boss you know leaving me alone or not giving me a hard time or you know whatever then that kind of tells you a little bit about your situation there and so i don't know i think it's a good question to ask yourself just to see what you come up with today's episode of coding blocks is sponsored byadog, a SaaS-based monitoring and analytics platform for cloud-scale infrastructure, applications, logs, and more. Datadog uses machine learning-based algorithms to detect errors and anomalies across your entire stack, which reduces the time it takes to detect and address outages and helps promote collaboration between data engineering operations and the rest of the

company and if you go to datadoghq.com coding blocks you can start your 14-day trial and if you start this trial and install agent then they will send you a free t-shirt which is purple and has a super cute dog on it so again that was datadoghq.com slash codingblocks and start that 14-day trial. All right. Hey, it's your favorite Jay-Z coming back at you again. As opposed to your not-so-favorite Jay-Z. Well, wait a minute. I mean, like, you don't know who my favorite Jay-Z is.

How do you know? I mean, I could guess. It's not a lot of competition. What? it's not a lot of competition what uh there's me and there's jwz who by the way still blogs on live journal so i'm a little cooler than that guy and i think there is a musician yeah i mean it just depends man if you're in a new york state of mind then you'll know the jay-z okay yeah so go on dust your shoulders off and leave us a review while you're at it. If you go to codingblocks.net slash review, then we try to make it easy for you.

We put in link system stuff. I tried to leave a review the other day. I couldn't figure it out, but I should have gone to our website and gotten some help. Don't you owe us a dance video? I thought I sent that to you. Oh, really? I'll have to check on that. Yeah, I don't know what happened there.

Yeah, I definitely did some dancing. Okay. Definitely a lot of the big dance videos. Great. Huge. It's great. Yeah, send me a TikTok link and I'll watch it. Yeah, I definitely don't want to lose that because i mean the the um outfit changes were just spectacular but it was also surprisingly difficult to do that without you know stopping the video or anything were there sequins involved or lots of sequins yeah yeah all right all right

well engine at runtime there better be sequence all right well then what we're talking about reviews that'd be great my eyes it hurts all right so uh with that we head into my favorite portion of the show survey says all right so a few episodes back asked, how do you feel about semicolons? And your choices were, sadly, they're a necessary evil for my language. Or my language doesn't require them, and I'm a better dev for it. Or there's only a finite number of keystrokes you'll type in your lifetime. And since they're optional in my language of choice, I'm not wasting any keystrokes. Or, lastly, they might be optional,

but as a wise man once said, never going to give you up. All right. You still didn't see it coming, did you? I just got rig-rolled, though, yeah. Got rig-rolled and survey says. All right. So I think Alan went first last time, if I recall.

So, Joe, I'll let you go first. Okay. Well, I think that lovingly they're a necessary evil for my language. What's the opposite? Happily they're a necessary evil for my language with 61% of the vote. Okay. Okay. Wow.

Okay. So I'm going to have to go with the Rick roll choice here and say that they might be optional, but as the wise man once said, never going to give you up. So what's your percent? I'm not going 60. That's crazy talk. Let's go 40. 40%? Okay. 40. All right. So Joe says, well, depending on your perspective, Joe says it's either sadly or happily they're necessary evil from my language at 61%. And Alan goes with 40% with they might be optional, but a wise man once said never going to give you up. Right?

Is that right? That's it. That's it. All right. And the winner is never going to give you up, never going to let you down. Yeah. Never going give you up. Never gonna let you down. Yep. Never gonna run around. Go ahead. And desert you. Yeah, there you go.

42%. Oh, look at that. Yeah. Yeah. Wow. It might be optional, but... And of course, I had to have fun with that was the that was obviously the fun option there but uh you know joe you you did have the second place answer though

but you overshot it oh yeah i mean well i mean if you know math you would have already known that but you know being the math of my chicken. Barely off. Do you know how many numbers there are? There are so many numbers. And to be off even by double digits is just nothing. You know, when you put it like that, Joe, you make a really good argument. I'm not going to lie. But yeah, 40% of the vote was, sadly, they're necessary for my language.

You know what's so funny about this? The reason I went with that last one is just personal. Like, when you write JavaScript, do you put the semicolon on the end of the line? Yes. Nope. I have to. Like, I have tried not, but it feels like you're ending a sentence without a period. Well, depending on the IDE and the linter, you might get complaints about it.

Yeah. Yeah. I'm not even worried about that. It just feels wrong. I feel like I'm empty inside if I don't put that semicolon on the end. I don't know why. It's the way. It's the way. So for this episode survey, I'm going to get some hate mail. So just hit me up at mathemachicken on Slack. But so this episode survey is, hey, what's your favorite mobile device? And your choices are an iPad, the tab father of tablets, or an Android-based tablet, great

hardware specs without the hassle of long-term support, or a Kindle. It was on sale. Or Chromebook for the win not quite as portable as a tablet nor as useful as a laptop or or a two-in-one laptop a giant bulky tablet that can run docker i gotta say so we didn't look at these beforehand. I love your wording on all of them. Yeah, I want all of them. Yeah, so again, hate mail at the Slack channel. Yeah, at the chicken. So I got something to sneak in here.

Okay, okay. So yesterday on Facebook, a buddy of mine posted, and their question was Kotlin or Java. That's all he said. And, of course, that's not enough context to answer, but it was kind of a fun question for me, and I went ahead and tried to answer it anyway. But it got me kind of thinking, I don't want to ask that one.

I want to ask a different one. I thought it might be kind of fun to do this. But when you give your answer, I don't want you to cast any shade at the one you don't choose. Oh, you can't do that. Well, I don't expect you guys to respect that rule, but you know, we got to try. So I was going to throw something at you.

So just gut check from the hip, not worried about facts, just total feelings here. We'll go, we'll go outlaw first. Go or rust? I think we had this similar conversation related to the Stack Overflow 2020 survey. And I think we said that rust was the most wanted, if I remember right. So I'm going to go rust. Okay. That's good. Well, what do you think,. So I'm going to go rust. Okay.

That's good. Well, what do you think Alan? I'm going to go, go primarily because it seems like it's an everything. So yeah, I'm going to take the one that seems to have more market share. Yeah.

I'm going to go with go as well for basically the same reason that i think it's just a better investment of the time so not knowing anything else about the project or anything else about you know what you're trying to do with the languages which is of course how you should really make that decision i gotta go with go just because it seems like it's much more popular and so much of the like the docker kubernetes ecosystem is built around go templates and just go as a language and so um it seems like a seems like a, a safer investment to me. Yep. So, so I looked it up and I was right.

Rust, but rust was ahead on the stack overflow 2020 survey by a lot. Yeah. But, but in fairness, that was the most wanted when you looked at the actual usage of it. Most love is like at the bottom of the heap, right?

It was, it was the most loved was uh was rushed go go was fifth in fifth place rust was far and away number one but when you look back at the stats the the people using it there was such a low number on the actual rust side like i think the people that loved it are the people who wrote it. This is what I'm saying. Well, yeah,

but I mean, it's not going to get 86% of the vote on a stack overflow survey from only the people that wrote it. So my thinking for picking rust was because if, if people love it that much, if they're that passionate about it, I want to know why. Yeah.

Right. Like there's gotta be something to it. it so that that's why i picked rust all right i like it thank you i like it all right well i guess i'll have to include two surveys on this episode oh awkward that's my specialty this episode is sponsored by secure code warrior secure code warriors gamification lets you learn how to write secure code from the start and identify bad code already present so i gotta tell you i had a chance to go in here and mess around and gamification is really the name of the game here for me is when you go in, you see scores, right? So Joe and Mike had already gone in and done some Docker stuff. And I got to go in and see that there were

some scores up on a leaderboard. So that was all the incentive I needed to stay up extremely late after the last podcast we recorded and play with it. So I think Mike had said that he was beating Joe's X score. Well, I went in and beat both of their accuracy. So I will say the one impressive part about Secure Code Warrior, at least for me, is you're not actually writing any code, but it's impressive how effective this stuff sticks with you just by looking through various different code pieces and choosing which ones have the vulnerabilities in it, because it teaches you to examine what's there and pick out the vulnerabilities and the problems with the code that's already there. And it's,

it's truly an effective way instead of just writing tons and tons of code. Yeah. You know, Oh, sorry. I just want to interject one thing real quick was that you talked about the, um, uh,

the, the code there, like not writing the code. It's really important to call out like what that interface looks like. Cause they'll show you like, here's some bad code and you got to like pick in point at like, what's the bad part? Like here's a,

here's literally the haystack. Go find the needle, right? Pick the line. Yeah. The line that has the bad code. Pick the line of code. That is the bad part. Like here's a, here's literally the haystack. Go find the needle, right? Pick the line. Yeah. The line that has the bad code. Pick the line of code that is the bad code. And, and then once you do, they'll be like, if you do pick it right the first time, they're like, Hey, congratulations. And then they'll be like, what would be the appropriate fix for it? Right. And then, and then they'll give you like some choices in some of those choices. They are, they will look compelling.

You'd be like, Oh no, I think that one might be the one. And you really, you got to study it for a minute. It's not going to be, I don't know how else to say it because the way I'm describing it, it might sound like, Oh, I could just easily click one and go away, but it's really not. You got to pay attention. Yeah, the fixes themselves are actually really good too. So I've learned a few things, you know, I mentioned with the Dockers and Kubernetes side of the house where the fixes that they put in

weren't like my first kind of inclination towards how I would fix it. So immediately it got me kind of thinking like, well, why did they choose this approach to fix it rather than another one? So it got me off and Googling and realizing that that was actually the preferred pattern for doing it. So it was just really cool. And also, I got to mention that it's just fun.

The gamification is really cool. I'm looking at the C-sharp one right now, and there's an adversary profile. We've got an alias of Daniel Pytho, who is well-known for targeting world-leading companies and selling information on the dark web. And we've got a threat profile here talking about SQL injection. So I know that if I accept this mission, then basically that's the kind of problems I'm going to be looking at for this little segment. And it's ultimately, I could get through this in probably like 15 minutes maybe.

And that's like a nice little milestone and I'll get a score there. And then Alan will come along and beat me in it. And so it's just super well done. And I definitely recommend checking it out and getting your boss to sign off on it. Yes, you definitely need to start getting a leaderboard together for your organization. So head over to discover.securecodewarrior.com slash codingblocks to start your next game. Get that tournament going within your team and have some fun. Again, that's discover.securecodewarrior.com slash coding blocks. And if you score 5,000 points,

you get a cool t-shirt. One last time, that's discover.securecodewarrior.com slash coding blocks. All right, so let's talk about infrastructure metrics. So we need enough telemetry to identify what part of our infrastructure is having problems. So how do we do that? Well, I thought we were just done. Oh, it's just enough to say it. Right. Yeah.

So you need to graph telemetry across your infrastructure and application because this is what actually allows you to see that things are going wrong. Right. We've talked about graphing things individually, but if you can overlay them, that's where you really get your money. Yeah. Now we've looked at a couple a couple different things. I remember we saw something at Elastic on Atlanta where Elastic was kind of tying disparate sets of information together and we were trying to figure out how the heck they did that. How they were able to kind of

correlate different kinds of things. It's a really tough problem. If you've got a lot of control over the agents or whatever sending those metrics, like we mentioned DataDog frequently, a sponsor of the show, but that's kind of their bread and butter is taking information from disparate sources and marrying it together so you can make sense of things because otherwise

it's just a jumble of numbers and so that's definitely the hard part and even uh i think we've talked a little bit before about how um this stuff isn't cheap like the metrics uh the logging it's a lot of information moving depending on how your sampling rate or whatever it can be really expensive and so it's kind of hard to know how much is enough and how much is too too much and a lot of times you'll see in different systems like you'll see one thing that's like log to death it has like every metric and it's all amazing and then you'll have some other piece that is way more important and has like basically nothing it's coming out of it so you know graphing those things across infrastructure

and the application allow you to see when things are going wrong much easier than having either one separately. Yeah, and they also say that when you use these business metrics along with your infrastructure metrics, this actually allows your development and your operations teams to work together

much quicker to resolve problems, right? Because now you both see it, right? And you see if there's problems happening. And if you've got some good BI people like on your team, then they can correlate stuff too. Like maybe you'll be able to see like, hey, if, you know, I mean, this is like business and business metrics correlating, but you might say like, hey, when we ship orders faster, we get more orders you know there's like a noticeable uptick in orders and so there's a correlation there between these two things now that's business business but you might see some other stuff too that's kind of surprising like when this you know site's running faster we get more orders that's something that's like

very well known at this point it's uh yeah it's almost mythical at this point like the faster your site is the the more conversions you get. Oh, yeah. Amazon had some great stats on that. No, was it Amazon or Google that had those stats? It was actually both. So depending on where you go back to, if you go back to when we were talking about the data-intensive applications,

Amazon had some real strong – they had some good case studies where Amazon focused on not the top 1% of customers because the problem is they had so many orders that they couldn't make their infrastructure run fast enough for all their order history, but they needed to do it for people that still were frequent buyers, right? So they would try and optimize their site for the 99% use case instead of the 1% use case. But Google, you're right, also had similar things, which I think you're about to talk about.

Well, I mean, I wasn't specifically going to bring up Google, but I was going to bring up, you know, Joe mentioned Datadog, right? And like, I can't stress it enough. Like, we've tweeted and shared all kinds of blogs, articles, and whatnot about Datadog. Full disclosure, obviously, you heard the ad, our sponsor of the show. But they really do have a lot of great tools out there to be able to connect these logs and put these tracing through all your different applications so that you could see like how that request made its all the way through the system, but then also see like,

hey, what was our server utilization at the time that that request went through? Maybe that's why we had a high abandonment cart abandonment rate at that particular time of day or whatever, right? And like, you know, if you haven't checked out their blog, they have great articles on there. I went to it just out of curiosity. The first article in there was instrument your Python applications with Datadog and open telemetry in your pre-production environments as you're doing production so that you can see these problems before they make it to production, right? Like it's one thing to have people doing QA there and, you know, looking for regressions and bugs, but doing full on telemetry at that same level,

it makes a lot of sense. It assumes a certain level of sophistication in your environment though that as it relates to um uh like stress testing performance testing like load testing the environment in order to like be able to make those correlations and and like you even in the the shopping cart example to like have a uh to have an automated environment that's going to automate checkout conversions at scale or clicking different parts of the app and then checking out so that you can see how those metrics relate, right? And then remind marketing to not get too excited about it because that's just your test environment. Right, exactly. Hey, you know, I kind of mentioned

one time. It's unfortunately, this is going to be late for when this podcast comes out, but dash 2020 is free this year and it's virtual.

That's a, we talked about this conference last year. I had a lot of really great sessions and because of everything going on, it's coming out.

It's August 11th. I still want to mention on the show because I'm sure many, if not all, of these talks are going to end up making it online onto YouTube or something else. So keep an eye out for that because I am sure it's going to be amazing. There were so many great sessions last time. I was very envious. I really wanted to go.

I'm registering right now, so someone else needs to talk. Well, you had this somebody put this link up about why speed matters oh yeah yeah so that just was what we're talking about like so I found an article that has a bunch of links to studies not just the one with Google although I believe I saw the one we were talking about was in

there but it's just one good article that kind of gathered up a bunch because this has been since that kind of broke I don't know 10 years ago 15 years ago something like that the kind of the first study started coming out about that it has just been studied to death so i kind of take it for granted because i've heard it like a million times over now that speed is important but um if you're curious about the actual numbers behind those or you know how they tested that or just how big of an impact it can make whatever then

here's a good article that we've got then we we'll have it linked in a couple of places in the show notes here. Can we say though, that like so many people would assume that we're only talking about like webpages, but like even your mobile apps, like if your mobile app has a, has a splash screen and it's going to take time to load, but that needs to be just as fast. If you want to hold my attention, I can't stand applications that have a splash screen on their mobile app. I mean, I get why because you're trying to like load things in the background or whatever. But like, man, we really got to – as an industry, we need to come up with a better paradigm for that instead of the splash screen because I don't want to look at it. I want – it truly is frustrating at times where it's like, come on already.

You are anti-branding. I feel like I'm stuck in Spaceballs. Like, we can't stop, sir. We got to slow down first. It's like, come on already. Just load the app. We can't, sir. We got to cache the app first.

It's like, no. Just load it. These are the things that keep me up at night. All right. So pushing on here, the next one that we have is overlaying other relevant information onto our metrics. So in addition to the business and the infrastructure telemetry that we were talking about before, You also want to graph your deployment. So this is going back to what Outlaw was saying, like, hey, how do I know exactly what got shipped out with this?

If you could overlay that as well, now you can quickly see that if it was a release that caused whatever application problems or infrastructure problems, right? It could be one or the other, or it could be both. But putting all three of those things in the same space where you can view it is hugely beneficial. Oh, and this is something interesting that they say too, is there might even be a settling period, which makes total sense. Basically after the deployment goes out, things look fine for a minute, or maybe they go crazy for a minute because caches are replenishing or whatever, right? But then it'll settle back down, right?

So you might expect that after a release, you're going to see things go haywire for a minute because you know that there are certain things going to happen. As long as they come back down into that normal range that you're used to seeing, then you're probably fine. You know, being able to, uh, thinking back to this idea of being able to like graph the deployments over top of like the metrics. Do you remember that, that, um, I don't know if we've talked about it on air, but I know in, in personal lives, we've definitely talked about it where there was this scenario where I had found this issue that had basically, unbeknownst to the company, was costing them hundreds of thousands of dollars a year, where based on a deployment, somebody had changed something to where certain recommendations were no longer being offered. And I was like, no, no, no, look, you can actually see

like, here's the, here's how much money we were bringing in per month when we were showing these, these recommendations. And then boom, that release went out and now you're no longer getting that money. And that money equals, you know, I'd say it was like $300,000 a year. Like it was a significant amount of money. Right. And, and, and it was because of like, I didn't have this kind of overlaid graph. I just have as the developer who, um, one, I had access to the metrics so that I could go and poke around in those things. And I knew that these specific areas of the app, of the code and the app, and I knew like, you know, what should be given metrics and whatnot and was able to like you know so it was only like coincidental

that that i happened to be able to find it wasn't in your face yes fortunately and that's the that's the thing is like having this kind of telemetry graphed over top of your deployments like how amazing that would be right like i only happened to find that coincidentally. Right. Just because like, you know, I happened to know the area and I could go and I had access to go look at it. But you know, it stinks about that. Point that out to like a marketing.

If they could like easily see this, then not only can they easily see when things that they do, they could make, they could do experiments and say, Hey, you know what? What if we were to make recommendations like three or four levels deep? No, maybe that didn't work out. Maybe if we only made it like one or two levels deep. They could do like all these different experimentations to see like what works better for them. And they would have all the metrics there to like have actual data to make those decisions instead of it just being a guess. And you know what stinks about that is the only reason you were able to put two and two together was because you looked at it within a certain amount of time.

Right. Like you saw it like maybe let's say within two weeks of when the deployment happened. Otherwise, if it had been like, was this one that was. No, we didn't actually. It's longer than that. Yeah, I know. That was how I happened to catch how significant it was. Because it had been going on.

Because like a month or two had passed, and I'm like, wow, did you guys happen to notice that this was really low in this area? Like, huh, why is that? And I got curious, and I started poking around to figure out why. And I'm like, oh, yeah, somebody introduced a bug here, and we're no longer showing these recommendations, and that's why. It's crazy, huh? It doesn't show you how important recommendations are. Like how many orgs have marketing that has great stats about marketing stuff, and customer service has great stats about customer service,

and developers have great stats about their infrastructure and releases, and none of that stuff is tied together. It's crazy. It's crazy. It's nuts. Well, I mean, I've never been in an environment that has shown like, I mean, imagine this. Maybe like a Microsoft, maybe somebody has it, but like an environment to where you could correlate your releases

with customer support issues. Right, right. Like, oh, all of a sudden we're seeing more issues with customer support. What happened? Well, we did just do a release yesterday and here's the five features we released. I wonder if it's one of those.

Yeah. And sometimes you have a, you'll have like a BI team that like is responsible for tying that sort of stuff together, but they're just attached for the problem. Like they're so caught up with like data warehousing and moving bits around. They tend to think of that stuff as bits,

but you get a developer there who sees a chart for marketing and can say, like, whoa, that dip corresponds to the day we did this thing. And so sometimes just having the right people see the data when it's convenient and fresh in mind is really important. Well, that's just an overall theme to these books in general, though, was, like, empowering the people who know that to know an area to be able to experiment and make decisions and try things. So like, even in, you know, that, that the comment that I just made about like, allowing marketing to be able to know that, right, like, they know

what they want to try. And if they can actually see those correlations, right, then then they have that, you know, expertise of like, what they wanted to do do and did it work or did it not. Otherwise, you're relying on somebody who has the access and the curiosity to go poking around in both things to be able to put those pieces together. And this is why the radiation of this information is so important, right? Like if you can put it out there so anybody can look at it and you're not trying to hide that information, chances are you're just going to increase your value over time. Yeah. Because, I mean, when people aren't scared to, when people aren't trying to hide it and when people have the ability to look at it, by and large, people get excited about improving things, right? So only good things can happen there.

The radiator terminology was curious, though. It was like, it's a good, it's an interesting term for it, but it was like, I don't know that I would have been creative enough to come up with that choice of words for it. It's interesting. Yeah. And then the last thing that they said is you should also do the same thing for maintenance, right? If you're having to do some sort of upgrade on your server, whether it's the OS or whether it's hardware or whatever, you should also be graphing that.

Because some change to the underlying OS could be all of a sudden when your application errors spike, right? I know that we've all been a part of that where some sort of OS upgrade broke SQL Server or broke.NET or broke something. And all of a sudden, you're scratching your head going, because let's also keep this in mind. As the developers, we weren't even aware that a server upgrade was happening. We only find out about it because we get called saying, hey, the application's not working. You're digging through the event logs and you see all of a sudden that, hey, wait, there were a bunch of hot fixes applied. Oh, and there was a scheduled restart last night. And this is when everything happened.

So again, your time to getting to the fix is severely delayed because you don't even know that something happened, right? Because the group that was handling those upgrades was detached from the group that's doing the applications. And there's no way to correlate the two except for digging through a bunch of logs. So yeah, putting all this stuff together, man, like it adds so much value. And it's kind of surprising to me that probably more companies don't even consider this, right? Like it almost feels like not necessarily this book, I'm assuming because I haven't listened to or read them, the Phoenix project. And, um, what's the other one? Unicorn something, unicorn project, the unicorn project. My guess is these topics come up in there. They're so good. It should probably be a listen for any kind of CIO or CTO of a company so

that they can think about these things. So that, because if you can drive that change from the top down, you improve your entire organization as a whole. I would imagine. Both. It's entertaining. They're just good books.

Yeah. Yeah. They're so good. I wish I had listened to Joe's advice years ago about the Phoenix Project. Like, why did it wait so long? Yeah, he said it like three years ago. I still haven't read it. I think it was seven years ago.

Yeah, that's right. We've been coding for at least three years. Yeah. So now I want to start my own company, right? And I know that DevOps is really important. I'm going to get that ci cd pipeline going from day one and i'm going to get the telemetry hooked up so i can see exactly what people do i'm going to correlate it to all the things that um that basically across uh you know applications and

businesses and also just you know standard kind of competing metrics so i got all this right so now what's the company about what's the business model it doesn't matter nobody's gonna succeed because that's right no matter what you're good that's what the third way is all about is actually making the money it's the profit you know i wonder if there's like some jenkins plugins that that help with this kind of thing hmm that's an interesting call out hey if you know of something let us us know. Yeah. We'll probably, if we remember, someone will win a book if you leave a comment because we keep forgetting to

mention that. Yeah, we forgot to do that on the last episode. Yeah, totally. And we should actually say that, hey, even if you already got the DevOps handbook previously, you should still comment on this one. Maybe if you want one of the other books, if you happen to be the lucky person that won and you're like, hey, but I already got the DevOps handbook, you you want one of the other books, if you happen to be the lucky person that won

and you're like, hey, but I already got the DevOps Handbook. You can pick one of the other three because all three books are so good. My point is you get to pick which one of the books you want to get. We'll always work with you. Maybe. Maybe.

You may say no. Right, right. We'll always try to work with you. Customer service with a smile. That's right. So, in conclusion, telemetry is muy importante, right? That's really what we're getting to here is, man, it's probably way more important than you ever thought. So, muy, muy.

Muy, muy importante. Yes. And just reinvigorate the previous topic to the first way was systematic thinking. So thinking about things in systems and getting your pipeline going. Second way was all about amplifying your feedback loops. So things like telemetry and getting the right people seeing or getting everybody seeing the right information.

And what's up next is the third way, which is building a culture of continual experimentation and learning. So episodes 140, 141, 142, 143, and 144. I mean, we still got a ways to go. We got to get through like hypothesis driven development. Yeah. So it's going to be like 18 more episodes before we get to it. We'll get out of the second way eventually. So hang in there.

No, I'm just kidding. Lots of surveys. There will be surveys. Survey says. All right. So, yeah, we'll have plenty of links in the resources we like. Obviously, we're all big fans of the DevOps Handbook, the Phoenix Project, the Unicorn Project. You can't go wrong with any of those books.

But we'll have other links there in the resources we like. And with that, we head into Alan's favorite portion of the show. It's the tip of the week. Alright, so I'm going to lead off with I'm a little saddened today because I only have one tip this week. Part of that is because I was on a little mini vacation and I didn't touch a computer much

and it felt kind of nice. Wait, you were gone like a week. How's that a mini vacation? Well, not a week. I was only out four days. Yeah. But not including the weekend. The weekend. Well, I mean, one of the days was a travel day.

So, yeah, I was only really on vacation for four days. Your definition of mini weekend or vacation of mine are different. A real vacation is two weeks plus. So a mini, a mini vacation in my mind is a weekend. You go somewhere for the weekend. That's a mini vacation. Anything more than that.

It's like, okay. Maybe I feel like I've been stuck in my house so much for this year. I don't. Why? Why Alan? Everybody. A trip to the park is a vacation for me at this point.

I'll just say that. I thought that was your office. I've seen your duck pictures. I know, man. I need to go back there. It just got too hot here in Georgia. All right. So on to my tip here. So this one, I'm actually really excited about this one. This is not a technical tip, but this is something that I think is just amazing that Google's doing. So I'll have a couple of links. The first one is to a Forbes article where they're kind of giving you a gist of this. And really what it boils down to is this. Google has a thing that they've had for a few years now, I think since 2017, and it's called Google Career Certificates and it's grow.google.com, I believe. Now, what's cool about this is they've got a few programs here, one for data analytics, one for project management,

one for user experience design. And these certificates, they're like a six month program. Now, here's what's cool about it. If you go through and you complete these certificates with Google, Google treats them the equivalent of a four-year degree because these are like hardcore, right? Like you go in, you learn this stuff, you are going to get the real meat and potatoes in this thing. Now, that's cool enough in itself, right? Like if you're somebody that's been stressed out about how am I going to go through college and do all that kind of stuff. Like maybe this is an option for you if you're interested in this thing. What's even better is Google is also doing need-based scholarships. So if you don't have the means to put yourself through this, you can actually contact Google and the courses are actually done through Coursera, but you can

contact Google. They're providing $10 million in Google.org grants for one and then your scholarship. So you could potentially go get one of these certificates, get it paid for, get the skills you need to potentially move into a position, maybe with Google, maybe with some other company, but these certificates will carry some weight because they are true learning boot camps, right? From a fairly big company. So this is just amazing. The fact that at least in my opinion, the fact that Google is going through and putting these programs together and then also helping people get that education if they truly desire it and they don't have the needs to do so. That's awesome to me. So if you're somebody that's interested, you should definitely check this out. Like I said, I have the Forbes article there. And then there's also grow.google.

It's grow.google slash certificates is the other one. And that will show you the list of things that they have right there. And they even show you the median wage of people that get these jobs when they get these certificates, right? Like the median wage for a data analyst was $66,000. For a project manager was $93,000. And for a UX designer was $75,000. And they all listed on the site there. So, you know, really exciting stuff.

So backing up to our original conversation or conversation at the start, we were talking about like, hey, how to get started as a developer. If you just go to grow.google. So skip the certificates part and just go to grow.google.com. Grow.google. They actually have a section on there for job seekers and students. Oh, that's awesome. I didn't even notice that. That's amazing.

Yep. Yeah. Yeah. I love Google. I do wish that they went back to the old mission statement of don't be evil. Right. I love it when that was their mission statement. Somehow they did.

Yeah. If anything else, it's like's like wait what does that imply then yeah we don't say that anymore like why not that's awkward right all right so my turn so i know that neither of you are going to listen to the podcast uh that i'm well, this is so awkward to say. This is awesome. So I'm going to reference two podcasts here in the next 30 seconds. And I don't think either of you have heard of either one. So you're welcome. So my name is Joe Zack and I know the best podcast of the week.

So there's like five of you out there who are gonna know what i'm talking about you're gonna think that's very funny and charming i think that was a polyshore reference that's good though that's good the weasel buddy so i stole that There's a guy on the Besties podcast, which I'm not going to talk about because I want to talk about another podcast. Okay.

This is me just being awkward like I do. So, you know Sean Martz? Yes. Sean Sean, who has a kicking beard now, by the way. Sean that we've talked about many times. Sean that we love. Ohio Sean. He's got a podcast.

Oh. Yeah. And I have been hoarding this information. It's got seven episodes right now. And it's a book club with some friends of his called Hearthbound. And they are currently reading through The Witcher, taking notes, making

jokes. very funny. Some have seen the show. Some haven't. Some are reading books. Some are doing audiobooks. But it's cracking me up. And I haven't read The Witcher books, any of them. And I'm still just enjoying the way they talk about it.

It's just been really fun. It's been a nice break to get away from kind of coding stuff and just like listen to friends having a good time. So it's been a nice break to get away from kind of coding stuff and just like listen to friends having a good time. So it's been really enjoyable. So if you're into The Witcher or if you're into funny podcasts or if you're just into Sean, then I recommend checking out the Hearthbound podcast. You can find it at hearthboundpodcast.com or wherever quality podcasts are found. Well, that's awesome. That's fantastic. Yep.

That's pretty funny. So was the Pauly Shore thing a reference to Hearthbound? Because you said you were going to mention a second podcast. Yeah, it was a terrible time to do a reference to another podcast. We're talking about another podcast on a podcast. Okay. Yeah, terrible reference. But I should have done that when I said, hey, the introductions, I should have said, maybe next episode I'll do, my name is Joe Zack and I know the best game of the week.

That's what the guy says. Every episode, he always says that. And it doesn't even make any sense. Is that supposed to be the, is that from, because I haven't listened to it, but you were a guest on,

was it GameFX? Oh, Gaming Fix. No, that's also another excellent show. Is that the one? I love podcasts. GamingFix, which I love. But no, it's The Besties, which is Spotify exclusive, and it features some ex and some current authors from Polygon, the website, and also to the McElroy brothers who are on shows like My Brother, My Brother and Me. Or also they had another one where they played Dungeons and Dragons.

I can't remember right now. Oh, my gosh. But it's really good. But they're just really popular podcasts. So there's going to be people I think that are going to overlap with this show. They're going to appreciate that joke. It was just terrible timing on my part. Sorry for bringing it up. How do you have time to listen to podcasts anymore though?

That would mean I have to leave my house. I only do – I have not been doing any tech podcasts. So sorry to all my tech podcaster friends I've just been like entertainment only wait wait wait who are the three friends though I'd imagine it comes up on the show it's Sean and I don't know the other two

that's ridiculous it's not in there about Sean it is it is on it yeah it is no no no it was totally on it it's at it is. No, no, no, no. It was totally on it. It's at the top of the page. It was terrible. Oh, wait. It's in the logo.

Yeah. I see it now. Lou Chapman, Sean, and Matt Mullen. I clicked about. I was looking all over the page. I didn't expect to look up in the logo. All right. I take it back.

I guess you don't need to fix it, but I still would. I put it in that about. I'm done. Yeah, I didn't even recognize that that was just an image at first but yeah okay uh okay so um so here was here's my tip of the week then so we're in this whole devops world right so we're like combining everything and hey there's also this whole sec ops thing right? That now we can like combine into this whole world. Well, Google released this really cool new thing called Tsunami. So you guys are familiar with like a Qualys type service, right? Where it can scan your network and look for like vulnerabilities in it.

So Google has their own that they have developed in-house called tsunami that they just released it to the open source community i'll have links to this on github and uh it it works on this plugin architecture so they also included a separate repository for the plugins but basically this way this thing works is it can go and it can scan your network. And this is, this is built for like, I mean, I, you know, I suppose like smaller, you know, companies could use this too, but obviously Google built it for Google scale, right? Uh, so within their enterprise type environment and, uh, you know, to scan their network for, like, known vulnerabilities and, you know, to be able to report on, like, problems within their network. That's really cool.

Yeah. You notice that they say at the very bottom under the disclaimer, Tsunami is not an official Google product. So they created it, but it's not like a supported type thing, but still. Yeah. I mean, what does that mean? What does that even mean? It's not an official product. Okay. Like whatever. It's some code on GitHub. Like go have fun. Like I can't, well, I don't know what I do with that to say that, but yeah. But still, it's pretty cool though. Like, because like, what was your alternative before, you know, last week, right? What was the alternative? You would pay for a service like a Qualys,

you know, to, to do those scans for you. And now like, Hey, you could just run this. That's really cool. Yeah.

And it's made for scale. So guess what? It's probably going to be pretty efficient. I don't know. So yeah, I don't know. I thought it was pretty cool. And I thought it kind of related to some of the things that we were talking about as it related from like a DevOps world to like mix in SecOps into that whole thing, right?

You know, because wouldn't it be cool in those like production-like environments if you knew that somebody just introduced a new uh you know security flaw because they introduced some new package or some new service that had known exploits and they didn't lock it down i don't know we might have talked about some open uh you know problems in mongo and elastic on the last episode so maybe i don't know maybe you could have found them oh man and you can provide your own plugins to this thing too if you wanted to and it's it's based on like uh if i remember right it was it's based on like you know they built they basically built on top of in-map where they'll like you know do in-map

like scans of a host to see like what's available and then uh once they you know have those those services they'll say oh here's the known services, bang away on those, and then I don't know how they handle the random other ports that they might find. It's crazy. I mean, it'd be interesting to just look through the code and be honest with you. So, you know, last time in the news,

I had mentioned that Garmin had been hit with some ransomware. You know who else just did? Canon. Canon that does cameras and printers and whatnot. They just got hit with ransomware. Like, this stuff is going around big companies. So, like, seriously, seriously, seriously, you probably want to, before you start releasing things out into the wild that things can get access to, see what you can do to lock things down and have a good backup, a disaster recovery plan in place,

especially if you're a large company with some assets that you don't or can't really afford to lose. But I got to ask, are you serious? Seriously? No, seriously. Okay. Well, since you said seriously. All right. Well, with that, uh, we hope you've enjoyed the show as we have continued talking about, uh,

the second way. And, you know, as I said before, uh, if you haven't already, you know, if you want to subscribe to us,

you can find us on iTunes, Spotify, Stitcher, wherever you like to find your podcast apps. Uh, and you know And as Joe mentioned, if you haven't left us a review, we greatly appreciate it. We do enjoy reading those reviews and getting that feedback. So you can find some helpful links there at www.codingblocks.net slash review. Yep. And while you're up there, we've mentioned it many times.'ve got amazing show notes we got examples discussions and again if you want a chance at winning one of these three books we've

talked about on this episode leave us a comment up there on codingblocks.net slash episode 139 and send your feedback questions and rants to slack which you can get to by the way hold on forget to say this if you go to codingbox.net slash slack we've got a button where you can click to uh get in so you don't have to no secret handshake or anything you just just do it and watch that it's a slack and we're on twitter and stuff too so if you headed the website while you're there uh joining slack you can see links to all our other social stuff there at the top of the page