Coding Blocks - Programmer Strengths and Weaknesses

Episode Date: May 28, 2018

Inspired by Rob Conery's The Imposter's Handbook, we take an introspective look at ourselves to find two weaknesses and one strength while Allen shows off his vocal prowess in song, Joe needs a list, and Michael is a dash.

You're listening to Coding Blocks, episode 82. 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, example discussion, and a lot more. Send your feedback, 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. And with that, I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by Datadog.

Datadog is a software as a service monitoring platform that provides developer and operation teams with a unified view of their infrastructure, apps, and logs. Thousands of organizations rely on Datadog to collect, visualize, and alert on out-of-the-box and custom metrics to gain full-stack observability with a unified view of their infrastructure, apps, and logs at cloud scale. And they've got 200 plus turnkey integrations, including AWS, PostgreSQL, Kubernetes, Slack, Java, and a whole lot more.

So check out the full list of integrations at their website, datadoghq.com slash product slash integrations. And Datadog's key features include real-time visibility from built-in and customizable dashboards, algorithmic alerts like anomaly detection, outlier detection, and forecasting alerts, end-to-end request tracing to visualize app performance, and real-time collaboration. Datadog is offering our listeners a free 14-day trial, no credit card required, and as an added bonus for signing up and creating a dashboard, they will send you a Datadog t-shirt. Head to www.datadog.com slash codingblocks to sign up today. All right.

And today we're going to be talking about identifying our weaknesses and filling in the gaps. You know, last episode we talked about complexity theory and we've all been reading the Imposter's Handbook. And so we kind of thought it'd be fun to talk about kind of our own personal weaknesses and kind of how we thought about them and how we're identifying them and working on them. So I hope you guys enjoy. Yep. And as we like to do up first,

our reviews that you folks have left us and we very much appreciate them. So I've got iTunes and it looks like I got John James, maybe. C. Weldfitch, Change Perspective, and Steve 555-356-7 and huge thank you to you guys

355-7? 555-356-7 but I don't know why I read numbers in 3's so 555-356-7 I was thinking that was like some kind of phone number

555 just give me a call at five, five, five, three, five, six, seven.

All right. And on Stitcher, Nick, the Greek, Dizzle McShizzle, and Ketch. Hey, I know Ketch.

I might know some of the other guys too. Anyway, just real quick note, I want to mention that I'm going to be speaking on search-driven applications. I'm going to be showing three quick prototypes that are all built around a search engine and the Elastic Stack. So if you're in the Central Florida region, you should check out the back-end devs meetup. We'll have some links here.

And if you aren't able to make it, you can actually follow along. I've got the slides actually already up on the GitHub. And it's the same with the apps too. So if you're interested, you can check it out there. It's still a work in progress, but I think it's kind of cool. Hey, and if you want to know something cool, because we did the Docker episode the way that he's got this on the GitHub link, if you want

to see magic, go clone that repo and then type in Docker compose Docker-compose-up-d and watch magic happen. Your entire environment will spin up. You'll have Elastic Elk, the Elk stack running, plus some additional things and a website. Like, it's just awesome.

That's so cool. And just in that project, like some projects, there's Java, there's Python, there's JRuby, there's JavaScript stuff going on. There's a whole bunch of technologies, and you don't have to worry about any of it. You just type that command, and all that stuff is loaded in those little Docker containers. So you don't have to worry about any of that stuff, and that's the magic. Yeah, it's really cool stuff. All right, so first up, we're going to talk a little bit about how to kind of assess yourself. And I've got some notes in here from when I did the deliberate practice.

So I was going to kind of, you know, talk about that a little bit. But really, I'm first, more foremost, more interested in how you guys kind of picked. And, you know, I don't think we really introduced the topic, did we? I think I came at you guys and I said, pick two weaknesses, two things that you don't think you're very good at right now, and one strength in kind of the field of programming. And we're going to talk about it in the air. And so I'm really curious how you guys determined what to choose there. Before we dive into this, you've got how to assess yourself.

Did anybody else hear like a Madonna song in their head when they saw this? You got to make them assess yourself. Oh, that's funny. Yeah, yeah. I heard treat yourself from Parks and Rec. Very nice. Sorry. It's been bouncing around in my head since I read it, and I was like, get out.

Just waiting for the next verse of the song to go, go ahead. Hey, hey, hey. Right? Yeah. Here's a little background dancers. Somebody, whoever edits the video needs to put some background dancers behind alan that he sings this that's awesome all right it'll be done yes for sure so so yeah how did how did you pick no you go first

uh i don't know hey tell you what okay i, I'll go. We'll get to that. I'll go. Okay. Because I definitely struggled with this because the challenge to me... Okay, so Joe's like, hey, pick two weaknesses, one strength, and that's what we're going to talk about, right? That's kind of like the central theme of it, right? And it was like, well, man, how do I how do I, like, I want to be honest. Right. So I want to be honest with myself. Right. So how do I find this? So I'm like Googling around

like, Hey, how, how do you like, you know, find, find your weaknesses? Like how, you know, how do you determine skills gaps? Right. Like I was going nuts? Oh my God, man. Like I have been stressing about this episode more than any other topic we've ever talked about because it was like, how do you seriously, like if you're trying to honestly find, you know, take an introspective look at what your real weaknesses are, how do you first identify those? Right. And it's a, number one, this is a very tough thing to Google because if you do start Googling this type of topic, or at least maybe I

was using all the wrong keywords, I would come back with article after article after article about identifying the skills gap within your organization and across your team and how to like hire the right people that, you know, can fill in those gaps kind of thing. But none of them were about like self-assessment kind of things. They were more like team-based kind of things, right? Or like, hey, these are the skills gaps that you need to be aware of that, you know, why you need this particular technology within your organization within the next 12 months.

Like nothing was about, you know about how to assess yourself, right? But there were some articles though, like several, I'll put links to them in there, but like Slashdot, Quora, Reddit, all topics like what knowledge gaps do self-taught programmers generally have? What specifically is the knowledge gap between a strong self-taught programmer and a software engineering grad? Or what are some common knowledge gaps among programmers? Like, you know, those are, you know, kind of topics that you could find scattered around,

but it was like really difficult to find like, uh, you know, for me to try to find something that I could like truly assess myself. So I ended up just picking some things that like, I probably didn't do it the way you guys did. So I'm curious to see how this is going to work. I didn't Google a single thing. Like, that's crazy. You're like, I already know what my weaknesses are.

I don't need Google. I actually, that was like, man, I don't have any weaknesses this is easy no no so how did i know alan would say that how did i know i should have called that i should have like secretly texted joe like alan's gonna say how far in right how far in no like oh god we should have made a drinking game out of it we could have no no seriously, you know how I did it? It never crossed my mind that this was going to be hard to do. It was what things frustrate me. Those are usually my weaknesses.

So the ones that we'll be talking about for me, it's the things that either frustrate me because when I think about them, I'm like, man, I have a gap there. Or there are certain aspects of it that just drive me crazy because I don't know how to handle it properly or whatever. So that was it. It was literally just, hey, what are the things that I'm always feeling like I need to be better at somehow because it would help me in some substantial way. That was it. I hate to say, but I think I put about five minutes of thought and I was like, all right, which one of these am I going to pick?

Right? Like I need to, I need to grab a handful of these and these are the ones that I'm going to do. Yeah. So the way I kind of thought about it is, um, I didn't have to think about it at all. Like I, if I only need five minutes, I need zero because I have a constant anxiety loop running. And so I just had to do a quick aggregate poll there and look at

whatever was kind of hurting my soul the most. And so it was pretty easy for me to come up with things I was weak against. Now strong against, that was another thing like, you know... Well, we'll get to that. It's definitely hard to say like, this is something I feel good and confident with my ability towards. So that was real's definitely hard to say, like, this is something I feel good and confident with my ability towards.

So that was real rough for me. Man, you guys. I don't get it. Where's the confidence? Well, I mean, yeah. We're 82 episodes in, guys. No, but, okay, it's funny you say that. So, uh, because like one of the thoughts that I had while trying to like research this, because again, like my whole approach was like, okay, well, how do I,

how do I assess those? Like, I feel weak on everything. So it's like, I can't say that. Right. You know? So I was like, well, how do I, how do I give like where the honest thing, like these are, how do I assess where the real things are and tackle those? Right. But then I was like, why do I feel like that? Why, why does it feel, why do I feel like, uh, you know, I'm weak on everything because, you know, am I, maybe not, I don't know. Cause I can't find this way to assess it. But, um, you know, I was like, well, I think it was, there was a think there was a video that I watched where it was from a Google I.O. presentation from I think like 2008, 2009. And it was called something like the myth of the something program or myth of the – The 10X or whatever?

No, no, no. No, that does sound familiar though, doesn't it? No, it wasn't that one. It was a different one, but I'll find the title of it later. But basically they were saying we kind of feel like this. It's a common feeling amongst our community because you have these people who are held up to extremely high standards. Really, they didn't build these things that they're well known for overnight, and they definitely didn't do it by themselves, but they definitely take a lot of the credit.

Torvalds was one of the names that was mentioned with Linux. It was like, well, it's not like he just came out overnight. He spent a lot of time building Linux before it became a thing, and it's only gotten better because of other people contributing to it. But yet he's the name that we think about. He's the one on the pedestal that we think about. And so if you're not on that pedestal, then it's easy to not think as highly of yourself. So, yeah. Well, tell you what, um, so I did a lot of preparation for that talk.

I did on a practice episode on it too, with, uh, Will Madison, who awesome episodes, check it out. But, uh, in that research, I actually kind of found, um, some objective kind of measures that you could do and I kind of split things up into knowledge and skill. And so I was going to go from real quick, um, LinkedIn and ProSci actually have self-assessments where you can go in there and kind of pick a subject like say C sharp or C++ or something and they have some more somewhat softer type topics too but you can actually do a little test and you'll get a score and that's kind of cool

so you can say like well I've been doing C sharp for 10 years now. Like I expect an A. And so if you don't get an A, then that's something, you know, to be interested in. I also thought of looking at the stack overflow survey results. Like that's not so much an objective way to kind of measure yourself, but like you can like look and see what other people are talking about. So if you've never heard of, say, React or Angular, it's pinning all of the top charts in a bunch of different fields. Like that's probably some sort of gap in your knowledge. So I thought that was an interesting way of doing it. By the way, I didn't do any of these. You can try building something.

One thing I'm really bad about being overconfident in my understanding of things. It's like, yeah, man, I know how Docker works. Kubernetes, I get it. I watched the two-minute presentation. It's how you deploy stuff. And then I go to do it. And you know, three weeks later, I'm still like, man, God, help me. All right. And he has been helping me. Thank you. Reading the Impostor's Handbook. Listening to podcasts,

going to beat up stuff like that, that introduced new perspectives. That kind of helps you at least see your gaps, I think. By the way, just circling back, I found that video. The name of it was The Myth of the Genius Programmer. Okay. I don't know. There actually was an article, The Myth of the Myth of the 10X Developer, which we talked about on the Delivered Practices episode. Yep.

So skills are different things so um skills really i should probably add the linkedin portal site stuff down in the skills section i'll move that but if that's something measurable i can do uh level four problems javascript time yourself see how many you do in 20 minutes or whatever you know that that'll give you something you can plot which is nice but it doesn't really give you any sort of relative like you know you can't really take that and say like well how well, how'd you do? You know, it's kind of awkward lunchtime conversation because, like, someone's going to be higher than the other, right? But as far as those soft skills, you know, finding a friend and asking for specific feedback is something that I kind of found in those books I read to be really important.

So, you know, I think it's good to be able to say like, hey, Outlaw, you've seen my code. What could I be better at? Don't tell me on the air. I don't want to hear it. But I think that would have been a really smart approach for us to take. I didn't take it though. And I wanted to mention

that it's never been easier. We've got all these collaboration tools. It's kind of funny too. I had all this stuff in notes. and I wanted to mention that it's never been easier. Like we've got all these collaboration tools, you know, like the, it's kind of funny to be like, I had all this stuff like in notes. So like I knew like the textbook answers, but I thought it was so funny to me that like none of these were kind of intuitive to me until I kind of read over them and I was like, Oh yeah,

this is how I should do it. This is how I should do it. Is that how you guys are feeling about it? I don't know. I don't know. We'll probably see when we get into them a little bit but i will agree that everything always seems 2020 in hindsight right yeah and the last one i got here is the um the worst case scenario basically assessing yourself and that's if you could kind of like come up with like a list of pros and cons here and basically say am i good

at this bad at this you know kind of come up with some sort of scoring system for yourself. And this is totally what I did, even though I've got it as the worst case scenario. You got to be aware of the Dunning-Kruger effect. That's the one where it's like when you don't know something very well, like you tend to like overstate how good you are. And then once you get really good at something, you tend to under.

So that's why assessing yourself is tough. Yeah. That there've been, there've been podcast episodes on that alone and, and how, you know, people will rate themselves super high when they don't know what they don't know.

And then when they realize the breadth of what they really don't know, then it's like, Oh yeah, I'm a three. Yeah. So, yeah. So really don't know, then it's like, oh, yeah, I'm a three. Yeah. Yeah. So that's the thing, like trying to be honest with yourself, right? And it's so hard because it's so big, right?

Like we live in a sea that is just ginormous. Yeah. And I feel like I live in a sea as an average. Nothing wrong with that. You're passing. For all you in school out there, disregard what I just said. For all this dang time I put into it, you think I'd be flying high, right? Right.

So you're going to kick us off with the dev weaknesses, right? Yeah. So now we're getting into the meat of things. We each pick two weaknesses and one strength. We're going to go round-robin style, starting with the weaknesses. I made a mistake of putting myself first, so I've been talking a lot. All right. We're doing it in jam order, just so that we keep these things straight here.

For me, my first one, I've got modern UX development, which I mean JavaScript frameworks, things like Angular, also just things like general good design sense and kind of thinking like a user. Would you guys agree with that? No, I mean, I've seen what you do. I don't think so. I mean, I've seen the UIs that you put together now. And this is, this is actually where it was hard to pick weaknesses because you could either get super broad, like you just said, UI frameworks. Like, oh, man, seriously? React, Angular, Vue. And we're just talking about web stuff.

Then if you want to get into things like WPF or Swing in Java go, you can go so wide with the UI thing that it's like, wow, that's hard. So are you talking about just not knowing the frameworks? Are you talking about actually how, how to design a good UI that is usable by an end customer? I feel like if lightning strike me right now, and I just had like the best idea in the world for an app, I wouldn't know where to start. Right? Like as for like the full picture kind of like user focused, like, you know, if it comes to like writing web services, like I've got my preferences. You know, like I know what I like to do.

It comes to database tables when it comes to, you know, C sharp architecture kind of organization. Like I feel comfortable with that stuff. If I had to come up with like a user facing like mobile app or website or something like all of a sudden it's like, Oh crap. Um, let me Google react versus angular. You know, I feel like I'm at like step one of this really big and complicated field. Well, wait a minute. Wait, wait, wait, wait. Cause it sounds like on the one hand, it sounds like you're talking about information architecture. And then on the other hand, you jump into a framework and it's like, wait a minute, those two things don't have anything to do with each other. Right.

Like knowing what components, what information should be present to the user at what time and where to put it and how to emphasize it is not the same thing as choosing a framework. Obviously choosing React. Right. Yeah, that's kind of what I'm getting at because if you're talking about what he just said, how would I set this up so that not throw away the framework, but what would this screen look like so that a user could use this application in a useful way? That's totally different than should I pick Angular or should I pick React? And there are degrees for that.

Yeah, exactly. So I just want to kind of focus in on what you're saying, your weaknesses. It sounds like your weaknesses, you don't have experience with every single UI framework on the planet. So it's hard for you to pick which one to use. Yeah. Like when I say this, like I've done, I've made like tons of websites, right? Like I've launched them. I've sold them.

Hey, I've done all sorts of stuff, right? Like I've launched them, I've sold them. Hey, I've done all sorts of stuff, but I just never really felt comfortable with it. Like, so even to this day, like when it comes time to like, hey, let me make a website. Like I always feel like I'm at, you know, like step one. So like, even now, like if you're like, hey, Joe, go make a website. First thing I'm doing is going to like bootstrap,

you know, ThemeForest to like try and get like some sort of stepping stone to kind of start on. Because I feel like starting from scratch, like I know scratch, I know HTML. I could type it. But as for what to do, what kind of patterns are good, what websites look like now, what things I like in a website, how I would build those things, what kind of JavaScript behaviors are in fashion and make sense for modern apps, I feel like I'm stuck 10 years ago. This is where I would flip it on its head though. So you're calling that out as a weakness because you don't have experience in all those things. And I'll call that a strength because you are aware that things have changed and that you need to go look and see what it is that you should be

checking out. Like, you know, about PWAs, you know, about theme forest, you know about PWAs, you know about theme forest, you know about these things that can give you that step up, right? That ability to leap ahead of where you'd be if you started from scratch. And that's, I mean, I know that's sort of a cop out and that might be kind of corny, but I honestly think that that's the kind of thing that comes with the experience, right? Like all three of us here would have that because we'd look at it and go, wait a second, you know, the landscape's constantly changing. What I did five years ago is not the same thing that I need to do today. And I think, I think that only comes with the experience. And so while yes, it's a weakness because you don't know them all. It's also a strength because you are aware of it. It's that whole, you know, what you don't know thing, right?

Or you don't know what you don't know. I suppose so. I suppose so. I'll take it. I whole, you know, what you don't know thing, right? Or you don't know what you don't know. I suppose so. I suppose so. I'll take it. I mean, Hey, you know, keep going. You know, what else am I good at? But no problem. So I'll take that. But for now I want to go on to you. Like what did you come up with for a weakness there, Alan? All right. So I kind of had to tack another one on here at the last minute because I realized that we went specifically for dev weaknesses. I'm going to throw in the first one that I did and kind of a toss away. One thing

that I struggle with the most is time boxing as a manager slash developer slash, you know, architect or whatever. The biggest problem I have is, and this isn't development related, so I don't want to spend too much time on it, but it's really tough when you're a manager and you have guys that have just great ideas all the time, right? And the problem that you run into is if you have a 30-minute box for a particular meeting and you get into a really good conversation about the direction something should go or why haven't we looked at this or here's another solution that might be better. I have a really hard time cutting those conversations off because I don't like killing creativity. I think some of the beauty and some of the fun of being a developer is the magic

that comes with it, right? And it's the magic that only happens when you're allowed to have that creativity bug in your head, right? And you're allowed to get it out in the open and it spreads. It's contagious, right? As more people start thinking about it, then they're mentally building on to that, right? Like they're creating those building blocks. On the flip side, it's really hard because it's so easy for that time to just disappear throughout the day, right? Like they're creating those building blocks on the flip side. It's really hard because it's so easy for that time to just disappear throughout the day, right? I mean, you look up,

you've been in meetings for four hours and you were only scheduled for an hour and a half. And it's like, man, that's, Oh, I don't, I, and I'm terrible at it. I, because I really don't like killing ideas. And then on the flip side, I just don't know what to do about it. Being completely honest, basically what ends up happening is I end up just working more hours in the day because I feel like I didn't get anything done in the earlier times. I don't know if you guys want to say anything about that, but that is one of the struggles I have that's not necessarily dev-related, but just as a person in development. If you become somebody that people rely on, this will happen to you more and more and more throughout your career. What do you think about that, Outlaw?

Yeah, I mean, I understand. It's basically like time management is kind of what we're talking about. And I've definitely known some people who, like, I kind of want to phrase it as they respect their time highly. And so if you get into a conversation with them that isn't what they want to say, then they're like, nope, I'm shutting you down. Schedule a different meeting for that because I only allowed for X amount of time to talk to you about X. And we need to stay on topic, right? And so I'm definitely bad, though,

about the wandering conversations. If someone throws an idea out there, I'll start pursuing that idea with them and let's see where it goes, right? So I'm definitely bad about it. Probably something I should try to get better at as well, I guess. That's the fellow that owns the time boxing. I was like, oh, crap.

Yeah, me too. It's hard. I mean, it really is. And I get it, right? Like there are times that I will say I have 30 minutes. I have a drop dead. We get out what we need to get out at the beginning. If we want to use the rest of time, fine.

Otherwise, moving on. But it is hard, and it's a struggle as somebody that believes that the, the main reason you end up with really good people is because those people are allowed to think and create solutions that they're proud of that, that carry things further. Right? So now moving on from that one, that wait, Joe, did you have any thoughts on it before, before I switched to the real one? It reminded me of some of the stuff I'd read about the differences between leadership and management, where leadership is all about thinking big and thinking about where to go, and management is about how to get there, and it's more tactical rather than strategic. And so I thought it was really interesting, and just like you said for

mine, it was recognizing the balance between tactical and strategy and big thinking and also focusing on current deadlines. It sounds like a strength to even recognize that. It's hard. It feels like a weakness because I feel like I'm constantly fighting that one and I know it internally, but I just, I don't know. I struggle with it. So onto the other one, and this one should be fairly quick because we've already done an episode on it. Targeted learning. I'm terrible at it. I'm absolutely terrible at targeted learning. So I'll set out to create a podcast app. And as I get into it, I'm like, oh, well, there's this identity framework in C sharp. I need to know how that works. You get in there and you're like, well, wait a second. If I use that, then I have set up an identity server. And if I do that, then I can tie it into this

thing over here. And wait a second, there's this Azure key vault, and I really don't want to store my security credentials in my application. So I need to learn how to use this, but wait a second, I can't do that because I need to then go figure out how identity management works in Azure. And there might be more than one of me that use this thing at the same time tonight while I'm developing it, so I need to make sure it can scale to a billion users. It's concurrent. I mean, so I am absolutely terrible at targeted learning. And I think the episode that we did where Joe was

convincing us that we were learning wrong was a very valid point because targeted learning should be what is your goal at the end of this, right? Like, are you really trying to sharpen a skill or create a skill versus I'm just going to go tinker because that's typically what I end up doing. And then I never finish it because I've gone down 80 rabbit holes. I'm at the center of the earth at this point, and I'll never dig my way back out. You found Alice. I did. I did.

It's like they see you're changing the light bulb. You watch, like, what's going on? You're like, well, I had to change the light bulb so I could see the keyboard, so I could replace the key, so I could type in the password, so I could see the keyboard so I could replace the key so I could type in the password so I could, you know. There's my wife. My wife tells me about this all the time. Like, I'll be out, I don't know, cleaning up the garage and I'll see something. I'm like, I didn't even remember I had this.

I got to go use it, right? So it's like, man, that saw's been hidden forever. Let's turn that thing on and see what it does. So, you know, I'm just that guy. Like I have a real hard time. If I don't have an end goal in mind, then like a very strict one, then I, man, I'm just bouncing all over the place. Does it have anything to do with like your excitement about the goal itself? Like, are you more likely to wonder when it's a, an appetizing goal? Oh no, I don't think so. I actually don't believe it has anything to do with what the finish line might be. So there's a difference,

right? Like when I have something that I have to get done, I'm very focused on getting it done. And, and I'm usually pretty pragmatic. Like I don't write garbage code, but I don't write the most elegant code in the world. I'll, I'll walk that line. Right. And I'll get to the finish line. But if it's a learning exploration, it doesn't matter how exciting it is at the end. It could be the most glorious thing ever. But if I got this shiny little thing that swam by me on the side, I'm over there. Like that's funny's to it oh god what a funny way to put that so what about you you struggle with that kind of stuff or um yeah i mean i think i think sometimes it's just the mechanics of the things though that i guess is kind of what you're

describing it's like you know sometimes you get lost in just the mechanics of it. I don't know. Maybe you want to play around with React. We can take this even much simpler. You want to play around with React and pick up React. You're like, well, I need to make this thing look good. So, oh, hey, the latest version of Bootstrap. What about they change?

Oh, so now you start going down that rabbit hole. And then it's like, you know, well, you really only wanted to focus on React. But now that you've gotten into it, you also picked up, you know, latest version of Bootstrap as well. So, you know, yeah, I think we all fall into that. And I will say, I'll flip this one too. I think it's a big weakness. Like not targeted learning is a weakness, but it's also one of the reasons why I have the breadth of knowledge and awareness of technologies that I do, because I'm just I'm naturally curious and I have a hard time not crawling my way through every little thing that shows up so you know it doesn't allow me to really sharpen a particular skill that i go after but it does open up my world of oh this is interesting i saw this right so yeah yeah the term yak shaving dates back to ren and stimpy yak shaving yeah that's the like the the word for like kind of like finding one more thing to do before you can do the thing like they've seen the yak and i loved ridden stupid yeah am i the only one though that

when alan was talking about time boxing kind of thought that we were going to go to pomodoros oh man i'm terrible at those two those drive me crazy yeah i should probably try that were you doing pomodoros there for a while? I'll forget. I was, yeah. I mean, it was kind of annoying because I – well, not because they were annoying, but just I was trying to find like a good app for it. And, you know, feel free to write in with some suggestions. But, yeah, because I really wanted one that like would sync to the watch,

and then that way I could just like that like would sync to the watch. And then that way I could just like stop, start and stop them on the watch. I didn't want to like have to use, bother touching the phone or anything for it. Uh, cause then that would be like a distraction right there. Like, Oh, there's an email or,

you know, Ooh, I want to play a game or something. Right. Something would come up. Yeah. Developer's life is full of distractions. Right.

All right. So it's your turn. What did you come up with on Google? Yeah, I totally... Different. So, well, maybe different. Let's see. So, because I couldn't find a way to, like...

What I wanted to find... Apparently, Joe found some tests where he could have gone to and tested himself on something. And that would, that's probably what I was looking for. And somehow that never came back in my searches. So instead I just kind of took more of like, I guess maybe more of a pragmatic approach. Like what's something that I want to be better at that I'm, that I don't feel like I'm good at today. Um, and so number one on my list was, I really want to be better at Python. Like I want to be as I want to be like, if, if Python was my daily driving language, like that, that I want to be there. Right. But it's not my daily driver. And so that's why, like,

I get kind of frustrated with it, you know, where, you know, where, when I am working in Python, then I'm like, wait a minute, I want to do, I can't even think of a good example, but, you know, I want to split this matrix up and, you know, get rid of these other columns out of it or something like that. And it's like, oh, wait, I can't remember. How do I do that? And then, because that's the thing that I hate about some of these things that we pick up, some skills that we learn and we pick up is because, you know, as we discussed before, if you don't regularly practice that, then you lose that muscle memory. And that's where, that's my pain with Python is that because it's not something I use on a daily basis, I'd like to, but I don't. And I think it's like

from everything that I read, it's definitely one of the top growing very important languages to be on top of. And it's like, I kind of want to know something about this thing. Right? So is that a weakness to you because of the discipline you want to go into more or just because it's a popular language that you feel like you're missing out on?

Definitely. The discipline part is a big part of it, but just because, um, it's not necessarily that it's the second one about because it is going to be a big thing. I think that's why it's important, though. But I just feel like I still stumble on some basic things that like in a C Sharp or a JavaScript, for example, that I don't struggle with as much. Does that make sense?

Yep. So it sounds like it frustrates you to do this thing that you want to be totally not frustrating and easy. Yes. So, so this weakness grew out of a frustration as well. I'm pretty sure that's what all these are going to end up being is things that we feel like should be easy to us that just don't,

that don't feel that way. I might surprise you. Oh, okay, cool. I'm looking forward to it. All right. Yeah.

Do you want to go next? No, I'll share something else after, uh, after my next one. Cool. I'll tease it. How's that?

All right. All right. Uh, Alan was targeted learning part of your kind of first one. Yeah, it was tease it. How's that? Alright. Alan, was targeted learning part of your first one? Yeah, it was. That's what I was saying. The time boxing was really more just... It wasn't dev related. It was more personal productivity management,

time management. I don't know. That's why I just wanted to put it in that one. Yeah. So for my next one, a couple years ago when I was doing some job uh some job kind of research i was like you know i'm i want to leave the job i'm at no doubt about it what i want to go into next and i kind of look at different like opportunities for like kind of employment like consulting versus whatever big company small company and then i also did this big venn venn

diagram where i was like there's security there's mobile there's security, there's mobile, there's machine learning, there's e-commerce. And I kind of put like the big categories. Um, there's, uh, yeah, I don't remember what all of a sudden, I think I ended up with like seven circles and I kind of had like some overlapping and stuff and it was real cute. I should have saved it. And I, you know, when I think about now, like the circles that like, you know, five, six years later, whatever, however long it's been, there's circles that I've definitely spent more time in and there's ones that have totally dropped off my radar. And so the modern UI development is kind of one of those circles

where like I felt like I just kind of like dropped out of the race on. Like I haven't built an Angular 1, 2, or 4 app. You know, I just kind of like jumped off that train and now I don't know how to get back on it. But the second week is I kind of felt like I totally just missed the train on and now it feels like it'd be really hard to get on is machine learning. I feel like it's this big, huge field and it seems like more and more companies are doing really cool stuff that you can't do any other ways.

I can't, whatever little app I do with like, you know, SQL server and whatever is not going to be able to compete with the sophisticated algorithm that's just has the same data. But these people have this better and stronger vocabulary with and know how to solve problems with the, I just don't even know how to approach it. Like I'm not even aware that there is a problem. So I've got a lot of anxiety about kind of missing out on the whole machine learning trend. That's interesting. I mean, Outlaw's probably got more insight on that as he's looked into it a little bit deeper,

but that's where I feel like certain things like Azure services and even AWS, right, like they make some of that stuff almost plug-and-playable to where you can play with things and not have to have a ton of knowledge, right? There's data scientists doing a lot of that stuff for you. And you can leverage the tools that people have built and play with them. I think you've even left links on some of our show notes on like the Azure Learning Labs and all that kind of stuff.

Like, I mean, there's just – so that's – I mean, I get it, though. That's a big one. That's all you hear about anymore is machine learning this and machine learning that. But I get it, though. That's a big one. That's all you hear about anymore is machine learning this and machine learning that. But I get it, though. It's a daunting subject, right? And there's different approaches because I've thought about this topic before because there's the people who are trying to come up with the new algorithms. And then there are people that are just trying to like use the existing stuff. So, you know, when you're talking about just using the tools, like

you're not trying to create a new and better algorithm to, to learn something. You're just trying to use what's already there, but you still have to have a pretty good understanding of how to use it, what it means, what kind of errors to look for, what kind of results to look for, and how to tweak those. So there's still a lot of detail there. Yeah. Yeah, and I feel like for you know basically step zero of you know knowing like thing these things exist and and that's it like for me to get kind of up to speed to where i could feel like i could solve like real world like business problems with machine learning like i'm looking at a huge time investment at this point and knowing how you know me and how

i operate it's just not gonna happen i mean i think it's very possible though. I don't, I don't think it's impossible for you to pick it up at all. No, no, no. But I don't think it, I based in relative to all the, all the things that I want to do with my free time, like outside of work, this doesn't rank high enough for me to really invest time in. So, so it's a weakness because you feel like it's sort of the, the trains left the station and you're standing there looking at it, right? Yeah. But I guess on the flip side of that, like you said, you know, you look at what you have available time wise and what interests you. And it sounds like it's something that interests you, but it's not high enough to really register in terms of dedicating the time, right? Yeah, I've elected to have this chink in my armor.

I'd rather have my armor stronger in other areas and just let this one go. Yeah, and that one's fair. I mean, there's a lot of those things that we all have to pick and choose, right? I mean, we can't learn it all. There's too much. There's only so much time in the day. Right. And I mean, if you take it a step further, right? Like, so machine learning,

I would almost argue is, is sort of, uh, I don't, I don't want to say dying cause that's a terrible term, but like AI is a new huge focus on things, right? The, the, the learning aspect of things, not just finding models and patterns and that kind of stuff is it's the evolving that kind of thing. So, I mean, there's always going to be bigger and better. That's going to be a tough one.

The way I thought about weaknesses, now that I say it and we talked about it, I think when I said strengths and weaknesses, it seems like I should have come up with things like estimating or time boxing or code organization. Those seem like the answers I should have come up with. But for whatever reason, when I kept thinking about this, I kept coming down to thinking, if I were to assess myself on kind of like an A through F score for, say, functional programming, D minus. Machine learning, straight up F. Like the UA, UX, I feel that's more like a C minus there because i feel like i can't pick up with it but like i feel like i'm not as far behind because i've got a solid understanding of html and vanilla javascript and maybe even css you know like those individual skills i'm higher on just overall

picture i don't feel like i'm where i should be given my years of experience especially doing websites i feel like i should be at a plus and I'm far from that. But machine learning is one where I'm just like, I'm an F, and I'm staying F. And it bugs you, though, right? It's something that bugs you. You want to have that knowledge, and you want to know more about it, but you just don't want to dedicate the time to it.

Yeah, if I go to lunch with some people, and they're talking about the mobile dev that they're doing, I can at least say, oh, I've got Android Studio. I've built two crappy apps and put it on my phone. I've at least got some sort of understanding of what's going on. I know about Kotlin. I know what's going on in that world. Machine learning, people are talking about two different classification algorithms

or something like, I don't even know if classification algorithms are a thing. All right, so Alan Alan what was your second so mine was almost what we've been covering or what we started to cover in the imposter's uh handbook handbook so mine is and this stems from being an employee at Amazon and seeing how their interview process is. And it's really frustrating slash annoying slash a weakness of mine. Just when you start talking about almost like theoretical type things from school, when you were in school, that's what you did, right? Like you'd learn this stuff and those were the practice things you did. But like when you go into an interview for like an Amazon or something and they start talking

about complex, like tree searches and in different types of sorts and all that kind of stuff, like that's a gap. And it's a gap because I haven't done that stuff in so long that I've forgotten what I've forgotten, right? Like I don't even remember any of it anymore. And, and that's a weakness. And it frustrates me. Like when we start talking about big O notation, or we talk about, you know, more efficient algorithms or a way to do a tree sort or a tree search or something like that. Like it's one of those things that is a real mental exercise, right? And, and it's a weakness. Like if I were to go into an interview today and they said, you know, what's the best way I would,

I would have some data structures in my mind that I would use to accomplish a task, but, but because I'm not in that, um, uh, learning mode of like the education type side of things, the, the more theoretical, the more the, uh, I can't think of the word right now, but because I'm more academic, that's what I was looking for because I'm not in the academic side of the world. I, I would have to really sit down and go through something like the, um, Coding Interview book and really work through it from cover to cover to get my mind back in that mode. Or I'd have to go. As a matter of fact, I have a list of these various different things that he found frustrating in interviews because they were either gaps in his knowledge or whatever. And they were super academic, a lot of them.

So that's a weakness of mine. It's just being able to quickly look at something and say, you know, that's a log, uh, in log and, you know, big O notation or something like that. And it's a frustration, right? Because it's one of those things that I knew at one time and I just, I don't use it in day to day. And so, so I would have to go back and reinforce all that. Yeah. We didn't mention before, but we actually got some really excellent feedback last episode.

And I kind of don't want to touch it because I feel like it's really hard to talk about. And some of the points that people were making in the comment section were really kind of poignant. And I just don't have the background to really discuss them intelligently. However, there are people in the comments, notably the author of the book, the, the monster handbook, Rob Connery,

who really had some, some great insight and had some things to say about that. So if you were interested in that episode, I just wanted to mention, sorry to sidetrack, but I thought that no, definitely fit in there. Yeah,

definitely. And I would say, go look at episode 81 comments because there was some great stuff. And this is, this is where academia plays a huge role, right? Like when you start talking about the theories and all that stuff behind it, like it's a big shift from everyday real world development problems to theory, right? And to conceptual things that you don't necessarily use in day-to-day work. And so it's kind of frustrating that you've got, you know,

all these years of experience. And if somebody comes to me and says, Hey, we need to build this out. I can tell you exactly it off the top of my head, what I think would work out really well. But, but then you start talking about how would you do this binary search thing? It's like, Oh man, let me whiteboard this, right? This is going to take me a little while and it's going to hurt my brain and I'm going to need to take a nap, right? It's just, I don't know. Those kind of things still frustrate me a little bit.

Yeah. I hear you. Outlaw, what do you think? So it's kind of interesting to hear Alan's take on this. I took the approach of algorithms. So kind of a long line, like if I were to like blur what both of you two said, that's kind of where that one is because it was kind of like, well, you know, it's been a long time. You know, if, if, if you had to come up with the, you know, a Bellman Ford algorithm off the top of your head and be like, ah, I mean,

I've definitely read about it recently. I don't remember. Right. Like, you know, those are the kind of things where it's like, just, you know, I don't know, is it a muscle memory that I need? So maybe kind of along the lines of what Joe was saying with machine learning, like, uh, you know, I don't know, is it a muscle memory that I need? So maybe kind of along the lines of what Joe was saying with machine learning, like, uh, you know, I'm probably not going to bother with it, but it's one of those things where I kind of feel guilty. Like, I should probably know that algorithm like off the top of my head. Right. Or, you know, other algorithms, like just like, because that way you reckon that way, this is, this is where the guilt comes in is because like by knowing them off the top of your head, then you know when you need them and you can recognize when you should be using them. Because otherwise, if you don't, then you don't know what you don't know and then you might start going down a bad path and create a really bad solution to a problem where there's a well-known trusted algorithm for it.

It's just like design patterns. So those so those, yeah, exactly. Exactly. So, um, yeah, I actually, we've talked about this guy before back in way back episode 48, there is a guy out there named John Washam. I hope I'm pronouncing that correctly. And I'll have a link to it. But he basically created a – he basically set out that, hey, I want to get hired at Google as an engineer. I remember that. Right?

And so he set out this outline for himself and spent like the next eight months working on it, right? I remember that. in there, right? And, you know, a lot of it on like all kinds of different books, you know, if you wanted to study on data structures, if you want to study on algorithms, you know, here's books on C sharp to study there. Here's here they are in Python. Here they are in Java, whatever, right? Just a wealth of information in this, this GitHub this GitHub repo, uh, that I'll include a link to, but, um, it also just totally, I want to come back to some of this, but one of the things, one of the resources he has out there is a flashcards that he made for himself as a way to study these things. And man, I went through them and I was like, oh man, I'm a moron,

like trying to go through some of these. I'm going to hit you guys up with some questions later, but it was, yeah, it was awesome. But yeah, so that was another one where I was like, well, if I had to think of something, since I can't find like a way to like truly test this, you know, find like, you know, because maybe there's something more basic. Then that's something I feel like there's probably a bunch of algorithms that I don't know off the top of my head anymore that I should probably go back and practice and regain that muscle memory. So we almost had the same last weakness there. Yeah, I was like, dang it, Alan cheated. He picked mine.

In fairness, so everybody knows, none of us have put notes in this one because we didn't want each other to know what our weaknesses were. Oh, but this was another thing too, though. And this kind of goes along the same lines with this because I thought about it from another point of view of

like, well, I don't know that it's necessarily a developer weakness maybe, but I guess it kind of is. Interviews, right? Yeah, I think that's totally legit. The technical interview as a weakness. And again, John's repo here is all about studying for the technical interview for Google, right? So I wasn't sure how that one got classified.

That's why I didn't end up going with it because I was kind of like, well, that's kind of maybe a soft skill, I guess. No, it's both. And to be fair, I think that what we just said with our algorithms, academia type stuff, that is a huge part of why they're important is for the interview, especially if you're interviewing with a Microsoft, a Google, an Amazon, an Oracle, any of the big software companies out there, you got to have those, right? And then there is the soft skills side of things. And that's, you know, we've talked about it before and we'll reiterate it here. If you're going for an interview with a company, it doesn't matter what company is, doesn't matter whether it's one of the big software companies or

not. If you don't do your homework, like you would for a test beforehand then you're shooting yourself in the foot right you should at least polish up on things so that when you go in there you have a confidence there's some muscle memory to whatever you're doing and it'll ease some of the tension the last thing you want to do is go and be overconfident and look like a fool when you walk out yeah i mean this totally made me fall down a rabbit hole though, because, um, I started approaching this topic as I was trying to like, again, I was coming at it from the point of view of like, well, how can I like truly assess this? Right. So that that's where I spent like a good bulk of my time trying to prepare for this thing. But then when I remembered about this guy's repo, I was like, oh, yeah, I wonder, you know, like, what would it take?

Like, what does Google, what would a Google interview be like, right? And so, you know, I found some resources. I'll include some links to these, but, you know, how Google hires, what that process is like. And Google even has their guide, their developer guide, to grow your technical skills with Google. That's awesome. And it was like a whole other set of like, we've talked about other learning resources, like Pluralsight countless times, right?

I think lynda.com has come up. Now LinkedIn Learning. Yeah. So Google has their own set of learning that you could do. And you can start with like, hey, I want the foundations that I need to start with, versus like, oh, I'm already an experienced, let's start with advanced learning, versus, oh, I'm already, I already am experienced. Like, let's start with advanced learning versus, hey, I'm, I'm a teacher. What do I need to know in order to be able to teach somebody? Right. Like, so, so it was a pretty neat little resource that they had there. But, um, one thing that though was that I read multiple times about the Google

interview specifically was that the, if anyone is listening to this, wants to hire a Google, that it was kind of like, don't put it off. Like it's better to go after it sooner rather than later. Because like, like even John in one of his write-ups was saying like, Hey, you know, I spent these eight months trying to study for this thing, right? And that was eight months. Maybe I could have put towards putting an app in the App Store, working on whatever other skills he might have wanted to work on, right? So even though he left the thing kind of thinking like, well, you know, maybe I spent my time wisely or maybe I could have spent it better. And, uh, one of the thoughts was that specifically at

Google, the longer, the more experience you have, the longer you've been developer, the more they expect, the harder it is, the harder the interview would be. And so one of the articles I was reading was like, hey, if you are just out of school, for example, and Google was like your target, it would be better to go after that as soon as possible rather than saying, I'm going to wait a year or two and get some experience and then come back to Google because then that interview is going to be harder. I guess how you do it once you get kind of a sense of what you need, and you might get the job the first time.

So, you know, spend one month, give it a shot. And then if that doesn't go through, you got seven more months to try again. Yeah, but it is totally true. If you're coming into one of those big companies as an intern or a, you know, somebody fresh out of school, they'll bring you in because their hopes are if they see the spark in you, then they're going to train you up and you're going to be a rock star in their team that they got in early on. So you do have a better opportunity getting into companies early

on, especially big companies that hire a lot of engineers, right? Like going to a small company that, that needs to put out a product fast, maybe not. But if we're talking to one of the big ones out there, yeah, man, the earlier the better. All right. And I was kind of curious to see if you guys had any sort of like honorable mentions, like things you thought about, but just we didn't really talk about or touch on. I see you got some there that are pretty good. Yeah, I got estimated just regular um not even so much code organization although i could definitely use a serious dose of that too but just organization like i feel like

i'm always trying different techniques for organization and i'm always like i think it's just not like a natural strength of mine maybe i need to keep working on but like i'm always trying bullet journaling or to do asks or different kinds of things for staying on top of the ball and like for the most part like those things work for me, but I just never really feel comfortable. I always just feel like I'm on the verge of dropping some ball I don't want to drop. I'd rather make a deliberate decision than have something just slip off my radar

by accident. The estimating, I think, is impossible. It's so hard. It really is. The organization, I'll just say Inbox 1000. All you people with this Inbox zero garbage, get out of here. Your inbox is a search box. That's all you need to know.

Inbox infinite. At the end of the day, I'm happy with results, the way I track tasks and stuff for the most part. I feel like I check them off. Not that many things slip through the cracks. It happens sometimes. So overall, I'm happy with the outcome. It's just for me, I feel like I'm constantly thinking about organizing. I'm frequently kind of slapping myself on the wrist like, did you write that down first?

I feel like I'm constantly struggling to keep organized. So it's like I'm running on the hamster wheel. Yeah, I get that. Especially when you're actually – the organization personal isn't that hard. The organizing of multiple people is really hard, right? Like when you're trying like first thing, nine o'clock in the morning, whatever. And someone's got, uh, you know, there's like two emails from the night before. So I'm like, okay, I add that to the to-do list. And then of course the third is like the one thing like I really want to focus on. And as I'm talking to one person, like someone else kind of pings. And so I add that to the list.

And so, and I feel like my overall, my system's working. I just hate that. I'm constantly like, oh yeah, the list. Oh yeah, the list. It never feels natural to me. I don't know if you guys ever felt that way or how you guys keep track of that stuff. I don't keep a

list. I mean, in my head. Yeah, I feel like everyone else can just keep it in their head and I constantly have to be diligently writing stuff down and X-ing them out. The only thing that I typically put in a list, I will flag things in my email for a followup.

If it's something that has to be done by next week or something, right? Like, and then that way I'll get the reminder and I'll look at it, you know, every day to make sure, okay, have I,

have I followed up on this? But if it's just the daily stuff, usually I'm pretty decent at managing that stuff internally. Um, because yeah, managing lists, they would drive me crazy. See, I hate that you can do that without a list. I, and to be fair, I'm pretty good at it, but it's just like you said,

some things fall through, but I'm not convinced that they wouldn't have fallen through even on a regular list. Right. Because it's like you said, you get pulled in 80 different directions and it's like, ah, that, you know, I forget. So, um, yeah. Yeah. I, I definitely feel you on that estimating though. That is so hard. It's just like we ought to do an episode on it, except I really don't want to. No, I really don't. Because then we'd have to estimate what we're going to come up with on this. I really wish that we wouldn't even call them estimates, just guesstimates.

They really are. And that's the frustrating thing, right? Like it dinged if you do, dinged if you don't, right? You pick one that you think is a fair estimate, and then you're going to get questioned about it like, oh, that's too long, or wait, do you really think it's only that long? It's like, man, really? Come on. Leave me alone. If we just caught it guess, then no one would second guess it.

Well, maybe. Yeah, maybe. I got two kids that would probably argue it oh so all right well uh you want to pick up pick up with the strengths after the uh call to action yes let's do that so uh with that guys we appreciate it thank you for the reviews you've left we got some really good ones this last go around, uh, some great suggestions as well that we'll, we'll try and squeak into a show here in the near future. So thank you for taking the time and going up and, and leaving us some kind words and for clicking those stars, whether it be an iTunes or stitcher. And if you haven't done so, and you like us a little bit and you would like to go up and put a smile on our face, you can do so by heading to coding blocks.net slash review and click on one of those things and put a smile on our face, you can do so by heading to codingblocks.net slash review

and click on one of those things over there and go leave us some kind words. We would super appreciate it. All right. And with that, let's get ready to survey! And thank you, Mike, from Slack for recommending that. That's been a fun little way to introduce this. It is. So, last episode we asked,

how important is it that developers have an understanding of computer science-y topics? Your choices are, uh, no. Or, uh, yeah, I guess it's good. Or, it's not mission critical, but I prefer working with people who know their O from their theta. Or, lastly, super important, and I can prove it mathematically if you accept my base case. So let's pick Alan, you go first. You know what? This one's hard for me. I think

and I'm basing this only on our Slack group. I think that we're going to see people that are passionate about this and they're going to say it's not mission critical, but I prefer working with people who know their O from their theta. And I don't think this is going to be a runaway. So let's go with 27%. Okay.

All right. Well, I guess then I'm going to go with, uh, yeah, I guess it's good at 27 so both of you 27 joe is uh yeah i guess it's good and alan is it's not mission critical critical but i prefer working with people who know their o from their theta yep one of us is going to win. And that would be Joe.

It's not you. Oh, really? Yeah, no, it was Alan. But you're both like... Way under? You both picked the top choices, but you're both way under as well. Okay. What did this end up being?

I'm going to say 50. 48% of the vote. Okay. Was it's not mission critical. And then, uh, 40 was, I guess it's good. That's interesting. Yeah. I mean, the thing is, is when you run into people, it, it, I think that it all boils down to when somebody sees code that is so obvious that people didn't have a base understanding of what was going on, it really angers them. Right. And I, that's why I chose that one because I think that's where if there weren't those silly, just, um, I don't know, naive mistakes made, then I think that people wouldn't be as passionate about it. But when they see something, it's like, man, if you would have just been in a class, you know, naive mistakes made, then I think that people wouldn't be as passionate about it. But when they see something, it's like, man, if you would have just been in a class, you

know, then that would have been avoided. Right. So, yeah. That's interesting. At least we weren't super surprised. No. So, this episode, for this episode survey, we ask, do you regularly evaluate your weaknesses in an effort to strengthen them? And your choices are, oh my God, daily.

Or, I try to pick up a new skill or get better at an existing one every few months. Or, yeah, but realistically, probably only once or twice a year. Or, I learn what I want to learn when I want to learn it. Or, no, that's why I listen to you guys. And lastly, why? I already know everything I need to know. I dare someone to pick that one. I think Alan just voted for it. I don't know what you're talking about. Watch that one be the runaway winner.

Yeah, it might be. All right, so back into the topic. So we talked about our dev weaknesses. And so now I think we all had a tough time for this, except for maybe Alan talking about our development strengths. I don't know what you're talking about. And stick with the same format. Funnily enough, I think that relative to how much,

maybe how much time I put into it or keep on to it, I think I tend to actually do really well with algorithmic and despite the topic class, algorithmic and kind of academic-y type stuff. And I think that this is because I always had a chip on my shoulder about not graduating from college. And so, man, I banged my head against the Project Euler wall for so long to get to where I did in there. I've done a lot of code wars. I've done code fights. I've done a little bit of hacker rank. I've always kind of gone after these kind of problems. And so whenever I see like a binary T problem or something like, I feel like instantly like I want to know,

or if somebody I know goes on an interview, like I always want to hear what questions, you know, they were asked and like start thinking about it. There's a, there's a, a psych person I talked to Vaughn, if you're listening to that's been doing a bit of interviewing. And so he's been talking about that. We've been talking about their problems a little bit. And every time it says like,

it's a change problem where they give you the quantities. Like it doesn't matter that I'm, you know, at public shopping all of a sudden I'm like, hold on, you know, honey, take the cart. You know, I'm going to be in the bread aisle, like trying to figure out this problem. Like I just, you know, there's something I really like about those types of problems

and like recursion and pretty much the algorithmic side of things. We're like, if I hear a problem, I want to solve it. I want to solve it in a good performing time. I like that. I don't know why I kind of gravitate to it, but it's something that I've traditionally done well with.

That's awesome. And to be fair, you're only like a couple of classes away from graduating, right? Yeah, and it's all like science classes. But you got that math yeah yeah yeah you gotta have something that drives you but so much of it i think was those project oil air problems is this one of the words on brute forcing doesn't work because it takes too long so like if you try to do like a brute force solution to a problem like it might take you computer 24 hours to compute so like you don't have a choice, but to solve every problem in,

you know, close to optimal solution. So there were some times where like, even like the beginning problems, I first started, it's like problem number seven. I remember being just a nightmare, but I just kind of kept going with it.

And after a time, like now, whenever I go into an interview or someone tells me an interview problem, like so many times, like my mind immediately jumps back. I'm like, that sounds like number 33. So I feel like I cheated in a lot of ways because i've kind of put that time in and so many problems are similar to the problems that i've done that i've just kind of

built up that skill i think well you finished most of it right or if not all of it no no not at all no okay it's so much harder so like there's people out there that are laughing in their boots. I think I got to level two, which is actually level three, before they lost their database. I still have all my problems checked in, so I could go through and redo it again. But yeah, they start at level zero. So you start at nothing, and you go level O, level one, level two. Man, that's coolness.

It probably goes up to level six or something. So it's embarrassing to even say, like, I got to level two, but man, I worked hard to get there. Yeah. Yeah. I've done a few of them and I just ain't nobody got time for that. All right. So mine is somewhat along the same lines. It's not algorithms, but I think what I'm pretty good at is taking complex problems and breaking them down into workable solutions.

And I'm good at learning what I don't know in order to accomplish whatever that is. Like I think so. So I guess the way that I'd put that is. I have I have the ability to visualize something in terms of the pieces that make it work, right? And then on top of that, I'm pretty resourceful when it comes to if I don't know how to get something done, I know how to find out how to get it done so that I can either help do it myself or help somebody else put the pieces together. Resourcefulness. Yeah. I would say that's what it is like resourceful and learning how to make the solution

work. So that's, that's one of the things that, so it's problem solving, right? Like it's one of the reasons I like programming. I love problem solving. Uh, did you guys like growing up as a kid? Did you ever do those? Uh, they give you the grids that had people on the left and, and, you know, places on the top. And it's like, Hey, Sally visited this today. You know, what did, what did Jane not do? And it was like, Oh yeah. I mean, I would sit there for hours doing those. Right. Like that was just, that was fun to me. I love solving problems and it's just like a big puzzle for me and And I enjoy it. Like, Sally went to the high school. Joe bought the perfume. Right.

And Michael likes dogs. Yes, exactly. Now, which one of these did this? Yeah. So, yeah, that's mine. Yeah, I kind of had trouble with this part of it. Because it was like, well, how do you, but again, because I could never find the stupid assessment, it was like, well, I don't know what to say that my strength

is. So like, like how do you really come across with something that doesn't sound like overly cocky or anything? But I guess one thing that I thought was, well, if I were to take like an introspective look, like I think I'm pretty good at I were to take like an introspective look, like I think I'm pretty good at paying attention to detail. Oh God. Yes,

for sure. Yes. You asked me like, I feel a little reassured by those responses, by the way, before he goes further, there is nobody more detail oriented than outlaw. Like probably on the planet.

Like if there's 9 9999 permutations he's thought of them all i feel like you know like when um like sadly you know it's weird to bring up steve jobs death at this time but you remember like when it when he died and there was like all these stories that were coming out about, you know, like there were the autobiographies or biographies or whatever about him. And, you know, there were a lot of stories that were coming out about like how, uh, his father, uh, raised him to where it was like, well, you can't just make this side of the fence look pretty. You gotta make the side that we don't see also look pretty. Right. Like I could totally relate to his father. Right. Like that, that makes all the sense in the world to me. Like, Oh yeah, of course, you know, because if somebody comes up

on that side, you know, you still want to, you've got to represent, right. It's still got to look good. So yeah, I feel like I'm pretty good at like following a detail through a complicated system and, and paying attention to that. Yeah. I think we, you know, we talked about you like having our time come up with the strength. I just instantly was like, well, here's four. No problem. That was number one. It took me a quarter of a second to come up with like... I didn't even remember

you said that. Yeah. Ah, dang it. Come up with another one. And when we say detail-oriented, also like edge cases, right? He thinks about the things that nobody else thought about. Like it's, it is a strength.

It is, it's, uh, there's very few people that have that ability to think through a problem that thoroughly. And that's, I can't. Yeah.

It's, uh, it's, it's impressive. I don't got it. Well, I mean, part of my thinking on that though, as it relates to our career, though,

is that you know that I think there's like some kind of cliche saying or something like that where it's like, you know, 80% of it is easy. It's the 20%, that final 20% crossing that finish line. That's what we get paid to do. Yeah. The devil's in the details. Yeah. The devil's in the details. That's the part that what we get paid to do. Yeah, the devil's in the details. Yeah, the devil's in the details.

That's the part that we're getting paid to do. So that's kind of like why it's just kind of been beaten into my head. They're like, hey, pay attention to detail. Pay attention to detail. Because it's the details that matter. You remember that story from Van Halen where they were on a tour and they had this 100-page document? I'm sure you've heard it.

Yes. And one of the items in this 100 pages of stuff that they had to get ready for their arena shows was like no brown M&Ms. That's what it was. Yeah. And the deal was they would come in and if there were any brown M&Ms, it was kind of like a canary. Because they would say, oh, obviously you didn't read our contract. And we've got pyrotechnics. We've got lights, sounds, all this stuff that needs to be done meticulously and done correctly.

So, if you can't get the M&Ms right, how am I supposed to trust that you got the big stuff right? A little bit. meticulously and done correctly. If you can't get the M&Ms right, how am I supposed to trust that you got the big stuff right? Whenever someone mentions that story, I'm always like, I know somebody who would have got those M&Ms right. Dang straight. You put any kind of contract in front of me, my wife hates it because I've got to read the whole

thing. It doesn't matter. That's smart. I'm completely the opposite. My wife gets really mad at me. How about the guy that you want and don't want on your pull request? Yes, exactly. Exactly. That's funny. For the same reason.

Yeah. You know, I meant to ask, like I teased the flashcard things earlier and never did get to ask it. So this was one of the resources that John Washam, God, I hope I'm pronouncing that correctly. And if I'm not, I'm so sorry. Put out there though. And it was another repo that he links off of, but he had like the normal.

So you could basically what he did was he created this whole site or app and that you could spin up you it's even Dockerized. You could just spin it up. And, uh, it was a web app that you could use to test yourself, you know, flashcards. You can create your own, but he includes two different databases of cards that he already has loaded up if you wanted to see like what he was testing himself with and um i didn't even load up the extreme one because just the normal one made me feel dumb like trying to trying to go through some of these so uh let's see let's do this on air and put us all on the spot. I love this. Yeah. Well,

let's make sure I'm not the only dumb one among us. I need to feel better about myself. Oh, here we go. What is the log of N factorial? What? Right? Wait,

hold on. Log of N factorial. Would it be zero? N times the log of N. would it be just be zero n times the log of n oh of course n log n yeah you know if it's like i guessed that like i like that's something i knew at one point like how to figure that out but not anymore man right yeah uh how about how about just a simple yes or no? So you had a 50-50 chance. Can you multiply a 3x2 and a 2x6 matrix? Why not? Why not? No. Joe had it.

Yeah, I mean – The answer wasn't quite why not, but it was a yes. Yeah, it was a yes. Into the n-log, the n-factorial one, that's actually important. We talked about dynamic programming last time, and I could see how you could have an n-factorial problem, know it's n-factorial, say like, oh, I see a change here that's going to reduce the things that I'm looking at

to a logarithm of what I'm currently looking at. I should be able to, from that point, be able to say like, oh, if this ran in an hour before, it's going to run in what now? But without like those polished chops, like that's not a question I could easily answer. Yeah, I mean, there's a bunch in here too about like patterns, like what's the proxy pattern? I don't think that's a pattern that we've ever covered.

Nope. I mean, I know what a proxy is usually used for. Right, right. So if you had to guess, based off the name alone, you might say... You hand it off. Yeah, some sort of go-between. I don't want to say translates, but almost like reflects. Passes it along.

Yeah. So his definition that he has here is, provides a surrogate or placeholder for another object to control access to it. Okay. Right. Yeah. But it'd be nice to have that stuff on the tip of your tongue though,

wouldn't it? Yeah. How about this one? We we've, cause we kind of talked about this one or at least by name, this one has come up in the past couple of episodes. What is the Bellman Ford algorithm? Chodding salesman, wasn't it?

Graph traversal, which would be what it's for. It's an algorithm that computes the shortest paths from a single source vertex to all the other vertices in a weighted diagram. Isn't it funny that we've got 82 episodes in now? Each one represents multiple hours of dealing with different subjects in programming. Plus, there's all the episodes that we didn't make or the things we talked about doing and then didn't do. And there's all the things we've talked about in Slack. And then other things, our various careers were like, what, 15 years a piece? And we get to the normal flashcards for Google interviews. We're like, uh, N squared? Right?

I don't know. I mean, that's the thing. It's so big. Which one's faster? Dijkstra's algorithm or the Bellman-Ford? Dijkstra's is N to third power, I think. It's three, four loops. So I'm going to guess Bellman.

I'm not answering this. No, no, no. You got to answer. Dijkstra's. Okay. And Joe, you said. Dykstra's. Okay. And Joe, you said? I think it's Bellman. Well, then Alan got it right. Ooh. See, get some.

But what's the advantage? Can you name the advantage? No. Joe? No. Bellman Ford can handle graphs in which some of the weights, the edge weights are negative dykstra they have to be all positive numbers oh yeah when i said uh algorithms i meant like you know solving those puzzly crap questions not named algorithms but when i said algorithms this was the kind of stuff that i was talking about though that's funny yeah wow so like you know

yeah graph traversal type problems, like knowing which one, when to use it, which one's better, for what reason, blah, blah, blah. All right. Well, dang. Yeah, now I want to – you have a link in the show notes, right? Yeah, I'll have a link to the flashcards as well as John's main repo here, which when we first talked about it back in episode

48, I think the repo was named something along the lines of, uh, Google interview university. And he ended up changing it over the years to just the coding interview university. Nice. Uh, and it's still growing repo, but he, he has his parts of it. And then there's like other areas where he's like, you know, Hey, feel free to like add to here. So like some of the classes, so there's videos that he has references to that are like behind paywalls, like, um, maybe a lynda.com or something, or something that is maybe seasonal on, uh, one of the learning platforms like a Udacity or something like that,

that you can't always go to. And so, you know, if you definitely can find something that is, uh, always available, like on YouTube, he would much prefer to have those resources available.

And indefinitely, if they are, um, have you ever seen how, like on YouTube specifically, like you can find course lectures from Harvard or MIT or whatever that are, you know, always available on YouTube,

right? Like those are definitely preferred. Yeah. Yeah. Cool. Hey, on one of the honorable mentions here, I had one like where you were saying that the UI thing,

at least the frameworks, like I, I'm pretty decent at UI stuff. Yeah, for sure. Yeah. I think it would have been funny if we would have done each other's like or could it kind of guess what we're gonna say like i definitely would have pegged you for uh getting it done type stuff yeah come hell or high water i don't i don't mean that just uh kind of having a good pragmatic sense for um kind of balancing like the business needs and kind of keeping the priorities the priority.

You know what? So let's do this. I think for you, I would have said ability to jump in and help people out in just about any situation. Like you do that well and a lot that's another one of those things like um if there's like someone told me there's a bug or something that they're having a hard time with like unless i'm up to my neck and something else like it just it pains me to not kind of jump in so like actually for my honorable mentions i have like debugging and kind of ownership because like those are two things like if there's a bug in my

area like so it says something hmm, something weird happened. I really want to know. But a lot of times, I get swamped and stuff. Depending on how far down the death bunch I am, whatever various project, those strengths slip, which I hate. But I think that was a close...

That was definitely on my mind for something I was going to list. For Outlaw, I would also say one of the strengths is just the ability to jump in on basically anything. Like just, and almost have, and it's sort of weird to say this, but almost have an empathy towards the problem, right? So understanding the pains that it's causing and what to do to resolve those pains. So I think, I think it might be an extension of the detail oriented, but like literally, I mean, I can't think of many things that you haven't done in terms of just random freaking out there things, right? Like anything from DevOps-y type stuff to testing to process flows to setting up, you

know, build environments or whatever, like just, you know, the ability to get in, understand a problem and attack the problem. But I kind of view that as different. I have a different take on that. And that's why this episode was also really one one of the comments that i remember making to one of you guys or both of you guys that i had a really hard time about because i kind of view myself as uh if you've heard the expression a jack of all trades master of none like so i mean to your point like yeah i jump into something but it's not like i i don't feel like it feel like,

you know, remember we've had that conversation about, you know, being the T shaped developer. Right. And that's where it feels like, you know, it's more like I'm a dash,

right? Like, sorry, man, can't, I can't let that. I'm a big minus sign. No,

that's not true. You're a bucket. That's not a dash. It's not even a bucket that's not a dash it's not even a bucket it's a barrel that's a thick honking dash man video processing devops uh machine learning javascript like here's the other things i wrote to you the other day were like attention to detail pitbull persistence depth of understanding and thoughtfulness like you I said ownership, that's not true. Because if something weird is happening in my app, I can let it go. You can't let it go. You want to know why it's happening, under what conditions, what it is.

And so I do think whether it's JavaScript or C Sharp or SQL or whatever, you can't just be okay with something being weird or whatever. You always have to investigate. There's no way I would say a dash. But that's a negative, though. But that's a bad thing, though. Disagree. Not being willing to walk away, to step away from something and move on to the next problem.

No, I disagree because we've talked about this stuff before, right? It's the pains that we've experienced as developers that make us as good as what we are now. Because we've experienced those pains, we have a better understanding of what we're walking into 90% of the time, not all the time. But I'll agree, right? Like you're the bucket-shaped developer. You're not the minus or the dash. And I'll give a perfect example here. And this is a real example right so at our current gig you know when when we all first started doing this stuff it was a small shop like when somebody said hey

we need a build to give to a customer it was literally go into visual studio right click publish you know and produce the thing right like it is in a lot of small shops. Exactly. And so a dash-shaped developer would be like, okay, well, I can automate this thing. I'll set it up to where it'll run MSBuild, and then we're done, right? So that's where maybe the dash-shaped guy goes in there. He's like, okay, I got my DevOps piece, and I'm done. That's not Mike, right?

Like when Mike got in there, he looked at it, and he's like, hmm, I don't really like this hard-coded thing. Let me figure out how to get that out. I'm going to extract that out. Okay. I got that out, but I really don't like this because there's not a pattern here, right? Like I can't really make sense of this thing and nobody else will be able to make sense of it. Let me break it down into its constituent pieces and put it in a build pipeline so that everybody can look at the process and it's this nice pretty tree, right? So that's where, and this is where I think it's important for people to really reflect on their strengths. It is real easy as developers and man, I'm talking to everybody that does this stuff to get lost in the fact that we're the one percenters who understand this crap, right?

When you talk to any other person outside of our profession, they know less than a fraction of what we do about how these things work. And so it's real easy because of our depth and breadth of knowledge to understand how much we don't know. But if you look on the other side of it, we have so much knowledge in this stuff that it's amazing when you think about how much you gain over time. And like what you're saying, you think you're a dash tape developer because you're all over the place, but I've never seen anything you've done that's been halfway on anything, right? Like it, when you

touch something, you don't just touch it and walk away. You're going to make sure that it's left nice and tidy so that when you walk away, you feel good about the next person that came in behind you. And that's not a dash shape developer. That's not a, a thin T that is somebody that took the time to be thoughtful about how it was set up, what it was going to do. And when you walk away from it, you don't have to think about it. And that's, that's a big difference. And at least in my opinion, because most people don't operate that way. I guess, I guess like one of the things like, you know, okay. So going back to the, uh, what was it? The myth of the genius programmer kind of thing, right? Like there's definitely, I feel like we definitely work in a, in a,

uh, career path where it's very easy to have insecurities about certain things. Right. And, you know, there's like all of these, like, you know, the whole, uh, DC universe about, you know, there's gods among us. Right. Or, you know, uh, the, the, you know, cause there's the people out there that are putting out the books like Rob, for example, you know, Rob Connery with the imposter's handbook, you know, you have the,

um, John Skeet, you have uncle Bob, like all these people that are putting out books, right. That are just, you know, they're like the gods among us. Right. And it's easy to, to feel kind of inadequate, inadequate if you're not one of those people. Right. I feel like I forget like everything. Like if after a week I've forgotten something like, all righty. Like, I don't know if you guys feel the same way, you know, but it's like, you know, like even, even today Alan and I were looking at some code that I'd worked on.

I don't even remember how long ago it was that I worked on that code, but let's say it was a year plus. And there's so much of that working with a third-party API that was like, I'd forgotten about. And it took me a while for pieces to start coming back together. It's that kind of thing that gets to me every now and then. And it could be anything. It could be like a React. Joe brought up machine learning. It could be Python. Anything that you're not in daily, then I'll forget it.

And then that's where I get frustrated. Yeah. And that's true. And I mean, to give one more bro hug here before I finish it up, but like with Joe, right. It's the same type thing. And, and this is, I think really what distinguishes elite developers from, from those that do a nine to five job. Right. Like, and I'm not being boastful and saying that I feel like the three of us are elite developers.

We are. And the reason is because we care a lot. And an example, and Joe's joked about this in the past, right? Like he'd walk away from a piece of code because he had to, but before he did, he'd write up a three-page wiki document on, hey, these are the things that you need to know about this because this is the state that it was arrived in, and this is what it needs to do, and you need this background knowledge to do a handoff. Or even, he says he's not good at UI, but I've seen his UI and I would argue the opposite, right? He may not know every framework on the planet, but it's just there's that level of care. And it's funny, man.

So I had a VP at UPS that was probably one of my favorite people in the world. And I never actually heard him say this, but the guy was from New Orleans, from Louisiana. And his big thing was making sure people did lagniappe. And I hope I'm saying this properly, but it's a French Cajun term for giving a little extra. He said that basically, when he was growing up in Louisiana, if you went to the butcher shop to get some meat, you know, you were a local person. He was a local butcher and he'd always add a little lanyard. He would basically give a little bit of extra meat. You paid for it. You walk away. And that is what elite developers do, not just in their code, but in understanding and presenting

the solution to their code, right? Like if, if you know that a customer is going to be working in your application and they're working in batch, but yet you create screens where they have to one click everything to go do it. You failed them, right? An elite developer takes it to the next level and says, I need to make this person's life better. Even though the requirement is to one off these things, they think they're a problem, they do it better. And like you said earlier, they paint the other side of the fence, right? Like you're not walking into a landmine field when you're going in and looking at somebody's code. And I mean, that's, that's something that,

you know, the honorable mentions, the dev strengths, those are almost things that you can't quantify, but is extremely apparent when you go walk into somebody's code that left it in the game. And that's why we do the podcast. That's why we interact with, you know, technical environments. And, you know, we put just a lot of heart into this stuff. That's why we do the show and participate in all the social stuff and whatever we do, go to meetups. And so, you know, we just all care about it.

And so I think that's a strength for us. And I also think if you're listening to a podcast on your commute, when you could be listening to anything else in the world or watching YouTube or whatever, I think that that's probably one of your strengths too. And so let us know in the show notes. It would be really interesting to hear your takes on the strengths and weaknesses.

And we really hope that you enjoyed this episode too because I kind of worry a little bit that people are going to hear it. It's like all these guys patting each other on the back all episode. So I hope it's not terrible to listen to because we enjoyed recording it, I think. No. And if anything, I agree. I don't want anybody to walk away thinking that this was literally a pat on the back session, whereas it's more think internally, right? Like we've talked about the, um, uh, the imposter syndrome. We're talking about the imposter's handbook in the previous episode. It's real. It exists, right? Um, everybody feels it probably that you interact with day in and day out, be aware of it and just know that, that, you know,

if you're trying your best and all that, then, then know that you're gaining knowledge, you're gaining skills and all that stuff. Gain confidence with it. Don't be cocky. Don't be arrogant, but it's real. And it's not literally just patting on the back. It's recognizing strengths and weaknesses, right? Like we pointed out our weaknesses. And sometimes that's hard to do, right? Sometimes it's hard to reflect on that stuff. But it's a useful exercise.

Well, how about this? I'll put you guys on the spot. Because Joe has done this to us before. So it's my turn. I'm going to do this. So what if we say, Hey, uh, you've been listening to this. You write in a comment on this episode slash episode 82 with your two strengths and one weakness or two weaknesses, one strength. So take a honest, introspective look at yourself and think of two weaknesses, one strength, and we'll pick one winner and we'll get you a copy of the imposter's handbook. I love it.

Hey, I'm going to up the ante. Let's do two. Two? Let's do two. No, no. I'll do three. All right. We're going to do the ante. Let's do two. Two? Let's do two. No, no. I'll do three. All right. We're going to do three.

All right. Three copies. Three copies of the book. There you go, guys. So, yeah. Three copies of The Impostor's Handbook. Yep. All right.

Awesome. Comments on codingblocks.net slash episode 82. Yeah, and just real quick, I wanted to mention too, like one thing that was really hard for me with picking up the strengths is like I know someone that is better than me in each individual like kind of subject or area i thought about it's like oh i'm good at this well so was this so it's kind of funny like i think that's the strength of the community like i like that there's people that i know that are stronger in every every area i can think of that i can go talk to and so that's that's really nice and I'm really fortunate to have that. And if you don't have that,

I recommend joining the Slack group and finding those people. Oh man, totally. And if you don't know who those people are, ask. Yeah, man. Amazing.

Go in there and say hi, and you'll be greeted by just killer people, killer good people. And a real quick, um, so we talked about honorable mentions. Uh, I thought it'd be kind of fun to like ask about,

you know, we talked about our weaknesses and strengths. Are you guys actively working on any of those weaknesses or strengths that you kind of know about? So kind of inspired by things that we've, I think it was the practicing episode. I don't remember which number that was. But I've kind of got inspired to do that,

the code wars for Python. And maybe take, everything that I've done with Python so far has been more around machine learning. And there's definitely been times where it's like, well, I got to just figure out, okay, how do I even splice up this matrix? Right. But I want to get better. I want to get more muscle memory at those kinds of things. So I was like, well, you know what, let me take a different approach to this.

And instead of like going after it from there, from the kind of going with Alan's point about the targeted learning, rather than trying to, you know, go at it from the point of view of like, hey, let's work on some machine learning problems. Instead, be like, hey, just focus on Python first. And then get some more muscle memory, get some better muscle memory there. So I'm definitely going to be making more of an effort in that regards. Yeah, I'd say for me, it's not all the time. I definitely will get an itch and sit down and watch one of the Stanford talks on YouTube on big O notation or algorithms

or something like that. I won't say that it's with any frequency or consistency, but there are definitely times that I will go out of my way to say, all right, I need, I need to revisit this. So for me, I would say that there are things I am definitely heavily pursuing, but they're not my weaknesses and they're not my strengths.

So there's things that I want to be better at that. I'm kind of feel like I'm more on the middle ground on like, so code architecture, modularity, communication. I've been doing some speaking stuff this year, the podcasting, obviously, um, DevOps, mom, and a little bit of the modern UI UX, but I just kind of thought it was funny. It's like, these are my biggest gaps, but I'm not working on them.

Oh, I agree with that. I definitely have more interest on the business side of things almost always. So, you know, marketing, uh, passive income, that kind of stuff. Like, my mind tends to float towards things not developing. Because I think sometimes I just need a break from it, you know? Oh, yeah, for sure. And that's another great point, too. It's like, this is my own time. Like, I already got a day job I spend plenty of time at.

You know, we got a podcast we put plenty of time in. Like, if I'm doing some coding on the weekend or something, darn it, it's going to be fun. Right. Yeah, but I mean, when you feel like you need something to get away from programming, that's what mountain biking is for. Yeah, and too, I just want to mention,

it sounds like we're all kind of in the same boat where it's like, on my weekend time, my extracurricular time, I'm not really interested in getting my A's to A pluses or my f's to d's right like i'm more interested in getting my c's to b's right i agree with that yep so uh i thought that was interesting and actually we took a bunch a whole bunch of notes on kind of how to get better in different ways of learning and different models and stuff and drive us models and learning pyramids and stuff but uh we kind of ran out of time, so let us

know if you're interested and maybe if you're lucky, we'll talk about that in some future episode. There's a decent amount here. For the resources we like, we're going to have a ton of links in here. The Impostor's Handbook is definitely going to be in here, but

there's going to be a ton. I know I've got at least a dozen just in my notes alone. definitely going to be in here, but there, there's going to be a ton. I know, uh, I there, I've got at least a dozen just in my notes alone, um, related to, you know, some of the things that I was finding. So we'll have a bunch of resources when like a bunch of links to, you know, interesting articles, uh, John's GitHub repository that I mentioned, as well as, well as a link specifically to the flashcards. Oh, I meant to say this too. On his repo, he had a really good quote that I liked a lot. Successful software engineers are smart,

but many have an insecurity that they aren't smart enough. So true. So with that. Hey, wait, wait, wait, wait. I should put the resource in there that I was actually studying when I should have been doing these notes last night, which was just home theater speakers, right? Like I have links all over the place. I can share all those. Yeah.

Aside from those PWAs. Yes. People were putting real stuff in our chat and I was like, man, I'm looking at speakers. I don't know what this is. All right. All right. Well, with that, it is time for Alan's favorite portion of the show. It's the tip of the week. Oh, man, I forgot about this. All right. Cool. Now, for me, I've actually managed to catch up on just about all my podcasts, so I had to go find a couple of new ones. And I found one that just started actually called AppDev Diary, where there's two devs who are kind of going through, they're discussing their journey on building a new guitar practice amp. And they are starting right from the get-go,

let's talk about what we want it to be. And they're just getting started and they're kind of researching and figuring some things out with how to play audio and JavaScript and stuff. And so it's really interesting. And I think if you like the show, you're probably going to like that show. So we'll have a link to it. It's called app dev diary. Very nice. So mine, this one's kind of interesting.

And Mike and I were actually talking to right, talking about this right before the show. And it had features that I didn't even, I wasn't even aware of. So there is a, is it a plugin? It's a marketplace thing for Visual Studio Team Services. And basically what it is, it's a package management plugin, we'll call it. Now, there's two sides to this.

There's the awesome side and then there's the not awesome side. So there's a link in the show notes for it, but it allows you to sort of easily first host a NuGet feed in your own VSTS environment. So you can have a private NuGet feed. You can also have it auto package particular projects into NuGet packages for you, which you can have in pre-release mode. You can have in debug mode, you can have in release mode, you can version them, semantic versioning, all this kind of stuff. It also supports NuGet, NPM, Maven, pretty awesome things.

I've seen Pluralsight videos on it. I've seen it in practice. Now here's where I will tell you, it kind of stinks. If you look at the reviews on it, there are currently 141 reviews at about two and a third stars. The reason it's two and a third stars is because it's a paid plugin, which people are really mad about. And I kind of think rightfully so. So basically you get five user licenses for free. So if you have five people on a team that are using VSTS and this, and this, um, new get package or this package management thing, then you get it for free. But for every person over five, you have to start paying a monthly fee for. So that is what the negative reviews are.

It's not about the functionality of it. It's all about the fact that, you know, people feel like Microsoft should be paying for or not forcing people to pay. Yeah. I, I hate that part of it. It's all about the fact that people feel like Microsoft should be paying for it or not forcing people to pay. Yeah. I hate that part of it. It's ridiculous. In team services speak, it's an extension. Okay. That's what they call it. And there's like a whole marketplace of extensions that you can add into Visual Studio Team Services. And this is one. And you know if you want to have if you want to have a managed hosted nougat environment then that integrates in with team services then this is the way to go and it really feels like team services should just include this yeah it doesn't feel like that you should have to pay for it. And this is made for and published by, made by and published by Microsoft.

And it's just like, come on, man. We're already paying for team services. It's really frustrating. I mean, when I say that it should be an essential thing that's already baked in because what it allows, and I probably don't, I'm not even making this clear is you can take projects that are dependencies in your other projects and tell it, Hey, this project, I want this to be nougatized, right? And it'll version it and do all that stuff for you automatically. Like you can have it when a commit goes in, it will go build the thing, create the, the new get package publishing pieces for you. And, and it just gets used in your projects

and the next time somebody does a a run on their system it'll pull down the NuGet package and run it super useful incredibly frustrating that they charge for it but if you're not aware of this thing and you have an environment where dependencies are kind of a pain in the butt, check it out. Yep. So you too can have diamond dependencies. Exactly. And if you don't know what we're talking about, good for you. So mine, I thought I would play in Alan's favorite land, which is SQL. So come oh,

come on. You love data. I do love data. So, um, I don't know that we've talked about this lately, but with SQL server 2016 and later, Microsoft has been introducing some little sugary goodness into T-SQL.

And I'm sure that there's like a whole bucket list of things that Joe wants that still hasn't been added, but there've been some cool ones. So I thought, you know, I don't know if we talked about it, so maybe we should, but a couple that were,

um, were noteworthy and I'll have links to like more, uh, you can find, but a couple that I wanted to just call out specifically was like, you remember if you, the old way of, okay, I want to see if this, if this table already exists, I'm going to have to like check if the object ID exists, blah, blah, blah, right. Select from the table, see if it, if this thing is already there. All right. Well, now you have drop table if it, if exists, right? So you can just say drop table if exists and whatever your table name is, right?

Which is totally awesome, right? And that one I thought like maybe we've already talked about that one. But the one that like caught my attention is yesterday I was talking with a co-worker and I saw one of her, some of her sequel that she had on screen. And I was like, holy crap, is that legit sequel that I had on screen. And I was like, holy crap. Is that legit sequel that I'm looking at? Because it said create or alter procedure.

And I was like, wait a minute. And that was a new feature that was added to 2016. That is nice. So I just thought basically the main takeaway from that was like I got to pay more attention to these SQL server updates to see what's changing So I just thought basically the main takeaway from that was like, I got to pay more attention to these SQL server updates to see like what's changing in T-SQL.

So catch up on all these new syntax features. Can you order by a variable yet? See, I told you, I told you, I knew Joe wasn't going to be satisfied. Stop with this pipe dream stuff, man.

That shouldn't be a pipe dream. The pain. Right. But let's also, in fairness, keep in mind that SQL Server is a transactional database. It is not a reporting database. So, yeah, maybe it shouldn't exist and maybe people shouldn't be trying to force it to do that. Yeah, I saw a great talk from Santosh over here in Orlando

talking about NoSQL versus SQL. And it wasn't just a, you should use NoSQL talk. It was a really great kind of talk about the strengths and weaknesses of NoSQL versus kind of traditional relationship. Very cool. We should talk about that sometime. Yes, we should. I think it's a great topic.

All right. Coolness. Yeah. So that's it for the episode. We talked about identifying our weaknesses and filling in the gaps and the kind of stuff that we're working on. We hope you guys enjoyed it. And we hope that you go to the comment section and drop your two

weaknesses and one strength for a chance to win one of the three copies of the books that we're giving away that we hadn't planned on. That's it. We'll all pitch in a few bucks. We'll be good. All right. So with that, if you're not already,

be sure to subscribe to us on iTunes, Stitcher, Spotify. Oh yes. We forgot to add that in there. Player FM, Overcast, Google Play, iHeartRadio. We're basically everywhere.

And if you found us on someplace that we're not mentioning, that's not listed on our header, let us know. We'll add it there, too. Be sure to leave us a review. You can head to www.codingblocks.net slash review to find some helpful links. Yep. And while you're up there, check out all our show notes. They are extremely full and well-featured.

Examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel, codingblocks.slack.com. We're going to be having some more community talks coming up. So if you're interested, you should join in there too. We've got a channel we're going to be talking about and scheduling and figuring out how to do more of those on a timely basis. And we're on Twitter or anywhere else, at CodingBlocks. So check out the website

and you can find links to just about anywhere you want to be.