Coding Blocks - Deliberate Practice for Programmers

Episode Date: April 3, 2018

It's time for more cowbell as we have a special guest in the studio, Will Madison (@IAmWillMadison), join us as Allen finally gets tripped up trying to pronounce a name, Joe teaches us the value of practice, and Michael evacuates in a rainbow colored straight line.

You're listening to Coding Blocks, episode 78. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And check us out at CodingBlocks.net where you can find show notes, examples, discussion, and more. Send your feedbacks, questions, and rants to comments at CodingBlocks.net, follow us on Twitter at CodingBlocks, or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by airbrake.io.

When your website experiences an error, airbrake alerts you in real time and gives you all the details you need to fix that bug fast. Now I've set up airbrake three different times on three different apps now. And each time it's been crazy easy to do and beneficial right out of the gate. I particularly like the aggregations, which intelligently groups my exceptions into different types. So when I log into the site, I'm not looking at a list of 3000 rows, I'm looking at 12. And I can easily see what they have in common. This is a massive improvement on my quality of life as a developer. And it's such great visual experience that it's easy to sell to management.

Right now, CodingBlocks listeners can try Airbrake free for 30 days, plus get 50% off the first three months on the startup plan. To get started, visit airbrake.io slash codingblocks. That's airbrake.io slash coding blocks. All right. So on this episode, we've got our friend Will Madison. I am Will Madison on Twitter on the show to talk about, you know, deliberate practice for programmers. So this is the first time we've done this and, you know, hopefully the guest thing goes well and, you know, welcome Will. Thanks, man. Appreciate y'all having me on, dude. I listen all the time. It's awesome to be on the show this time. That's excellent. Will's one of our buddies that we worked with a few years back and just an awesome guy, knows his stuff. And

unlike us, he's not in love with the.NET side of things. He comes from a different perspective. So, you know, maybe you'll get a little bit of that on the show here. So for all of our Java developers out there, Will will be here to make sure that they get fair representation. That's right. I'm really here for all the gophers in the world. Yeah, gophers. You did Dart at one point, right? No, I did some Kotlin stuff.

Okay, yeah. So if you're already part of our Slack community, you've probably had some interactions with Will or you've seen some of his interactions in the Slack community. He's an active member. And if you're not on the Slack channel and you haven't seen him, then you need to join. Go to www.codingblocks.net slash Slack and sign yourself up. Awesome.

And as we like to do every show, we like to go over our reviews. We didn't put any names beside these so i'm taking itunes this time um and somebody can figure out stitcher for the next one all right excellent all right so uh for itunes we got pito shea we've got no ops or no no pc buzzwords montemur buster and dallas mr bimbleimble, HeyDixon, Oren0007, ChannelZ13, Ram Cassiup, Virtua Boza, Sravan Kumar Kilaru, I believe was all of them. Man, he's so good with those names. No, dude. You want to know the funny thing is I met some people out at MVP Summit from Croatia.

No, dude. So let me give you a little clue. Wait a minute. You got tripped up once in your life. For the first time in your life, Alan got tripped. I can meet someone from Alabama and be like, what? They're born and raised in Alabama, and I wouldn't know how to pronounce their name. Yeah, man.

The thing that got me on the Croatian thing is they pronounce every single letter. Every letter. So it doesn't matter how long it is. Everyone has its own individual sound. And it, it threw me off, man. Like I always try to do it.

And the guy's like, look, dude, you're never going to get out. It just, just give up. All right. I give.

So yes. Thank, thank you guys that did the reviews there. Yeah. And I actually just got to meet a virtual Boza last week. So I apologize for spelling your name wrong initially, but thanks for the review. And now I'm going to read this review.

So thank you big time to Licka O, Lean Web Start, Mains, Tactical Penguin, and Super Good Dave. We really appreciate it. Definitely. And now I,

so this, I think I've been listening to a lot more podcasts this week than I have been in recent time. And I don't know why, but there was a lot of cool stuff that came out of both from Twitter and different podcasts. So the first one is, and I'm curious what you guys think about this. So on it on security now with Steve Gibson, a podcast that I know Mike loves, and I don't know if you other guys listen to it. We've actually mentioned it as a tip of the week in one of the early episodes.

I mean, he's really good. He goes deep on things. Sometimes it's a little bit too much, sometimes not enough. I mean, but whatever. This one, it was the episode where he was talking about, and I haven't even got to this part yet. What's it called? I can't even think of it What's it called? WebAssembly. Thank you. But the interesting thing is in there, we've heard of Troy Hunt, the guy who has the haveyoubeenpwned.com,

right? The thing where it has your password leaked out and your username leaked out on one of the hacks online, right? Well, one of the things that he talked about in this episode that kind of threw me off, and I don't know that I love, is that Cloudflare is a CDN that you can plug into your website. And basically, instead of your site being hit directly, it'll always proxy through Cloudflare, right? And it's for security purposes, it's for speed purposes, it's for all kinds of things, which is a really cool service considering it's for security purposes. It's for speed purposes. It's for all kinds of things, which is a really cool service considering it's free for the most part. You can get an enterprise plan or whatever. But this is the part that bugged me.

And it was shocking to me that Steve Gibson was really excited about it. So here's what they're doing right now. And it's a neat idea. Let's say that you go to log into your site. You've got your site set up with Cloudflare. When you submit your form to log in, it's going to see if, hey, did you submit a password? And if you did, it's now going to make a request out to the Have You Been Pwned API to find out if your password might have been suspect at some point, like it had been hijacked and they're going to insert a header into the content of the data that's coming across the pipe. So if on your site, you decided you wanted to take a look and see if that header is alive there, then you could say, Oh, by the way,

we see that, you know, Cloudflare sees that you have a password that exists out there on the web somewhere, do you want to do something about it? And to me, that's kind of scary, right? Like it exposes the fact that your data isn't safe, right? Like there's this man in the middle that can kind of look at things that are going back and forth and you hope that Cloud Flare is not doing anything bad with it. Well, I mean, let's be clear in this particular scenario, you are the user of the site. Yes. So you might be registering for a site. Maybe Alan has a site, a new e-commerce site, and you're going to set up an account on it

and you're going to log in. And Alan's site is hosted on Cloudflare. And because we live in a world post-Snowden, he's got an SSL certificate on it. And he's hosted on Cloudflare for CDN reasons to distribute some of that traffic. And so Cloudflare has to have the cert. They need to have the certificate in order for that to work, in order for them to be able to relay that content for you. And so they're already the man in the middle.

You've purposely made them the man in the middle. You consciously made them the man in the middle. So I feel like that's okay. And then when you, the user, log into Alan's brand new e-commerce site, that call, they recognize that you're logging in. They see the username and password coming through. And so they make a call out to Troy Hunt's site. And then if there is, if that user ID password is in there,

then they will add a CF password pwned header to the call. And then that is what ultimately makes it back to you, to Alan's server, right? With the header CF password pwned. But does that not feel dirty to you guys at all like that that sort of scares me feel it i think it's awesome i don't know man yes i feel both ways like it's definitely a good thing i feel like they're in a good position to do that sort of thing on a large scale but at the same time i don't really like the idea of being reminded that they have this kind of power but i don't think it's anything's really changed other than we're more aware of it so right well okay it seems like both of you might be getting tripped up on the fact

that cloudflare is doing this right as a convenience to their users but you could do it on your own like if alan did wasn't hosted on a cdn in example, e-commerce site that I made up for Alan, which, by the way, get that up and running. He could make this same API call himself. You could, and I guess that's my thing, is when you make that conscious decision in your application on your own, that's fine, but this almost feels like there was the whole uproar about when Comcast and Verizon and those guys were inspecting packets that were coming across the wire. Right. And they were changing things and they were trying to inject their own trackers and stuff. Like,

I, like, I feel like this is getting into sort of that, you know, I hired you to be my CDN. I didn't hire you to be my, my, you know, babysitter type thing. Right. I don't hire you to be my babysitter type thing. I don't know, man. I don't know. What do you think? The only thing I was going to say, we'll make it whack, is if this is one of those things where they snuck into the end user license agreement and didn't send you a deliberate email saying, hey, by the way, as a

convenience, we're going to be doing this extra thing. That would be whack if they did that. Otherwise, I think it's actually pretty neat. So some form of an opt-in. Yeah. Even in the Cloudflare configuration. Yeah. I have to like, yeah, I want this. I like this. Have I been don't?

Have I been pwned? And let's be clear. I don't think they're doing anything nefarious, right? Like, I don't think they're, like, I honestly believe that Cloudflare is usually looking out for guys trying to be the good guy and help protect sites and all that kind of thing. But it just, it was shocking to me that Steve Gibson was all excited about it. And I'm like, dude, like you're always talking about man in the middle stuff.

And this is like, this is something that they just kind of did. And again, I mean, usually when we talk about a man in the middle attack or anything like that, like it's because you didn't know the man in the middle, but in case of Cloudflare, you had to consciously make them the man in the middle for your website. To serve up your content, not to modify your content, right? They're just adding a header. That's modifying your content.

I'm just saying. That's a pretty weak one, though. Again, I don't think it's a huge bad deal, but it was a little interesting. I mean, the Verizon one that you're talking about, they were adding JavaScript and HTML to the payload that was being delivered to the client. Right. I know it's not the same level, but again, just an interesting thing.

So definitely we'll have a link to that particular show in the show notes here. Another one. So SuperGoodDave, who left us a review this time, thank you. We've been chatting in Slack because our Slack channels are awesome. And we've been hanging out in the gear channel and the upcoming Intel eighth generation processors with the AMD Vega graphics chips are soon to come out. And those things are supposed to be on par with the like Nvidia GTX 1050, like somewhere in between the 1050 and the 1060 so that should be hitting pretty soon both dell and hp have some pretty decent offerings

coming up so uh we're both waiting and keeping our fingers crossed for that so do you know when like should i hold off buying a laptop if i was thinking about buying one in the next three months so it was supposed to happen in march now i don't know if this whole meltdown thing that happened with Intel and AMD, by the way, also had some bad stuff happen with Ryzen recently. Ryzenfall. Yeah, Ryzenfall. So I don't know if it's because of that they're trying to fix some of these things before they go out full market. But I would imagine here probably within the next 30 to 60 days, these things should be hitting because it was already supposed to be on the market.

So, uh, and I think some of the Dells, uh, nah, they're not up for pre-order either. I was looking at those earlier. So as soon as we get some solid information,

we'll put links on that. I mean, good. I hope so. Cause I need to, I need to mine some Bitcoin on the go. So I need as good of a graphics card to my laptop as I can get. You heard that they hacked a Tesla,

right? And they, uh, they found an open Kubernetes thing from Tesla and they actually had some of the Teslas out there doing mining. The car? The car, I believe. Like people were driving around mining Bitcoin. I don't know if it was the actual cars or what, but they definitely had a Kubernetes thing that wasn't password protected and it was hijacked.

It was on the same episode that they were talking about the web assembly stuff so uh yeah that one was packed full of cool information this next 2018 uh yeah no flying cars but they're mining bitcoin that's right sorry about the fave icons uh hacking some sort of uh uh doing some sort of nefarious uh mining it's crazy times. It's ridiculous, man. All right. So some really cool news that I just saw on Twitter, and actually Six Figure Dev, they're the ones that shared this out.

They just released information about Windows Server 2019, and that's going to come built in with Kubernetes and Linux support. Times is a changing for Microsoft. That is amazing. So building in Google and Linux, right? Like that's a, that's pretty cool stuff. Uh, let's see. We'll have a link to that as well. Uh, and then, okay. So another thing related to just really cool stuff happening. I love Docker. One of the things that's been frustrating on windows is typically if you wanted to run a windows docker container then you had to go down there to your little whale thing and say hey use windows containers right and your whale thing your whale thing the guy that's shooting some some water out the top of them right but if you wanted to use let's say you know alpine

or some other linux container then you'd have to go down there, click the little whale thing and say, you know, switch to Linux containers, which is cool that you could do that on Windows. But it was always a little frustrating that like, oh, man, I can't run my SQL Server developer container next to my Elasticsearch container, right? Now you can. So with the latest release that just hit like a day or two ago, they now have the ability to run, and I think I put the acronym up here. It's called L-C-O-W. Yeah, we need to go ahead and solidify a proper way to pronounce this now. L-C-O-W? Little Cal.

Little Cal. I propose Little Cal. I like it. All right, so Little Cal, that's Linux containers on windows. You can now run them side by side. So I don't know how fully baked and fully featured and how well this works yet. Cause I haven't had a chance to play with it, but that's truly exciting. Like, Hey man, pull down whatever you want from Docker hub and run it. Just, you know, you have one configuration and you go, so that's really cool. All right you know, you have one configuration and you go.

So that's really cool. All right. And then the last bit of news, seeing as it seems like I've taken over the section today is, you know, I've heard about blockchain. I invest in some cryptocurrencies and I like to watch my money flush down the toilet. So that's fun, right? Which Will, I think Will also uh some bit mining and some investing so you know maybe we'll get his thoughts on this but i never truly really knew what blockchain was i'd heard about it and i never really taken the time to look into it and and i've always heard oh it could change the world it could you know it totally changed the way that you do things. And I was like, really? Like, I mean, Bitcoin's like, okay, it's not regular money, but fine, whatever. I listened to the MS dev show where they had a guy on who was talking about blockchain who works on the blockchain project for Azure. And it was an awesome episode because in a nutshell, what I learned was the whole purpose of blockchain

is really just having a live ledger, right? Let's a distributed live ledger. So the lots of ledgers. Yeah. Lots of them. So that basically you can't just go put something in because it's not going to be validated, right? Like this whole bit mining thing. And I didn't know any of this stuff is really, you know, somebody's going to solve this problem and then that's going to get put on something. And then the problem is going to be easy for other people to solve to verify that that was a legit answer. Right. So the part that was interesting was this. All right.

That all makes perfect sense for the for the bit mining and the monetary, the financial aspect of things. Right. What didn't make sense to me was when people were talking about different industries. And this is where I thought things were really cool is think about something, ice cream. If you're going to be, you decided to start your own ice cream business, let's call it Madison's ice creams, right? Madison's best ice creams. When you ship these things from point A to point B, that stuff has to stay refrigerated at a particular temperature or below, right? Because if it gets

above it, then you could get listeria, you could get all kinds of bacteria and problems, right? And how do you verify that? You typically can't, right? You just trust that the refrigerated truck that you put it on is going to be proper from point A to point B. Now you put an IOT device in there, right? With the packages of ice cream, when it gets shipped, that thing's constantly monitoring the temperature. And so now you have this ledger from the time that it left your shop to the time it arrived at the grocery store. And it can be proven that, Hey, the temperature was, you know, 35 degrees here or 30, obviously below 35, but probably 32, 31, whatever. And now you'll know if there's a bump in it and you'll be able to say, Hey, there was a problem on that refrigerated truck. We can't put these things on the shelf because it can be a health hazard. Right? So

that was an interesting take to me on a real life problem other than cryptocurrency or something like that. Right. Like where does this stuff actually fit in? So that was really neat. Right. It's in the way the guy put it. And I can't remember his name. I should probably look it up. But the way the guy put it was the blockchain is for when you can't fully trust the information coming from another source, right? Like it doesn't make sense to use blockchain internally in your company typically, because you got to jump through a bunch of hoops to make it happen. But when you need to verify an outside party, then it's really cool. So at any rate, man, I highly recommend listening to that episode. I literally just did a tiny summary, but he goes into all kinds of cool stuff. So, uh, good stuff.

Oh, and then I guess the last thing, since I'm going to talk the entire episode, um, the last thing here is, is this where we say this is your favorite part of the show? Not typically. Usually we have news from everybody, right? I guess I was the one listening and reading stuff this week. Um, so no, the last thing is we've mentioned it before. have news from everybody, right? I guess I was the one listening and reading stuff this week. So no, the last thing is we've mentioned it before. If you guys are, you know, go check out codingblocks.net slash resources. We have books up there. We have things like Pluralsight and all that kind of stuff. So anything that we find extremely valuable that we use to learn and we

share with you guys to learn, we'll have on that page. So if you sign up for it, you know, it's not going to cost you anything extra. As a matter of fact, it might even come at a discount. But, you know, if you plan on buying any of those things, please do check that out and, you know, go from there. All right. And on to the show topic today, we're talking about deliberate practice. And recently I did a talk at Orlando Code Camp. I know you guys up in Georgia are just devastated that you had to miss it. I know a lot of listeners out there are just heartbroken about this.

And so I wanted to bring a little bit back and do it on the show here so you didn't have to miss the whole thing. But wait, before you go on, you asked a lot of people to come up and kick you in the shin. Did that happen? No, there was luckily a kind of a podium and I had a laser pointer. So there are a couple of people I suspected. They got that look in their eye like they might be kicking so I made sure to blind

them. Oh, that's nice. Well, it's either that or should we be disappointed that no one made enough of an effort to actually kick you in the shit. I also had a table full of stickers in front of me. So I think that kind of helped distract. I think the problem is when you see Joe in life, he's way bigger than what you think

he might be. It's kind of like Will, right? The first time you meet Will, you're like, okay, yeah, I'm going to be real nice to this guy. As long as the spacing is good in your code, we're going to be all right. That's actually what we're talking about today is tabs versus spaces. Oh, boy. Yeah, well, that's what deliberate practice is all about, practicing how you space your code. Yes. Right? You can make an argument for that.

Actually, a big part of the reason I wanted to do the talk was because of the podcast. And thanks to the podcast and really because of the Slack, I've gotten to interact with a lot of people from a lot of different diverse backgrounds and different countries and different stages in their career, different programming languages. And we kind of talk a lot on the show about what kind of brings us together. Who are these people and why are we able to communicate? What is it that we have in common? And what I've kind of come around to thinking about is basically thinking that the people listening to the show or going to Slack, they have a vested interest in being better programmers. And so I've been on this kind of like this journey, reading a couple of books and thinking

about it and reading some articles, talking to other people about what it means to be a better programmer and how we can get there. And so I pulled together some info from like five different books, which we'll have listed on the show notes. And I kind of pulled together the info that I thought made the most sense for software engineers and tried to kind of dump it into one place and distill out the kind of the core of those books that I thought could make the most sense to us. And so I was going to talk it over with you guys, and hopefully we'll have a fun and engaging rowdy show. As always.

So, to wrap it up into three pieces, I basically want to talk about what it means to be good. Like, what does it mean to be a good and a better programmer and what deliver practices. That's the answer. If it compiles, you know, you are good. Show's over. All right. That's right.

Uh, semi-colons man, semi-colons. Oh, and, uh, what deliberate practices and why researchers say it's the best way to advance bold skills in bold, the best way to advance bold skills in bold the best way to advance skills and then how we can we can take those lessons bring it into programming and i just want to point out before we dive in you know i said we've already given in that if you go to codingbox.net slash practice i've got a bunch of resources up there so you're going to find a lot of other links and some essays and stuff that i wrote while kind of preparing for this talk cool so first up i wanted to ask you guys actually and uh maybe we'll start with will just kind of put on the spot uh when i say someone's

a good programmer like if i say hey my buddy will's a great programmer what does that mean to you well for me like it means a couple of things so like the way i've always looked at it is that it's just like recognizing skill in any other way right when i watch kobe bryant play basketball right like i can tell greatness when i'm watching it uh so like normally like when you look at somebody's coaching like okay this person is deliberate they're intentional about what they're doing like they actually care about the craft and for me that's sort of what good means right like if i can look at your code and be like, okay, this person has the things lined up, right? They like name things with great intention. They didn't just go in here and haphazardly kind of just throw some code together

and make it work. That's kind of what good means. And like, they're always trying to improve day over day. And you see that progression. Yeah. I like the idea of improved too, because it kind of says like, well, maybe there's different paths that you've taken to get to this spot you know maybe you've read a lot of books maybe you've watched a lot of videos maybe you've done a lot of side projects there are multiple avenues to get there but kind of the core there is that you care right and so because you care you found some way to to get better and you kept kind of hammering at it until you got to a good spot. I was thinking of my own answer to that, which might be that in the code you can see good practices.

An example might be the inclusion of unit tests and maybe the way some of that stuff is structured. Use of interfaces and things like that, like removing away concreteness as much as possible in the places where it's not necessary, things like that. That sounds like a kind of dedication to discipline there. Yeah, I was just trying to think, like expanding on what Will was saying, like, you know, when you're looking for, when you're looking at someone else's code to be able

to define like, well, what does good mean? Right. You know, you're, you're, you're kind of seeing those types of things in it, right? It's not, it's not, well, I, this must work and I can't understand it. So they must be better than I am. That's not what I'm looking for. Man, that's a, that's a tough one for me. I, so I I'm always that guy that straddles the line between practicality and, and pretty code. Like I I'm always trying to find the balance there. So I know that, that probably most of the time my code's going to be good, but it's not going to be the most perfect that it could be because at some point I just call, I call the ball, right? Like I'm like, I got to move on

from here. But I think for me, look at, and this is why it's such a tough one because I don't think anybody would ever look at my code and say it's bad. I think for me, a good developer is somebody that I follow along and I understand why they did things, right? Like it's, it may not be the absolute best pattern, but it might be because we don't know the situation that person was in. But when I see obviously bad patterns, I'm like, that's what it's almost like an anti-good programmer to me. Like, I don't think I ever look at anybody and say, I think that's a good programmer. I look some and i say wow that person really needs to improve or i just don't have a thought right like i just assume everybody's always striving to be better and so so that's i kind of opposite is what you're it is you can more easily point out the bad programmer

yes but the good programmer you're like i just assume you're all good until i see something like whoa you're awful and and typically it's not even for me it's not going to be one thing right like it's going to be you just see this pattern evolve over time where just bad decisions are made right like i mean dude when i first met joey like he would give me these these five page you know dissertations on this is why this exists like this. And it was because he was sort of ashamed of what he was presenting to me. But I also understood the reason why that was happening. And so that's why I say saying somebody's a good programmer, I think it's just you almost see it in the way that they approach the problems.

Because you can almost find your way through the code that way. And I guess that's my take on it. Yeah, I don't know where I read this quote at, but just kind of piggybacking on the notion of a bad developer, I think it said something along the lines of, there's no such thing as a bad developer. It's more so reasonable developers in a bad situation. Yes, yes. You know what I mean? But I've seen bad developers. I'm not going to sugarcoat it but i've seen bad developers i'm not i'm not gonna sugarcoat it

i've seen some well you know i was thinking like there's been plenty of times when i've gone through code base and i can say like look at that crappy code i can say this is bad code but there's not a lot of times i've seen something said oh hey that's good code and a lot of times i tend to think of good coders versus good code and maybe that's because i'm only seeing things kind of with the magnifying glass you know got my nose down in it. But I definitely think of people as being good programmers. It makes me kind of think of like,

you know, what I personally think of as being a good programmer. It probably has to do with kind of a mix of what you guys all said, but also like Alan's really said, like a focused on kind of pragmatism and what they did kind of in a bad situation, right?

Or like Will's quote too. So I recognize that there's those trade-offs and so I can understand when someone consistently makes good decisions and is able to move the ball forward even in bad situations yep so uh there's this uh study have you guys ever heard of the the notion of the 10x developer i had not all right so this is a real hot hot topic um there's a lot of articles about there about the myth of the 10x developer and also about the myth of the myth of the 10x developer and there's some really good arguments on both sides but i thought this is interesting because this is kind of a highly tatted term for talking about

what it means to be good and how you kind of can compare programmers and it comes from a really flawed study that was actually done in get this 1968 50 years ago programming was a little bit different back then but the study was old it was done on 12 different programmers not very many they all had similar levels of experience but only 12 and they did a couple tests over the course of like two afternoons so not not a great test not a great sample size and you got to kind of wonder like what kind of programming questions are you really getting answered in two hours here you know maybe four inches there like that's not the kind of things that i think about when i think about tough code you know i talked about people making consistently good decisions and dealing with bad

situations and it kind of sounds to me like they kind of give them a couple like toy or interview questions timed them and said oh my gosh you're 10 times or 20 times better than the worst person. Now, I will say, though, that I actually wrote a ended up writing an article about this because I looked into why it was so controversial, because to me, like reading that, I was like, oh, man, this is obviously flawed. This is a terrible study. We shouldn't talk about it like this. But what I found is like there actually have been similar studies done on better sample sizes over the years with more modern languages and it kind of substantiated the claim that like you know what it's not crazy for people to be in order of magnitude better than programmers at certain measurable things and we could think about like

basketball like is it totally crazy to say that the best player in the NBA today is 10 times better than the worst NBA player? Yeah. I tell you what, I definitely can't pronounce his name. No, I mean, going back to your example of Kobe Bryant, right? I mean, let's pick him apart a little bit from a perspective of an NBA player, because I think what Joe just said was extremely important. A certain aspect of a programmer or a particular focus of a programmer could be. Kobe Bryant is definitely 10 times better score than the worst player in the NBA, right? There's no question. The dude dropped 81 points in a game. That doesn't happen, right? Dennis Rodman hardly ever scored five points in a game.

So if you just took 10 X by there, you know, he's already beating him. I think. Yeah. And that's what they did. They looked at individual tasks and said, this person is 10 times better scorer than this person. This person is 10 times better, you know, rebounder than this other person. Right. And that's where I think that there definitely are going to be people that excel at things, right? Like there are some people that are really good at algorithms, right? Like they have a math type background. And then there's some people that are really good at fitting the puzzle pieces together.

This whole series that we just went over with clean architecture, right? That's another aspect of it that maybe not the math driven person's going to look at and care about, right? So I definitely think that there is room to say that somebody's 10 times better than another at a particular focus, right? Yeah, that's definitely one of those flame wars. Like one quote actually from one of my homies named Brian Lyles said, is he like to think of a 10 X developer as somebody who can make five other developers twice as productive, right? Like somebody who can like amplify their ability amongst the team and make the team level up as opposed to being a rockstar.

Like I forget the dude's name from the Phoenix project with that guy. Yeah. I'm really interested in that topic of like that notion of a force magnifier. And I think like one of the things we talked about recently on the, the productivity and tech, like kind of the manager talk we had was like as a manager like you have the ability to magnify other people's outputs like much greater than any one individual person like if you've got to say a manager of 10 people like theoretically if they can remove the blockers if they can facilitate that communication make things go like you can potentially have a lot more of a valuable outcome than you can as one individual contributor.

At least that's what I think. Man, I'm doing it wrong. And there's also the flip side of being like a quote unquote 10x developer, right? Like if you always, like that amount of pressure all the time being on you, right, it could lead to burnout. It could lead to all kinds of unhealthy things, right? Like a disproportionate amount of knowledge silo happening in the organization, like, which is not scalable. So like if you get hit by a bus tomorrow, you win the lotto,

like what's going to happen? How are they going to continue without you? Like, it's just kind of all bad if you kind of get into superhero mode. But there's also a flip side to it. I mean, Outlaw shared with me years ago, like probably not too long after I met him, like they had done a code competition, I think when you were younger and there was some dude that beat you, but you were pretty sure that your code was better and

all this kind of stuff, but he got a little bit further along. And so, so then this whole question of a 10 X does, does the code quality matter or does it just mean output? Right? Because if you can write an application 10 times faster than I can, but then nobody can maintain it after you, have you really created 10x what somebody else would do? There's fast, and then there's maintainable is basically what you're going after. Well, not just that. I mean, there's other aspects. I'm just saying that you can't measure. It's hard to measure those things.

There's not typically quantitative analysis of that type of stuff. You could probably say that you could take static code analysis after the fact and put grades on it, but there's still going to be how modular is your code or does it scale well? Like there's going to be people who are really good at scaling. There's going to be people that are good at the algorithms. There's going to be people that are good at actually writing good patterns. Like how do you measure some of that stuff? Some people write ugly code but it gets the job done and they write it really fast. There's value in those type of people

by the way. Going back to the minimal viable product, right? Yep. Go ahead, Joe. Let's keep it joking. There's all sorts of stuff. There's meetings, there's JIRA, there's communication, there's setting proper expectations, there's estimates. There's a lot of things that are, I mean, estimates, you can quantify pretty easily your accuracy there.

There's a lot of things that are just really tough to measure. But I don't think that's an excuse, especially after reading these books. I don't think that's an excuse for just saying, well, we can't do it. Because there are other people in other fields doing just that like whoever kobe bryant's coach is like he's not focused on maximizing kobe bryant's stats or any individual player stats right they're focused on winning the the super bowl or whatever i knew you were gonna just you know continuing the whole kobe bryant analogy like one thing too that anybody if you've like done any research into Kobe,

like anybody who knows Kobe will tell you he's one of the hardest working people ever in the league. Like would show up and be shooting shots hours before the game, right? Like it kind of goes back to the whole notion that we're talking about deliberate practice. Like when Kobe was in the league, there was probably nobody outworking Kobe. And they show it every night, right? He practiced like he played. And you can't argue with the results. Pretty much every famous player, continuing along with the NBA analogy, has been like that. I mean,

Jordan was another one where from the time that he first got interested in basketball as a kid, he would spend every moment practicing that he could. I mean, it's everything, right? It's everything in life. If you take the best person from the NFL, if you stick them with sports, right? Jerry Rice, same thing. If you go with Tesla, this dude eat, lives, and breathes trying to change the way the world works, right? Like everybody that ends up becoming the best at what they do is somebody that's almost to a certain degree obsessed with what they do, right? I mean, I know we all do it. We all look at our code and we're like, oh man, I could have made that better. Or, or I mean, that's the reason we do the podcast.

It's the reason why like, well, you read books all the time, right? You listen to podcasts. It's the reason we do practice stuff. It's because nothing's ever good enough to a certain degree, which is, it's a good and a bad thing, but I think it transcends sports. It transcends everything. There are just people that always want to achieve the very best that they can possibly do. And that is how you get to a 10 X, I think. Yeah.

And I think there's a lot of value. Even if you never make it to 10x like i wouldn't mind being five six seven times more productive than i am right now if that's theoretically possible so maybe there's some things i could kind of get from looking at some of this research and some of these articles and books that i could kind of apply to software engineering to get me at least part of the way there and if even if i don't want to commit fully maybe i could take some of this away and improve my life. And one thing I kind of noticed in looking at some of the books, particularly Peak, which we'll have links and Outliers, is they separate knowledge from skill.

So what they said is basically that knowledge is what you know. And when I say know, I mean, like you understand, you grok. It's not enough to like be able to recite the definition of like,, say solid, right? You need to understand it at a deep level. But there's still a difference between that understanding and being able to apply that knowledge. And I think basketball or sports is a great analogy too, because, you know, you can have a coach or a, you know, a mentor or a peer who really understands like the way the bones and the muscles and the nutrition and you know they can grok all that stuff but they're not going to be able to hit that percentage of field goals or you know do whatever kind of skill level type thing that there is involved and so they draw a line

between those two and what i kind of thought was funny when i was doing this research is like i can tell you all that i can list a long list of things, resources online for improving your knowledge. Things like Pluralsight, CodeSchool, books. Just Google your favorite language and getting started and you're going to find 20 different articles going for that angle. So I feel like we're pretty well covered on the knowledge, but we don't really talk about how to advance skills so much in programming. You guys agree with that? I do. I think some of the more kind of recent sites, like things like code school that kind of like try to intersperse some

actual programming in between, or sometimes they actually have some, it's like a mentor, like our buddy Jason Wyman over at Unity 3D college. He does like an intensive six week kind of almost like a bootcamp, but he actually is there and is able to provide code reviews and whatnot in between those lessons and actually work with the people. And so I feel like our industry is kind of getting there by looking at some of the ways that other industries have handled this. And so I'm excited about that. And I want more of it.

And we can see more, you know, some more hot topics like, you know, interview questions we kind of alluded to already, where like the job might where the job might ask you how to balance a binary tree and then you get into work and you're changing the colors of divs. You're describing something different than just practicing on your own though, right? Yep. I kind of divide it into two parts. I say there are things that you can absolutely do on your own. I call those the x for y's it's basically do a thing for x minutes at such and such skill level and then measure your output and so that works great for things like code wars or code fights or practice

problems um if you want to get like a list of like you know college um like what you call it um discrete you know prove proving things by induction, like get a bunch of problems, do as many as you can at a certain skill level, time it, see how it goes, do the same thing, you know, tomorrow, same thing after that, same thing after that. Those are really easy to do on your own

because you can assess them without any sort of bias. But for those things that are not so easy to measure like communication or, you know, how effective you can be working in a team. Things like that, I really think that you need some sort of either peer or mentor or some other person to work with. And I actually think there's some really good ways to get that because even though it's hard and it's not nearly as easy as being able to kind of sit down, tap, tap, do it

on your own, thanks to the internet, it's never been easier to get this kind of help for any field. Yeah. And the reason why I asked that though, like, you know, the mentoring kind of like coaching scenario part of it, right. Is that it almost feels like there's maybe a little bit of backlash happening in the developer community, right. Where like for so long, and it's felt like hey man if you don't um if you don't put in your 60 hours at work and you're not you know you don't have your own apps in the app store that you're writing and you're not contributing to all these open source projects and you don't have a blog that you're writing like then you're doing it

wrong right but you know lately, it seems like, and maybe they were more than just lately, and I'm just only now recognizing them, but, you know, more questions and articles about like, hey, in my spare time, I don't write code. Does that make me a bad developer? Right, like there's several articles like that, right? So it almost feels like there's backlash

in that among developers about like, Hey, I wanted to do something besides just sit behind a keyboard all day. Yep, absolutely. So how do you balance that? I've got some ideas. I actually think that because it can be kind of hard to find like mentors or coaches. I think that the best way to do something like this is basically through some sort of work organization where like you do some sort of like pair programming or you work with like a high output developer. If, you know, some sort of coach or we'll say manager in this case can kind of pair up good combinations of peoples, then there's actually a lot of really good tips for how to work in situations one on one to get a lot out of a little bit of time. Will, you have thoughts? Yeah, I was going to say one thing too. Like a lot of the people that I admire in, you know, our developer ecosystem, you know,

do take breaks from being rock stars during the day, right? Like they hike or bike, you know what I mean? Like they don't just always, you know, slam fingers to keys all the time. So like, I think it's important to have that balance. I mean, and some of the times, like the things that you see blow up like Docker, right? Who knows how many years they spent writing that before it was a big thing.

It wasn't like it didn't happen overnight. So I think sometimes like without that context, you don't really see the full picture of what went into what we see at the end of the day. Yeah, there's absolutely no obligation to kind of do this sort of stuff like day and night. You know, I don't think you have to be Michael Jordan. If you want to be better, I think it's okay to put in some time and make yourself 5%, 10% better. And I think that's really good if that's what you want to do. And you don't have to want to do it. And actually, one thing I kind of focused on is like I kind of looked at it as like, well, what advice do we have for advancing skills?

And what I kept kind of seeing from people is like, hey, do a side project as a way of kind of learning to program. They would tell a lot of university students, like that's kind of the kind of standard advice. It's like, go do a side project. It's great on the resume and it gets you some real world experience. So you sound like that with your air quotes there that you don't necessarily believe in that. I believe that side branches are great for a lot of reasons, but I don't think they're after doing this reading.

I don't think they're a great way of advancing skills. So if I want to be a better JavaScript programmer, then I don't think that a side project is the best way to do that. What is? I want to kind of catch it because I think that a lot of times your goal may not truly be to be a better JavaScript developer. Better is good, too. You could be a butter programmer. You could also pick and pick

a people perfect and all that. That's pretty good. Oh, man, you're good. You're good. But, yeah, so. Because, correct me if I'm wrong. I think we've all told people pick up a side project or go contribute to some GitHub project out there so that you can see how other people are collaborating and creating code and those patterns. So it sounds like you're saying that there might be a better way to build skill.

So to be clear, when we're talking about doing a side project, it's to get practice in the entire thing, right? Like, like you don't say do a side project to just learn JavaScript because that's not what you're going to be doing, right? You're going to be learning how to build an application. You're going to be learning how the files fit together on the file system. You're going to be learning how to commit it to source control. Like it's more of the entire ecosystem, like the beginning A to Z type stuff, right? So what you're suggesting then is if you're trying to build a particular skill, in this case, JavaScript, then creating a side project may not be the right way to go, right? Exactly. That's exactly what I'm getting at. And I kind of think

of side projects as being like akin to a scrimmage you can think about like a soccer game right like a soccer practice where we got all the the soccer players together 22 people on a field you throw down one ball in the middle and say go play soccer that's a great way to build teamwork that's a great way to get used to playing in games and it's probably going to help you win but it's not an effective way seven years old because then all the kids just rushed to the ball, wherever the ball goes, all, all, it's like both teams.

They're just all moving wherever the ball's going. Right. Even the goalies, even the goalies. So in a, in a, whatever, like a two hour soccer game,

I think I ended up seeing that your average player would end up touching the ball 20 times. Right. And then of course of the entire two-hour game now practice right that's another story for one there's gonna be a lot more balls right it's uh i think the ratio i saw for just the study i was looking at was um four person per ball so if you're interested in working on your ball handling skills your passing ability your ability to block goals is another good one then a scrimmage is not it.

Like think about how many goals are attempted in a soccer scrimmage. It could potentially be very few. So your goalie, even though they're in a critical area of the game, they could actually be getting very little practice over that two-hour game because, you know, maybe the defense is doing a great job. I think about a kicker on a football game, right? They may only be in the entire game for three minutes, but those three minutes could win the game. Okay. But let's, let's think about this

though, because going with the sports analogy, I mean, you have a very targeted, very specific kind of thing that you're like, uh, you know, going with your, your kicker example, like, okay, I need to work on my field goal, goal, long field goal attempts. So I'm going to keep moving the ball back and further and further and you try to extend that distance, right? And my accuracy. But when you're talking about developing, like, what are you going to do? Like, I need to practice my array declarations. I need to make sure that when I make an array, oh, it's spot on. Awesome. Right? Like it's different. Well, I think that is,

and I'm curious where this is going to go, because I think that is really the bigger problem is, is if we're talking about sports, it's very easy to say a goalie's job is to block shots coming into this goal, right? Like you have one very specific task that you need to get good at. And yeah, there's different approaches, right? Some balls are going to come up in the air. Some are going to come down on the ground. Some are going to be spinning. Some are going to be moving, but you have one task. If you're trying to learn JavaScript now, are you trying to learn about memory management? Are you trying to learn about performance? Are you trying to learn about asynchronous? Like, I guess that's the thing is where do you call exactly? Like, do you have to say the skill that I'm trying to learn right now is asynchronous

JavaScript and anything else I need to put completely to the side, right? Or, or like you said, I need to learn about the fastest way to access data in JavaScript. So I need to learn everything about the different data structures in JavaScript. Like, is that what you're saying? And, and then my next question is, how do you know that that's what you need to know how do you know what you don't know that you need to know and that's always to me the hardest part yeah and the one thing i was going to say too like in keeping with the sports analogy is one thing that you could have to be wary of you know as a former athlete you have these people who are like practice all-stars right like you look like you

look like the man is no as long as nobody's guarding you, right? You can hit all the open threes. What are you going to do when somebody's in your face? Like, what are you going to do when the lights actually come on, right? And I think that one thing that we got to do, like, as practitioners

is more so not trying to, like, practice to be a specialist, right? Like, if I was the goalie, all you got to do is kick balls at me and all you got to do is block them all day. But really, we're more like Coach Belichick, right? Like, I got to be a student. I got to, like, watch film. And also, sometimes I got to get is block them all day. But really, we're more like Coach Belichick, right? Like, I got to be a student. I got to, like, watch film.

And also, sometimes I got to get down and put my hand in the dirt and, like, show you how to do things. Like, it's multiple facets to make you more well-rounded, not just practicing one thing at a time. But hold up. Let's take this to a different analogy then because this is going to be the show where we talk about things that we never talk about, apparently, because we're talking about sports ball a lot here and that never happens, right? Sports ball. Yeah. But let's take it to a military approach. When you go and you enlist in the army, the Marines, the air force, whatever, you practice things over and over and over and over again, because when the time comes that that needs to happen, it automatically kicks in. Like you don't think about it. Right.

And so, and this is where, so what you said about, you know, the lights come on, things change, practicing that skill over and over allows you to more easily go into auto mode as opposed to, you know, don't get me wrong. There's some people who are just going to excel. Michael Jordan, right? We talked about him. That dude excelled at just destroying people at the end of a game. That's not something you can learn. You either have that or you don't in you. To a certain degree, I know you're making a face over there, but there are just some people that don't like, for instance, there are tons of people out there that all go to college. Some people excel at taking tests. Other people get crushed under the pressure. They know the information, but they get sat down, they have a timer, and they're like,

they stress out, right? And so that's where I think it's important. I think what you're saying about the skills is very important. You have to test those. You have to use them. You have to practice them constantly so that those become second nature, so that you can focus on the bigger picture when it's time to work on it. I think anyways. Well, that's a great way of putting it. I think of it as like a higher level abstraction to kind of bring it back into coding terms. Like when you're first learning how to do something, you think at a very explicit procedural level, right? When you think about like, say, you know, playing, playing guitar, right? You don't think like G, C, A minor, D, you think like middle finger goes here and index finger here. Keep it pointed up a little bit. Keep my

wrist straight. You know, it's, it's very explicit and procedural, right? That's how you think. And you practice that thing a thousand times and it gets to the point where you think like, oh, play that, play that song I like, right? And so your brain has created like a shortcut. It's created a label and is able to generate the output that you need. And so you're now dealing at a higher expressive level. And it's like working in a higher level of abstraction or a high level language. You've moved that explicit procedural to now be implicit and declarative. You just say what you want and it happens.

And so that's what I'm kind of saying is like if we can if we can get this stuff down like let's say like i want to be a better javascript programmer because i want to be able to think about my business problem or i want to be able to knock out a bunch of code without refreshing and checking stuff in the console every three times because it's a distraction then i can focus on just that one thing to enable me to do other stuff but you obviously, you don't want to overtrain one specific thing. It's not going to help you to kind of be on the sidelines doing that high kicking stuff that football players do. You don't want to do that for all of your practices, right?

You want to have some sort of balance. So you do want those scrimmages in there because they're important. But you also want to be kicking those field goals. You want to be doing weightlifting and other kinds of muscle training as well. So that when the lights come on, you've already built this language so you can think at a higher level and accomplish things. That makes sense to me. And the danger with side projects is that you can potentially have a lot of stuff going on. So, I know I have a bad habit of doing this with side projects.

I just started one two weekends ago where I got Elastisearch, which I'm not too familiar with. I got Kibana in there for doing some visualizations. I'm doing it in.NET Core, right? So I'm not real familiar with that. I'm doing it all in Docker, which I'm also not familiar with. So I got like five different things. And what ends up happening is I start taking shortcuts because I only got two hours before I got to go do something, right?

So I want to get something on screen. So there's this incentive there for me to focus on the side project and the result. And what can happen here is other things start slipping, like unit test starts slipping, good abstractions, my clean architecture starts slipping because I just want to get Docker working. I want to get something on the screen before I have to be done for the night. And when that happens, I'm cod the night. But when it happens,

I'm codifying them, but that's okay. I'm reinforcing those bad ideas. It's okay. Depending on my goals. Right. That's what I was going to say. Did you have an implicit or an explicit?

I should say, did you have an explicit defined goal? Because maybe your goal is, Hey, I want to see how all this stuff works together. And if that's what it is, then you've accomplished something regardless of how poorly you did it. absolutely so i i think it sounds like what you're getting at is what outlaw just said is maybe this is not a bad thing it just really depends on what you set out

to do yeah i mean you know how to unit test so you know okay fine if you skipped on that but you were like picking up a new skill like uh using cabanaana and Docker and things like that, and how to make those work to your advantage and their strengths, their weaknesses, that's a great skill. Right? Yes, but I'm also mixing knowledge in there at the same time. So what could end up happening is even though I may be trying to focus mostly on, say,.NET Core, I'm getting tangled up, I'm not doing it properly, and even though I know, I could say that I've got the knowledge of the unit tests, like we know that's a skill. We know that if you aren't unit testing upfront,

it gets real hard to add that in later. Even if you have been a longtime unit test practitioner, right? Okay, but okay. Okay, let's take a step back there. Because that depends on what your goal is for this side project to that. Like, when you were talking about this at the beginning, I was thinking back to a lot of times where, you know, I'll pick up the JavaScript framework du jour. And, you know, there's this one particular type of app that I just kind of like uses my my guinea pig framework, you know, it's kind of like kind of like think of the to do MVC app, right? Where, you know, you're just rewriting the same thing in every framework just to because you're not trying to focus on the functionality of the project. You're trying to focus on like, hey, how does this framework work? What what are its advantages?

Right. And so if your goal is to learn those other things, then, yeah, great. You know, who cares if you skipped out on the unit test? Because that's not what you're trying to gain. Right? Yep. I think we need to be careful with that. Because sometimes you can let those other things slip. And when you let them slip, then you end up codifying or building them into muscle memory. So if you start like skimping on your bad variable names and bad abstractions, like those things can tend to slip when you're in, you know, at the beginning, when you're in, you know, at the beginning,

when you're in the flow working, like those bad habits can kind of seep back in. Well, one thing that we do in practice, like, because I do TDD pretty much all day, every day is what we call pretty much what you call a spike, right?

It's like, Hey, we're just going to throw some stuff together, exploratory, try to figure something out. But when we're done, we're going to scrap everything that we have and take back with us the knowledge of what we learned and then do things right.

Right? Right test first, do all the things, right? And that way you kind of get best of both worlds. You fast track to figuring out the thing and then you go back and do it with good practice. So that's interesting. So Will does pair programming. And what's really interesting about that is that I always wondered, right? Do you just start with the unit test and no matter how crappy your code gets as you go, you're just going to live with it. But

I like hearing that, that you guys do that. There is the ability to just go figure something out, take notes of what, what worked and then throw it all away and do it clean. Like that's, that's interesting. Um, I know that was an aside to what you were talking about, Joe. I'm, I'm sort of more on outlaw side with this. Like I, I love the idea that you practice certain skills, right? Like, uh, we've talked about interviews before, right? Like if you're going to go interview with Amazon or Google or something like that, you better pick up, you know, cracking the coding interview and you better practice and you better learn algorithms and you better learn data structures because I guarantee you're going to get hammered on it, right? So with that in mind, you start with a goal. You know that you need to know your data structures. You know that you need to know certain algorithms. You know that you need to think about

things in a mathematical way when approached with a problem, right? So that makes sense to me. I think what it all boils down to is how well defined is your goal, right? If you're wanting to play with Elasticsearch, and by the way, you haven't had a chance to really look at Docker, but this is a perfect time to be able to get it sprinkled in. Like, I don't see that as a bad thing, you know? It just really depends on what your focus is. Well, I mean, we have talked about this though. And, um, in past episodes where I think even jokingly referring back to some of the projects that your side projects you've done, Alan, where you can sprinkle in too many unknown technologies and then you fall into rabbit holes down one or more of those. So I do think it's wise and important to limit those new kind of technologies until you feel like you really have a grasp on it before you start introducing other ones. Because to avoid those kind of pitfalls, right?

I don't know what you're talking about. Well, I know in my example here with the Docker, one thing I noticed is because I kind of did it from ground up with the focus on the side project, I've got a couple of containers now that I'm able to talk to. I've got three containers and they're all talking. They're all on the same network. It's awesome. But I know that there's this like Docker composed thing that I should have used to kind of put this together. But I kind of, you know, squeeze this stuff together based on a couple of Stack Overflow answers.

Right. So I'm not really doing things in a great way. And so if I were to say, like, hey, guys at work, here's my new project or whatever, like, there's a good chance I'm going to kind of bring those not so great learnings in and do it wrong. Whereas if I had started with a Docker course or a Docker book, then I probably would have done things in a lot easier way. See, I disagree. I think that's fine, though. It sounds like you're setting like too high an expectation on it,

though. I feel like it's setting too high an expectation on it, though. I feel like it's okay to iterate on the learning process. Yeah, I mean, so I'll give a perfect example of something that you just said that I went through the same exact thing with Elasticsearch, because you'll look at it and you'll find, oh, there's this Docker image out there with Elastic. Cool, let me add it. Oh, well, I need it to be able to talk to this. Well, let me add that.

Well, how do I make these things talk? Well, they're not on the same network per se, unless I force them all on the same IP. Well, this doesn't make sense. Well, how do people do it? Well, there's this thing called Docker Compose. So it's like a natural progression, right? And then, and then by the way, you're going to go figure out Docker Compose, and then you're going to find out, wait, this is not what the industry does. They use Kubernetes. And so then you're going to go from Docker Compose to Kubernetes. And then at some point they're going to be like, well, maybe Kubernetes isn't what we should do. We should do Docker Swarm. Not saying that's the path, but what I'm saying is I don't feel like the path that you took is wrong for what you tried to do,

right? Like maybe you do introduce those things and maybe they aren't perfect, but guess what? It was a step in the right direction. I think we've all talked about the fact that programming and even learning should be an iterative approach, right? You're not going to get that knowledge and those skills without first taking some stumbles along the way, at least in my opinion. But what if you stumble and you never get up? Like you stumble, you do things the wrong way and you never get back to that have you ever done that now get back to the side project now that's different that's that's almost not fair but that's also why community is important too right like whenever you're learning you try well i guess i guess if you're kind of like the stereotypical developer you might be doing that in your own silo but having like a network of people like the slack

channels right or twitter to bounce things off of like hey network of people like the Slack channels, right. Or Twitter to bounce things off of like, Hey, I'm stuck, like infinitely stuck. Can you help me out? Like, that's why that stuff's important where you'd like fall down to that degree. Yeah, absolutely. Co-workers are another, another great case of that. So I think that's really important. Like that's like kind of like all those soft skills or anything that's, you can't easily quantify. I think you got to bring other people in, which I mean, I've got like an introvert. I'm literally a card-carrying introvert.

This is like an introvert pen right here, a little turtle. It's not if you want it to be. What you're saying, though, is I don't know that I actually agree with the whole mixing incentives can encourage bad habits. Okay. Maybe it's true, but I don't, I feel like not doing that kind of keeps your boundaries too far in, right? Like, I feel like you don't get to expand your boundaries if you're not willing to take some of those, those mistakes and those leaps just to find out, Hey, what, what does this do? Or again, I think it really depends on what your goal was at the outset.

If your goal was, I need to learn.NET Core, then you should trash everything else, not have a Docker container. You shouldn't be doing anything except working in Visual Studio or Visual Studio Code and trying to hammer out some.NET Core stuff, right? Yeah, so yeah, I think you're totally spot on.

Like definitely, side projects are good, and it's just a matter of what you want. But I think you've got to be really careful about making sure you understand what your true goals are and actually working towards those. It's like if you're doing a.NET Core project to learn.NET Core, and you spend a half hour of your two hours

messing with CSS, then either you cared about CSS more than you thought, or you're not training effectively okay so i think that's the real takeaway here as when we talk about being careful with your side projects is to set realistic expectations of what you want to get out of that side project and hold yourself to it right don't be careful with codifying bad practices because have you ever have you ever cussed in front of your grandma probably yeah like me once once just once you should like the taste out of your mouth afterwards or it's because i

built up some bad habits right and something happened i slipped and my bad habit made it out somewhere i didn't think it was going to that's true man i'm just having a hard time like i i know where you're going with this bad habit i know but'm just having a hard time like i i know where you're going with this bad habit but i'm having a hard time applying that to code though because man like god some of the best stuff you learn happens because you went outside your intended zone right like you stumble across something that sounds like knowledge to me you're talking about learning things like new concepts new paradigms new ways of doing things like that's kind of knowledge to the house i'm talking about the things where like i need to get something done i want to be able to type type type and solve my problem and be finished but i'm talking about the

skill side of the house right now i mean let's be real though right how many times have prototypes made it to production right like something that's pulling you away alan you got some experience with this every time and if you're not disciplining away alan you got some experience with this every time and if you're not disciplining those prototypes you got sometimes garbage code out there supporting real life production but that's prototypes though i i feel like that's different than a side project though if we're talking about a prototype like when i think of side projects that's like something in my spare time i want to learn uh you know or maybe maybe a skill you want to practice like uh search search you know you want to write a you know or maybe maybe a skill you want to practice like uh search search

you know you want to write a binary tree or a linked list or something like that just you know to dust some of the cobwebs off your head right and make sure you can do it right like am i going to take the time to like make sure i have proper unit tests and abstractions away just for something like that like a prototype no probably not now if you're asking me to prototype an application that might query a third-party system to retrieve data from it that might fit the form of an existing application, maybe that one would be structured different. I could see that happening. Might be some relevant experience in-house there might be

i mean so to your point yes sometimes prototypes made to production actually i'd say 75 75 percent of the time it happens but i will also to a certain degree argue for the business and say does this thing do what it needs to do if If the thing is valuable enough and it warrants revisiting at some point in the future, there's nothing that says you can't iterate to make the thing better. Right? So again, I mean, I know that we've just beat this thing into the ground at this point. And I think the part is, is we're all torn on it, right? Because I think that we all have gotten to where we are in our careers, which by the way, all of us are very good developers, or we at least see each other as very good developers. We've all gotten here because we explore and we're curious.

And it's almost like, why do we get called for support from our family on their computers, right? It's not because we're not computer support people but we are those people that curious enough then when something happened to us we learned everything about it and then when somebody calls us we're like oh yeah you just need to go do that right and so that's kind of where i'm going with with that thing so point taken careful yeah bad habits are very real yeah they are you can see evidence of it like if you like you know any sort of little something that you do, it tends to get kind of built in because your brain is super lazy. It loves shortcuts. It loves stereotypes.

It's biases. And a lot of those can be good for some things, right? It lets you take shortcuts on thinking. It lets you think at that higher level. But if you get some bad stereotypes or bad biases or bad habits kind of built in, then you can start making bad mistakes without even realizing that you're making decisions because they're not conscious decisions. They're not deliberate. They're the things that just kind of fly out of your fingers

when you're thinking about the business problem. And that's why I think we just need to be careful. I think I would, gentlemen. You kind of got to practice how you play, right? Or at least try to for the most part. I'm somewhat there. I feel like Joe should have had his laser pointer so that he could have just flashed it in our eyes

and been like, shut up, i know i'm from learning guitar you know like a lot of times they would tell you like kind of learn something slow learn it right and then you speed it up but that first time it was always like learn it slow learn it right they don't say like you know play a double time and then eventually when you go to play it you know half speed it'll be fine like they always they emphasize getting it right first because once you speed up, like those habits that you've built up doing it slow are what's going to come out because your brain doesn't think like one, three, four, next string. What it thinks like a minor scale, the rest is generated.

So there's a couple of really good books on blink and a power of habit in particular. Cool. And a, uh, you know and power of habit in particular. Cool. And a, you know, power of habit, like the whole book was really about how to break bad habits and how to replace them with good habits. And they actually, they kind of boiled down to one simple thing. They basically said, there's like the cue, there's the action and there's the reward. So if you want to replace that bad habit, you have to recognize the cue. So if you have a bad habit of like say um you know running crappy code you got to recognize the cue might be you're under a deadline or you know you don't have a you know

all the requirements up ahead of time and so you want to recognize whatever that trigger is that's kind of getting you to do this bad thing in this situation you want to try and replace that with the desired activity and then hey treat yourself cool there's a whole book about it but there you go 30 seconds i don't know why the like algorithm nerd in me was like thinking q u e u right yeah yeah it's like oh he means like pool q yep so hey um thank you for all the reviews this time. We got a ton of them. We really appreciate it. It really helps us out a lot.

And we really thank you for it. And if you want to leave us a review, you can go to codingblocks.net slash review and you'll find a bunch of links. You don't have to install iTunes. There's lots of other ways to do it, like Podchaser or Stitcher. And we really appreciate it. So, thank you so much. Hey, and while you're there, you know we've talked about um earlier there was a conversation about stickers that came up and uh you know if you check it out or like if you're watching the

video here you can see some new designs that we've made up and if you go to www.codingblocks.net swag you can send us a self-addressed stamped envelope, and we can send some stickers your way, including the lovely new layout. You're going to Vanna White this thing. Yeah, right. I don't think I'm quite as pretty, but you know. Now, Alan, don't talk bad about yourself. I know. That's just wrong.

All right. So let's head into my favorite portion of the show. Survey says. All right. In a last episode survey, we asked, do you pay attention to third-party licenses? Your choices were, yes, because my company forces me to. Yes, because it's a good habit. No, wait, you actually read those things and lastly no wait

am i supposed to all right so we're gonna let our guest go first all right uh price is right rules you know yeah yeah all right let me take yes because my company forces me to with 57%. No way, man. 57%. You are crazy. You haven't listened to the show enough. No, Alan, don't be rude. This is getting into a foot race, isn't it?

I'll win that just so you know. Wait, wait, wait. Here we go. So what you got, Joe? What do you think this one is? I think no way am I supposed to with 30%. And I'm wagering that most people are doing web development nowadays and they don't really think about it too much because they're not distributing.

Yeah. And I, you know what, I'm trying to remember back. We had some sort of episode where we asked how big the company was that people work for. The smaller the company, the less they think about this stuff. I honestly believe. So I'm going to say no weight. You actually read those things. And I'm going to go with 35%.

35%. Alan says you actually read those things. 35%. Joe says I'm supposed to with 30%. And Will goes with, because my company forces me to, with 57%. Do I have those numbers right? Those are correct. That's correct.

Ding, ding, ding. We got a winner. It's me. Winner, winner, chicken dinner. Alan takes it home you actually read those things 38% of the vote

that's scary that's really scary we did an episode on this I don't remember what it was 3 I don't know it's definitely not 3 don't not three yeah don't listen to three i mean no wait you can listen to three we won't rehash it here but if you don't pay

attention to them you probably should i mean just look if you work for a small company and you're writing code and you're just pulling in libraries willy-nilly at some point somebody else could own your code yeah you could be getting your company into some serious uh legal trouble if you're just pulling in libraries willy-nilly, at some point somebody else could own your code. Yeah, you could be getting your company into some serious legal trouble if you're not paying attention to it. Yeah, it's real. And no license is not okay. No, put a license in there.

If there is a library that you're using or some sort of third-party utility that you're bringing in and they have multiple licenses, choose the one that you want to use with your product. And if you use anything like GNU, take a hard look because a lot of times that means you have to open source your code. So yeah, there's a lot of nuances there, and that scares me a little bit. What was the second answer?

Probably Joe's. No, am I supposed to? Yeah, no. Everyone missed it. Yes, because it's a good habit. Really? Yeah. Alright. 28% of the vote. That's surprising. Yeah. That really is surprising. So, more than 50% were split. Those were the largest percentages of the vote, right? And they're split. Literally in half between yes and no. Yes, because it's a good habit. Not because I have to, but just because it's a good habit.

And no, and it's a bad habit because I'm supposed to. Wow. So it's a good thing that we're talking about habits here. Right? Get in the habit of looking at the license. As a matter of fact, like I know you do. I do, Joe. You probably do.

I'm assuming, Will will you probably do too like if i'm looking up something that i'm going to use the very first thing i do is search the page for license and if it doesn't come up then i go to the code and say where is the license file and if it's not there i'm like yeah i don't really think i can use it or i'll contact the author and be like yo dude can you add a license because we can't we can't use this better get pull request, dude. Yeah, right? No, that's a good point. That's a good idea.

Why not, right? I never even thought about that. Apache license. Here we go. That's my tip for the week. Right in the show as we go. All right. So for this episode survey, we ask, do you participate in open source projects?

And your choices are, yes, but only my own projects. Or yes, but only when I'm trying to beef up the resume. Or yes, but it's documentation, not code. Yes, but I only participate in projects owned by others. Or yes, I have some of my own projects and I also participate in projects owned by others. And lastly, man, I'd love to, but dang, who has the time?

This episode is sponsored by airbrake.io. When your website experiences an error, airbrake alerts you in real time and gives you all the details you need to fix that bug fast. I noticed that airbrake had an open source.NET library. So I dropped the example code from GitHub into one of my old.NET websites.

And the site worked great when it first launched, but I was pretty much done with it and I hadn't really touched it in years. And I knew that there were errors and I couldn't reproduce them. And I thought maybe Airbrake would be able to make it easier for me to see a pattern. And it did pretty much immediately. Once the exceptions were aggregated, it was really easy to see that there were only a few different types of exceptions and that they came in interesting waves. And what I kind of figured out was that somebody was actually automating and doing some repeat calculations using my web services directly. They were skipping the UI where

I was incorrectly doing some validation and they weren't the greatest speller. So there were a few little mistakes that I had not made that they were making when they were doing these thousands of repeat calls. So now I handle that problem better and traffic wasn't much of a burden. So everything's great and they might still be doing it now. Awesome. So right now, CodingBlocks listeners can try Airbrake free for 30 days, plus get 50% of their first three months on the startup plan. To get started, visit airbrake.io slash CodingBlocks. That's airbrake.io coding blocks all right so continuing on with our conversation here let's get into deliberate practice and what does that mean i kind of dogged on side projects a little bit even though i do still think they're really good but just not the most effective way to to practice skills so the question is what what is the most effective way? And what the

kind of the general consensus is right now is that deliberate practice is the best way to advance skills. And what they mean by that is basically just a results driven feedback loop that requires focused attention. And so like the example I gave in my talk was that playing your favorite song guitar is not deliberate practice but if you record yourself and you grade yourself on the various skills involved like say chord changes or your legato your staccato and then you you slice it up you measure it see how well you did and devise specific practices around those particular areas that's deliberate practice so another example is like karate kid wax on wax off he was practicing specific movements that were later incorporated into like the real the real thing but they weren't quantifying it which you're saying is the key

element right is actually measuring your your results after that after doing the practice i mean can you still get the value out of it without the measurement though that's a good question i think like the the idea behind measuring is to kind of make sure that you're you're doing it right and so if you can kind of get the sense that you're doing it well enough and that you're maintaining like kind of the correct form then i think it's okay i think same with kind of like weightlifting is a good example where like it's really easy to have bad form when you're say doing a squat or a deadlift but i think that once you kind of get that form down right i think it's you know you could probably get away with not having a spotter

there or doing that stuff on your own and so i do think that there's value to doing that and you know realistically this stuff's hard to do you know with other people so i think that's kind of our only option but what does measurement mean in this sense, though? Are we talking about like, you know, understanding the space time complexity of the problem that you just solved and trying to better that? Or are we talking about like, well, you know, I solved this problem, and I wrote these 10 unit tests, and it passes those, and that's good enough? Like, what does it mean? Yeah, a couple different things. So if you're doing an X for Y, I could say like, I'm going to do level four JavaScript programs

focusing on fundamentals and I'm going to do it for 20 minutes. I'm going to set a Pomodoro timer. I'm going to count how many I did correctly. You know, the first time, seven, second time, six, third time, nine. You know, I should be seeing

that stuff go up into the right. So the measurement there is my number of problems. Now, if it's something like a soft skill, it gets a little bit tougher. But what I could do is like do some sort of like little pet project send it over to my buddy will and say hey will i'm not going to ask you how my project is because that's a crappy question i'm going to say how's my architecture or how are my variable names

or am i getting my intent across um how are my dependencies managed you know is this how does this look i want to ask those kind of specific questions and i want them to grade me on those specific asks so that's another way of measuring things that are kind of harder to quantify an example i like here is um there are actually like a ton of like writer groups out there on the internet like like for people who want to get better at writing. And one interesting thing they'll do is a lot of times have like kind of tasks or quests for a week. So like one week might be, hey, write a hundred word action thriller story that doesn't use any weak words or doesn't use pronouns

or doesn't do something else. Or they'll have some sort of theme. They'll have some sort of theme. They'll have some sort of goal there with that writing. A bunch of people will submit it. They'll mix it all up. And basically everyone kind of cross, do some cross feedback where they focus on the one thing.

And of course, if you got some other feedback in there, you can slide that in. But the goal is really just to kind of focus the exercise and the measurement on that one thing. So it's not great to say, how's my project? You really want to focus on that one thing. So it's not great to say house of a project. You really want to focus on that one thing. I like that. And they've got a couple of rules for the, for the deliberate practice to say it's intentional,

which is saying that you know what your goal is. It's not just the right good code. It's going to be more focused than that. You want it to be improving appropriate. So something that you can actually get better at. Responsive. Now, this is what I really like. What they mean by responsive is that you get fast feedback on it.

So the example that I like here is something like ReSharper or Good IDE, where as soon as you type that unconventional variable name, you go to the next line, boom, squiggle marks. Right there, immediately telling you as soon as you make the mistake that you should go back and fix it because it's so much more valuable to do the right thing and encode that success than it is to find out a week later when, you know, someone emails you back and lets you know, hey, that's not the standard for Java. Finally, it's repetitive. So it should be an exercise that you could do more than once

and see how you do. And then the fifth rule i really like it should be not fun that's a hard one for me to wrap my head around not fun yeah i can see that with you because like what i what i know about you is that you've got kind of a mind for practicing i think that you get a lot of fun out of seeing things go up and to the right because i feel like that's the thing that keeps you motivated keeps you wanting to practice like if i'm not having fun i'm more than likely not going to do it you know and i think the contrast like the what i kind of got out of them saying it shouldn't be fun is that you shouldn't be slipping into flow if you guys are familiar with the notion of flow it's basically that feeling where you like start typing on the keyboard you take a sip of coffee

at nine in the morning and you put the coffee cup down and like what the heck it's dark outside because i've been coding for eight hours straight i I closed, you know, more tickets than I thought I was going to be able to. And I feel great and energized and refreshed afterwards. And it's basically that kind of state of mind where your brain is occupied. So, it's solving challenging problems. So, you're not getting bored, but it's not too hard that you're having to really struggle with it. So, things just kind of float right out of you and you actually feel good at the end of it. Well, I think I get the intent here though, is a lot of times you skip doing things that just aren't inherently fun to

you, right? Like you're not going to go out of your way to learn something that doesn't interest you to a certain degree. Right. And so you might be missing out on some of those skills that, that you might not pick up. Like,

I mean, have you done a binary sort recently? Does that sound like fun to a lot of people? Probably not. Right. Like, I mean, have you done a binary sort recently? Does that sound like fun to a lot of people? Probably not, right? Like if you're interviewing for a job, it's a necessity, right? To him it says, yeah, totally. But I mean, it's one of those things that I think the purpose of this is it's easy to go after things that are in your wheelhouse. It's easy to go after things that you would typically go after anyways. But if you're truly trying to better yourself all around, then you also need to look at those things that like big O notation, right?

Like why does it matter to two people? Right. It's not something that's really all that for me, it's not fun to look at. Like I've watched the Stanford YouTube videos. I did the stuff in college and it's one of those things that you really have to get back into completely to, to really drive those points home.

And it's just not fun. It's almost like a drudge, right? Like I think three of us or maybe four of us signed up for the course at one point and we all dropped out after like three weeks. Cause it was like, man, this is a lot of work,

you know? So yeah. Oh, you're talking about, I think it was like man this is a lot of work you know so yeah oh you're talking about i think it was a corsair algorithms yeah uh program out of stanford yeah and it was heavy duty like it was one of those things where you're like yeah this you know i thought i was gonna get to just play around and learn some stuff but no they want me to do homework and this is this is yeah i'll't want to do homework like what's that i think that the kind of the problem with getting in that sort of flow and kind of having too good of a time with it is that uh it generally like they what they're saying is that if you're having a really good time actually doing the thing and not you're not having a good time because of the outcome

then you're probably kind of in that flow where things aren't too challenging and so you're kind of able to rely on kind of your instincts and that muscle memory that you built up. And it feels good to kind of solve those problems and get those wins because it's, you know, you're hitting all the targets, right? And it feels good. But you're not pushing on your limits. You're not kind of pushing on the boundaries of your abilities. So, you're not moving forward and you're kind of stagnating. So, it could be great for like getting through the work week. Like it would be wonderful to be in flow Monday through Friday all the time. But what they said is basically

it's not an effective way to advance your skills. So it might be a better way to phrase it then instead of saying that it should not be fun, that it should be hard. Maybe. I think, but we don't want to go too far too because one thing that they kept pushing back on is like you don't want to just dive

into the deep end of something. And that's because it's really easy when you're way out of your depth to do things in a wrong way. And so like an example I like here is like wakeboarding. If you've ever done wakeboarding and you've never done it before, like, or, you know, maybe even like learning to dive, something like that. You don't want to go off the high dive, the highest, because you don't really know what you're doing. You haven't built up the skills. It's probably going to hurt when you smack that water. And so if you can kind of build up to something in a way that is better aligned with your

current skill level, then it's going to go faster and be smoother and you're less likely to codify bad habits. That makes sense. Yeah. One feature I wish there was like a number six where like they include like the stickiness factor and like you want to keep coming back to it, right? Yeah. That would be like a cool thing to like measure like say for example when you're

lifting weights right the stronger you get the more your body starts to change it like it keeps you wanting to come back to the gym and keep keep improving yeah i like that and one thing too to kind of to contrast to like the scrimmage or the or the side project thing too is like it can be a lot easier to pick up on a practice than it can be on a side project if you go three weeks without touching that side project or six weeks or you know you don't have a lot of time it can be hard to get back into it depending on how you left off but if you are doing javascript level four problems for for 20 minutes you know the barrier to entry there is having 20 minutes you know i almost equate it to video games like it's it's kind of an odd analogy but video games that i play nowadays, which I

don't get to play that much. It's usually things that I can pick up and do fast and then put down, right? Like, like people that go and play, uh, elder scrolls or oblivion that are like 600 plus hour games that those hold no interest to me because I know I'm never going to get there. And, and even when I play it, I have fun, right? Like somebody will buy me the game and I'll play it for two hours. And I'm like, well, that was a lot of fun. I'll never play it again. Right? Like, like it's seriously like that. Whereas if it's a basketball game or if it's call of duty, I know I can jump on play for 30 minutes,

have fun, and then I'm done. Right. And so it's kind of similar to what you're talking about with the skill is you get in there, you had something tangible that you walked away with, right? Like you, you feel like you accomplished something. Whereas sometimes side projects, honestly, can just be sort of frustrating, right? Like you look at it, you're like, man, I suck because I tried to do this. And you know, I got so far, you know,.NET Core was a perfect example. I got into it and I was like, well, if I'm going to make a real-world app, then I need people to be able to log in. They need to create accounts.

Well, I'm not just going to create an account. I need to figure out the identity service. I mean, it's got to be secure. I've got to secure these identities. And wait, now there's J tokens, and you can do things. Wait a second. So now I've got to go into OAuth. Literally before I even get anything done, I've got 30 do things. Wait a second. So now I got to go into OAuth. Like literally before I even get anything done,

I've got 30 other things. We don't even know what we're authenticating to yet. But you got to have Facebook, Google, GitHub. Yeah. So, yeah. I mean, so yes, it's, I like this. I like the fact that if you do focus on the skill, you have something that you actually feel like you accomplished, right?

Like it's a task that you can walk away and say done you know and if i want to come back and polish up on it later i can and it's not that huge barrier to entry in the future i'll just use octa you get all that stuff for free which one octa octa i don't think you've heard of that this is why those peers are so important so how can i practice this stuff though yeah and we mentioned a couple of these like the x for y categories um there's a one i really like the regex crossword i think i gave it as an example or my tip of the week a while back where it actually kind of lines up different uh regex on different axes and you've got to find the commonality between those two regexes

like a crossword type format you know that's the kind of extreme example same with code golf but code wars i think is like the ultimate kind of x for y here because i can say javascript level 4 20 minutes count how many i do at the end and once that bottleneck gets to be my typing speed that i can go ahead and up the level on that and um i think that uh you know i am still kind of mixing things there because like on one hand like i'm talking about solving the problems on the other hand i'm talking about solving the problems. On the other hand, I'm talking about learning JavaScript. And so you do still have to be careful about that. But I do think you need to learn, you know your language really well before you can really get to that level with the algorithms. Because if you're taking that two seconds to look up like the syntax for slice or splice or map or filter or is this capitalized or not?

If you don't have that kind um kind of uh implicit declarative language built up in that higher level thinking then you're constantly going to be tripping on stuff and you're not going to be able to kind of unlock your potential to really fly on that stuff so i think you've got to have the basics down and i think those x for y things like code wars are a great way to do that one thing that's neat though looking at the list you have here like code wars and hacker rank you know the usual suspects is suspects is like these sites are sort of focused on like writing code. Right. But are there any sites that you can go to or like any resources for like learning how to become a better code reader?

Right. We spend like an absorbent, an orbit amount of time like reading code. Right. But how often do we practice like becoming better at catching up and picking up context? Oh, that's a hard one. That's an interesting concept. Yeah, I really like that. You imagine if I wanted to get better at understanding code,

like one side project or one type of exercise I might do is like I find some sort of code online that's not too long, and I read it, and then I try to explain in like one sentence or some sort of tight, concise thing exactly what's going on. I think just by trying to do that really helped. The, the Regex crossword puzzle that you mentioned though, that is an example because you have to be able to read the, the Regex and understand it.

Now how you would apply a similar kind of concept to something outside of just regular expressions. Someone more creative than me will have to come up with that. That's a tough problem but it's an interesting one though because that's actually where resourcefulness and people's thought process comes into play i will say like code wars like when i did it initially it was fun but it also frustrated me because after i got into it like my mind is trained to you know validate the inputs, validate the outputs,

you know, do these things, try and try and do things nice and neat. And, and it turned out, it was all about who can write the most creative way to do this entire thing in one line. Right. And, and, and it almost got to the point where it was like, man, I don't really feel like I'm getting that much. I don't feel like I'm getting that much useful takeaway from this. Don't get me wrong. It was cool to look at some of the answers and be like, oh, I never thought about doing it that way, but I would have killed anybody that would have put that in my real code

because you can't understand it. The fact is, if you saw that in source code somewhere, you'd be like, okay, let me go do a get blame and find out who wrote this so that i can go yell at them right because it doesn't make sense and so i think you have to be careful i i love these resources because it's a good way to get practice and it's a good way to learn how to solve problems right because they'll throw a problem up there but you know just be aware that sometimes you know just the way that they get to the outcome isn't as important as just understanding the thought process of how you should get there, you know.

Yeah, and one thing I like about Code Awards is you can actually tag solutions and vote them up. So, like, when you solve problems, I don't know how new this is, but if you solve a problem, go look at the solutions, people will tag them as best practices or novel solution or shortest solution and kind of vote them up. And I really like to see other people's solutions. And sometimes particularly Dance to Die and Robert have really creative solutions that are always different from how I think about it. And so I get a lot out of that. But I totally agree that if you're just focused on like, say the lines of code or getting that problem done in that 20 minute span, then you're probably taking some shortcuts to get there that are codifying those bad habits. So, you just got to be careful about slicing up and making sure that you're addressing

the things you actually want to get better on. Cool. And we talked a little bit about soft skills. I think communication is really important. We didn't talk about it too much, but if I can express my ideas to my coworkers and my managers, if I can express an idea to them eloquently and concisely, I can say one sentence and they just get it and understand. And we don't have to have a two-hour meeting. Or if I can drop just the right comment at just the right time or write just the right email, there's immense business value to that, to getting everyone on the same page very easily. And so communication is a skill

I'm particularly interested in. And of course, you know, the podcast is another reason why I'm interested in this. And it's another avenue of me trying to kind of get better at it. But I do think that stuff is part of being a better program, at least to me. Yeah. I don't know if you've heard, but our communication skills at describing triangles and graphs, we are amazing at it they're off the chart yeah like i see what you did there that's good another outlet that you don't have listed is like participating in hackathons like showing up and offering your development skills for somebody trying to build a product with like a team of complete strangers is also another way to kind

of work those soft skills muscles and also get some like gratification out of it as well from a technical perspective i like that i honestly think that for developers a lot of times soft skills are overlooked a lot like it's the thing that they put the least amount of effort into and honestly if there's one thing that'll hold most people back in their careers it's probably this right here you can be the most amazing programmer on the planet but if you can't communicate or if you're hard to deal with or you're brash or you just, you act like you're better than everybody else, at some point that is going to limit you. At some point that's going to hold you back. And granted, there's going to be exceptions to the rule, but being able to communicate and being able to work with others is huge, just immense in what it can do for your career.

Cool. And another thing I can think of that will probably fall sort of under do X for Y as well as soft skills is exorcism. So exorcism is cool because it has these exercises, but you can also have people who have like expertise in that particular language or framework, give you feedback and say, Hey, this is sort of not idiomatic. You kind of want to try to do things this way and that way. And you can kind of iterate and learn that way from, it's like crowdsourced code reviews in like a gamified way. It's pretty cool.

Yeah. Wait, exorcism.io. Yep. Exorcism.io. So like exercise, not exorcise. Like exercise.

I thought it was like you know getting the evil out all right got it now our buddy um uh dance that i um actually did a thing on interviewing.io which is a site where you can actually practice interviewing with a person and they'll give you sample problems and you kind of like work through it with them and they push you they do some questions and then they give you the video at the end with their feedback and say, hey, this part didn't like work on this, you know, that sort of thing. So I think that's a really cool kind of service, too. And, you know, like kind of time on the scrimmage example, like you could definitely argue that the best way to practice interviewing is to go interview. But if you like, say you live in Seattle or somewhere, you don't want to necessarily burn those learning experiences. You don't want to burn those companies that you actually want

to work for practicing, right? So it's, you don't want to go out to the Microsoft's or the Amazon's or whoever else is around your area, the best companies and practice on them, right? Those are the goals, you know, depending on what you want. And so I like the idea of being able to practice those sorts of things in isolation and work with a service so you're not actually taking you know six hours off work to go practice an interview this is pretty cool how do you sign up to be an interviewer do you know say what oh how do you sign up to be an interviewer oh i don't know i'm sorry i know um there's a website someone told me about called carrot i think that where you can actually sign up to,

to be an interview for other companies where like, you're actually like a kind of admin, like a, almost like a test giver. And then they actually pay you per kind of interview that you run. You turn the videos over. I think I found it on the FAQ. Just send an email to like this address and they'll get in touch with you.

What do I need? Yeah. That's interesting. Sending email now. Yeah. That's awesome cool so uh another couple ideas that have we're basically just around static analysis um and that really i was just thinking more like this three sharper will kind of give you the squiggle lines and say like hey this could have been a link statement or hey if you move this if above here you can

shorten your cyclomatic dependency whatever uh cyclomatic complexity um and you can look at those kind of numbers and and just see what you get so it's a little loose i mean ideally you'd be working with somebody and that like ultimately everything comes back down to you're better off working with somebody yeah but i mean using those static analysis tools does give you an opportunity where you know if you can't or maybe it's like really late in the evening and you you just don't want to like wake anybody then at least you maybe it's like really late in the evening and you you just don't want to like wake anybody then at least you could see like hey am i in the zone of pain right and it gives you scores right like it's quantitative which is which is nice yeah and i

know for me you know i mentioned communication being kind of one of my goals for this year another one is just really architecture and kind of writing good maintainable systems that are going to be easy to change. And getting practice on that can be really hard, especially if architectural decisions are often made up front in a project and you end up kind of dealing with the after effects, you know, forever after.

And so how do you get practice with something like that that's really important but doesn't actually come up that often? It's kind of like the kicker example of football i feel like architecture more so than anything it definitely benefits from like a mentorship and being around other people who've built systems and experienced things because like it's hard to learn that stuff through osmosis you kind of got to work with somebody who's sort of been in the trenches right you can like read all the martin fowler that you want right it doesn't resonate as much as working side by side with somebody who's done it before

so true uh there's a book i really like called practice perfect we've got a linkedin down there the Martin Fowler that you want, right? It doesn't resonate as much as working side by side with somebody who's done it before. So true. There's a book I really like called Practice Perfect. We've got a link down there in the resources section. And it's actually 42 tips where they took basically their lessons learned kind of teaching and mentoring and coaching and actually spent a lot of time looking at actual teachers in classrooms and kind of figuring out how those teachers best express the ideas to the students and how they actually actually like maintain discipline and whatnot as well and so that book's got like a ton of just really great like hard and fast kind of ideas or i don't want to say rules because they're not hard hard and fast rules but just kind of

ideas for things and one thing they really hammer on over and over again is practicing just about everything like if you're a manager man if you can find someone to work with you and if you've got like a tough conversation you're kind of not wanting to like say like you've got to give someone a bad review or something you've never done that before like man if you could just do like a 10 minute kind of walk through with like a friend of yours or something just kind of practice just do it out there once that second time is going to go so much easier. That's my own experience with that sort of thing. If you can just get one or two little kind of trial runs, like flush out some of the stumbling points and life can be so much easier for you. Yeah. I know, I know people that

speak at large conferences. I remember, I know Joe, you and I listened to smart passive income and you know, Pat Flynn from that, like he would stand in front of a mirror and and do it you know many many times before he went out on stage so that he had it down right like and he did it like he was going to do it live so it definitely helps yep and i've got a couple uh quick rules to just kind of jump in for a little bit of practice they say the first and most important thing is to identify your goal. And, you know, as it like has come up quite a bit tonight, it's really important to hone in and really grok and understand what it is you really want. Because it's easy to kind of either not understand what it is you want or to not actually practice towards the thing that you truly desire.

So, understand your goals and then mapping the relevant skills just means like say the interviewing example you might kind of do a little mind map and say well there's whiteboarding there's um answering tough personal questions like what's your biggest weakness or whatever there's um you know algorithmic analysis there's it's kind of all sorts of different things that you could probably come up with a list of like 20 things that are involved in in interviewing and then after you've mapped those skills not knowledge just skills so even like speaking comfortably is a skill and you're going to want to assess those individually sometimes you can kind of lean on past experience a little bit and so i know that there's things in interviews that i have more trouble with than others, like rambling. And then one thing I like to say, identify a high

value target and high value. I like that way of saying it because sometimes you want to play to your strengths. You know, if you've got a great field goal, like sometimes you want to take that, you know, 80% shot rate to 85, you know, but sometimes you you want to take that you know 80 shot rate to 85 you know but sometimes you also want to do the opposite you want to focus on something you're really terrible about because you're going to get bigger gains in that area for your time spent theoretically or else maybe uh you know there's some other reason so there's a skill that's not necessarily you're that good at or that bad at but it's high value because maybe it's got some sort of other crossover in your life.

So for me, like getting organized would be a good skill to, to work on because it would make my wife happier. In addition to my boss. What are you thinking about? I'm trying to like figure out how to the high value target as it relates to code and and practicing there so i guess is that something like like you mentioned map and slice earlier like okay i want to see how those work or yeah i was just trying to figure out that's like the nuts and bolts of

language but like another thing could be like what about writing or interacting with other people's code i think that there's a lot of people in there that like when they as soon as it gets to other people's code like all the rules go out the window because they don't really want to change stuff too much or they don't feel comfortable they don't want to maybe they don't want to read as much code as they probably should because they just want to focus on the one little additive if statement that they can add to make the problem, the program, the problem go away.

And maybe that's something you want to work on, or, or maybe you have a bigger issue with Greenfield problems where you start to prototype things and those end up in production. And the whole time you kind of like took little shortcuts to get stuff showing on screen. And so maybe you actually tend to work better with, you know,

bugs than you do with Greenfield type stuff. Yeah. Or it might be something like fluency. Like, hey, I want to make sure I'm more fluent whenever I get ready to write a link statement, right? Instead of fumbling through and having to Google and figure out all the right keywords to use. Yeah, and links are a great example. Like, if you really know your link stuff, you can use that sort of stuff all over the place. And before you really know link, there's all sorts of crazy like aggregate stuff that you're going to be doing with for loops.

And it's just, that's more cognitive weight. That's more stuff you have to think about. And if you can just kind of dash out like a two liner to do it and move on, then you're spending more time focusing on the business problems. Y'all proud of me? I knew like a C sharp thing.

Yeah, there's Java lambdas. There are in streams they they confuse the heck out of me i've been trying to work with them lately and then uh finally you want to design your exercise it's going to target one thing we talked about that you want to do the exercise and we got a cute little go-to step number two here because we got a little cycle going on of course so you want to keep repeating this stuff so should this list be bad form then should we should we like peer review this uh this pull request and say like this is bad form because you used to go to statement like that go-to statement i started the list with zero though did i get some some cred there actually yeah i was going

to give you props for that because even in the article going back to when we were talking about the four reasons why the 10x developer is controversial, I noticed that those were also zero-based. Your array counting skills are pretty good. We've got to work on that go-to skill there.

Right. At least give number two a better label than just two. That's a magic number. Wow. You didn't realize that we were going to review this, did you? Oh man. Yeah.

On air code. Blessing. So I mentioned that book, a practice book. Perfect. That's a definitely a really good one if you're into mentoring and coaching and you're interested in some like real tangible kind of thoughts on that side of things and i do think work is the best place to do it because you've already got a bunch of people and you've got a vested interest in everybody doing things and being consistently

so if you could take some time away even if you don't peer program often and and do a couple little exercises or get people together and focus on one or two things like tracking down a bug. I think there's a lot of value of like, say me and Alan trying to track down a bug that I would only track down on my own because it's in my area. All of a sudden he's here now he's got different tools or different viewpoint on things. And at the same time, he's also getting kind of like a nice little tour of my stuff and the way I think about it and the way I kind of debug it. And so it is funny. I just, just for those out there, when, when I go to debug a problem, I don't want to hear anything about, I just want to know what the problem is. I don't want anybody

to tell me anything about how they've tried to find the problem because I don't want it to cloud my judgment. I want, I want to stumble through and figure out, you know, because it might've been just one thing that, that, you know, somebody just assumed in one spot that I'm not going to assume or whatever. Right. Like I like to solve the problem from beginning to end. And it's almost like when somebody wants to design a system or something, like, I want to know what the problem is. What are you trying to solve? Don't tell me what you want done. Tell me what your end result is, what you're trying to look for. And that's, I love approaching problems that way. And I like for other people to think about them that way too, because somebody will think about something that I didn't think about. Right. okay not not not up front right like i want to at least take a minute to get my head into it right like tell me what the problem is but don't step me through it because then it's going to take my mind off my natural you know curious whatever it's going to do right i do want to revisit at

some point like maybe i don't go through it, but I at least want to get my head wrapped around it first before anybody starts, you know, injecting things into my mind. So don't stand over your shoulder and say, try that. Try that. No, don't do that to me. Oh, my God. I'm bumping your head with my belly. Now things just got weird. Moving right along.

Oh, geez. Yeah. Sorry. I'm like reliving a manager nightmare right now. Eating an apple over my head, popping me in the back of the head with the belly. Hey, Peter. What's happening?

Oh, man. DSO, I think we actually covered most of these tips for practicing we know we talked about um flow being a little dangerous because skills can stagnate and that one study they actually looked at there was with doctors um who have the diagnoses to do and then they validate the diagnoses and um you know looking at like tumors and stuff like radiology type things and what they found is actually um like a lot of the people who look at these things would kind of peak after a certain amount of time where it's like year five, they're like peak diagnosis. And then after that, it kind of trails off. And I think a big part of that is because your brain just loves those shortcuts. And so, you can find a shortcut that works 80% of the time.

And it's a lot easier than that 85% of the time. Then a lot of times it's going to kind of want to fall back into there if you don't got if you don't have somebody kind of reining you in so so wait a minute is the takeaway here that you don't want a doctor who's been practicing for more than five years i think that's what once your doctor has practiced for more than five years you got to go find another doctor machine learning i think uh pretty sure i heard on the podcast this is going to be replacing all the doctors in all the world within like the next i don't know six months or so it is funny though when you think about it just from just from a pure human perspective people that are newer at

something take more care in getting it done right the builder who's building his thousandth house is going to take so many shortcuts like walls aren't going to be completely square that kind of stuff right like as opposed to somebody that's just getting started they're really going to want to do a good job right like it really does make sense to a certain degree so i'm i'm changing all my doctors well as a programmer like i know that no program i write is going to be perfect so i'm probably like quicker to jump to that like yeah good enough than like somebody who's only been programming for two years. It is interesting.

I mean, it really does. I mean, if you were going to go take on a task that you'd never done before, you're probably going to watch 20 YouTube videos. You're going to know every single downfall that could happen, and you're going to plan around all of them. It's going to take you 12 hours to do this 30-minute task, but by God, it's going to be amazing, right? And it's interesting to take you 12 hours to do this 30 minute task but by god it's going to be amazing right and it's interesting when you think about that i can put this into a real coding kind

of thing all right we've all when we were all learning to code right your first like uh let's just take it down to like a c-like language okay and uh you know you you're you're learning loops and four loops for example right and you're really getting that down and you're learning loops and for loops, for example, right? And you're really getting that down, and you're using them for everything, everywhere. Anytime that you need a loop, you're like, mm, for loop, that's my boy. And then you make your way into like a C sharp, and you're like, oh, man, this for each is amazing. You mean I don't have to worry about the iterator? And then you get lazy and you start using the for each in places where, you know what,

that for statement would actually be more performant if you used it, but you've gotten kind of lazy and you're like, oh, you know what's going to be good enough? This for each is just going to be good enough. And by the way, that enumerator might actually blow up if you change something because now you changed the collection underneath it. Yeah. I mean, yeah, there's you're definitely right. You get you get sloppy. And I think it happens to everybody over time and it's just natural.

But, you know, I was thinking about some of this stuff as Joe was talking about, because there was the one point that he made about like, you know, hey, don't just ask how the code is. Ask about specific things though and it made me feel a little bit better about you know there are times where not necessarily from a practice point of view but just like you know i'll look at it from the point of view of like a pull request like you know i'll ask someone specific to either an area of the app or or a particular skill set and be like hey man tell me, do you think I'm crazy for doing this? And I'll explain like, you know, you know, here, here's the thing. Look, you take a look at it and tell me, is this crazy? Would you, do you want to, do you want to immediately revoke or, you know,

decline this pull request because of this? Right. So I feel like, you know, that kind of, I don't know, I guess I should think of it as mentoring in that case you know that kind of i don't know i guess i should think of it as mentoring in that case but uh that kind of peer review that that what joe's talking about though is kind of along that line maybe and that's a way that you might be able to incorporate something without it actually being like practice outside of your um your day job necessarily but just like a way that you could incorporate it in as part of your regular routine. Right.

Yep. That's one thing that's cool about pair programming, you know, as much as it's exhausting, you do shorten that feedback loop a whole lot, right. You can kind of get that litmus check immediately. Like if you're going some way,

way off in left field. Yeah. And you're encoding that success. Like one example, I kind of like there is like, sometimes I'll do something like, Oh, I think there's a better way to do this, but I don't want to stop what I'm doing right now and look it up. So I'll just kind of do what I can now and I'll take a little to do to do it later. And then guess what happens later?

And now I'm busy. You know, I got to get this checked in so I don't do it. And if someone had been there that was more familiar with that area and was able to say, hey, someone else did that like last week, like go check it out right here. Then we could have encoded this success and the next time that problem comes up i'm more likely to remember that good thing rather than the bad thing that i used to work around it right so i've got a couple tips here for just kind of mentoring we'll go through quick um one thing i thought was interesting is that that they really emphasize making a plan up front and sticking to it i think that a lot of times they would see, at least when working with teachers, that a lot

of times the practices would actually devolve very early on into talking about the practice itself, particularly about how the practice is like, not like real world or not like whatever, or just it kind of devolved and lost focus. Wait a minute, is this mentoring tips from the point of view of being mentored or mentoring tips from the point of view of being mentored or mentoring tips from the point of view of mentoring others mentoring others okay so if i'm going to mentor others i need to make a plan and yeah definitely the onus like the the entire perspective and the practice perfect at least has always been from the perspective of the teacher i don't think they really talk too much about about what it meant to be kind of a good pupil

other than going out and finding a good teacher. Call Your Shots, I thought that was really interesting. They gave some cool examples there where they're pairing two people up, like a good salesman and a bad salesman. And then they go into a meeting and they come out of it and the new salesperson thinks like, oh man, this didn't go very well because, you know, we got a deal, but it was real rough and it was rocky.

It was really awkward. And the other salesman was like, I didn't think we were going to get that at all. This is fantastic. This opens a lot of doors. And because the new salesperson didn't understand what kind of problems and situation they were in ahead of time. They didn't understand the goal, and they didn't even understand that a good thing was happening when it was. So I just think it's important. What does that mean for call your shots, though?

I think I'm missing the point. You want to be up front with your pupil or the person you're pairing with. Here's what we're going to do. We're going to make a simple login form. It's going to be really robust, and it's going to use this technology. Okay, so make sure that the person that you're mentoring understands what the goal is. So not just you made your goal. Yeah, okay, so I'm with you.

So that's what you were talking about from the sales perspective is that person didn't understand what his goal was going in, so he didn't know that his outcome was going a particular way. I got it. Yeah, you can give an example there where you got two coders that are pair programming. First one says, like, come on, we're going to write a login page to get together. They write the little page. And at the end of the day, that new programmer might think, well, we used this kind of technology stack because that's the best for writing login pages.

Well, really, they use that technology because that's the one that most coders have experience with or because there was a simple example they had to look at so they may not understand the reasons behind why things are done and you can see how they might go and they think like well they made this login page in c-sharp because c-sharp is the best so now they go to start a new greenfield project like well let's see sharp's the best and what really what happened was that decision was made because, you know, for very application specific reasons. But because that wasn't discussed up front and the exercise wasn't planned out

ahead of time for specific reasons, like here's why we're working on this thing and here's why we're working on it in this way, then the person left with the wrong interpretation. Okay. Makes sense. We talked about encoding successes. successes sooner you can get that success and sooner you can correct that bad activity the better and that also goes along

with the the idea of the get a whistle which is a really cute chapter it's basically like the coach like blows the whistle as soon as that bad habit happens like you're playing basketball and you got a bad habit of like shooting with one arm right blow that whistle immediately as soon as you start to see that happen because you want to get them to not do the bad thing you want them to always do the good thing you want to encode that success cool another one of my favorites was actually coming up with a name and um they kind of i think had a harder time coming up with justifications for this in the book because it's kind of not as common to us as programmers who have, you know, lots of experience with abstraction. But I think, like, when we talk about design patterns and I say, hey, let's implement a

factory or we need an observer here, those are really powerful terms because I say the word observer and you're already thinking about 10 examples where you've used observers and you've seen and i don't have to try and describe what i mean by you know like eye notifications and i you know throwing uh throwing updates and whatnot so like just that one word observer is really powerful to you and it lets us communicate at a higher level so later when i'm looking at a pull request or something i could, why don't you use an observer here? And it kicks off this whole world of knowledge in your brain and thinking and discussion. Whereas if we don't have that term observer, we're going to spend half that conversation trying to get on the same page about what we're talking about because it's an advanced topic.

So just modularity, good abstraction. Same with solid. Like if you send me a pull request thing, say like, Hey, where's the, where's the, where's the S you know, this is a, you've got your dependencies intermingled here. You know, I can use these, the shorter words and like, you know, you don't, it means if I say your dependencies are intermingled here, you've got your logic kind of your presentation and your query logic mixed together because you've been doing this sort of stuff a long time you've been having discussions like that for a long time so it's great that i can give you like five words that mean a lot to you so it's more about like coming up with a common vocabulary

language yep and uh don't forget to measure and then don't forget to do it uh it's kind of funny to think like you can like you know get the tdd book work all weekend on it get back to your day job and then never do it again yeah i mean uh along with all these mentoring tips the thing that that stands out is in i joe didn't share it this, but he actually had a slide in his presentation deck that actually showed that one of the most effective ways to learn is to teach. It's one of the reasons why we did this podcast. I mean, when we first talked about this, the way to sharpen and enhance your skills is to force yourself to really dig into it. Right. And so going into all the topics that we have over time and continuing to do that, it forces us to go read books. It forces us to do more practices. It forces us to take a look at our code and say, oh, what could we have done different here?

Right. And that's, we've learned a lot doing this podcast. I'm sure that we have. And, and so even if you don't think you're as far along as where you need to be to mentor somebody, don't let that stop you. Right? Like if you're, if you're an intermediate developer by some random measure out there, find a junior dev and see if you can mentor them, right? Or if you're a junior developer, find your little cousin who's 12 and try and make some IoT type thing, right? Mentoring can happen at every stage of the game

and it will make you better along the way. Absolutely. So we'll have a bunch of links to the various books we talked about. I actually want to pitch up codingblocks.net slash practice where I've written a bunch of essays and also gathered just a bunch of links to the various books we talked about i actually want to pitch up codingbox.net slash practice where i've written a bunch of essays and also gather just a lot of different links to various studies and and whatnot if you actually drill into those articles you'll see there's a just a ton of links in there as well as my slides for the talk cool

yep so with that let's head into Alan's favorite portion of the show. It's the tip of the week. Yeah, baby. And we've got a new participant here, so you're going to get some bonus tips. Yeah, so we'll let our guests go first. I'm sorry, Alan. I didn't mean to cut you off there. No, you're good.

All right, cool. So I have a couple here. I'll start with probably the most interesting one first. So there's this app called Krypton. And basically what it is is you can sort of use your SSH keys securely by only having them on your mobile device. And then you can SSH from any machine without having to have your private keys stored on that machine. So it's especially good for environments where I work, where i move from machine to machine all the time and i don't really want my privates to be on there where somebody could be you know committing stuff and looking like it's me

um it's really cool it comes with like a nice cli application that you use to like pair your phone to that particular machine for that to that period of time and then whenever you get ready to do anything that involves your keys it sends you like a push notification saying hey i see somebody trying to like pull from github using your credentials is this okay and you basically tap yep i approve this is cool and then everything works as normal so that was pretty sweet dude that's awesome yeah it's really cool and bonus tip it's written in go i'm pretty sure uh the back end is and you gotta like the pricing on it too the core version version of it is free, $0 forever. It says now, I guess there's going to be something if you're trying to do this at a team level.

They're, I guess, looking at how they might charge for that. It looks like they don't say a price yet. They just say it's early access. Dude, that's ridiculous. But it's awesome. You should totally try it uh second tip is uh source graph which is another platform i think which their most of their tooling is written in go as well they have an awesome chrome plugin for if you want like sort of like an ide type of experience when you're browsing through github

looking at open source repos and trying to navigate sometimes those repositories can be really large especially for like big projects like Kubernetes. But a lot of times I use it to like figure out different idioms and patterns that big projects like that use to find some of those best practices and things I can incorporate into my own code. So like the Sourcegraph plugin for GitHub is also really awesome. Man, we talked about something similar to that one though, but what was it called?

Yeah, I'm going to go look that up right now. That one came from Critner. Yeah, I've seen something very similar to this before. We were talking about it earlier. Yeah, it was – I'm sorry. No, no, both killer tools. Yeah, it was a plug-in specifically targeted towards GitHub that would basically put like a File explorer view on it, right?

Make it. Yeah, I've got it at work, but I don't remember the name. Oh, Octotree. Oh, yeah. So it looks really similar where it gives you kind of the file browser on the left. And I really liked it actually because it made it really easy for me to get back to like readmes and stuff so I could hop into the code and then like quickly get back out to the top level.

Yeah, the cool part about Sourcegraph though is in addition to like the directory, it also gives you like very smart code navigation stuff like jump to definition and really sweet code search like far and beyond the stuff that you get but on github by default that's beautiful that is awesome so like i could look for show me places where they use this particular package or this thing from this package like it's's really cool. Very nice. Excellent. All right, Joe, what you got?

Uh, me, uh, I just want to mention, uh, our buddy will get from a complete developer podcast. I just listened to him on another show, which is called the junior dev podcast. And he was talking about what it's like and why it's beneficial to learn other

programming languages. This podcast is, uh, it's kind of aimed at, um, kind of more junior developers in there. So if you're looking for your first job or in those first couple of years, this is a fantastic show to listen to. And so I just wanted to make sure to give them a shout out if you're not already

listening to it. Awesome. All right. And I'm going to have a couple links in here for unpackage. So this is basically how you can use a CDN for everything on NPM. So you can use it to quickly and easily load any file from any package using a URL, including you can specify the version as well that you want. So it's pretty cool. I'm to include uh links to a github which has examples of how you can use this thing as well as the link to unpackage itself uh it's unpackage.com but it's you know only one vowel well hold on yeah on yeah not unpackage.com yeah you you in pkg.com there yeah but yeah i mean you would pronounce it unpackage right yes so that's really cool it reminds me of this thing in go to call go package in that there's a similar thing it's almost like a proxy that like fronts all the npm packages that's

pretty cool yeah it's super cool i mean if you haven't already used it it makes it really easy to just bring it in although i do kind of like, okay, is that a bad habit though to do it that way instead of like bringing it in as an NPM package that I can then save the environment? Yeah, it seems like so. Yeah, hard to say. Does it get listed in package JSON like a normal dependency? Just with like a different URL? No, not in the ones that, at least not in the ones I've seen now,

maybe, maybe I need to dig into this thing more, but in the times where I've used it and where I've seen other people use it, it's like baked into like a script tag in your, in your HTML file. Like think if you're bringing in bootstrap or something like that, you want to pull it. Yeah.

And you want to pull it from a CDN. Gotcha. Yeah. Cool. Did you have another one? Nope. That was it. Oh, okay.

Wow, I didn't realize. Way to put me on the spot, Alan. I got to come up with a second, third one. Well, yeah, there's two links to the two things. Now I got to come up with another one off the spot, so thanks. There are two links. All right. No pressure.

So here we go. All right, so this one's awesome. So in the previous episode, we had some sort of, I think it was our survey, somebody was saying something about stand-up desks. I can't remember exactly what the conversation was now. But like a lot of people had stand-up desks at their job. We were like, wow, that's crazy. A company just spent a lot of money on stand-up desks, which shocked us. So go ahead

stack overflow survey results yeah okay that's what it was okay it wasn't our survey oh i thought it was gonna be yeah because there was another conversation where we specifically had like how to spend you know like 2500 and that and that was kind of like what started the whole stand-up desk conversation i think maybe at least from us in the past you had you had specifically one of your things that you'd recommended was very by the very desk yeah so here's one that's really cool this is a complete desk that we'll have a link to on Amazon that Richard wrote us directly in email and shared with us and this particular stand-up, I asked him because one of the problems with cheap sit stand desk is typically when they're fully extended in the stand position,

they're wobbly as heck. Like you can touch it and you just watch it like swing back and forth. And he said that this one was not, and they've bought several of them. This particular desk is called the Titan Fitness A2 and it's actually motorized. It's got a top and it's called the Titan Fitness A2, and it's actually motorized. It's got a top, and it's got the motorized legs for $312. That's cheap, guys. You typically can't even buy a cheap desk for $312, let alone one that's got a motorized stand on it. And that's free shipping.

And free shipping. It's ridiculous, man. And if you sign up for the Amazon Prime Rewards card you can get yeah whatever oh hey can i slip can i slip a quick tip in here you may all right um one thing i want to mention about those uh those automatic ones with the uh you can kind of hit it up and it'll go up and you can walk out of the room get a drink while it's rising or falling don't don't go get a drink because sometimes you might have something hanging off your desk that ends up kind of getting stuck in the wall and dragging a nice little line up there. I punched a pretty nice little hole in my wall there. Something just got jammed just the right way.

I will say, typically, if you have things like I have computers on my desk, right. Or mounted to my desk. I actually have the things that, that screw up to the desk that hold them so that when the thing's going up and down, you know, it doesn't snag cables and all that. Although it doesn't fix the thing when you just got something hanging off your desk, charging your phone or something, but you know, yeah. Interesting. I was expecting, and maybe, you know, you guys were going to go here too.

I really expected that Joe was going to go here too i i really expected that joe was going to tell us a sad story about it like how he broke his new phone or something because he he hit the up button on it and walked away and then the phone just happened to fall and land right on the metal leg or something of the desk or something no he put a hole in the wall it was better i mean who cares about a hole in the wall man that's okay the interest kidding me my phone's been cracked for years oh man that's ridiculous i can't i can't talk about that um i will say so the cool part is it looks like this thing has you know a foot and a half of travel almost it goes from 28 inches tall from the top up to 47 so pretty good thing here

uh so at any rate very good tip thank, Richard, for sending that one in. And then the other one I got from the same podcast episode on MS Dev Show where they were talking about blockchain. This was really cool. Didn't even know it existed. And I found out something else new about it. So a lot of times when you're dealing with cloud services, whether it be AWS or Azure or any of them, typically

there's a command line client for, for interacting with these things. And they're way more powerful and you can script them out and you do all kinds of stuff, right? So Azure has the CLI, but if you don't want to have to install that thing and bring down all the dependencies, you can go to shell.azure.com. And if you've got your Azure account set up, you can go in here and you can actually interact with this thing directly. So you can, you can spin up Azure services or do whatever you need to do all from an integrated environment. That's a command line on the web. Really cool stuff. The other thing though, too, that I found out was, is this is also baked in the Azure portal. So if you go to azure.com slash portal and you log into your shell there up at the top, you'll see like a little bell.

You'll have your search box, then a bell, and then you'll see this command prompt type thing. If you click that, it'll actually give you the shell down at the bottom. So there's two ways you can access it. You can either do it from directly within your portal, or you can go to shell.azure.com. So again, really cool stuff. I mean, it does all the stuff that the command line does, but again, you don't have to bring down all your dependencies and everything. It's all right there. So it's kind of a nice way. Oh, and the cool part is, so if you decide that you're going to do shell.azure, which if any of you guys just clicked on it and went to it, it was probably like, Hey, you need to set up a block storage account for it or a blob storage, right? So the thing is

you can actually create your scripts because it's going to set you up a storage section. And when you save your scripts, they'll actually be there available so that when you come back next time, you can get directly to your scripts and pick up where you left off. So, you know, thanks, Carl. I stole your tip.

I really enjoyed this one. So, you know, there you go. Okay, well, huge thanks to Will for coming out tonight. I know I speak for all of us. We've got a ton of respect for Will. Will, I wish you could be like my full-time guardian angel, just sitting on my shoulder, keeping me from making bad code and otherwise mistakes.

So I really appreciate you coming out here and talking to us. I'm just glad y'all had me on, man. I'm such a huge fan. This is such an honor to come and do this with y'all, and I miss y'all. I'm trying to turn this into like a bro love fest. No, I mean, we had so many conversations when we all worked together. Like we would just have awesome conversations about tabs versus spaces or formatting or, you know, the most performant way to do things or breaking things apart.

Like it was always some good geek out things. Nougat versus Maven. Oh, man. There's no look. Maven wins. That's painful for me to say as somebody who's a C-sharp guy. But, yeah, man, thank you very much for coming out. It's not a short drive for you, but we do appreciate it.

Yep. And we hope that you, dear listener, also enjoyed this. And you can find Will on Twitter at IamWillMadison. Follow him there. Yep. I will retweet a lot of Go stuff, so you'll learn something interesting about Go probably if you follow me. Awesome. And so with that, subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. Be sure to leave us a review if you haven't already by visiting www.codingblocks.net slash review. And while

you're up there, go ahead and check out our show notes, which are said to be some of the best around our examples, discussions, and more. Send your feedbacks, questions, and rants to the Slack channel, codingblocks.slack.com and follow us on Twitter too at codingblocks or head over to codingblocks.net and you can find social links at the top of the page. Alright, I lost back here

and I'm going to ask my question now. Alright. Dude, does the unicorn poop stand thing actually work? Oh my god, dude. The squatty potty is amazing. You wanted to try it, didn't you? I was like, no.

You're more than welcome. I don't know how to try it right now, but I was curious. Man. I wanted to try it for science. Like, I always wondered, like, if I stood on this thing, would I be, like, likely to fall? Well, I mean, you don't stand on it. I know, but you squat. But, like, I don't know.

I was like, can this support you? Yeah, your knees are going to be at your chin, and you're going to feel things that you've never felt before. Oh, my God. I mean, it's amazing, dude. It is a game changer. And that's actually like the, you know, that, that, that's not the amateur league version one in there. Cause there's like a beginner version, right?

There's a, there's a beginner version one where, you know, you're like, uh, I forget how many inches tall it is. And then there's that one, which is the one you's that one which is the one you step up to right? so you have to start small because it takes you're going to pull a muscle trying to get up

I think I saw this on Shark Tank you got to have some yoga skills I think dude I don't know that we're cutting this part of the show. I want to be in a blooper reel, man. Gotta cut this part. He wanted to ask about my poop situation. What's wrong with that? Oh, man. You know what's

awesome is, when we first started recording over here, because we used to record at my house, I went in there and he had that thing in there, and I was like, man, in my mind, at my house, I would have hidden that thing in the closet or something, right? Like I don't want somebody to come and be like, oh, you poop with your knees in your face, right? I came out of there and I did the same thing.

I was like, dude, really? You've got the squatty potty thing? And he's like, oh, man, it's amazing. I was like, all right. I'm intrigued now. Can you rent one? What's the return price? I offer everyone that comes over that wants to try it, I'm like, you you rent one? What's the return price? I offer everyone

Everyone that comes over That wants to try it I'm like you know Go right ahead I'm not No judging I don't need to go I just want to stand on it for science

Or squat rather You can try sometimes You sit on the toilet And you put your feet up on the toilet That's just the thing You might You might squat on it And then not realize

Like I didn't think I needed to go And all of a sudden Boom No you don't squat You sit on the toilet right And you stick your feet up on it and then not realize, like, I didn't think I needed to go. And all of a sudden, boom. No, you don't squat. You sit on the toilet, right? And you stick your feet up on it, right? No. Well, it's a squatting position once you do that.

Yeah, no, you don't squat on it. You don't stand on it. You don't stand on it first. No. Oh, that's what I thought you did. No, you sit on the toilet and you stick your feet on it. And then basically. Just kind of like, you know, you'd slide it to where, you know, you want it and then put your feet on it.

Yeah. Yeah. All right. Yeah, no. It keeps it all straight want it and then put your feet on it. Yeah. All right. Yeah, no. It keeps it all straight, man. It's like a straight line. Will's going to take a bathroom break. We're here.

Crack. Because he steps up on it. That's awesome. Oh, God. Anyway. Yeah, this is the kind of stuff that we cut every single episode, by the way. Except this one. Except this one. Yeah, this has got to go live. Oh, this is the kind of stuff that we cut every single episode. Except this one. Except this one.

Yeah, this has got to go live. Oh, boy.