Coding Blocks - How to be an Intermediate Programmer

Episode Date: February 27, 2016

In Episode 38, we dug into the first section of the essay by Robert Read on what it takes to be a programmer.  In that episode there was a lot of great information on what to expect and what should be expected of you as a developer.  In this episode, we go into the second […]

You're listening to Coding Blocks, episode 39. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. Visit us at CodingBlocks.net where you can find show notes, examples, discussion, and more. And send your feedback, questions, and rants to comments at CodingBlocks.net. And follow us on Twitter at CodingBlocks or head to www.CodingBlocks.net and find all our social links there at the top of the page. With that, welcome to Coding Blocks. I'm Alan Underwood.

I'm Joe Zeck. And I'm Michael OneDrive. Very nice. Yes. Do we want to explain that or are we just going to let it go? Well, I was going to explain it in a minute, but yeah, we'll get to it. I'll tease you. All right.

This episode is sponsored by Infragistics. Use Infragistics for your enterprise mobilization and modernization. For business users and IT organizations, you can deliver exceptional user experiences to your customers through Infragistics mobile enterprise solutions for team collaboration and BI dashboarding. With advanced integration with major mobile device managers, extensibility frameworks for full customization, and embedding and white labeling options, Infragistics Enterprise Mobility Solutions are designed to fit your enterprise or OEM software needs. Go to www.infragistics.com today and download your free 30-day trial. Okay, so we got to say this. Man, you guys are awesome. The reviews this time have been amazing. Yeah, truly. Like both in content and the number of them. Oh, the quantity of them has been amazing.

I'm going to just take a stab at reading through these names. And if I mess up your username, forgive me now, but I'm going to do what I can here. So we have ZZZZBurger2016. Rick Pack. I'm already messing up now. Erebor? Maybe. Setter.

MJD. DevSec. And in Zuzu? Yeah, that's pretty good. Andrew W. Lane. P. Wright 08. Wilson. Drummer.

Starchild 2. Doves. Katie Ann Riley. Caney Shammy. Yep. What would that be? Terry times 512 or Terry X 512? 510. 510.

I'm sorry, 510. Why am I saying 512? What would that next one be? Derek Kane. EstuQ89. Thank you. Ozzy Steve. I don't know how to say Danny's last name.

Heligroza. There you go. With all the hard ones. Bert, 1178. Allen. Nalamb. Okay. Hikosh.

Hikosh. Okay. LA Medical Delivery. P. Wright, 08. Jason. Wyman. hakosh hakosh okay la medical delivery p right oh eight jason wyman wyman jim w and michael c yeah i'm assuming that was michael i've never i've never seen that spelling but that's an interesting spelling but oh my god and hey by the way if anyone was paying attention there as the names were being called out, P. Wright, W.O.8, or P. Wright, O.8. I said that one twice. It was in Stitcher and iTunes. Yeah, thank you.

Huge shout out. Thank you, Paul Wright. And seriously, all of you guys that took the time to come over here, I mean, super appreciated. It helps us. It's like the biggest payback that you guys can give us. I know that we've said that before, but it really is. It brings such a smile. It is a huge joy, and it really does help us out.

I mean, and by the way, we cracked 100 reviews in the U.S. Right. I think we all kind of did cartwheels. Yeah. And we're pretty small guys, so it was kind of entertaining to watch us all do that. I don't know about the small part, but yeah. We're guys. So, yeah, seriously, thank you so very much for taking the time and doing that.

And for all you guys, most of you have come joined us on Slack as well. Right. So, you know, if you haven't already joined us over at Slack, head over to codingblocks.slack.com. Well, actually, I take that back. We still have to find some time and set up a more automated way to do this, but right now we don't. So what we need you to do is if you would like to join in on the fun at, at coding blocks.slack.com, then what we need from you is an email address. You can either DM it to us on Twitter, or you can email it to us at comments at codingblocks.net.

And then with that email address, we can send you an invite. Yep. Or if you can't even remember the comments at Coding Blocks, you can always go up to the site and use the contact form. Some people have done that as well. But we do need an email. And one other thing, too, just for the people that have joined i've noticed like a lot of people hit that general the the hashtag general don't forget you can go join the other channels too

like we have a dev talk channel we have a podcast channel we have random which is gaming we have truly random music to code to and people seriously like some of these folks like Dre, Dre Young, he's been amazing on there. He's dropped a ton of of interesting stuff. Gustav has been amazing. Stefan has been awesome. Like we've really had a lot of great interaction, Jason. So, I mean, and that's not to leave out anybody else who's been who's been interacting. But there have been a lot of great tips dropped on there and just really useful information.

And then a lot of fun, too, right? Like when somebody needs a break. So come join us. I mean, it's a blast. If you'd like to know why I am now Michael OneDrive instead of Michael Outlaw, you could see my meltdown last week. I think it was like Thursday or Friday of last week. I think it was Friday of last week. Anyone who's ever used OneDrive knows my pain

because it's such a nice thing when it works, because your documents are just synchronized everywhere and you don't have to worry about stuff, right? Don't change your password. Because as soon as you change your password, it is so frustrating. And that's when everything, like OneDrive just falls on its face and doesn't know what to do. And it's so confused.

Oh my God, you changed your password so yeah i i completely melted down on friday and it was almost like like i joked around about i should create a comic book or a comic strip you know and and i would title it michael versus one drive and you know in that thread i had joked about, I should just change my name to Michael OneDrive. Yeah, there was definitely some dialogue back and forth there between you and OneDrive for a while. Oh, my God. I can read some of it if you'd like, but...

This will probably be a long enough episode already, so we'll save that for maybe the next one. But, yeah, I mean, there's some great, great conversations, even monologues even that happen over there you know uh so what's up what's up next we got we got a t-shirt giveaway that we promised like three months ago i think yeah so so we forgot in when we recorded episode 38 about the t-shirt giveaway that we had mentioned in episode 37 so we remembered it this time and the winner is man reek or man reek a i'm not sure logan so there you go congratulations you will get

a nice pre-worn t-shirt grayish yes and so we'll definitely be contacting you over on discuss on episode 37 in order to get some information from you so that we can ship that out and congratulations yeah and uh you know also on well actually no this one didn't come from slack we got a tweet about this one so you know we've done surveys on various episodes sometimes we're better about remembering to do a survey than other times and i would like to say at least in the last couple episodes we've been pretty good about remembering to you know have some fun with it and do it but this time we actually got a tweet from uh tired of the carp and uh she says hey coding, how about some girl power for your next survey?

Princess Rap Battle, right? So she sent us a link to a YouTube video. We'll include that as the survey. How do you pronounce that name again, Alan? It was from Lord of the Rings. No? Oh, Galadriel. Yeah, there you go. Versus Leia. See, Oh, Galadriel. Galadriel.

Yeah, there you go. Versus Leia. See, I'm horrible with names. It's not just your name, dear listener. It's everyone's name. I can't even pronounce this guy in front of me. It's Alun. Alun.

Ayan. If you say it in Spanish, it's actually Ayan. So, you know. I don't know. Now I'm going to be all confused. There it is. Hey, Ayan. Okay.

We'll have a link to the video and we'll have a poll there. It's fantastic. And should we say which one we prefer? Hmm. No, let's not. Yeah, yeah, yeah. Let's do a little review of the results. But I will say.

Yeah. Okay. Were you about to say? I will say, though, that, you know, this is marked with some explicit language. When you see this video, just the page alone, it says that it's explicit. So if you're in a work environment, maybe you don't want to watch it, or if you're okay with watching it, then I would definitely suggest some headphones. But it's all in good fun.

Yep. And so wait, what happened with the results from the last survey, the puddle? Oh, we'll get to that later. Oh, okay. That's convenient. Yeah. You hoping we're going to forget Outlaw? I think Outlaw's climbing around the puddle right now.

No, I will get around to it when I get on the other side of the puddle. All right. So what are we talking about tonight? How to be an an intermediate programmer all right yep we're continuing on with the book we were talking about last time how to be uh intermediate programmer robert reed's book yeah it's hard to even really call it a book it's uh it's it is a book it's a lot of things i think we referred to it actually last essay last time. Yep. I'm sorry. Well, it's an essay too, I think. The world hasn't caught up yet with all this technology.

He actually did leave a comment for us linking to the GitHub page where you can actually submit pull requests and bugs. I was referring to some of the lag, though, because there have been a couple of times where I've mistakenly talked you know talked over you and i wasn't trying to but yeah video conversations it is interesting it happens what what does the world come to where you have a pull request for a book that's really interesting right it's quite awesome yeah it's actually pretty smart if you think about it you have all the editors in the world now that means you're probably denying a lot of pull requests but it is pretty interesting so i actually went through the history and i was surprised to see how many um little small edits there were for like um you

know grammar consistency stuff like that so it's interesting to see just how many editors there were yeah well there was a a similar going back to our slack channel conversations for a moment like there's all kinds of great resources that are getting dumped in there man like it there's really some awesome conversations that are happening and uh one of them i'd completely forgotten about this this author um it's kind of similar to what we're talking about tonight with the robert l reed the fact that it being now a book in GitHub, but, uh,

another author, what was his name? Trying to remember. He has his books posted on GitHub as well. And he was actually a presenter at, um, this year's connect JS that we were at. Um,

what was his name? I can't remember. Uh, Kyle Simpson. Very cool. So one of the members of the Slack team threw that link out there, and I had totally forgotten about it until I saw it. And then I was like, oh, yeah, I remember.

It was this whole series about you don't know JavaScript. And it was scope and closures and type and grammar and async and performance and at the connect js where i'm trying to refer you attended that session with me alan i think you did but he talked specifically if i remember right it was about promises and asynchronous programming and it was a really good i didn't go to connect js this year oh you didn't no because i was busy i was i was working like 90 hours a day right okay i remember i remember who was there with me now yeah hashtag lame yeah pretty much all right well let's go ahead and dive on in let's uh let's hit part two of this three-part series on how to be a programmer an intermediate programmer an intermediate

programmer this go around so the first section is personal skills and the very first part is how to stay motivated and i like this section a lot because there was a lot of this stuff that i thought hit home for me especially and i know a lot of other developers and one of the things that i read in here that i really liked was if programmers are asked to do something that is not beautiful useful or nifty they will have low morale that is so incredibly true a lot of people will say oh it's just a job i program i program whatever but if you don't feel like passionate about what you're working on as a developer, it can really drag you down. And it can kind of kill not just your morale, but your productivity as well.

So that was a great line, and I don't necessarily disagree with it. But the only reason why it didn't maybe hit home with me as much as it did for you though it's because i was thinking like well you could be working in a technology stack and just be completely bored and you don't care how useful it is or how beautiful it is like whatever you've been asked to create if you're bored with that tech stack, you're still bored with it. So the one that did hit home with me in this section was looking for new opportunities to apply new techniques and languages and technologies. That one hit more home because like you could – okay, let's take C Sharp, for example. We've all done C Sharp. You could be working in C Sharp and just get kind of bored with it.

What? And then, yeah, it could happen. Crazy. Right. But then all of a sudden you come up with, you learn some new pattern.

Maybe, maybe something finally likes a fire under you and you start using dependency injection. Right. Uh, as an example. And now all of a sudden you get maybe, you know, renewed interest, right. In it. That's an example and now all of a sudden you get maybe you know renewed interest right in it

that's an example that and i i liked that one i like that part of his point that he was making the first bullet point he has right here is you see sharp for the job he does oh you're um you know i'm sorry it says use the best language and i just kind of substituted there. My bad. Right. Awesome. You know what's funny, though? On this topic, one thing that has really been driving me crazy lately is the amount of crud-type stuff, like literally just boilerplate code that you write day to day. Like, honestly –

That's REST programming right there. Dude. Oh, man. Like, there are times that I look at it, and I seriously will stop doing what I'm doing and write something to write it for me because I can't take it any longer. See, I would almost want to say, like, well, I kind of want to say, you know you're doing it right if that's what you're doing is a lot of crud because then you know that you're using REST correctly.

Right. And until we were recently showed that video on graphql and then it's kind of like well maybe oh don't get me started on graphql this episode will go five hours yeah i think i think some of the uh guys in the slack channel already uh got a taste for that yeah it's it's kind of ridiculous but um go ahead jo. Did you find anything else in here that you thought was pretty relevant? Yeah, this is just kind of a fun counterpoint, but it's a quote from the article. But just kind of a little reminder here that there is a lot of money to be made doing ugly, stupid, and boring stuff. So if you're greedy or you want to take a little break from fun stuff, then you can do some of that too.

Wow. Okay, please don't leave us listeners, any of you that are SharePoint experts. One thing that I did think was pretty interesting here was when you go through this section, like it's all about learning and doing things that you're interested in. One point that I thought was great, and this is kind of why we did the podcast,

is try to teach people something too while you're working because it renews an interest in what you're working on because as so as you see somebody else get excited about it it's easy for you to get excited about it again well it kind of goes hand in hand with the example that I gave earlier about a new technique because he also says in that same one about you learn something try to learn something right and in the example I gave about learn something. Try to learn something, right? And in the example I gave you, maybe you're trying to learn using dependency injection, right? And then the one last piece in here for me that I thought was really good

was when they talk about it, you know, we have these ticketing systems and all these things where you can, like, track the number of bugs that you bring down. But for a developer what does that mean right like we've all been in systems where it starts out you had 20 bugs and then as more people are using the system you're knocking out two or three a day but it's growing at 10 a day and you're just you feel like you're kind of buried but what can be motivating is seeing how it impacts the customer, right?

So not how many bugs did you finish, but of the bugs that you completed, what was the actual impact on the customer? How did they receive those changes? Well, I can tell you from my own personal experience working on e-commerce sites, whenever I could equate those changes into dollars. Oh, it's amazing, right? That was highly motivating. I don't care how small the change was, but if you could contribute that change back to here's the dollar amount that changed per month or week or whatever metric you choose to use, I found that to be awesome. Oh, it's really cool. When you make a change that took you an hour

and all of a sudden your company's making $50 extra in revenue a month you're like well that's killer right like i did that right so but it's it's important for you as a developer to know what kind of motivates you so that you know those kind of things that you need to be aware of and as a manager it's it's very important to to bring those things to light right so i although i will say though when you were talking about you know the the number of bugs and everything i really thought the where you were going with this was you know the the t-shirt about the 99 little bugs on the wall 99 little bugs take one down pass it around 103 little bugs on the wall. I really thought that's where we were going. It's so true. It's unfortunate, but it's true.

All right. So let's move on. So how to be widely trusted. Well, for starters, you don't have a name like Outlaw. That's not going to help. You need to have a name like Michael Goodguy. Or Jay-Z. An Empire State Word.

Right, right. that's right well I prefer to build trust by being responsive and informative to those outside my department or team that dude that is the same one that I highlighted same here man same it's so important yeah how many people have you known in your career that are like so i've i've definitely had bosses bosses in the past that are extremely demanding and everybody's like oh you don't want to be on his radar and i'm like what that's crazy talk no i do want to be on his radar because my boss can't really do and i'm not trying to play down what your boss can do for you. But guess what, people? The ones that are making the decisions are up above their level, right?

Like your boss can't just go hand out raises willy-nilly, right? And usually it's one or two up the chain that can build relationships with people in that line as well as outside of that department. And going along the lines of that goodwill, though, there was another one that I really liked that was not pretending to know something you don't. So if someone asks you something, don't fake it, necessarily. Know when to say, well, I don't know this right now,

but if you give me some time i can figure this out or i can research this or whatever right but also know like if there's gonna be times where i'll never be able to figure this out then i should be honest about that too yep right and also don't become the the person that's taken advantage of right because some people will abuse these relationships if they know they've got an open line to you and they're like, Hey man, can, can you get me this? You know, your knee jerk reaction is you want to make somebody happy. You're going to be like, yeah, yeah, yeah. I'll get that to you. And then it starts becoming a habitual type thing. You know, you, you kind of have to be aware of that stuff too. So, you know, you need to set

boundaries. Yes. You want to build some goodwill, but you also don't want to be that guy that's slipping on his own work because you're trying to do something for everybody right so agreed all right the next section i thought was really good it was about um trade-offs between time and space and this is getting back to more programmery type of stuff. And basically talks about how you can often trade off memory for CPU cycles. So you can do something, you know, you can cache data, for example, in memory to save processing cycles. Or alternatively, you could save memory by recomputing values. And this is a nice big section, I thought. Yeah, he even had a statement that said something about, you know, for a truly intermediate programmer,

you can't be a good one without knowing the basic computational complexity theory. And by that, he means you don't have to go deep into big O notation, which, by the way, if you're trying to get hired at some of the big firm or big companies like Amazon, Google, Microsoft, you are going to need to know that. So you might as well, you know, suck it up and do it. But you at least need to know what constant time logarithms are going to be or n log n or n squared. So quadratic type things, because if you don't know these,

then that means you probably don't even know when you're doing something bad. Right? Yeah, and just as a refresher, we've talked about this as a tip before, but if you need a refresher in Big O complexity, head over to bigocheatsheet.com. And there's a nice little chart there that has a graph of all of the or at least you know a lot of the bigo notations where you can visually see from a complexity point of view what's what yeah and i don't know i don't remember this is the section they talked

about it but um so there was a quote in here somewhere i'm sure we'll come across it that basically talked about um all you really need to do is just kind of know your algorithms and know your data structures and i think that kind of ties into this um so there yeah totally i mean like if if you don't understand the difference between like a hash and an array and what the lookup complexities would be and the time taken and all that kind of stuff you might be making poor decisions that you could vastly improve with very little code changes right so yeah those are pretty major things the point of saying that uh you know part part of this is knowing like well am i even going to make a is what i'm trying to correct here even want to make a difference in the performance, right?

So if you already don't understand, you know, the big O notation, like maybe you don't know big O notation. But if you at least can look at the code and understand like, okay, well, because this loop is inside of that loop, then every time it's going to get executed, it's going to cost me more like if you can at least you know conceptually understand that that's going to cost you more effort right even if you don't know which one of the big O's that's going to be then you know you can start to see like where your improvements are going to matter the most right um you know before you even make those changes because even if you you know any of those changes that you make you're hoping that it's going to include a performance gain, but it's definitely going to include a test burden. So you need to be aware of that, right?

Yeah, I like that phrase, test burden. Yeah, I mean, there was even, we've talked about caches in the past before, right? Like if you start caching data locally, you have a database, then you have some tier that caches data. Okay, That's great because you have a faster access to it, but now you have to have more complex logic around it, right? You can't just go get it every time. Now you need to know when do you need to flush this thing out? You know, like there there's any time you start

trading these things off the space versus the complexity you're always looking at okay is is this does the benefit outweigh one way or the other you know and and it's always it's an interesting trade-off and a lot of times you know sometimes you'll make these things in a vacuum because like well we need to do this and so you end up doing it and you might over complicate your code or you might even cause performance problems so So, you know, it can be hard to see sometimes when, especially when you're dealing with a lot of frameworks, you know,

it's, it can be hard to see what's going on exactly and where your problems are, which I guess kind of leads into the next section, which is how to stress test. Yes. He says stress testing is fun. Yeah. I read that as testing is stressful. Oh, wait.

Maybe I'm doing it wrong. So this guy, Robert Reed, I think I would like hanging out with him, but I am not him and he is not I. Oh, man. Yeah, I've messed around with some stress testing tools before, and I just found it kind of frustrating to set this stuff. And then you kind of, you know, started running and go to lunch, come back, figure out the server died. You know, something somebody restarted something because you were messing up what they were working on or whatever.

So it's just always been exercise and frustration for me. Yeah. Well, I didn't necessarily view it as fun like he wrote here more as i just viewed it as like a a necessary evil maybe you'd be the best exactly what i was like it's not something entertaining to do but it's like all right well i gotta set this up i mean i guess we're performance nuts it it is a little bit fun because the way that he put it is it's when you're running something and and all of a sudden your performance just takes a nosedive that's what he calls hitting the wall right and so doing a stress test is an artificial way to find where that wall is and then you do what you can to try and move it

further back right so that was the whole point of what a stress test was was just so you can find where these were basically it does take that nosedive. So I get it. But the problem is, is it can be depending on the test suite you're using. It's fairly complex, right? Because trying to simulate if you are an e-commerce site, you know, simulating the same click throughs on the same pages, you know, a hundred times concurrently doesn't give you true life interactions, right? So you have to mold these, these types of tests so that you more mimic what real life interaction is. Well, I guess this is part of the thing too, where I,

you know, kind of begrudgingly said it like that was that when I think of stress testing like this, I'm thinking of these are integration tests. These are not unit tests, right? So if we go back to our conversation about what's a unit test, what's an integration test, right? Integration tests are touching, you know, dependencies, whereas unit tests are not. They're single, isolated, you know, tests that can run independently of one another in any order, and there's no dependency on other stuff, right? Not even file systems, right? So when I think of stress tests, I think of integration tests,

and that's where it becomes a hassle because now it's like, oh, crap, we've got to have a network to set up just like this and a database server that's scaled out just like this. Like, you know, if we're trying to test, unless you have the ability to, maybe you have the ability to stress test your soon to become production environment beforehand,

then fine. But you know, if you have, if you were tasked with building out a replica of your, your production environment, just to stress test something to see like, okay, well what's the maximum that this thing can take that can be a real headache chef or puppet right yeah man you

want something it'll spin it up i mean i i would imagine somebody like netflix has done this to a t right but they've got all the tools built to do it because that's what their their end game is they need to be able to replicate those things well they certainly didn't start out with those tools right going back to like an mvp kind of process right yep and so you know netflix didn't make their make their name for themselves because of their testing ability true that all my good testing stuff from there but yep no he doesn't make a good point i'm sorry joe go ahead uh all right sure yeah so i was just thinking when I think about stress testing, I still think very much in terms of like requests per second and how the database server is doing and the application server. But I've never really used a tool that measured like browser performance, which is becoming more and more important when you're working with spas. And that's basically how sluggish is my UI behaving and how usable is this?

And I'm sure there's tools out there. I just did a Google search and I saw a couple, but I just thought that was kind of interesting, at least to think of my own bias in this kind of testing. Because not everybody is running a Core i7 with 16 gigs of RAM. That's right. So if it's running crappy on my computer, then we're in trouble. Yeah, he does make a good point here, though, that the plan for stress testing should be done early in the process. plan is to test a mock production environment then yeah you definitely gotta get started sooner

rather than later to just start building that thing out even if you're going to have it to where like some tools can spin up like ec2 instances dynamically right but those instances are just going to be the clients making the request that Those aren't necessarily going to be like your database infrastructure, for example, or your app servers, right? So, you know, you still might have to set those up. Even if you're setting them up to where they do scale automatically, that's still time spent on configuration, right? For those of you who don't know what EC2 is, it's Amazon's AWS. It's their Elastic Compute platform. It's Amazon's AWS. It's their elastic compute platform. It's where you can spin up a virtual machine.

So hopefully we didn't lose anybody on that. And we totally didn't even mention Azure because we are not Microsoft snobs. FYI. Actually, I would love to be an Azure snob, but man, it is a fairly high barrier cost of entry. Well, it's no more than the others, though. Is it not?

No. It seems like. They have minute-by-minute pricing, which is nice for messing around. That's kind of nice. Yeah. And plus, if we're talking strictly to Microsoft developers, if you have a subscription, whether it be the new cloud-based subscription that you could get, or you pay a monthly fee, or if you have the more traditional MSDN subscription, those come with free monthly hours of Azure time.

Yeah, that's what I'm playing with. If you haven't messed with cloud services before, it opens up a whole new world of thinking. It's pretty cool stuff. So my only point being is that Azure is no more expensive than Google Compute or Amazon. And if you are a Microsoft developer, then Microsoft is at least trying to, you know. Incentify you to come in and play, right? Well, I was thinking of it more like the first one's free. Okay, yeah.

They're trying to rope you in, right? Which is fine. I mean, they're starting to do that with Visual Studio as well. Visual Studio Community 2015 is free. If you're just an individual developer and you want to go play with stuff, you have a free IDE that's amazing. Here's another point, though, that he makes in the stress testing section, which was that if you do stress test this application, right, and you find where's that upper limit, where's that wall, that maximum where things are just going to go sideways if it goes, if one and that depending on the situation, it may actually hurt the application performance.

On lower loads, right? Right, right. handling a babillion concurrent requests, but in reality, you're going to have no more than one or two, then you could be taking a hit on a lot of overhead that you're not going to ever use or take advantage of. But by God, when you turn into Instagram, you'll be ready for it.

Yeah. I also wanted to say that if you don't have a production environment that's similar or a staging environment that's similar to production, then you should go check out our episode on the 12 Factor app. And it's just a red flag. It means something that you don't have the exact setup that you're able to test. So if you're not able to do stress testing for whatever reason, then you have some things to think about.

Yeah, that's a great point. Great point. All right, moving along, how to balance brevity and abstraction. Well, our episodes do not adhere to that. Yeah, I was gonna say, I can't actually comment on this section at all. Dude, this, this one's actually very, this is one that I'm a little bit passionate about. Because I've definitely known coders that want to write the most elegant code on the planet, and they want to make it scalable to the nth degree. And I'm like, dude, we got 10 users. Why are you looking at me? I'm not looking at you.

I'm looking at – I don't know. Actually, you're looking at who? Who are you looking at? I'm looking at my Kindle. Yeah, you better be looking at my kindle so yeah you better be looking at that but no seriously like that's it's one of the things that frustrates me and i and i struggle with it myself too sometimes right like you sit there and you're like oh man i could totally make this thing to where like i'd never even have to write another line of code after i get done with these five million lines of code that i need to do to make this happen. But the whole thing of getting

to the point where you have 20 layers of abstraction is almost more of a hindrance than having a fairly concise set of code that may not be all that gorgeous and object oriented or whatever, but it's easy to maintain and it's easy to see what's going on. Right? Like, so there is a balance there. And so many people jump on one side of the line or the other and never hit right down the middle. There was a quote, Joe, maybe you can help me out here. I think it's an uncle Bob quote where it's something along the lines of abstraction can help anything except solve abstraction something like that

do you know what i'm talking about is that yeah but you know what this reminds me of this section it reminded me of the episode we recorded almost two years ago now right after we had done the solid episode where joe came back he's like yeah, I tried to write a solid app and all I have is interfaces and abstract classes. You just took away my next joke. Oh really? Well, because,

because there was this one line in here that there was just a one sign of this is if you create classes that don't really contain any code and don't really do anything except to serve, except to serve to, ah, except serve to abstract something. And I read that and I was like, well, that's solid. That's totally solid.

I mean, you have to, right? You got to do that? No, you're saying don't do solid? Man, we all know a guy named Will. And I'll never forget, like this dude, he's a very strong, strong software engineer. In every sense of the word yeah every sense like the dude could bench press probably 400 pounds and on top of that he's a good coder but i'll never forget there was one day like you see the status on his instant message profile

so what was it something along the lines of too much abstraction causes confusion and you can tell that the dude was just defeated in layers of interfaces and abstract classes and more interfaces and it's so true well yeah he he points this out as a form of speculative programming totally right where you're just assuming that all this abstraction is going to be necessary. And really, there's a strong possibility that whatever you're working on, it's the first time that it's ever been used. You don't even know how it's going to be used yet. You don't even know how other developers are going to start to use this yet.

So you have the best of intentions and want to make this thing just amazingly portable and configurable or whatever like you know to where it could fit any need but you kind of don't know what those real world use cases are yet so maybe tame it down a little bit and and what you said he calls it speculative code about a paragraph down from that he writes you should not produce much speculative code, right? And it is so true. And there was somewhere in here, and I didn't highlight it, but he even said something to the effect of, and I do agree with this.

If you're writing some sort of public API, you know, you're a company that's providing a software product, a software as a service or something, and you're giving a public API, yes, do those things that abstract and you might create a little bit more abstraction there because you're giving it to the public to consume. If it's an internal app, like, do you really need those 30 layers of separation, right? Like, yes, yes, Yagni, you ain't going to need it. Well, I did kind of find this humorous, though, because this being the brevity and abstraction section, right?

And there was this one line in here where he mentioned that portability poses a similar problem. And I don't know why it was that portability triggered this thought in my mind. But immediately, you guys care to take a guess what might have popped into my head portability java there you go java popped into my head because like as soon as i read that this whole section about brevity and abstraction in like spring for example like yeah i mean it was just like well i don't know if he's a Java programmer. Maybe that's where he was thinking of. I don't know.

Yeah, I mean, if you start trying to work cross-platform, I mean, we even had something come up on Slack today where I think Juggernaut brought up React Native. He was like, is it true that you actually have to code some of the UI in the native code for the platform? And I was like, yeah, probably so. And so, yeah, I mean, if you're going to try and make something ultra-portable, you're going to have a bigger code base to deal with. So, yeah. Yeah, definitely portability can bring about some craziness into your application. So let's move on to how to learn new skills.

That's probably the best skill you could have, right? The ability to learn new skills quickly. I mean, that's what Einstein said is the reason why we go to college, right? Is to learn how to learn. Yeah.

Yeah. I guess that would be my superpower. I think that's one of the things we were talking about in the Slack channels. What superpower would you want? I think like knowing how to learn things quickly. Wait, superpower that you would want or superpower that you have. Oh,

uh, want. Oh, okay. Okay. Yeah. You know, one thing that I liked about what he said in here,

and I don't know if I highlighted, this is a pretty long section was just going to a course or some sort of conference where you learn about something or watching a video or even reading a book. That's not good enough. If you're trying to actually learn a skill, you need to put yourself in it and do it, right? And that is so incredibly true. I mean, even doing the smallest amount of

code can drive home a point better than watching five hours of a video right so right yeah as soon as you start trying to like put something into into motion on your own for that first time right there's there's gonna be huge learning curves sometimes you know not as huge as others, but yeah, that effort will definitely stick with you, right? And I liked that he had this statement in here about how important it is to learn and how fun it is to learn new skills and that companies should embrace this because it would boost morale. Encouraging your employees to learn new things would help boost morale within the company. And I thought that was a great point. And to take it a step further, not only would it boost morale, you would bring new knowledge in, which could help everybody out.

It really is kind of a fine point that is glossed over too many places. But, yeah. One thing that I did like is they say take a small project. Even if it's not something you're super passionate about, take a little tiny small project. Like you did the – when you were trying to learn Angular, you did the whole, you know, the review thing, right? If you take something that you can actually apply, it will help so much. But if you guys. Well, this goes back. Sorry to interrupt.

But I think we've discussed something similar to this, though, where like especially a code example to illustrate whatever it is that we're talking about in the show. Or it could even be in a blog post that we're going to write separately. And sometimes it's just coming up with, like, what's that use case for that thing, right? And so sometimes that part of it can be difficult just coming up with that. But once you come up with some stupid, it doesn't have to be extreme. It could just be some stupid little example. And then once you decide, okay, fine, this is what I'm going to settle on, then you can focus trying to learn that technology and apply it to that. And then just keep iterating on it and making it bigger and bigger and bigger. You always grow it.

I mean, you can't start off huge because you'll never make any traction. This section did remind me of something. You guys ever go on to, and I'm sure we all have, you've gone to those conferences where you watch some dude showing you like the latest visual studio or something else. And they're like, watch this, guys. I can build an application in 10 minutes. And then they'll blow through it and you'll be like, oh, my God. And then you go home and try and do it. And like three hours later, you're like, man, how long did this dude rehearse for this?

And how many things did he, you know, slide by that he knew were problematic? Because you get there and you're like, this totally isn't realistic. He knew what to click, what not to click. Yeah. What, what options were required in the order to do it in. Right.

Like, Oh, if you do this thing before this, it'll totally not work. I've always like, whenever I see those kinds of things though, I guess maybe I've just gotten so burnt by that, that every time I see it just instinctively,

whether I mean to or not, and I'm not trying to be rude to the person, but I immediately think, okay, this is smoke and mirrors. Right. It feels like that. It is frustrating because I've never been able to replicate that, ever. Yeah, Ruby did the build a blog in 10 minutes, and the node was like, write a web server in two seconds.

Like, what are we going to do next because those things are no longer impressive isn't that crazy think about that that's not impressive anymore that's insane when you can write an operating system in one line yeah chew on that one

what is it gcore live the DNS the DNS thing yeah I mean nobody can write anything that's even working now oh that's yeah well that well i mean that was written eight years ago so maybe they didn't maybe they weren't using solid techniques back then they didn't have it wasn't abstracted enough yeah they didn't they didn't have a good testing framework in place then uh so all right what's our next one learn to type yeah i actually have an

experience here i'd like to share because i recently got the microsoft sculpt keyboard yeah so alan do you have anything you think all right so we're moving on yeah if you think you know how to type you should get this keyboard and uh you'll figure out very quickly which keys you're cheating on oh are you getting better at it yeah i'm pretty good except the bees keep throwing me off i guess i was always hitting the bees with my right hand and so now i keep typing things like key nord it's the bees knees so what's your what's your quick review on this because i gotta know you like it on the keyboard on the keyboard yeah yeah it's great um like i i don't really have any pain or anything so it's not like you know switching to it was

suddenly much more comfortable but i i do like it um the you know the the delete home and keys are pretty annoying so i get kind of frustrated sometimes i'm trying to do something quickly and i have to go searching for one of those keys but i think i'm gonna learn that but everything else you know the typing the letters the stuff that I thought I would be most annoyed with are totally fine. I do sometimes have to lean forward to figure out which one's F8 or F7, but it's all coming along really well. So I think just a couple days of using has got me 90% there.

Awesome. Did any of you guys, after you read this, go take a typing test just to see what your speed was? No, I hate those. No. I mean, I haven't bothered with one of those in, you know, well, I'm 21 now, so it's probably been a couple weeks ago. Yeah. Yeah.

No, I totally did. I think when I was messing around, I got 80, what was it, 82 or 84 with two errors. 84 words a minute with two errors. That's not terrible. You suck. Did you guys take one of those typing classes in high school where it's like line three, 14 spaces, three X's. By the time you did it,

you would end up with a picture of a llama or something. I hated that so much. I was always trying to figure out what the stupid picture was so I could just do it. I remember the games around it where you had to type correctly I was always trying to figure out what the stupid picture was so I could just do it. I remember the games around it. Where you had to type correctly whatever word or character was being popped up. And the one that stands out in my mind was that there was this little character that was – the screen was like a cliff and he was trying to run away from the cliff.

But the cliff would catch up to him, which sounds like a crazy description. Basically, think of like the world was falling out from underneath him. But if you were typing fast enough, then he could run ahead of the crumbling world. So stressful. But if you messed up, then it would start to catch him. Oh, my God. I actually learned how to type because of Space Quest.

That is the reason I know how to type. The movie? No. No, I was making a joke. Yeah, okay. Man, y'all are making me feel old. We did our class on typewriters. Ooh.

Yep. No white out loud. Oh, that's awesome. We did it anyway. Yeah, that was Beauty being 21. Yeah, so he makes the point here, though, that it's important to learn to touch type. But it's not necessarily that important of a skill for programming so much as by the time you become an intermediate programmer, you're going to be writing so much natural language elsewhere that that's where you're really going to benefit from just being able to type

it and type it fast and be done with it emails documentation yeah because it's not necessarily going to be the code you're going to look at that screen like a monkey to a math problem you know sometimes for like you know a while longer than you might like to admit looking at that code like wait a minute where's the problem right so there's not going to be a lot of typing during that it's true i mean we just made that section way longer than it should have been but it was fun well you know whatever all right fine we'll move on how to do integration testing i feel like we did this one with the stress testing well you actually don't do integration testing all right moving on to the next session wait what no i mean you brought it up

earlier right this is all your your well again i mean that was just like when i was thinking about stress testing that's how i think about it is it's you know a bigger thing so that implies integration testing but he specifically calls it out separate and you know like any good plan he says that you need to include this in your estimates and your schedules but this also like i don't know about you guys like every time i read that though i also think of waterfall like all the planning and estimation every time there's something in there about a plan and estimate i'm like wow that's uh you know a definitely an older way of planning maybe or project management maybe. Yeah, I've definitely worked on things where it's like we're going to hook this up to Salesforce,

but we don't have the setup yet, so just go ahead and program as if it's there. And then once you start getting close and you start thinking about pushing this thing live, you realize, oh crap, we've never actually tested this with Salesforce. And so sometimes, surprise know surprise surprise integrating with these systems that you've kind of been taking for granted can be more problematic than you might think they will be well that's actually kind of a neat example that falls in line with some of this though because he makes a point of saying that it's better to integrate gradually you know as things do become available you know both the code and the resource like Salesforce in this example, as that does become available, then you can do the integration testing on that part.

But you don't necessarily need to wait on all of the integration testing to be available before you start. Right. So. All right. Let's move on to communication languages. Man, I took issue with a couple of things in here. Go ahead. I don't think we mentioned that this book is also available in Chinese.

If you're listening to the show, probably not very good. But if you know multiple languages, one really awesome nice thing you could do would be to translate this book into another language, and they've got folders set up for it. That's kind of cool. All right, so yeah, this whole section

right here, the communication languages, like he calls out three specifically and to me only one of these made sense. So he basically said that there are ways to communicate what your intent with the code or anything is with other members of a team.

And he calls out UML, XML, and SQL. And to me, UML is the only one that fits that mold. Yeah. I actually had my own question mark by those. I was like, wait, what? Dude, there was some place where he actually calls out xml and says right here xml is a standard for defining new standards it is not a solution to data interchange problems though you sometimes see it presented as if it was dude that actually made my

brain go haywire i was like no i can't i can't get behind this like xml is a way to save data and and exchange data well also keep in mind the time frame that the document was written in too i still don't get it uml is the only one that is actually intended to to define an object space or or what are what were they called i can't even remember you have actors and and uh oh i can't even remember what it is in uml but but basically you can define like use cases actors yeah i it's been a while but yes at least nobody uses that crap not anymore i mean back then this was probably fairly it was a pretty rich thing but i, it could write some of your code for you. It could define things that business users could look at and all that.

That's what it's for. XML does not do that. And SQL is for querying a database or inserting records into a database. That is not a communication language for other people. Well, I mean, I kind of, so I agree with you that UML was the one out of the three that he mentioned here. But I did kind of like the idea of like describing SQL as a communication language because if you were to take that approach, then you're kind of saying like, okay, well, this is how you get that data. I'm going to describe to you how to get that data and here's the syntax here's here it is for a several times i'm not saying i agree no go ahead dude i'm saying there's been times when someone's

trying to describe like an application flow or something i need to do and i'm like just send me the tables and i'll figure it out right because you want to see where the one to minis are in the foreign keys uh hopefully then that gives you a really good sense of how the application is supposed to work. Yeah, but now you're going back to diagrams. You're not going to SQL. That's closer to UML. I mean, I look at the tables. But yeah, I don't use the designer.

Give me a break. That thing's terrible. Well, I mean, it's just, I don't know, man. When I hear SQL, like, if you're talking about the very most vanilla thing, right? Like, you want to say, okay, show me the orders and the order details. Okay, I might could get behind. You could take a simple, you know, select all from orders, join order details, and send that to somebody, and they could get a fairly decent picture of it, right?

But as soon as you start going much deeper than that, like this is no longer any means of communication. It is literally sending code around that people either are going to understand or they're going to look at you and go, dude, I have no idea what you're sending me, right? But I think if I remember right, this article or essay rather was originally authored in 2002, if I remember correctly. Yeah, it was early. And he makes a point that he says,

I'm fairly sure UML is at least as good for you as studying Latin. I disagree with either of those. But back in 2002, Sorry for those Latin-speaking people. Back in 2002, though, I would have totally understood where he was coming from because I do remember there being a lot more hype back in the late 90s and early 2000s around UML. But now it seems like we as a society have progressed into this phase where we're like, you know what? Going back to our chick, but I don but i ain't nobody got time for it anybody got time for documentation so let's just let's just move on like you know we're we've moved forward into this culture where we're like hey just code

it get it out there and you know before we waste time on documenting it we're probably going to iterate on it anyways and it'll be completely different so you know, before we waste time on documenting it, we're probably going to iterate on it anyways, and it'll be completely different. So, you know, let's just keep going until we get to that end state, which may never, ever happen. Right. You know, and that's where it becomes so important to make the code readable and self-documenting because we're probably not going to take the time to document it so the likelihood of you even being given this uml diagram or even having time to create the uml diagram probably not going to happen if you remember right the big selling factor for uml was you could define your business cases and then it would write your boilerplate code for you like that i remember so many like we mentioned the rational tool suite before, and it was so, I'm going to say bad about that.

Yeah. You'd create all these stupid boxes and like, here's my customer object, and this object is going to have these methods, and it's going to return this value. But it wouldn't have any real business logic in it necessarily. It would just be stubbed out there's only one thing that i can think of off the top of my head that that falls into this and i know outlaw you and i went to a meetup and joe i don't remember if you were here or not but it was a thing to where you could write business type oh oh golly i cannot the The testing framework. Yes. And I cannot remember the name of it.

It was based on cucumber. You could write it in layman's type terms. It was a spec. That's it. Gosh. Man, now, why'd you have to do that to me, Alan? So basically, that falls into this category for me, something to where the business person gives you plain English directions of

what something should do. And then you build your test cases off of it. What was it? Spec flow, spec flow. It was a language for writing a business unit tests or business. I'm sorry. Let me rephrase this.

It was a language for writing business requirements that could translate into unit tests. But it allowed your business owners and users the ability to provide the developer business requirements

in a language that was easy for them. That the developer could just import into the code business requirements in a language that was easy for them, quote, easy for them. Right. That the developer could just, like, import into the code. And with a tool set like SpecFlow, it could automatically understand that and then build out the unit tests that were necessary to support it. And generate reports showing that, you know, hey, these business tests pass or whatever. So to me, that is more what the input was to spec flow. a first time customer, when the customer successfully places their order, then they get a welcome coupon emailed to them,

right? So that might be the business requirement. And then you can, you know, using that syntax of given when, then, then the developer has a lot of information that they can use as their, what their requirements are. And then use test cases can be written around

that. So that, that's what that is. Yep. So anyways, that we, we kind of beat that section up, but that,

I don't know, maybe it was the timeframe this was written in, but I definitely did not see some of this being quite relevant, but well, well, speaking of relevance, you guys might be surprised to know what you've been talking about over here googling i could not find a single uml tattoo

sequel yes xml yes but uml is so nerdy and forgotten that nobody even has any diagrams tattooed on them on the entire internet hey maybe that's how Kanye can earn some money. Because I hear that he's in need of some cash. There's actually a GoFundMe for that. I know. That's insane. So maybe he needs to contact Rational and be like, yo, I got this primetime real estate on Rational. Right, right, right.

Or maybe we should make that a thing. Like the first person, you know what? The first listener that sends us a picture of their UML tattoo, wherever they have it, let's not make it too obscene, but whoever sends us that first UML tattoo, then

I don't know, what do you want to do? Give them a t-shirt or something? Whatever you want. Let us know. It can't be our friend john because we know he's the king of photoshop so oh yeah no it can't be photoshopped that's cheating uh all right so let's move on to the next section here yep heavy this is a new section yeah yeah okay moving on yeah i don't know what to really say about that he he basically is talking about

like uh you know learn some heavy tools and he was talking about like databases and stuff so i don't yeah i mean there was a bunch of there were several of them that he lists as examples but you know databases were definitely up there and full text search engines were up there so you know solar comes to mind well to me when i read this section i thought of a time when i was working for like a small company you know web shop that was doing custom websites and we were talking um to this company about doing their e-commerce site and we had done e-commerce sites before and they're like why don't you use a search engine and i'm like what what's that i just you know, I have this where clause and I add and clauses to it based on whatever you need.

What could possibly go wrong with that? But I definitely think there can be, especially if you're in kind of a monoculture or you're working in a silo where you don't necessarily see, in your actual work where you kind of get in this not invented here syndrome, where you just kind of start to write everything by scratch, and forget that you can kind of reach out and grab stuff. But I think that's gotten a lot better with tools like, you know, package managers like Maven or NuGet or, you know, NPM, whatever. So I think it's gotten a lot easier to bring in third party stuff over the years and documentation has got better things have gotten simpler so I think that's getting a lot better nowadays I don't think anyone tried to write a scratch a search engine by scratch from scratch yeah I mean one of the heavy tools listed that he lists those a spreadsheet yeah I this this part

kind of got me. I looked at it. I glanced over the bullet points. I was like, okay, I'm out of here. So it's not to discount what he's trying to say, but I don't know. That just didn't do it for me. But what you just said, Joe, so like the package managers, Maven, NPM, all those, I feel like they're starting to reach uh apple store levels of clutter which

is driving me a little crazy right like you can't find anything right hey man you can't say that because uh just a few episodes ago we were talking about gulp and how many great packages there were for gulp and now it sounds like you're going back on that yeah Yeah, I might have overstated how awesome it is. But here's the other thing, too, though. And this is something that I think people this is a good resource for just kind of finding out about some things that may be outside their their knowledge zone. and look at the services they offer because a lot of the services they do offer are based off problem spaces, right, that needed to be solved. So if you think about, like you said, you didn't know that there were these search engines that you could use like Solr or any of those. Go to AWS. There's Cloud Search, right? If you go to Azure, they have their own version of it, I'm sure. So those are good places, if nothing else, just to kind of browse the features that they have so that you can kind of get an idea of tools that you may not even know exist.

Just a thought. Yeah, that's't know why, but for some reason, it reminded me of one of the conversations in the Dev Talk channel on codingblocks.slack.com. And where Carl had mentioned that he posted this article about AWS documentation being – well, there was an expletive there basically the the long and short of it was is that a Java developer who was wanting to use an AWS service

using Java obviously had to basically rely on the C sharp documentation because the Java documentation was horrible and basically what he wanted to see rely on the C sharp documentation documentation because the Java documentation was horrible. And basically what he wanted to see, there was a beautiful example in three lines of code and C sharp that applied to any language. Oh, that's awesome.

And, and I, and I guess like that particular service I've worked with, with, um, AWS. So I kind of felt a little bit of the author's pain. So I was like, yeah, I hear you, buddy. I hear you. Yeah.

I think when we were working with outlaw, I think there was only the Java version of the documentation. I don't think they even have the C sharp. Um, well, they did have the C sharp version of the document. And we're, for those curious,

we're talking about the Amazon simple workflow service. And, uh, gosh, that's been like what three four years ago now a while and at the time the documentation there was documentation for either language but all of the documentation the c-sharp documentation was very i mean that brevity chapter that we talked about, it definitely adhered to that. But everything tried to really gear you towards using the Java version. Because there were complete projects, let's say, that hadn't yet been made available in any other language except Java that built on top of this core set of APIs. And, you know, it was only available in Java. So, yeah, it was definitely rough. But, yeah, I kind of, you know, my heart bled a little with him when I read that. And when you were making your comment just a moment ago about it, it brought back tears.

Yeah. So the very next piece was how to analyze data. And this one, I don't know. I guess, again, this was just – go ahead. I'm so surprised. Even as you're trying to describe it, you're like, I'm so bored about data. I totally thought that you would be all over this section. You love data.

You've said that many times, even on this show. And here's a section on data. And you're like, oh, data. It was more talking about like it wasn't talking. I didn't feel either. I just missed the whole point of that area, but it didn't feel like it was analyzing data. It was more talking about like, how are you going to store your data structures and where you're going to put your variables? Like, I don't know. Joe, what was your take on that area?

I don't love this one and if I was a better person I would probably contribute and try to inflict my own thoughts on it but I will say that here's the quote I was looking for earlier it's from Nicholas Wirth algorithms plus data structures equals programs and that's all I have to say on this section well actually even the author here has a similar one.

He says algorithms plus data structures equals programs. Yeah. Oh, yeah. Sorry. I thought you were quoting something from the Slack channel. Sorry. Oh, no. Not this time.

Yeah, I think we all like this section, so we should probably move on. Yep. All right. Well, but hold on. No, because this section was talking about, like, understanding what that data is and so that you can know how your application can scale.

You know what it is? The paragraphs are too big. Mr. Big Data. That might be what it was. So Mr. Big Data didn't like this section because it was too much data? Yeah, probably. Yeah, three line max per paragraph.

We need to get a linter on this thing. There's a two-word paragraph, in all fairness, in this section. That's my favorite one. Yeah. So the one thing that it did say that I agreed with was, you know, if you feel like, if you're trying to take, like, all the permutations of a word or something,'re trying to do something if you go about it one way it could take days to run that algorithm right whereas if you were to approach it from a different perspective then you could do it in maybe seconds and so i do feel like there is a lot of of usefulness in understanding and knowing your data and how what the expected outcomes of that should be.

So it's not anything I want to belittle, but I don't know. I guess maybe when I was reading all this, there was so much here, and it really all boiled down to that. It was like literally understand your data, understand what you want out of it, and then figure out how to make that work. Because you had to read a lot, you're like, yeah, you know, anybody got time for that? So I don't know.

I mean, yes, it's valid. You should understand your data. You should understand what's coming in and what needs to go out. And then, you know, the best ways to get there.

Yeah. Summarize it. And then, um, the next section on how to manage old in time. All right, fine. We'll move on to how to manage to hold in time. All right, fine. We'll move on to how to manage. Well, actually, this came up in Slack today.

I made some joke about getting someone else to do my estimates for me since it would probably be as accurate as if I did it myself. A total stranger. Yeah, I'm going to find this good thing. I feel like we need like Triumph the Insult Dog and you know random stranger on the street trying to guess like what

the estimates should be for Joe's next task well I like it because it was some decide he had just joined the channel right before I asked this like minutes before and he was like what's your velocity and i was like oh yeah oh yeah crap there's totally uh this is totally a known problem that people

have been working on for years and there are many many techniques and many years of techniques and articles written around how to make good estimates and i am not following any of their advice and then complaining because my estimates are bad. So he schooled me within five minutes of joining the chat. Thanks. Joe's exited the building. We will no longer see his interactions on Slack. So I just wonder then, all of this documentation and essays and whatnot

on how to better improve your – make better estimates. Were they also long-winded sections that you didn't feel like reading? I read them all. Yeah, I highlighted a whole paragraph. Oh, yeah. I got tons of notes in my kindle i always thought that i always heard and in my own personal opinion he agreed that like if highlighting was just something you're just kind of like telling your mind i'm gonna come back to this no i don't need to focus on it right now i'll just come back to no for me it's actually

i thought this was an important point like if my mind doesn't work like anybody else's apparently yeah i i just don't highlight except well i mean you're on a kindle so i guess that's kind of different you can't make notes otherwise i've heard the same thing but for whatever reason Yeah, I just don't highlight. Except, well, I mean, you're on a Kindle, so I guess that's kind of different. You can't make notes otherwise. Yeah, I've heard the same thing. Say what? I've heard the same thing, but for whatever reason, like when I highlight something, I'll remember, oh, I highlighted something there. And so I'll go and find that one thing I was looking for.

It sticks out in my memory. It's like when you write something down, it sticks in your memory for some reason. It's the same type thing. But there was something in here i did like he said if you miss a milestone you should take immediate action such as informing your boss that the scheduled completion of that project has slipped by that amount the estimate and schedule could never have been perfect to begin with this creates the illusion that you might be able to make up the days you missed in the latter part of the project that to me is so key it happens so much because you're like okay

i missed this one by a day, but I can make that up. And in reality, that's almost never the case. Yeah, totally. I have been on so many projects where the first deadline slips and that's already a bad sign. And then they're like, you know what? That just means you have to buckle down on the second part. And then that one slips. And then eventually you get this gigantic snowball of doom that you're never going to be able to surmount.

But somehow the deadline never changes. But everyone knows you're not going to make it. But somehow it's still the deadline. Well, this goes back to my comment earlier about a lot of these readings. Like the mindset is definitely in a waterfall kind of project management. Because there was another statement in here where he says, the project plan exists to help make decisions, not to show how organized you are. So, yeah, I like that.

That's what it should be. I like that. I like that it's to help make decisions, right? Sometimes those decisions are, can everyone go on vacation or not? That sucks. Yeah. But, uh, um, but again,

it, it still felt like it wasn't a more modern, um, take on it. Now, again, this document, their essay has been updated on GitHub. And unfortunately we found out,

uh, the author, uh, pinged us, uh, was that an email or a tweet? It was on a comment. Oh yeah. Comment on episode 38. found out the author pinged us. Was that an email or a tweet? It was a comment.

Oh, yeah, a comment on episode 38. Actually, the copy that we were reading wasn't the most current one. So maybe some of that verbiage has been changed. But I will say, though, in terms of that, I've definitely worked in agile shops, and it's still the same thing. You can still go to them and be like, yo, I know that we thought that this was only going to take a week, but it's going to take two weeks. And then they'll be like, oh, well, you're just really going to have to kick it into gear that third week to try and get the rest of that sprint together. It's like, dude, come on, man.

I came to you honestly and told you what's going on right there were x y and z hidden landmines that nobody had any idea about and so now i've got to suffer for this and unfortunately that happens way more often than the inverse where they're like okay let me adjust and slide this back out oh Oh, no, we estimated the points. You got those points, right? So that outage that we had yesterday that took me 10 hours to solve, that doesn't count, I guess. Right. It doesn't count for anything.

None of us are better. We've not done it. None of us are better at all ever about any of this. And by the way, this is how to be a programmer, intermediate. Right. You jovially gripe about the things that happen like that and you move on because they're going to happen so yeah over and over and over again all right well let's move on to the french stripper

and talk about how to manage third-party software risk. I actually love this. I really like what they said about not resting hopes on Vapor. Dude, totally. That's basically a promise software that isn't already available. I've definitely worked with things and been like, oh, the next version is going to come out. It's going to solve all your problems. So you're just like, okay, well, you know,

I'm just going to kind of ignore all the problems that I'm seeing right now because I'm sure they're all going to get fixed. Dude, totally. And then, yeah, you get bit in the butt. Just for those that, you know, any new listeners that may not have caught up on back episodes and they're like, the French stripper. There was a story in one of the earlier parts of this essay

where they were talking about a third-party utility to strip html out of text that was written by a french company and they were referred to the uh that third-party software as the french stripper and um you know sometimes you don't even have exposure to what those tools are doing. So dude, but the vapor is so awesome. If you're being promised something that he basically says, assume that it doesn't exist. And that is so true. I can't stress that enough.

If you have a third party company that's saying, yeah, we're getting that out to you in this next release, which is coming out in two weeks. Don't believe it. Just assume that it's not there. Assume it won't be there. And if it is, dude, that's icing on the cake, right?

But even if it's not necessarily vapor, maybe if you do have it, going back to the French stripper example, there's the point in here that he makes that there's great risks associated with that third-party software. Yeah, absolutely. And that was the story that he illustrated in one of the earlier chapters. Yeah, he even said, if third-party software is not vapor, it is still risky, but at least it's a risk that can be tackled because you have it, right?

It's in your hands. You can at least go after it. And in the case of that that other software you know there was a problem with it and they had to figure it out but at least they had it but if it's something that's being promised to you it's just as good as assuming that you know your company's going to sink while you wait on this right well i like that he summarizes it too by saying never let your schedule depend on vapor. Right. Although I've also seen third-party solutions that were totally working go belly up over Christmas while I had the flu. Are you serious?

Yeah. I feel like he's referring to an example that you should know about. I feel like I can't remember what it is. Yeah. an example that you should know about. I feel like I can't remember what it is. Yeah, but yeah, so it's just a, you know, it's good to always be aware of your dependencies and have backup plans. Yes. Maybe he's referring to a search example.

No, no, definitely not that next. No? Okay. So, yeah. So this next one, how to manage manage consultants this one's kind of interesting because i've been a consultant or i was a consultant for many many years uh i know outlaw you kind of did consulting for most of your career as well and this one's kind of a touchy subject because a lot of times as a consultant you're like the go-to guy on a lot of things right like you're the one who needs to have the, you're like the go-to guy on a lot of things, right?

Like you're the one who needs to have the knowledge. You're the one that's kind of burning new paths. You're the one that's doing a lot of the legwork. And the fun stuff. And the fun stuff. And that's true. And the problem is that does step on employees' toes. Because a lot of times they get stuck with kind of garbage work while you're out there blazing the

way right right um but on the flip side the frustrating part of it is you know you're kind of a disposable commodity right i mean okay so yeah you're the guy that's all gung-ho you might be the dude that's just working your tail off and you're getting everything done while it seems like the employees are coasting by but guess what at the of the day, you're the one that they have no real obligation to. So, you know, they basically have to treat you as a throwaway to a certain degree. And I hate to use it that way, but. Well, you know, I mean, he starts off this section by saying to use consultants, but don't rely on them.

And, you know, you want to agree with that so much because you're like yeah totally why that makes absolute sense you should not rely on them but yet anyone who's ever been in that position can tell you from experience oh you'll be relied on oh absolutely oh yeah you'll be relied on you'll be leaned on heavily oh yeah you will more so than some of the employees yep and it's weird and i don't i've i've tried to reason this out over the years because i was a consultant for a massive part of my career and i think part of it is typically as a consultant you're always on the edge and you know you are. So you're always pushing that boundary back further, right? Like you're always attacking and trying to find out new and better ways to do things.

Whereas a lot of employees are like. Keeps you on the edge of your seat. It really does because, you know, it's one of those things like, hey, if I'm not performing, I'm dead weight, right? I'm not somebody that's got some sort of, you know, they have to write me up three times with some pink slips to kick me out the door. They just got to be like, yo, Mr. Underwood. They're going to decide while I'm at lunch that they didn't like my morning. Exactly. Hey, you kind of looked at somebody wrong today.

I mean, it's a totally different ball game, but it also makes you a little bit sharper. And that's why I feel like you're kind of more of a go-getter when you do that. And people sort of look to you for the answer because they know you're the guy that's going to go do things. So I don't know. This part's frustrating because I've always taken what I do personally, right? Like if I make something for a customer, I want it to reflect something awesome. Like I want the customer to think this is incredible. I want to look at it and be like, man, I did a killer job on this and I want everybody to be happy. And so when when you're kind of seen as a disposable, you know, commodity, sometimes it's hard to take that in and not internalize it yeah you know he also says too that you know the best way to use consultants

was as educators in-house that can teach by example and from experience from practice really i don't know that i've ever seen like maybe I'm misunderstanding what he means in regards to in-house educators that teach by example. Because unless he means like, hey, go look at that code that Outlaw wrote as a good way to do it, or maybe not a good way, that never happened. Well, I've seen situations where some consultants will come in and say, set up your network or maybe some sort of monitoring tool or log aggregation tool. And then they kind of step you through it and they're supposed to kind of give you some kind of – or ideally they would give you some sort of tips or pointers on how you should kind of continue on and integrate further with that once they're gone. So that's a fair point. So I guess the distinction that I would make there, though, is depending on the length of the contract. Hired for a task versus hired for augmenting a work team or something. If you're bringing someone in for a week,

then I agree with what you're saying, Joe. Those are going to be examples where you're like, hey, just come in, set this up, show me what you did, and then thank you. But if you're bringing someone in for three to six months or something like that, I've never seen those people necessarily used as in-house educators. And I also kind of got to take, too, that maybe he's just had some bad experiences with consultants, at by the consultants, right, he makes this assumption that it's not going to be reviewed and that you wouldn't want large blocks of code written by these consultants because it's not reviewed. And it's like, well, okay, A, why is it not reviewed? Right. Right? And B, why can't they write large blocks of code?

What do you want them to do? Would you bring them't they write large blocks of code? What do you want them to do? Well, would you bring them in to write small blocks of code? This has always been the frustrating part. And I hope nobody's taken away that, you know, we're downgrading employees because I'm actually an employee right now and very happy to be. Um, but the interesting part is one of the frustrating things to me as a long time consultant was they're like, Oh, but if you get hit by a puss, then I need to know what's going on. And I'm like, okay, what about that employee over there? Just because he's W2. Oh yeah.

Doesn't mean that dude can't walk out the door. Like, what are you talking about? Yeah. I know that, I know I've shared this story personally. I don't know if I've ever mentioned this on the show, but you know, to your, to your example about,

you know, that employee getting hit by a bus. I actually worked on a project one time where one of the guys on the team, he was an employee of the, you know, the company. He was our, uh,

CIS admin. And, uh, I think he might also played a DBA role too. But super bright guy, right? Loved to skydive. At that time, he was definitely well into triple digits in terms of number of jumps. And, you know, as a traveling, you know, uh, consultant, he would, uh, well, cause you know, everyone in the company was a consultant for someone else.

Um, but as a traveling consultant, every new place that he would go, one of the first things he would do is he would find and book a jump, you know, at least one for that week right and we literally had to have uh you know a line item in terms of risk of like okay uh you know as bad as it sounds in case things go splat then what's our contingency here right so so uh yeah i mean you know just because it's an employee doesn't necessarily mean that uh you're not gonna get hit by the bus yeah i mean i guess kind of to just sort of wrap up this little portion right here yes you don't treat consultants exactly like you do employees first off there's laws against it but i will say though thank you microsoft yeah right um they can be leaned on and should be leaned on and if they're not if they're not doing

what they need to do then you know you need to move on because the whole point of a consultant is to bring expertise fast and get stuff done and and so i get that but at the same time they are still people and they do still have feelings and a lot of them take pride in what they do so you know you know treat them as you would any other person as well as you could but you know they're a resource so two last points i want to make here one the in regards to the microsoft joke it's not that there are laws about, um, that you can't treat them as employees. It's kind of the other way around that. Um, if you are treating the consultants and,

or, you know, contractors as employees, then they get the benefits of the employee. And that was a lawsuit that came up to Microsoft. I don't years ago. I think it might've been like, it was well ahead of my time,

but yeah. Um, why are you laughing? I was just like, I'm working in the eighties. Um, and, uh,

and then the other comment that was that, um, I think it was early this afternoon. I was reading an article that was kind of interesting. It relates somewhat to this about, you know, use, you know, he's saying to use consultants and, and the this afternoon I was reading an article that was kind of interesting that relates somewhat to this about, you know, he's saying to use consultants. And in the article that I was reading, it was talking about, like, were discussing was the company said, okay, fine, once we determine what our staffing needs are,

we'll staff up to 85% of that and then we'll contract out the rest. We'll contract out that last remaining 15%. And so maybe depending on what your situation is in your company, then that's something that's helpful for you too. Absolutely. Keep some portion of that staffing budget available for consulting. Yep. All right. So the next section is how to communicate the right amount.

And I like this one a lot. Meetings are sometimes necessary necessary but smaller is usually better and that is so true yep it's multiplied by the number of participants so the more people you have in the meeting not only is it the more time spent but it's also um you know there's lots of studies talking about how uh people will take less individual responsibility when there's more people in a meeting. One thing that he said that was kind of interesting here, too, in addition to that was if you see somebody getting bored, that means your meeting is probably too big. There's too many people in it. You need to shrink it.

Right. And that's pretty key. I definitely have worked in places where they would just bring everybody in the department into a meeting. And it was usually so counterproductive because people would almost just argue to be heard as opposed to trying to come up with a good solution to something. Maybe it's just – maybe it's as an engineer, I like numbers. Maybe it's being a numbers guy. But whenever I'm in a big meeting, I can't help but just kind of look around the room and take a head count and like oh my god how much money if you were to extrapolate that out into dollars yeah there's some serious money in this 30 minute meeting yep right like

you know especially like in larger meetings yep no yeah, I mean, shorter is better and with fewer people, you know, get to the point, have, have a point, get to it and then call it and move on. I did like, he, he makes a point about, you know, doing everything, doing everything you can to encourage informal communication and that sometimes the most useful work happens during lunch with colleagues. Yep. Totally agree. And, you know, years, I've always had the opinion of some people will bring their lunch to work, and I've always been like, no, I got to get out of here.

So it's not anything bad, but sometimes you just got to step away from the problem, give your brain a chance to reset. But then not only that, but sometimes you just get an opportunity to brainstorm with your colleagues while you're out right or talk about like learn whatever they're working on and be like oh man that sounds amazing i want to work on that how do i get to work on that you know yeah definitely uh you know those informal communication lines are

sometimes the most valuable. Yeah, I always thought if I had a company that I would do paid lunch hours. So basically you work from 8 to 5 or whatever, and that one hour there was kind of like basically encouraged to kind of go spend it somewhere because you can. Are you referring to like a Facebook or a Google where there's an in-house chef and you just go to the cafeteria i like it i've worked in places where people will skip lunch in order to like leave early or you know they'll just eat real fast in the in the break room and then leave

you know 45 minutes earlier or whatever so i like the idea of kind of doing the opposite be like you're going to be here from you know eight till and whether you go to lunch with all your buddies or not, you're still going to be here for that time. Although it really doesn't match up with – I'm much more interested in flexible scheduling and whatnot now and even working from home. But I always just thought it was kind of a cool idea to encourage people to go to lunch together. Yeah, the whole cafeteria thing sounds nice, but sometimes I just got to get out of the building, though. It almost feels like in travel. You don't want to breathe the same air anymore, right?

Totally agree. The grass is greener kind of philosophy. Yep. All right, so the very last section in this area is how to disagree honestly and get away with it. Well, you start with having a name like outlaw. I disagree. Oh.

Yeah. You know, I like where he starts it off with saying that disagreement is a great opportunity to make a good decision. Right. True. True. Yeah. And it reminded me, there was another comment that he makes in here about, you know, basically during this disagreement, you know, maybe you don't, maybe your side isn't chosen, right? And so the decision is to go with the other one.

But sometimes you have to, even though you disagree with it, you have to go along with it. And it reminded me of, I think we mentioned it last time, about having backbone and commit to whatever the decision that's finally made, right? Yeah. I mean, the finally made. Right. Yeah. I mean, the thing is, yeah, the, the one key part here that I think is super important is don't disagree

silently. Right. Because there's something positive that can be, that can come out of you bringing up the topic in an agreeable way, but disagreeing. And then that way the people, even if they don't go your way and you're still a team player, that's a positive reflection on you, right? You didn't agree, but you still came together and did whatever the decided path was. And that is a reflection on how you work as a team. And that's,

that's important and probably something that a lot of people, and especially programmers in general, the either they're extremely combative or they're very internal, right? It's, it's usually one of the two. I'd say most programs I've met are, are one of those two polarizing.

Yeah. Alan is definitely internal. Totally've met are one of those two, polarizing. Yeah, Alan is definitely internal. Actually, if anybody here is, it's Joe. Joe's just like, whatever. I disagree so much with everything. I disagree with myself. Even a few minutes ago, I was encouraging

group lunches and also working from home on flexible schedules at the same time. I hold these truths 100% on both sides of my brain. Oh, that's awesome. And they're totally in conflict. So, backbone and commit is just a suggestion, is what Joe said. It is a suggestion, and it's truth true and it's also false.

Well, there's another great point that he makes in here though that like – okay, so the decision is made and it doesn't or not or whether it's reversed you can never ever say and i told you so oh that's horrible because even though your decision wasn't the chosen path guess what your decision wasn't fully explored as well as the decision that was made right so as tempting as you might be able to say, I told you we should have done X, Y, and Z, you really don't know. But here's something else, and this is just an observation of Joe in action over the years. Here's something that's...

Did you know that we were going to dissect you on the show here, Joe? Yes. Sit back. Yes, and know at the same time. Dr. Phil is here. So this is kind of interesting, and this is just an observation. So Joe really is not all that combative. Like, he's pretty agreeable on just about anything.

Say what? Mellow yellow? Pretty much. But here's the thing. It can play out to a benefit, though, for this reason. He's usually very agreeable but if he does raise a concern a lot of times are people like whoa this guy's bringing something up right this must be a big deal right like i i he never talks right right why is he speaking let's take

a step back here step back folks let's see what's going on. And I think we're giving Joe a complex like, I never talk. And it's not that he never talks. He's just very agreeable. I mean, we're right, right, Joe? Go ahead and agree. I'm wrong. Well, I also, I'm a big fan of kind of being patient like in meetings and whatnot. Because a lot of times, like if I hold a pen in strongly, if I just kind of hold my tongue long enough,

like the other people arguing out will sometimes come around to my way of thinking and you know if they don't i can always voice my opinion you know at that time but even better is sometimes they convince me that i'm wrong before i've ever even bothered to say anything so it's like ah i just thought of the most excellent example of this. Please share. So this is definitely more meta about the show again. But God, I don't even remember how long ago it was. It may have been six months ago or maybe a month or two more, give or take, that we had this great idea. And by we, I really mean Alan, to set up a design competition to come up with a new logo, right? And so all of these great submissions were coming in.

And I swear, if you ever want to test your friendship with anyone, try to agree on art. So especially when it's like a decision that you're going to make, like this is going to represent us. And so we would have these discussions, we'll call them for, you know, lightly. Call it lightly. Very low key. Angry hangout sessions. And I definitely remember that there were some times where more than once Joe would let Alan and I talk for 20 minutes. And then Joe would come to me like, yeah, I don't care what you guys are doing. This is what I'm doing.

And if it happens to fall your way, whatever. It would literally be to the point where both me and Mark are like, I don't even freaking care, man. You just pick. I don't care. I'm one star. It was like the old bickering couple right like the beauty of it is is we got to a really good design yeah i mean we at least like it we don't yeah i mean yeah yeah i love it i think we still need to uh update we still need to use it we were so completely destroyed by the end of it that we were like

man that logo is awesome. I'm not touching it. I'm not using stupid design. Yeah, I'm not touching it. This is so important that we have to argue over it for hours. Now that we have it,

you were just kind of tired. Oh, dude. I'm not thinking about it. So many talks of monkeys and plain looking logos. But hey, you know what? The stupid monkeys. Oh my God.

And dinosaurs. But you know what, though? Somebody went out and got themselves some business cards. Yes, they did. And it wasn't Mr. Alan Underwood. Or Mr. Outlaw. Whoa, whoa, whoa, wait a minute. Why are you throwing a hand at the bus?

That's so awesome. I actually gave out a good portion of them, too. Oh, really? Yeah. Nice. We need to get some. I need to go by the print shop. Anyways, all right, so moving on.

What is next? So I don't know if you guys check iTunes as often as we do here at CodingBlocks headquarters, but when we get lots of reviews like we have the last couple of weeks, we shoot way up in the rankings in like software and technology, which is huge for us finding new listeners. So I just want to take a minute to say

thank you so much for leaving us reviews. And if you haven't done so yet, we would really appreciate it because it is fantastic and absolutely crucial for us getting new listeners. So please do it and you can do it iTunes, Stitcher,

wherever podcasts are found. We actually have some links too on the website. So yeah, if anyone remembers the link, I would appreciate them saying it. www.codybblocks.net slash review that's awesome yeah we we really do appreciate those we're all about i can't stress that enough

this episode is sponsored by dev boot camp thinking about becoming a software developer check out dev bootcamp the original short-term immersive software development program that transforms those new to coding into job-ready full-stack web developers learn front and back-end web development teamwork and leadership skills in a rigorous and inclusive environment devCamp has several locations around the country and is accepting applications now. Visit devbootcamp.com slash codingblocks to learn more.

So, before we get into the last section here, one of you, I don't remember which, had brought up the poll from the last episode yep now neither of you cheated right i did not okay barely what so in episode 38 there was a video that we had posted that was uh you know and the question was how would you cross the puddle right and you had

three choices you could either hop around the side. Who knows what's underneath there? Or you could say, hey, you know what? No wake zone. Slow and steady. When does it race? Just walk right through it. Or you could just say, you know what?

Damn the torpedoes. Full steam ahead. We're plowing through this. Okay? Like a boss. All right. So, those are your three options which one do you well let me rephrase this do you want to just pick one that you think everyone picked or do you want to give

percentages like we did last time you just want to pick one i'll just pick one everybody picked the first one everyone picked hop around the side yeah all right what do you uh what do you say there joe i think that most people would not even notice it because they're listening to fantastic podcasts and thinking about other things so it sounds like you're in one of the last two options then. Yeah, I'm in full steam ahead. Yeah, he's blasting through. Full steam ahead. All right. And torpedoes. Okay, well, I'll put it to you like this.

You're both not wrong. Whoa, we have an even spread of percentages here? We do. Really? Crazy, right? But, yeah, it worked out this time to where those were the two popular options, and they were even. What was the evenness? Were we talking 40% each?

Yeah, yeah. They were like 41%. See, I was not wrong in my assessment of how that should be done. But you know what? Neither was I, which is you walk around the puddle. I have a more adventurous side i like how i like how your option was to just go through it but yet you picked that the audience would say to walk around well i think most people live on the safe side i'm more of the man let's just see what

happens yeah let's just step in the pothole all right man like right i mean it's a puddle for a reason let's just walk into it speaking of somebody, somebody on the Slack channel, and I don't remember who did it, they put up a YouTube video where they got this dude standing next to a pretty innocuous looking puddle, right? And he jumps in there and disappears. Right. That's why you don't step into a puddle. You don't know how deep that thing is.

It was amazing. Yeah, but come on, dude. You've walked down that street before. It's not like it was me visiting the city for the first time there in London and being like, I've never walked down that street before. What are you talking about? That's what I'm saying. These are people that are out for lunch.

You're assuming that they've walked this path before. Man, whatever. You don't know that. Yeah, if they're wearing flip-flops, you might want to skip that puddle because you don't want to get an athlete's foot. Oh, yeah. Gross. I've already got athlete's feet. These things are fast. I've had it for years. Oh, my God.

Oh, well. What was the TV show that we were talking about earlier? Oh, uh... You wouldn't tell me the name of it. No, I wouldn't tell me the name of it oh no i wouldn't would i that's helpful maybe you should have told me huh yeah remind me next time to tell you oh so much for that idea yeah uh there was something else i was gonna bring up too i really gotta start writing these things down that you're on gauge wait what yeah exactly

can't hear me can you uh you know we were out drinking hey watch it there the drums were so loud. Oh, man. All right, so here we go. Moving into the last sections. Judgment. Yes, judgment. Did you feel kind of like you were reading about the Terminator when you got into the judgment section?

A little bit. You know? A little bit. So how to trade off quality against development time. In the coffee... I like how we're already like, this is already a joke, right? You just write it and hope it's quality. There's no trade off.

You got to get it done. This has got to be done yesterday. Oh, this will be awesome. Now we talked about project plans. Do you plan on cutting corners ahead of time, or do you wait until the last minute? I think it's more efficient to wait. Identify a few areas that you probably know that you're going to skimp on ahead of time, and set the priority appropriately.

Oh, that's amazing. I mean, it starts off comical, but he makes the point of saying, you may be asked to trade off quality to speed the development of a project in a way that offends your engineering sensibilities. And I'm like, wow, you're not going to... Hold on. First off, it's not a you may be asked.

Yeah. You're going to be asked this every time. This is like death or taxes. This is a once a day thing. Yeah. Yeah. Get used to this one. Yep.

Oh, man. That's amazing. Now, did the copy that you guys read have the quote from Ninja Programmer? From, say again? Ninja Programmer? Yeah, yeah, yeah, yeah. Okay, cool. Yeah, I just thought there was a reference to Slashdot.

Ninja Programmer at Slashdot. Yeah, although I will say that Slashdot shows the age again, which I am fond of saying that sorry robert i don't know why i'm a jerk yeah well and you know for anyone that gets the commander taco reference how's that oh yeah um yeah i mean he says that you know um if this happens to you that you should inform your team and clearly explain the cost of this decrease in quality. Best to do this at lunch,

by the way. Well, no, the best way to describe that is just because it's just to say, this is our standard. Although he did say something that I didn't really agree with. And he's like, good design will help uh offset

poor code implementation and i was like yeah i don't really see that either i mean yeah design can help a little bit and it can aid in having better code but i mean bad code is just bad code like there's really not much you could do about it. Well, I mean, I kind of did understand. I kind of, I'm not sure if this is necessarily to the degree that he meant. But when I read that, I kind of took it to mean that, well, okay, let's say, for example, you need to write a factory. And maybe you didn't implement it in the best way possible. But the fact that you implemented that factory and now it's in use, at least we can refactor the factory. Right.

Okay. Maybe. So to make it more efficient without being a big overhaul to the entire application. Okay. Maybe. Right. So at least that was the way i read it yeah i mean the the fact is this entire title how to decide no wait where do you go sorry um the how to trade off quality against development time it's a fact of life period

it's just gonna happen there's nothing you can do you got to do the best you can with the time you have yeah yeah i mean it's so true it's horrible that we laughed about it but i mean it's literally it's it's what it is yeah i'm more interested in coping strategies for this and i do think that going to lunch and kind of passing around the wine stick is a good way to get to deal with this you basically you tell your horror story and then uh you know the person sitting next to you tells theirs and you just go around the circle over and over until you're late getting back to work yeah i mean he says you know if it's going to affect it if the quality trade-off is going to affect it QA effort, then be sure to tell your boss. Be sure to tell the QA team.

I do think it's a good idea to have some sort of note in the ticket like, here's how we could have did it, and here's how I did do it. Well, that's in the git commit statements, right? Right. Well, I still feel like that's a little bit uh passive aggressive though if you do that that's like it could be passive aggressive depending on the situation right like especially if it was you know a bitter going back to the previous you know conversation like you know if this is a a bitter choice that was made you know and and you make some comments like that it might not necessarily be uh well received yep yeah and i do think you know there is a way you can kind of reframe what

they mean by what you know what you mean by quality redefine quality to match what you're doing and basically uh you know we talk a lot of times about like minimum viable products and mvps and if you think about things as um you know basically doing what you need to do to get the feature out and then kind of iterating if it's necessary and, you know, not spending time on things that you may not need, then, you know, those can be trade-offs that are worth getting that item shipped sooner. But that's a pretty rosy view, I think.

But pretty accurate. I'd say extremely accurate. Yeah. Were you going to make some comment or reference to the Ninja programmer quote or just the fact that it was dating the article because it was slashed off? Just me being a jerk about it being dating. Although we did kind of reference it. Basically, the quote was remembering that good design will be resilient against poor code implementations.

And now, as Alan said, it kind of depends on what you mean by design. You know, if it means that there's a couple of bad methods, yeah, that's easy to replace. But if, you know, design is a really good user story, then that's really not going to protect you too much against the kind of implementation that might be behind it. All right. Well, I mean, other than to say that it was nice that there was some comic relief in the essay, let's move on to how to manage software system dependence.

Well, the 12-factor app? I don't know. I feel like we've discussed some of this. We have. And 12-factor app with the managing of dependencies was a nice overview of that. The one thing I did like that he pointed out was try to encapsulate portions of it so that if you need to swap out systems, you can. Sometimes easier said than done. You're not going to just switch from SQL Server to Oracle.

That's not going to happen. Not easily anyways. But there might be other things. There's patterns for it like the facade pattern or adapter patterns or that kind of thing to where you know you can build things to where it's easier to swap out components so yeah i mean to a degree okay so i do agree with that and i know that all three of us we've definitely done this before um you know i've seen your pull requests um but i've also you know there have been times even when i've done it that i felt like well this is speculative programming it is right right and and

so that's the one downside is like well like, well, how realistic do you think you're going to swap that out? Do you really think it's going to swap it out? Like, yeah, that's a tough one to weigh, you know. Well, speaking of weighing. Sorry, go ahead. Well, I was just going to say one last point here was that, you know, he makes the point of saying that encapsulating this does not translate to portability right right those are two separate concepts but make but the encapsulation may make the porting easier yeah i just wanted to point out um an interesting sentence here saying that the source having the source code

for a component decreases the risk by a factor of four, which I thought was a pretty interesting number. And the copy I'm reading didn't really have a good reference for that. Yeah, it didn't in mine either. And I was wondering where that number came from. And it almost felt like that sentence and paragraph kind of belonged to the managing third-party software risk section, right? But yeah, that was like a weird statistic that just came out. Did you just pull that out of thin air? I don't even know that that's completely valid either.

I mean, yeah, the number seems kind of, I don't know, made up. But I mean, so tell me this. If you had the source code for SQL Server, is that going to reduce your risk factor? No, of course not. You're not going to go looking at that. So it depends on... Define risk is one thing.

Like, if this is an open source project where you can actually contribute and make changes to, because in your SQL Server example, then you're not going to make the change. You're at the mercy of when Microsoft does a release. Um, well, I guess you could compile it yourself if you wanted to, but, um,

if you want to, to make the change, if you found, um, a bug, then your ability to correct that bug could be, could have a major impact in the usability or safety or protection of whatever your application is or does to make it, you know, still a usable thing. So yeah, having that source code could definitely reduce your risk.

If you're going at it from that point of view. It might take you some time, and I would actually assume that it would take you a lot of time to go in and understand that source code. Having been completely green to it, having no idea about it, you're just going to dig into it for the first time trying to find, okay, where's the entry point, and try to solve your one random problem. Yeah, that's where the increase by risk of four kind of questions, because it seems like it might decrease the risk by a factor of four, but the time is going to increase by a factor of ten. I don't know. Hard to say.

It depends on how big the project is, right? Yeah. That you're working with. I mean, you brought up the GLIB-C example earlier referring to the eight-year-old defect in the DNS that's been there for eight years. It's gone unnoticed. So depending on how big that library is it could definitely hide well one thing i did like and it was right here at the tail end of this was they talked about if you do like let's say you are working on some third party you have a new get package or something from you know some get repo out there and you find a bug and you

fix that bug great you've moved your project forward you probably should try and push that bug, great, you've moved your project forward, you probably should try and push that bug fix out so that it can be updated in that project, you know, put in a pull request to have it updated in the project, because here's what's going to happen if you don't in a lot of cases, that thing is going to diverge from what you have locally. And now you're having to try and maintain your local copy with any other bug fixes they've done remotely that don't include your fix. And that becomes, we've actually done this before, it becomes a mess trying to deal with a repo that has diverged from what you have locally. And, you know, so in most cases, if it's not against your company's policy, you probably should put in a pull request to try and get that bug fix put into the main product. Yeah.

Now, that's where it becomes a headache, though, when the company policy is that, like, no, you can't contribute to that project or it has to go. Your code change has to go under review by a legal team to make sure you're not divulging any company secrets. That's when things are frustrating, to say the least. I mean, you understand their intent, but it doesn't make your frustration any less. And it can actually cause you a lot of for lack of a better term technical debt down the road because like i said when those things diverge and you need the the fixes or the updates or whatever they've done now you've got a manually hand jam code into what you have locally and that's well it feels like policies like that in in a company kind of make the, I don't, I almost want to call it lethargic, but I'm not sure that

doesn't, that feels kind of like the wrong way to describe it. But when, when you hinder your, your developers abilities to contribute to an open source project, to even if it's fixing a problem, a bug in a package that you're using, but in order to do it, you have to go through a legal review, you're just disincentivizing people to bother with it. Right. Because they're going to look at it and be like, oh, that's too much hassle. And it's going to cause me a headache down the road, yeah.

And could you imagine if you had to do that, like if it was a one-line commit? Right. Like, you know, one line. And it could happen. I mean, it totally can happen that way. Yeah. But I do think that's important.

If you can, update the original source. Yeah, definitely. All right, let's move on. How to decide if software is too immature. Well, you can tell by the jokes it makes. They're all American pie-ish um you know i don't really think about software being too immature but i do think about frameworks being too immature i thought he was gonna call me out i was gonna be like what co-workers angular 2 is a perfect example for me right now like i've tried to mess with that.

I don't know how many times over the past six months, and it's too immature. It's just not there. The documentation isn't ready. There's not enough good fully baked examples. It's hard to get behind it. There's this great one-liner in here, though, that he says that using software other people wrote is one of the most effective ways to quickly build a solid system. And you think about it, though.

It's true. That's the way. I mean, we've joked about JavaScript, right? And all the different frameworks and package managers and everything, all the tooling that's required, right? And as funny as it may sound and as true as it may be but at the end of the day when when you're done with that like you wouldn't have wanted to code all that yourself right so think of all you know once you you do take the time and that you take that initial hit and investment and getting it set up after the fact.

Now things are going to roll more smoothly for you. So, yeah, I mean, a lot of these points that I mean, just real quick, is it vapor? If it is, obviously you don't want to deal with it. Is there an accessible body of lore about the software? Basically, do people talk about it on the internet, right? Are you the first user? If you are, it's probably a bad idea. Is there a strong incentive for continuation? That's usually a pretty good indicator of whether or not it's mature enough.

Has it had a maintenance effort? Is there anybody actually supporting this thing? That's a good one will it survive defection of the current maintainers yeah i mean how can would anything right i mean i don't know that one that one seems a little superficial uh is there a seasonal well i guess i guess what they mean by there though is if it's uh if the maintainers if it's a small group of maintainers and it's like they have all of the tribal knowledge around it, and then they move off to something else, then basically that project just died.

Yeah. Right? Maybe that would work. Is there a seasoned alternative at least half as good? That's a viable thing to think about. Is it known to your tribe or company? Probably important. Is it desirable to your tribe or company probably important is it desirable to your tribe or

company also probably important well if it's not known or desirable then why do you even care to use it now number 10 is probably the one that i find the most difficult can you hire people to work on it even if it is bad so this is one of the projects that I was leading previously. I ended up going with Angular because I actually spoke to recruiters and people in the industry and said, hey, what kind of people can I get to work on this project? Well, yeah, it was several technologies. They were thrown out.

There were several technologies I was looking at, and they're like, look, Angular, you're going to be able to find people. Man, they weren't wrong they weren't wrong you found you found people you get tons of resumes for angular experts right and this is what's frustrating i think in general in our industry is yeah you get them in house and it's like you don't know how to do this like what do you mean you don't know how to do this this is where you got to be careful about the questions you asked see you asked if i could find people right you didn't ask how to do this? Like, what do you mean you don't know how to do this? This is where you got to be careful about the questions you ask. So you asked if I could find people, right?

You didn't ask, could you find good people? No, I'm sure I did. Right. But no, I mean, that's,

you can, you can do what you think is all the legwork to figure out if you're going after the right thing and you still may not get to the right place. I mean, it's hard to do that. It's, it's the same problem that everybody has when they're trying to hire developers, trying to judge whether or not that person actually has a good body of knowledge coming in

is hard to determine in a lot of cases, especially if you're trying to hire fast. So, yeah. Yeah, so let's move on to the next section, which is how to make a buy versus build decision and you know very quickly he goes on to make the point that we should probably rephrase this this cliche term, right? Rather than saying, calling a buy versus build,

because if you, if you do that, then you're automatically making it sound like you're throwing out open source alternatives, right? Because you're not buying those. So, you know,

instead he's saying like, well, what if we were to call this and then obtain and integrate versus build here and integrate decision? And the integrate part, that's a key part of this process, right? Yeah, you might be able to buy something and you know there might be a software package that does something and does it beautifully but integrating with it might be a nightmare or you know add a lot of complexity and maybe even you know 80 of the features of that thing that you're going to buy are fantastic that you really have no intention of using. So why are you bothering to take the hit

on the integration time with it if you're really not going to use all of those features? But also keep in mind, we talked about this a while back in the licensing, and just because something is quote-unquote free doesn't mean there aren't ramifications to that. So you need to be aware if you are looking at open source. And by all means, I love open source.

It's amazing. But you need to be aware of the licenses. If you go and do a GPLv3 thing, you're now going to be potentially liable to open source all your code, which could be your potential trade secret in whatever software you're writing. So that's one thing to consider when you're looking at open source and, and that kind of thing. Yeah. And, uh,

we've, we've talked about open source licensing before. We don't understand it at all. But, uh, if you want to go back and listen to that that's episode five we still don't understand open source licensing and um enjoy that but some of the important parts here and i'm assuming probably all three of us have worked on integration projects with third-party software that you either obtain or whatever. Don't you always, I mean,

isn't that like every software project just about right. But one of the key parts that I thought that he pointed out that I full heartedly agree with is the, if you're not going to be willing to put, you know, X amount of time into evaluating it properly, like maybe 30 days or, or,

or 60 days or whatever, then maybe you shouldn't even be considering it, right? Yeah, I definitely, I like that a lot. If it's not worth you spending that much time researching it, then yeah, then it sounds like you've already kind of made your mind up or you're going to make a flagrant decision. Yeah, if you are not making a well-informed decision, it could be a very bad decision. Well, he makes a similar point back in the section on managing third-party software risks

about if you're going to consider using this, then you have to devote energy early in the process to evaluating it. Yes. Yeah, there were a couple of quick bullet points here i was going to go over about like um some of the things you know that he calls out in this this decision process of build and integrate versus build here and i'm sorry let me rephrase that the obtain and integrate versus build here and integrate decision and those were well how well do your needs match those for which it was designed? What portion of what you buy will you need, which is kind of what I mentioned where if you're only using 20% of it. What is the cost of evaluating the integration?

What is the cost of the integration? Will buying increase or decrease long-term maintenance costs? Will building it put you in a business position you don't want to be in, which is also a great point, right? Like if, if your business is selling t-shirts, right?

You don't need to write your own database software date. Writing database software is not what you do, which is kind what you do. Which is kind of interesting, though, when you consider companies like, for example, an Amazon, where they made an entire business out of cloud before it was even talked about. But yet, they were in the business of selling products. You know, getting, you know, basically it was kind of like a logistics thing. Buying stuff cheap, getting it shipped to the customer cheap, and then here are these other examples where it's like,

hey, what if we sell them some of our compute time? Yeah, we have some leftover resources. Right. What can we do with this? Yeah. Yeah. All right. Let's move on to how to grow professionally. The very first sentence here.

Assume responsibility in excess of your authority. So true. So true. I mean, probably the biggest way to stand out, right, is make yourself a bigger part of whatever you're doing. You know, stand out. Take responsibility for things. You know, take on a greater role. It is a big deal.

It's amazing how many people are like, well, how can I get promoted? Act like you need it, right? Act like you want it. Well, act like you have it. Yeah, yeah. Treat it like it's yours yeah i think amazon had like a weird rule where you were supposed to be doing the job for a year

before you actually got the promotion or something but um that seems a bit extreme but it is kind of interesting to think that um you actually kind of need to be doing the job before you get it yeah i mean this goes back to the cliche you know fake it until you make it. Yeah, I mean, this goes back to the cliche, you know, fake it until you make it. Right. Kind of mindset. But it did kind of bring up a question of like, well, okay.

So it says, assume responsibility in excess of your authority, right? That's the line you pulled out. Mm-hmm. But what if you have no desire to move into a management position? Right? Yeah. You want to stay technical, and you want to go as far up whatever your company's technical chain allows for. And if that does include managing some people then maybe that's okay but as long

as you're still technical you don't want to move into a management position for the sake of moving into a management position then it's well how do you not you're right you're like you can't you can't assume responsibility above your authority in that case because you don't want it. Yeah, that's a tough one. I mean, because a lot of people get pushed into that, right? Like you become the lead on your team, and then the next move is management, and that's not what you wanted, right?

Well, it sounds like in that case there isn't a role there that you desire. There's not a position that exists yet for what you want. Yeah, that might be possible or true, yeah, depending on the situation. Man, that's such a hard one. I guess I'm thinking of like – sorry to interrupt. But like I believe at Microsoft, the most technical position they have is a fellow, right? And I believe that was the same way at IBM, too. It was like, you know, fellow, once you got to that level, like that was as high as you could be technically

and still be in a very technical role within the company, right? So, you know, if your company has that type of path for you, then great, right? You can keep going to that. But if your company doesn't have that, if you're in a smaller company, which is the majority of the companies in the world, I think you move. I mean, it depends, right? And that's such a hard one because I've definitely seen HR structures where it's exactly what you're talking about. Once you get to a certain point, maybe it's not a company that's based around technology, so they don't have those paths laid out. And you really have two options. You either stay exactly where you are or you explore outside that company and you look for a place that gets you closer to

what you're looking for right and that's a tough one because you might love that company but there's no room for growth in what you want to do and i i don't know a great answer to that i really don't yeah that's definitely uh not so sure i like your answer. I mean, honestly, what do you do? I, in some cases, HR will take a look and say, okay, we, we do need to add another position that, that you can fit into, right? Like that can happen. And that means that you need to have open communication with your HR and your boss and whoever else may be involved in that decision. But, I mean, in a lot of cases, it seems like the whole thing is, especially in corporate America, you do get pushed into management. And if you want to be a coder, that's not what you want to be doing. And that's a really tough one. Yeah, I mean, we're engineers, after all, because we like to solve problems, technical problems. All right.

And, you know, if you're not growing professionally and you are also, you know, there's nowhere to go professionally and you also aren't pushing yourself technically, then, you know, Scott Hanselman always likes to talk about, like, are you getting another year experience or are you having the same year, you know, X times or the same years worth of experience X times. So, um, you know, sometimes you do have to think about what that means and it's, you know, you can talk to your boss about it, figure out, um, there might be something you could do or kind of change that role or create that role to something that better suits you and where you want to go. Well, I guess, I guess here's the way I could sum this up where, where I took issue with this section was that, um, you was that growing professionally doesn't necessarily mean changing your title. Right. Right? It doesn't necessarily mean assuming the responsibilities of whatever title is above you, right?

Right. And faking it until you make it. It could just mean being a better version of you. Right. You know, and learning new techniques and new skills and continuing to, you know, master your craft. And introspection, right? You constantly evaluate yourself. Am I doing a better job?

Am I getting better at communication? Am I getting better at managing my time? Whatever. It could be a ton of things, but actually reflecting on what you're doing as a person is useful. And maybe you even need outside help to find out, hey, am I doing a better job? Talk to maybe your team members or whatever.

That can be helpful. I mean, all those things can help you grow professionally. All right. So how to evaluate interviewees? Man, I'll tell you what. Yeah, did we talk about this? We have several times. This is so hard.

Yeah. Look, there was a statement here that I highlighted. Candidates are no more honest with interviewers than they are with themselves. And the human capacity for self-deception is astonishing. That's awesome. It is so true. So true. Oh, man, I know everything about sequel.

Oh, really? Here we go. You know, interviewing is probably one of the hardest things to do because, unfortunately, you're putting somebody on the spot. And so you're kind of playing God to a certain degree, right? Like you're judging these people in a short amount of time. And so you're kind of playing God to a certain degree, right? Like you're judging these people in a short amount of time. And that's frustrating. The best you can do is try and assess them in the best possible way for the role they're fitting. And this is one of the things that frustrates me about some of the big companies like, like, uh, the Googles, the Amazons, the,

the Microsofts, like they may interview every single software engineer exactly the same. Like they're going to have to be these mathematicians, right? But when you get the role, you know, you're plopping HTML on the screen. Oh, right. We talked about that before. And so my take on interviewing and how to assess somebody is come up with real- world problems that you're solving and what you're doing and try and give them to them in a way that they are almost open-ended questions and see where they take them, you know?

Yeah, there were a couple of points here that he made that one of them was evaluate their ability to learn. Right? But I kind of felt like that was a difficult one, too, to assess because teaching is, I mean, that sounds like what teachers do, right?

They relay information and then they evaluate how well you, you know, they give you ways of testing you on that information and then try to evaluate how well you you know they give you ways of testing you on that information and then try to evaluate how well you did it that's teaching is definitely a skill set in and of itself um that you know you either it's not something that you just immediately have but um you know he goes on to say that uh you how well people communicate and work is more important than being up to date

on the latest programming language. That one I really liked. Because how well you can communicate with that person and work with them is huge. Yeah. Right? Like, yeah. Okay, so they know Go, right? If you're not using go, it doesn't matter. Yep. I mean, yeah, they're staying up to date. So that's, that's nice. But what's it going to be like day to day working with this guy in whatever your tech stack is or gal. And then, uh, another point that he has here was that,

uh, you know, um, you know, uh, one of the readers of his, his essay had mentioned that he had good luck using take home tests for the interview.

He, yeah, no, uh, I, I've done one of those before and only one cause, um, there was another time when I was asked to do it.

And just, you know, I don't want to spend four hours, you know, kind of auditioning for your company if I don't like the company or if I'm not already really sold and really passionate about working there. And, you know, maybe that's an important distinction. You know, maybe you only want to hire people that are really passionate about working there but if you write kind of like standard line of business you know kind of boring business applications then you're gonna have a hard time finding people who are gonna you know want to spend their nights and weekends working on your takeout and take them test you know i guess in that situation you're here's the thing i like about this this section is that it takes some of the stress away from it right so so the interviewee isn't sitting in a stressful situation where let's be let's be honest like it's a hostile situation as the interviewee you're sitting you're sitting in unfamiliar territory with unfamiliar people, and then

you're being hit with a barrage of questions, right? That's a hostile kind of environment. And with the take-home test for the interviewee, you're removing that. You're letting them go back to their comfort zone, right, and relax for a moment and just solve the problem and at the end when it's over you get to evaluate well a are they able to solve the problem b how well did they solve it do i like what what what i see here are these good patterns is this horrible patterns like you automatically get an idea of what that type of developer is right away.

And if they don't solve the problem, then why didn't they solve the problem? But to Joe's point, right? Now you took what is typically a one- to two-hour interview, and you've turned it into a six- to eight-hour for the guy that's doing it. And there's value to that. And maybe if the person wants it bad enough, it's important to do. I mean, that's within each person to do. But I definitely see from the interviewer's perspective how that can be helpful, right? Like you get to see a lot about how a person thinks and how they organize things and just how neat or sloppy or whatever. Like their attention to detail can come through.

Right. And let's be clear though. This could all happen. This take home interview could happen before you've even met them. Absolutely. It could. So they could look at this and automatically know whether or not they're even interested in coming in the door.

So whether they even use your time or not. Right. Right. Because if they see the type of questions that are coming here, they're like, oh, man, I don't – this is way above me. Then they'll just immediately cancel and not bother, right? Right. So you're already weeding out some people before you even – I hate to say it as waste time, but before you even take the first moment to talk to them. Yeah, it's interesting.

That could be a bad thing too, right? You could be weeding out good candidates because they aren't going to be able to do that. They've got plans for the next couple of nights or whatever. And so you may be searching for employees with a certain skill set and only be finding one or two. And now you might be scaring them off you know um yeah i mean that that's true with you know if they have plans coming up and i would i would think that you'd be flexible enough that if so if they were to be honest with you and say, hey, look, I have plans, whatever they may be. I'm not going to be available. I'm not going to have any free time in the evenings or this weekend or whatever the case

may be until X, Y, and Z, which realistically, you wouldn't expect that to be maybe a week at most, right? A few days plus a weekend um so i would i would think that you could be flexible enough that you could be like okay fine you know when you when you are back in town or or when your free time is available let me know and then i'll send you the the uh, uh, homework assignment. And then, you know, we'll schedule your interview for the next day. Right. That would be part of scheduling the interview. I would think. Yeah. I just remember, um, on the, like the test that I was given, it's like, they gave me a couple of the, the one that I didn't take, I didn't do it. They gave me a couple

of days. I was like, Oh, you know, I'm not gonna be able to do that. I'm not gonna be able to work on this till Sunday night. And they're like, okay, well, just Monday is fine. And then when Sunday night had come around, it's like, well, I've been working. I've been busy kind of all weekend. Now it's finally Sunday night, and I just don't want to do this. I don't care enough about this job to do this anymore. So you'd rather just sit there and interview there? Well, I think it depends i think it's um depends on

whether it's a buyer's or seller's market you know i just for me i didn't want to spend my sunday night you know especially like i tend to kind of overthink and if you know if you tell me i have four hours to do something like that i start thinking like oh you know i don't want to do it you know too pragmatically because then you're going to think i don't know design patterns but i don't want to go too nuts because you're going to think I spent you know all weekend on it and so I get kind of stuck in this um you know it's kind of trap of you know stress that where I am not really sure just how much to do or not so I don't really like taking take-home tests so I think I'm put off whenever I um you know whenever that's an option if it's too open-ended basically is what

it boils down to like you don't know what to expect or or what they're expecting it sounds like i'm really looking for that job it's like yeah it sounds like you need to focus on how to balance brevity versus abstraction that's right uh but uh the the test i've seen so far um the two that i've done like we're both supposed to be done in around four hours, which is a good chunk of time, especially for a school night. Yeah. Yeah. Well, all right. Let's move on to how to know when to apply fancy computer science.

When hands touch the keyboard. Oh, when hands touch the keyboard. Okay. Yeah. Well, there you go. You guys keep a graph paper by your desk so you can work out some equations? Oh, you got it. How are you working?

Crew by induction. I think all the big O notation is commented in the comments like, you know, hey, we're about to go in log of N. I definitely think there are times when, um, especially the, like the traveling salesman problem tends to come up where you have some sort of scheduling algorithm or something that you need. And I definitely think it's a good time to kind of crack open the book and look at the algorithm. But, uh, that kind of stuff doesn't seem to happen too often, but if you find yourself trying to really design like a big algorithm, then I think it's a good time to kind of look at what's out there and you might find some really good solutions for something.

Or if something you're doing is just taking too long, then you might try a little Googling. Yeah, I mean there were some great comments here. And the sad fact is that for the majority of developers, a lot of the, as he puts it, fancy computer science is just going to be stuff that you're going to rarely use. More often than not. And I know what your gut reaction is as you're listening to me say that. You're like, whoa, whoa, that's not true. I am smart. I know my stuff. But come on how many times have you had to just like change

some fonts or change some colors or move something 10 pixels like that just happens and you know it's important it's an important part of the product overall too so it's not always going to be you know complex math that you're working on or you know i can't fancy computer science but um you know he goes on to say that that you know in practice this is wonderful stuff that's just too complicated and generally unnecessary it's kind of fair i mean it's complicated but unnecessary well depending so he did in what you're saying there if a well-isolated algorithm that uses a slightly fancy algorithm can decrease hardware cost or increase performance by a factor of two across an entire system then it would be criminal not to consider it right so

that's that's a good example right like if you can improve performance by a factor of two by doing some fancy algorithm then yeah you should well i mean he he makes another example that too that like there's no point in improving an algorithm when most of your time is spent making inefficient database calls agreed so okay fine but what if what if you are working on let's say the linux kernel or the windows kernel right like inefficient database calls are probably not your bottleneck right right so but but i guess this is where maybe the generally unnecessary comes in or you know rarely used because like well how many people are actually working on the linux kernel that's the thing right like if you are one of those guys and this might be necessary

right because you're writing the core of a system okay that's a little bit different if you're writing software that's using generally available libraries out there then probably it's not as big of a deal yeah and so like if your application involves a web browser then we're probably talking to you i mean right yeah i mean there's so many other factors there so i have a buddy who works for amazon that works in the networking stuff and amazon will buy basically commodity hardware like no name hardware because they can buy it for dirt cheap and they can put it in their systems he actually has to help program the algorithms on how to make the most efficient route from point a to point b okay he has to do fancy

stuff they have a bunch of doctorates. Well, that's the traveling salesman problem you're talking about. Right. And that's what I'm saying. So in that case, they actually do have a need for doing fancy things because they're trying to make these the most efficient they can through software abstraction. Right. And so, so yeah, depending on your job role.

Yeah. If you're writing webpage or web applications, yeah, this probably isn't going to matter that much. If you're writing low-level hardware drivers and stuff, yeah, probably so, right? Like, if NVIDIA comes out with a new card, right now the 980 Ti is like the creme de la creme, right? They come out with the 1080 TI next year. You better believe that the software engineers that are working on the hardware drivers are going to try and squeeze every bit of performance out of that thing, right? So it depends on your job role. So let's say that applying fancy computer science, let's say that the closer you are to the actual hardware, the more likely you are

to need it is that a fair statement i'd say that's probably very accurate the further away the further you are abstracted away from that so to the point to you're in a web browser for example then chances are it's not going to come in as often. It may come in. I'm not saying that it won't. I'm just saying that it's not going to be a part of your daily routine. I'd say if you amended that as well to where depending on, so not just the hardware, but the type of hardware, right?

Like we're mostly thinking in terms of computers, but if you're thinking of like IoT devices to where it doesn't have a lot of memory and a lot of, you know, CPU processing and that kind of stuff, then maybe there you have to worry about that kind of stuff too, right? But yeah, I would say generally speaking, if you're writing applications for like a computer, it may not be that big of a deal, right? It's more important about how it functions as opposed to the most crazy, fancy. Right. Well, by the way, you made the point of saying about the Amazon using the commodity hardware, they are not the only ones. Oh, I'm sure. Google famously, maybe, questionably, I remember there was a video or picture

of one of their first systems that Google started out on way back in like 98 or something like that, 99, where the case was built out of like Duplo box. Awesome. That's amazing. So, all right. How to talk to non-engineers? Well, first you get a podcast.

No. No, because everybody's engineers that listens to this. That's right. Actually, some of us, you, Outlaw, and I saw a talk on something similar at the security conference, Atlanta B-Sides. And the talk was called The Art of Speaking with Muggles. And I think it was a great talk. It was coming from a security perspective, but it's basically the same thing. And it talked a lot about the kinds of things that people are wanting to hear from you and the kinds of things that they care about and focusing on,

you know, communicating effectively in a way that they can understand and not getting lost in kind of the details and going off in the weeds. And so we're going to have a link to that in the show notes. Well, he definitely gets kind of opinionated in this section though, that, um,

you know, like Where was it? Thou shalt not use a shorthand. Were you talking about the non-engineers are smart but not as grounded in creating technical things as we are? Yeah, there was that kind of mindset. And this wasn't the first section that it was like this either, but he says that engineers and programmers are generally recognized in popular culture as being different. So I'm not sure if he meant like smart or just dorky. But yeah, then he goes on to say that non-engineers are not as grounded in creating technical things. And he also said, assume that you will miscommunicate,

be aware of your miscommunications. I think that's a good point. You know, a lot of times we were talking about intimate knowledge we have. And so it comes across in a way that maybe, you know, they take a different way and it's not accurate. I know that I have definitely been guilty of this in the past where maybe there's some topic where I'll get very passionate about it and very excited about it. And I will start talking about it and maybe just assume that everyone in earshot is on the same level as me and following everything I say. And then after speaking for some period of time, they look at me and they're like, I don't know what you just said, kid, but whatever it was, right on.

And you're like, kind of hurt because you're like, well, I just spent all this time. I thought you were with me. What happened? It's definitely something that you have to practice at because being so close to the details sometimes is hard to back off of that. Oh, yeah. Instead of that one-foot view coming out to that 10,000-foot view and being able to speak at that level, it's a skill, and it's something that

that requires some crafting so and it's important it's it's so important that's the reason why there are people that that end up being the liaisons between you know business people and engineers because some people can't make that leap so it's a it's a tough thing to uh to do properly and effectively yeah yeah i'll let you know uh as soon as i figure it out i guess i'm still an intermediate programmer because uh i uh have problems with this one as well yeah i mean i think that's like one that we just forever have to work on yeah i think a bad sometimes like i'll say something like this is going to take forever to do and they think maybe that means either um you know i'm gonna go spend forever tonight and do it when i meant uh there's no way

that i'm gonna do this well here Well, here's a test for you. I think there's like a subreddit on it. Explain it to me like I'm five. Oh, yeah. Yell I five. If you ever think that you are perfect at talking to non-engineers, explain it to a five-year-old. Yeah. And see how well you got them-old. Yeah. And see if you, uh, see how well you, you got them to understand.

Interesting. Right. All right. Well, that was, uh, this evening's take on how to be an intermediate programmer, uh,

which is, we'll have links in the show notes to, um, uh, the, the book by, or essay by Robert L. Reed. And what else? What are the resources we like here?

The book, essay, whatever, also mentioned an essay by Paul Graham, Succinctness is Power, and I thought that was a good one. Oh, yeah. I did have that. I've got a link to that. I had that one marked too one. Oh, yeah. I did have that. I've got a link to that. I had that one marked, too. Good call. All right.

Well, let's get into Alan's favorite part of the show. The tip of the week. It's the tip of the week. Yeah. I've actually got one that I can't believe I never thought to look this up prior to maybe a week or two ago. So if you work with SQL Server specifically right now, I'm sure all relational database systems have some form of viewing execution plans, but I'm currently speaking directly about SQL Server.

One of the frustrating things is if you have a just horrible query, and let's say this thing takes 10 minutes to run, which can happen. The execution plan in management studio, there's, there's a button up there that says show actual execution plan. You can do the show estimated, but I've found that for whatever reason, that thing is not very accurate. So I always do the actual. And what that will do is it will show you what SQL server is doing behind the scenes to optimize the query. So if you're joining five tables and it's going out and trying to get the rows, it'll tell you, Hey, is this thing using an index for this table? If it's not, is it, is it doing a table scan? Is it doing a seek of an index? Is it having to do a key look up? So it'll tell you all this useful information about how you can go and start attacking this

thing to speed up the query. Well, the problem is with that actual execution plan, when you hit run, you have to wait until that thing's done before it'll come back. So 10 minutes later and after you've hosed the server, you can finally look and see what was going on only to then try and fix something, run it again, maybe wait another 10 minutes just to do it all over again. So here's what is so cool there is actually a system table in sql server to where you can go query and get an execution plan link that you can click on and it will actually show you the actual execution plan so i'll read it out real quick even though it's not going to make a lot of sense. So basically, select query plan from sys.dm__exec__requests cross-apply sys.dm__exec__query__plan er plan handle, where the session ID is whatever SPID that you have.

So, again, I'll paste this in, but here's the beauty. You have a running thing. You can basically go do, as from a previous episode's tips, you could do an SP who to to find out what your spit is that's running and you should see it because more than likely it's spanned across multiple lines and you're eating up all the IO and CPU. You can take that spit,

plug it into this query right here. It will give you back a link that you can click on in the result set and it will actually open up the image of the execution plan that you can inspect. Now, in fairness, we should,

we should say, because we've had some comments on, on some of these things being specific. So this is clearly, this is SQL server, SQL server specific. Yes, this is,

that's why I said this will probably, there's probably other things in other database servers that do this, but this is specific to Microsoft SQL Server. And it's absolutely amazing. I used it the other day when Outlaw was trying to crash a system. Wait, what? I was able to find what was going on, and it was awesome. I don't know why you got to throw me under the bus.

All right. So, oh, there's a tip you could use Dense rank Oh Yeah I mean Good But you have one

Never mind Yeah Alright so Alright so Alan was trying to give me a tip But you know what Joe already did So

Joe threw out this great Idea The other day That You know I, hey, that's a beautiful one. One of us should mention it on the show. And it happens to be on one of my favorite topics. Good. So let's pretend that there is a file that, you know, you're going to change on your system. And you're probably going to change it frequently,

but you don't want to commit it, right? It's not, it's not something you want to, you bother with. And your alternatives is you could just, every time you're about ready to put a commit in, just not stage it. So in other words, don't do a git add on that file name. Or you could reset the file or, you know, or let me rephrase that wording. You could undo your changes by doing a git checkout dash dash on the file once you're done with it. But what if you just want to leave whatever changes you've made to it, but completely ignore it and not have git even try to prompt you to commit or stage this thing, right? So what you can do on that file name is git update-index space dash dash assume dash unchanged and then the file name right and what that'll do is it'll tell git to just ignore any changes to that file uh and so that it won't prompt you to commit it all right

there wait for config files if you have those right right so so So like database connection strings. Maybe you want to point to your own local database and not whatever was in some configuration that the team was using, whatever. Configuration files in general. So the one thing to be aware of, though, is that if you look in the Git documentation on the assume unchanged command, Git will fail gracefully in case it needs to modify this file when merging a commit. So you've made a change to it, for example, and you've saved your change, but you didn't commit it because you've told it to assume it's unchanged,

so Git hasn't prompted you to commit anything or to stage it. But now when you pull in a remote branch to merge it in to your branch, then, and that file has changed remotely. Well, then it's going to show up as a conflict, right? So,

uh, and gets going to tell you in that case. So be aware of that situation. But, uh, this is a nice way of being able to just have some local configuration file that you don't have to, that you could tailor to your local dev environment needs without having to worry about committing it. So, that's a permanent change then? Like, if you wanted to add it back to the index, you'd have to run some other command, I guess? Yeah, I don't know how you do that. That's a great question. If you want to undo that

so you would do a get space update dash index dash dash no dash assume dash unchanged and that will unset that flag. Cool. If I remember right,

was there a way where it would do it automatically? I thought there was. I thought you might be able to add it explicitly, but I've never tried it. Oh, like get add and then the file name? Yep. Interesting. Cool tip. Yep, I love it.

Speaking of tips, I wanted to give you guys a life pro tip here. Take warning. Today, maybe not today, everyone was. It all blends together. I ignored a JavaScript warning, which turned out to actually be the problem that was banging my head against the wall for an hour about. And it's one of those things like sometimes when you get a couple warnings whatever like you kind of ignore them and you're going to come back to them and whatever and you don't necessarily notice when a new one

kind of slips in there and so suddenly um you know i realized wait a second there's normally only four warnings here now there's five and this mysterious mysterious issue that I've been solving and having no luck on, or trying to solve anyway, slipped in there around the same time, and it fixed the warning and fixed the bug. So yeah, just take those warnings seriously. And in Visual Studio and pretty much any code tool, any sort of compiler that you're using, you can actually set usually a flag that will treat warnings as errors. And I definitely recommend that because if you don't, you will get warnings. They will be ignored and they will add up.

And so you know you'll be missing important things and important changes. So take heed. Cool. All right. So with that, we hope you've enjoyed this episode. And be sure to subscribe to us on iTunes, Stitcher, and more using your favorite podcast app. And, hey, like Joe mentioned earlier, please be sure to leave us a review on iTunes or Stitcher or whatever your platform of choice is if you haven't already we really appreciate that it's a surefire way to put

a smile on our face when we read those reviews yep also contact us with any questions or topics you might have and visit us at www.cuttingblocks.net where you can find all our show notes extremely thorough show notes examples discussions, discussions, and more. Yeah, and send your feedback, questions, and rants to comments at codingblocks.net. Join our Slack. Send us your email and we'll get you in there. And make sure to follow us on Twitter at Coding Blocks. © transcript Emily Beynon