Coding Blocks - Lightning Talks

Episode Date: July 30, 2018

We meet up around the water cooler for a quick round of lightning talks as Allen and Michael sing FizzBuzz while Joe passes the caching buck.

You're listening to Coding Blocks, episode 86. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And you can go to codingblocks.net where you can find show notes, examples, discussion, and a whole bunch of other things. Send your feedback, questions, and rants to comments at codingblocks.net. Follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood. I'm Jezek. And I'm Michael Outlaw.

This episode is sponsored by airbrake.io. When your website experiences an error, airbrake alerts you in real time and gives you all the details you need to fix the bug fast. And airbrake just announced airbrake insights a couple of weeks ago, which will connect trends and error occurrences with your code changes and deployments. It'll actually bring the source code in if you hook it up, hook up their GitHub integration, and it will correlate these hotspots, these files that have changed a lot recently around the same time the errors ticked up, and it makes it even faster to track things down. And like I said, bringing in that source code is really nice. So right now, CodingBlocks listeners can try Airbrake for free for 30 days, plus get 50% off the first three months on the startup plan. To get started, visit airbrake.io slash CodingBlocks.

That's airbrake.io slash CodingBlocks. All right. And tonight we're taking a break from the computer science topics we've been talking about to talk about a few more practical items. So we each brought a couple topics to the show tonight and kind of surprised each other a little bit. And so we hope you enjoy. And first up, we got a little bit of news.

So you want to tell us about it, Alan? Yep. So we have our reviews as always. So first, we'd like to thank those that have taken the time to do it. We've got IPA one 85, James K four 79, Matt PBO, madam robot, and Nick key.

And from stitcher, we have rich club, Brown, the dev and shake your app. And like Alan said, thank you guys very much for leaving this review. If you haven't already, we'd greatly appreciate it if you did.

Yep. I do have to say on Shake Your App, his review I loved because it said it reignited his passion for development. And honestly, that's what this podcast did for me too because I was kind of hitting a lull. And that was just awesome. I love seeing people say that it got me excited or I started exploring again. That's good stuff. And speaking of thank yous, I've got to give a huge thank you to Vladimir Vlados. You're out there, absolutely abysmal person.

You know, that's your screen name, but you're not an abysmal person. We love you. You've been a huge help on QIT and keeping me in order. I know it hurts sometimes when I am not able to commit something because one of your pre-commit checks has prevented me from doing something dumb, but I do appreciate it even if I gripe at you about it. So I want to take a minute to say thank you. Very nice. And so into the couple bits of news that we have, this one was brought up on Slack today and I actually saw it come across my Google feed the other day. There's this rock star programming language, which we'll have a link in the show notes. It's on GitHub.

But apparently it's a lot of fun. Like, Joe, I think you've looked into it more than I have. So you want to give a rundown? I haven't. Angry Zoot sent me the link, or she posted the link in Slack earlier, and so I was taking a look. But it looks amazing. The lyrics, the code, I don't know what you call it, but it's actually more verbose and easier to read, I think, than a lot of my co-workers' code. And the lyrics are

definitely much, much better than any of the music that I'm listening to. So you got to take a look at the syntax. It's really fun and really interesting and weird. A little background here, though, because I don't think this has been said yet. Basically, this is a programming language where the syntax of the language is lyrics from songs. Yes. So you're going to have to have a pretty good in-depth knowledge of some song lyrics in order to write a program in this. I think they wanted us to read like Fizzbuzz or something on here. But here's a loop.

Here's one that's kind of fun they say similar to the if statement a loop is denoted by the while or until keyword which will cause a subsequent code block to be executed repeatedly whilst the expression is satisfied so here's some code tommy was a dancer while tommy ain't nothing knock tommy down so that's the kind of code that you're going to see, which sort of hurts my head a little bit. Like, I mean,

you got to sing it. Come on. I can't say it like that. Okay. You sing it. I can't sing. Well, they actually have fizz buzz is already here.

So if you wanted to try it, Oh, we could definitely do this. If you're ready. I don't know how we're going to do it. I'm trying to figure out what the tune is for this. Don't overthink it, man. It's got to cover the soul.

This is rock and roll. Okay. You know what? I'm already overthinking this. EAB, man. EAB. Modulus takes a number and divisor. I'm not a rocker.

Put number as high as divisor. Put number minus divisor in the number. I didn't know you guys were going to embarrass me like that. Thanks, AngrySuit. Moving right along. Oh, yes. Limit is 100. Counter is zero.

Dun-dun, dun-dun. All right. So, yeah. You guys will have to check this out. It looks like a lot of fun. And so the next thing up that I actually think is really cool, this was something that was introduced back in January in the Edge version of the desktop Docker server, client, whatever you want to call it. But now they have moved Kubernetes into the stable desktop Docker app.

So now you have Kubernetes support and abilities in your regular Docker on your system without going to Edge. So that's really cool stuff. And don't forget, we're going to be talking about Docker and Kubernetes in our next community talk coming up here pretty soon. Yep. Really good stuff. So with that now, I guess it's time to get into this. So as Joe said, this is kind of just going to be our typical what we would have used to done with like our cubicle talk, right? So the one that I wanted to start with, because we've gotten a number of emails from people over the past month or so, maybe even a little bit longer. They're like, hey, I'm just getting started in programming.

What should I do? And so I thought this would be a good opportunity for us to kind of share what we think that maybe would help you out the best. If you're trying to get started, whether you're coming out of college or whether you're switching careers or whatever. So I guess I'll get the ball rolling. Like I think to me, probably outside of choosing the language you want to start with, um, you know, we've mentioned in the past, like look in your area, find out what's hot in your area. You know, if Java is the big thing, go Java. If it's C sharp, go C sharp. JavaScript is always hot everywhere. So that's always a good one to look at. But outside of that kind of stuff,

I honestly think one of the things that I've come to realize the more that I've developed over my career, data structures are so important. So I would say after you pick your language, learn about the data structures in that language. You know, if it's C sharp, your dictionaries,

your hash tables, your, you know, your collections, I just, man, like really learn those things because when you go to solve a problem, if you know the types of data structures available to you, a lot of times it'll make that problem a lot easier to solve, right? So that's instead of trying to cram something into an array, because you know that arrays are these lists of things that you have, you know, then maybe you'd be a little bit more well-informed about the type that you'd pick. So that, that would be my starting point. I think

you guys, you guys have anything? Yeah. We're in code where you're like constantly jumping over hurdles to get the data you need. So it's like every function you're like trying to get my objects dot whatever dot items. And then you're like looping through the array to get the data you need. So it's like every function you're trying to get my objects dot whatever dot items, and then you're like looping through the array to get to whatever you need out of it. You're constantly like writing a little helper functions or whatever to just get the data you need out of it. That's an example of where you might build or kind of arrange things differently. I think the data structures are really important, but also just the shape of your data, like

learning how to kind of separate things logically so that things that change together stay together and I guess vice versa. So I think that's really important. like learning how to kind of separate things logically so that things that change together, stay together and, and I guess vice versa. So I think that's really important. Um, but I guess that's kind of advanced. So maybe that's not really good getting started. Yeah.

I would just say, uh, it kind of goes back to the practice episode, like code wars, katas, things like that. Just like practice, practice,

practice, you know, like keep, keep working on that, that muscle memory, right? Like even if it's, even if you might already know those data structures, cause you could be like a, you know, a graduating college, you know, CS student or nearly graduating student. Uh, so you might already have a pretty good foundation on some algorithms, data structures, things like that. But you're trying to get prepared for that job and those job interviews, right?

And just working on through practice problems is going to help. Oh, I got a line I'm going to steal from Shop Talk. Just build websites. That's kind of true. If you want to do the absolute hardest thing possible, build websites right up there because there's so many pieces involved.

We're not talking about HTML, right? We're talking about application. No, I'm talking about HTML. Build a little HTML website and it's going to be terrible. You're going to want to add behavior. Ultimately, it's hard to find a job that doesn't deal with HTML websites in some form. So depending on how you slice it and what you're doing and what frameworks and WordPress and all that could be really different. But knowing that kind of the base, kind of how the internet and browsers work, I think it's really important for just about any job you're going to end up with.

You know, another thing... I always kind of viewed that... I'm sorry to interrupt. But I always kind of viewed it like... I mean, it really depends on what you want to do there, right? Like if you're like more low level, you know, device driver,

operating system level, like creating a website feels like it would be beneath you. Like that doesn't seem at the same level. Like you were saying, it would be the hardest thing. And I'm like, ah, is it really? Well, it's funny.

There's a lot of annoying things with building websites, right? Like cross browser compatibility. If you get into CSS, like there's just a lot of really, and I don't know that hard is the term I'd use as much as just frustrating, right? Like you're trying to make some drivers.

Yeah. I would imagine like really hard stuff. Um, you know, going back a little bit to the getting started to thing, though, like the Q, I think the QIT thing that Joe and, you know, they've all been doing. It's just an open source project and they get together on calls and they talk about code structure and what they plan on doing and the features and all that. Man, get involved in something like that, right? Because then you'll actually get to see how people are working through problems, right? These pull requests that go in, you'll learn how to use source control. You'll, you'll learn what type of features people are trying to add. And then, and then the problems

that they run into and, and they started off with unit testing, right? I think you guys have that in there or no? Yeah, just started adding a couple. I've been stuck in those. So definitely added after the fact, which is a little bit tougher and I've been slow about adding it. But it's been really great just learning

what like MVP introduced me to the actual testing libraries that we're using. Super good. Dave introduced me to the end-to-end testing that we're using. So, I mean, I've been learning a ton from this. So it's really not my project. I've done like a minority of the work at this point and I've just been like kind of hanging on and learning.

It's been awesome. But that's a great way for people to learn, right? Is to actually get in there and see how people are interacting and the type of code that's being written and that kind of thing. Yeah, for sure. Working with other people is really eye-opening and just really broadens your perspective. It's really different from working on your own. Have you guys ever interviewed interns or anything? Been a while.

It's been a long time since I've interviewed anyone. is, and it's fair, this, this makes total sense. They come out of school, you know, they've been taking programming for two, three years, whatever. And they, most of them not, not being mean, most of them just really didn't know how to write code, right? You tell them, Hey, uh, this is what I want. How would you model this? Right. And just what you'd see end up on the board. You'd be like, wow, that really doesn't make sense. But I get it because you've been learning about data structures and all that kind of stuff. So if you haven't put it into practice, you know, it's impossible. And so that's why I say the getting started thing is like, like outlaw said, you know, Kata's code wars, that kind of thing,

actually writing code that does something is way different than understanding what code is supposed to do. When you actually go down to sit down and write your own different ballgame, you can read an entire book and know what you're trying to do. And then you go to sit down and you'll be back in that book in five seconds trying to go to the page like, where did I see that? I mean, we still do it today. So that was my big one i i can't think of anything else i mean networking is also a big one uh outside of that right like go to meetups uh talk to if you're in school talk to your professors go to the to the job fairs and all that kind of stuff if you're trying to switch careers, surround yourself with other programmers, you know, whether it's in something like our coding block Slack channel or meetups.

I mean, you get a meetup. There's always recruiters there. A lot of the meetups that I've gone to, you know, the well-organized meetups, they'll usually have a portion of the talk, you know, either at the beginning or the end where they allow recruiters to, or anyone who's like maybe just representing their company looking for, uh, you know, potential hires to list out, like what type of job opportunities they have. And if you're, if you want to talk to them, they'll be available after the talk, uh, you know, to, so you can learn more about it. So meetups are a great opportunity to get out there and network and find out what else is going on

in your area. Yeah. You'd be amazed at how many people, especially in our space programmers, like just try and stay hermits, you know, stay in their house, stay on their keyboards. Man, talking to people, getting into rooms with other people can really open up opportunities. So, you know. But what if you live really far away? What if you live in Alaska? That's a hard one. What then?

I mean, do you like I said, I think at that point you also get involved in communities online, right? The coding block slack. There's there's other things as well. Get up, right? Get get involved in open source projects. It is tougher when you're more remote, but I'm sure there's ways to find out, right?

You might even, heck, you might even post an ad on Craigslist or something. Try not to get mugged and be like, Hey, anybody interested in getting together and talking about software? So I don't know. Be creative,

right? That's the key, but surround yourself with it. Get, start playing with it. If you have a project that's in mind, try and make it, you know,

as simple, as simple as it might be. Yeah. Oh, go ahead, Joe. I was going to tack on that. You know, it's it's hard to find other people as awkward and it's weird. It's not easy, but it's never I like to always say it's never been easier. Like we've got this great Internet thing out there.

You can probably find like 10 other slacks in the coding blocks for programming type communities within five minutes of searching. So you can find something that aligns with your interests and just put yourself out there. Be cool and give it a shot and who knows? Yeah. You made your comment about the

programmers are hermits or something like that. Yeah, they try to be. And no one to stay at home and whatnot. I found this, I posted this in the jobs channel of our Slack, but there was this article trending on Reddit in the programming subreddit about a job board for only remote developer jobs. And you can go and search for like,

you know, whatever language you want, like work from home jobs just in your area. Like it's a east vox.com E A S T V O X.com. And yeah, it's pretty neat. That's awesome. That's really cool. It's pretty crazy to think that that exists now, though. The world is a changing.

That's for sure. Oh, I guess the, you know, the last thing I would say is also kind of know what you're interested in. This, this might sound really stupid, right? But I'm sure that people, you know, I said, look in your, look in your area for what types of jobs are out there. Maybe that's not what you need to do. If you want to make video games for iOS, then start there. Right. It's, it's a no, no, what you're going to be passionate about and what kind of things will drive you to completing something. Right. Because we've all talked about it, creating side projects and even trying to get

them done or even, you know, staying with them for more than a month is sometimes really hard. So finding something that you're very interested in will help push that ball forward. Yeah. And if you are still having trouble with that, you can always build a website for whatever you like, like riding bikes, make a bike website. Find some data, throw it in a database. I don't know. Ask me. Just tweet us or something

and say, what should I do for my side project? We'll figure something out. That's a good point. Yeah, we'll tell you what we want built. Exactly. That's what I have with QIT. That's awesome.

All right. So let me ask you guys this. Have you ever wondered why arrays start at zero instead of one? I probably have. I think I know. You think you know?

I don't think I ever cared enough to look it up, but I probably had that passing thought like, why isn't this one? So this came up, I think it was in like a dev 2 that i found this where there was a medium article and the headline just the the title was like clickbait enough for me like oh yeah let me click on that but it was like why do arrays start with index zero right and uh like you alan i'd never cared i was whatever who cares but then the answer i was like, whatever. Who cares? But then the answer, I was like, oh, yeah, that totally makes sense. So, okay, first of all, let's get this out of the way. There are some languages out there where their rays do start at one.

Cold fusion. All right. So we'll forget those for a moment, all right? All the COBOL programmers are like, hey, wait a minute. We start at one. And, yeah, we're not talking about that. No one's proud of that. Yeah.

But for other languages, let's start like C-like languages, right? It's an offset. So if you have an int array, then the pointer, the address of the first element is the same address as the beginning of the array. It's the same. Uh, and the second element would be the size of int offset away from that. So it'd be one away from it. Okay.

That makes sense. So it's really fast to know if something's at the 16th, that you just take 16, multiply by the size of whatever's stored in there, whether it's a pointer or an integer or whatever, and there you go. There's your memory address. So it's a hardware-based thing, basically, is what it boils down to.

For true arrays. Addressing, finding the address space. Now, some languages get funky with what's in their arrays and how their arrays are actually put together. Maybe they're actually vectors or linked lists under, under the hood, like JavaScript, but in like a true kind of C style language, like you have to declare the size of the array when you create it.

And that's because the size matters and how you jump around and, and add those indexes together. It really matters. Very nice. So I just thought that would be like a good, like a little reminder. Cause it probably been a minute. Yeah. I haven't thought about it in a long time yeah so then i had this other thought too though uh like

you know we talk about code smells a lot right and and i think we've even said it and i definitely know i've heard alan mentioned this recently uh but you know good good, Oh, Oh, Oh, good practices in your Oh, Oh, code make for horrible sequel and good sequel practices make for horrible Oh, Oh code. Right. Yes. Um, so then I got to thinking about like, well, Hey, then is it a code smell? If you have a stored procedure that calls other stored procedures, and those might call other stored procedures, is that like a code smell? Because then you're treating your stored procedures like they were functions in any kind of other programming language.

Joe? I just can't say anything without shouting. But no, it's so, it's so hard to work in SQL server and probably all the others. It's really hard to work with like the results that you get out of store procedures. So it's really hard to even use store procedures from store procedures and

functions are not easy to work with because they can't modify data. Well, so, well, no, outside of that though, it's, it's the whole modularity thing that he's talking about,

right? Whether you're in my SQL, SQL server, server postgres whatever yeah good luck here's the problem i think it is a code smell and it's so unfortunate right because if if you're trying to make database operations as fast as possible then it makes sense to duplicate code. In a nutshell, that's really what it boils down to, right? If you're trying to go for maintainability, which is this whole stored proc calling into the stored proc with use of functions and whatever, then that makes sense, but you're going to take a hit, right? Because like a function, depending on how they're used or whatever,

that thing might have to be called for every single row that comes back in your result set, which is slow because that's an operation on every one of them. But you wanted to be able to reuse this thing in 20 different places. So do you copy out whatever? I mean, the function one though, I've got a total workaround on how you can get around that though. Okay. you could just get the results of the function into a temp table and then join on that temp table in your other table that way you're not recalculating that function over and over you could do that you could take the hit of calculating the one time so you still have the function that you can reuse in all your other procs but yeah it just there was there was some a code base that i was looking into and it was like you know one store procedure calls another

store procedure and then that store procedure calls another store procedure. And they're like passing around user defined types all over the place. And, and I'm just like, man, this feels like it's gotta be like, we're treating stored procedures like their functions in any other language. But that kind of feels wrong.

Yeah. But I understand the intent. I understand why, like you said, like it's, it's about maintainability, but at the same time, it's like, eh. that you're going to massage, right? The one item, right? I'm going to modify the Mike object or the Joe object. That's how you think. When you go into the database world,

you have to think in sets because that's how it is optimized to run. And the problem is, is crossing those two is typically a bad idea because if you have a SQL statement and those tables are indexed a particular way to work that way, well, then you probably need to write your SQL to be that way every single time. When you start cascading that you called that product because it was going to give you this

result set, but then you call another product to give you another result set, and then you're going to join those there. You probably lost a lot of the efficiencies if you had just gone and joined the tables yourself, right? So it's, man, it's frustrating. And I hate this answer, but I honestly think that the better, if you're going for performance, it's better not to pass around shared or common code, right? So everything you've learned about clean code from Uncle Bob, throw it away when you start writing your SQL. That's what I'm hearing.

For sure. Yep, absolutely. You'll just go crazy trying to reconcile those two. I mean, like, have you guys found anywhere where that wasn't the case, where you would have rather seen the functions or has it ever not bitten you having an OO type approach in your database?

No, no, it does never worked out well for me. Okay. And SQL is great. Like I know I tend to pick on SQL. It's fantastic. It's used by like everyone and, you know, forever and will be used forever and ever. But, uh, it's definitely got some downsides when it comes to maintainability. You know, that's what it is. But I will say though, that brings up another question,

I guess without going too far off topic here though, we've talked about this in the past. Do you put your logic and whatnot in the database or do you put it in your application? Maybe if you're putting it in your application, you don't have to worry about this stuff as much, like you have some sort of service layer that's helping with that. Or do you put it in your application? Maybe if you're putting it in your application, you don't have to worry about this stuff as much, right? Like you have some sort of service layer that's helping with that. Maybe. I don't know. Depends on what kind of logic we're talking about there.

Like logic can mean a lot of things to a lot of different people. It can. If you're putting your logic in store procedures and you're implying the database is the heart of that application and that ecosystem. And if you're okay with that, then you're okay with that. But if you want to start introducing a search engine or some other data storage mechanisms, or now you've got different types of databases and you've got a really big type application or ecosystem, then it's hard to really have one system that's at the heart of it. And so that kind of falls apart.

Well, it's not even just the heart at that point. It's your heart and your brain, right? Like it's all of it. It's the entire organism, right? Yeah. So here's where, and this is where some of my thinking goes. So I recently tried to do a little thing to where I was pulling out data and it was joining two massive sets of, or actually many tables together. And all I was trying to do was pull data out. And it took hours because I'm

joining millions of records against millions of records against, you know, another hundreds of thousands of records and just trying to get all that stuff together. It was struggling. Now, granted, you can beef up the hardware, but there's only a certain point that you can do that, right? And it gets really expensive. So this is where I'm going with the whole application thing. And one day I want us to talk about this stuff in depth. But like Kafka streams or any type of MapReduce type problem, if you're talking about like Hadoop or something like that, in Kafka streams, what you can do is you can pull in a stream of data from a table. So you're not joining all your tables at once, right? Like you're not trying to join 10 different tables and get that stuff out, which is an expensive

operation. You get a stream in that contains the table information for one, right? And as data comes in for another one, the streams, you'll have a bunch of little applications running everywhere that puts that data together, mashes it up, and then sends it off to wherever you want it to be, right? So it can actually be faster than hitting your SQL or your relational database trying to join all that data together because now you have a bunch of little applications that can quickly chew through that stuff, right? So it's an interesting concept. I just bring that up because if you do it that way, you're actually writing applications in an OO type way using streams as opposed to, you know, trying to modularize your SQL database or your relational database type thing.

Yeah. I mean, you know, hitting on a point that you made a moment ago, one of you guys made about the – oh, shoot. Now I even lost my train of thought. You hate it when that happens? It's gone. Uncle Bob, central nervous system. No? What was it now? Uh-oh.

Functions, modularity, maintainability. Something to do with SQL. Indexes. No. It'll come to me got nothing yeah yeah but i agree it is a code smell it's funny it's a code smell and that you know that performance is going to suffer but it's the inverse of a code smell because you now have maintainable code in sequel right so i remembered it now. It was about the, the, the heart of it, the central nervous system, the heart of it. Like I'm all for, you know, not keeping that in your

database. I like that idea because, you know, one thing that we've learned over the years, right, is that you can only scale, like take SQL server, for example, let's beat up on SQL server for a moment. You can only scale that thing, but so big, right? You can only get so much of a server for it before you just can't buy any more hardware, right? You know, because the next version of whatever, you know, faster memory or faster SSD or whatever you need isn't available yet. Right? So if you keep that in your application tier, then you can, you can spin up more servers, right? So you can scale horizontally instead of vertically. Right. So I like that idea, but yeah, it was just the main thing that the, the main theme behind this though, was like, at what point, at what point

do you try to recognize that, Hey, I think we're treating this SQL like it was any other language and we should put a stop to this. We should recognize this as an anti-pattern and stop. I agree with that. But then that begs the question of, well, how are people going to try and fix that, right? Then people are going to start storing their SQL in tables and have it try and create things, right?

Yeah, I wouldn't go in that far. Well far well no that's the commonality right like if you people don't want to duplicate code right like it's almost even sql developers don't want to duplicate that code but a lot of times you have to to make it performant so well okay this is a great point, because it's, why do we not want to duplicate code? Because it's been ingrained in our head that it's badant. And you might think, oh, I'm duplicating code. But it might not be. Because if it changes for different reasons at different times, then it's not true duplication. But I don't think that's the case in SQL. What you're saying is absolutely true when we were talking about the O stuff. But I would venture to say that if you're using the same where clause all over the place

because that's how you have to filter your data down based off some business rule, you're duplicating it, right? To make it fast. You're inlining that code to make your query perform well, right? But maybe, but I'm thinking of the case where like, maybe you, maybe you have a block of code where you are, you know, doing some pre-selection of data and you're putting it into like a temp table or whatever, or a CTE. And, you know, you might be tempted to like put that into some other, you know, store procedure that could return it back or whatever so that you could like, quote, de-dupe it. But it might not be a bad thing if you had that same section of code in a second proc, in a second store procedure, right?

Because then if the first one changed for a different reason and the second one was okay to leave it as is, you know, those are changing for different reasons. But then there's the inverse problem where they were supposed to be the same, but somebody only knew about the first one and changed it. That's where it gets complicated, right? This is hard. Can we just stop? Well, to be fair, too, like 99% of applications aren't going to run into horrible scaling problems with SQL Server

or whatever SQL database they're using. It's going to be fine for whatever website or whatever small application they're doing, and they're never going to run into these. They're never going to run out of hardware for the application they're doing and they're never going to run into these or, you know, they're never going to run out of hardware for the application that they're working on. You don't think so really though? I would say 99% of applications don't have to go to like Google scale.

No, I agree with that. But I do think that at some point, like I've seen it in so many different things I've, I've worked on is there's, there's a breaking point when data reaches a certain level to where it's like, everything was fine yesterday and today it's not.

It's hitting the wall. I mean, listen, man, I can write enough bad queries and add enough indexes to any query to make it perform bad enough to where you'll think that you're at Google scale. Just, just give me five minutes with your query.

I mean, I guess that's the thing, though. Like, you're joking about it, but it is true, right? And I'm not talking about, like, your typical WordPress type site or anything like that where there's a database behind the thing. But I think that a lot of times, especially homegrown applications, they grow to a point to where it's like, wow, this thing performed great and we didn't expect it to be in use a year and a half later. And now the data has grown out of control and now my modular SQL doesn't work so well. Now we've got to revisit this and get rid of the modularity and go more

performant. So I don't know. I think it's a great topic. It makes you wonder then if you have to pass around user-defined types, is that a code smell? They're no fun to work with, so I'm going to say yes. They're stinky.

You just got to make those generic user-defined types. Ultimately, I think they're a good thing. Like user, I don't know what it's like in other databases, but I know in SQL server, uh, it's annoying to work with because of how you have to kind of fill them in

and work with them. But ultimately it's good. Like you add a column and like, it lets you know every single place that you have to drop and recreate in order to even work on it. So it's good for maintaining that kind of type safety, which I'm a fan of. At least they used to be until I went full on JavaScript.

All right. So we have, we have blank topics for Joe. What's this one? Do you guys listen to the indicator? It's the podcast from planet money, short little topics, economics.

Never heard of it. No. Okay, good. So they play a game called a Under sometimes where they'll bring on a special guest and they'll ask them about a particular topic or question and they'll say, is this underrated, overrated

or, you know, kind of meh. So we're going to play Over Under. And we're just going to go in alphabetical order. Well, no, not quite. We're going to go Alan, Outlaw, and Joe, just to make things easy and consistent because i got a bunch of questions here wait you're gonna ask yourself a question

how's that gonna work well i want the answers oh you'll see it'll be fine all right so yeah i've trapped you guys all right so So first topic, remote work. Alan, underrated, overrated, or? Wait, what was it? Just fine. Remote work. Remote work. Yeah.

Is it overrated? Oh, hmm. Just fine. Okay. Outlaw. Yeah, I'm in the just fine category. Yeah, I think it's about right too. What about standing desks?

So there's just under, over, or just fine? There's not awesome? No, awesome would be like, I think it's awesome and people don't even know how awesome it is. So that would be underrated. That would be underrated. Underrated. Okay. Because I have standing desk envy, I guess

I have to say underrated. Yeah, I'm going to say under too. I love mine and I think that it's way better than people think. Agreed. It's going to start getting harder. Yeah, I mean I have like a ridiculously expensive ergonomic chair and I spend so much time seated in it that it's still like I have to get up because it's like, God, my butt hurts. Why?

Well, hey, that makes for a good one. What about fancy chair? Alan, over, under, or fine? Fine. Okay. Outlaw. i guess overrated you think it's overrated isn't like people think it's too good oh well i mean like that's why i'm that's why i'm going with the the wanting the standing desk right it's because i have the chair okay you know i have i have a herman mill Herman Miller Aerion chair that I sit in. And yet, you know, because my doctor was like, yeah, no, you have to go out and get an ergonomic chair, right?

And so, like, after looking around, I was like, okay, well, I guess this is the one I need to get. So, you know, it's a stupid amount of money, but fine, I'll buy it. And now, you know, I still spend so much time seated in it. Then it's like, oh, I'm still in pain. This thing's overrated. Yep. All right. I mean, I love the chair. Don't get me wrong.

What about you, Joe? I think they're overrated, but that's just because I don't really care much about it. I'm not spending 500 bucks or up. But man, I will say, I got to add a little bit to this. It's not overrated because a quality chair doesn't creak and pop and it'll freaking last a long time like there's other benefits to it right like a hundred dollar chair will last you a year and you're going to be tossing it right oh yeah so yeah i don't even know how long i've had this one yeah i've

had it forever yeah that's the thing like you buy a quality chair that's why i don't want to say they're overrated i think it's a yeah i'm not trying to swing your vote but yeah all right but he's trying to swing i try to swing your vote, but yeah. All right. But he's trying to swing. I try to swing your vote. Not trying to, but you know, if he happens to, that's just coincidence. So what about MacBook pros? Oh man. Nowadays I feel like it's over and I hate to say that, but I think they're overrated for the, for what do you get? As soon as they, as soon as they, well, I want to say as soon as they introduced the Touch Bar, they were overrated. But honestly, I kind of feel like as soon as they went Retina, it went overrated. Because I still feel like my model MacBook Pro was the last good one.

Where you could upgrade it. Yeah, where you could open up, you could change out the memory in the hard drive if you wanted to. Yeah, it's a little bit thicker because you has, you know, you can plug an ethernet cord into it without a dongle and yeah, you know, it's got a DVD player, but you know, I love the retinas, but yeah, those touch bar ones, especially overrated. Now, now they have the I nines that overheat. Well, they fixed it. Apparently they've software software, but there was somebody that actually went and Now they have the i9s that overheat. Well, they fixed it, apparently. The software?

Software. There was somebody that actually went and did a video, and they showed it after the update. And it's fast. But, yeah. So, what about you, Joe? Over, under? Over. Over.

Yeah, three overs. That's sad, man. I know. What about programming books? Ooh, programming books. Underrated. Under. Okay.

I think so, too. Okay. So you know what the next question is. Which programming books are we talking about? Are we talking about a particular language, or are we talking about some of those, like the Clean Code series, that span any type of language or topic? I meant either one. Up to interpretation. Sounds like we're all on the same page for the most part. Yeah, they're valuable.

Well, because I also think of books like books on Git, for example. Git isn't a programming language, but there's books on it, right? And the Angular 1 book I've got isn't very valuable anymore. What about online courses?

Underrated. I'll go with under also. It depends on the price. I'm going to say just fine. Okay. There's so many free ones, though. There are, and that's why. Video, I think, is great.'s i think everyone knows it's great i i've been a big fan of corsair

here lately going through their catalog uh so yeah i mean and just like the amount of free stuff that you can get from like legit serious college universities that are out there. They're putting this content out there that you can go and take this class for free and learn it. It's unreal. It's insane. Well, speaking of colleges, what about algorithms? Learning algorithms as a programmer.

I think it is man if i was in school i would be like overrated i think now that i've been a developer for a while i'd say it's underrated how about what you think yeah i'm somewhere in that i'm somewhere in that ballpark with you i'm somewhere between underrated and just fine yeah i'm somewhere in that ballpark with you. I'm somewhere between underrated and just fine. Yeah. I'm somewhere between that. So whatever that is. Under fine. Like it's just under.

Under fine. What about you? I'm going to go with fine. I think there's pros and cons. Some people really need them. Some people not so much. And so I'm just going to say right in the middle. I like it.

What about native apps? Like if you were to develop a native app. Overrated. All right. I'll wait for his answer. Just fine. Because if it's a game, just fine. I'm going to go just fine.

I'm going to say over. Here's my reason. Unless, okay, let's take games out of the equation because, well, I mean, games can kind of come into this equation too. Unless you need a specific, you know, some specific subsystem of the device, then I think that you can get by with just a web app just fine. Probably. Take out the marketing side of the equation where marketing is like, no, but we want the icon on the phone. That's important real estate to us. So take that part out because that's about feelings. And we're not talking about feelings here. This isn't a feeling

show. But if you... And by subsystems on the phone, I mean like if you need access to GPS data or you need, you know, a jet. It's hard to even reach because nowadays you have access to most of that, right? Yeah. So I'm trying to think of one. So games might need to actually get to lower level systems because they might want to get to something like, you know, shoot, I keep thinking of Core ML. But what's the other one? GL? OpenGL? No, uh, you know, uh, shoot, I keep thinking of core ML, but what's the other one? Uh, GL open GL or no, no, no. On iOS. I'm trying to remember the iOS stack, but I can't at the moment, but yeah, that's what I'm thinking. Like, you know, you, you might need to get to that,

um, metal metal is what I'm trying to think of. Um, you know, that you need to, you need to have access to that framework, that library in order for your game to perform. So I would include games in that category of you need access to a specific subsystem. And in that case, the subsystem might be the video processor that you're not going to have in a browser. You said fine, and Joe, you also said fine.

No, I said overrated. You said overrated too, right, Joe? Yep. Nicholas showed me the way I'm fully on board with PWA because I don't want to install another app. Let me just use the internet. Yeah, true that. Wah, wah. Relational databases.

Just fine. All right. Me too. Yeah, I think that's fair. I think they're important. They still play a crucial role. I think that in some places they're way're important. They still play a crucial role. I think that in some places they're way overused and other places they probably should have been used.

So, yeah, they're just fine. What about NoSQL? You didn't know this was going to be a painful episode, huh? Document DVs in general. I would say underrated. I want to say under. Maybe that's just because my current. Yeah, what we work in.

Man, I think I'll also go under because I think just a lot of people grew up in the relational world and they don't understand the place for the document world. Fair enough. What about. No, you didn't answer. What was yours? Oh, I'm fine with it. You're fine? Okay. Yeah.

I think it's one of those ones that averages out. Unit testing. Underrated. Under. You? Under. Okay. I mean...

It's hard, though. So, I'm tempted to say fine. No, but that's good to say fine. No, but that's why it's so underrated though. People don't, don't understand the value of it. Like if you take the time to break out your app enough to where you can write unit tests on it up front,

you know, like what, what that buys you long term in regards to it, not having baked in dependencies and you know, the portability that's going to come with that. Yep. Not to mention the maintainability of it and how fast you can iterate on it.

Totally underrated. What about Docker? Oh, man, that's so hard because I want to say underrated. The hype is high. Yeah, that's what I was going to say. The hype is so high. So I'm going to go with fine. I don't think it's overrated.

I think it's important. So are we talking Docker or are we talking containers? Docker. Same, Docker. I'll still go fine. Man, yeah. I guess I'm in the fine category. You, Joe?

I'm fine. Okay. I think there's a lot of hype, but I think it's really the fine category. You Joe. I'm fine. Okay. I think it averages. I think there's a lot of hype, but I think it's really important and interesting. So, yep. What about TypeScript?

Hmm. We're almost done. I think it's underrated. I don't know, man. That's the thing that you like about JavaScript is that it is loosey-goosey. Yeah. I love it, but I've heard enough people say that they were able to speed up development by 2x

because I had type checking and just the safety built into it. So you took away all the things that made JavaScript awesome to make it work like every other compiled language. Sort of, yeah. So it sounds like Outlaw, you're over? Yeah, I am kind of leaning more towards the over, but I am kind of finding it humorous, though, as i listen to myself because i'm like man i'm pretty sure if we go back to like the early episodes like coding blocks year one i was totally like hating on javascript and it's loosey-goosey and everything but now it's like okay fine don't take all that away from it yeah let it be man it never hurt you what about joe what was yours on typescript i think it's fine

i think that um you know possibly a little bit underrated like i i'm glad it's fine. I think that possibly a little bit underrated. I'm glad it's out there. I think that ES6 is really cool. I'm kind of personally more excited about that. So I'm not that excited about TypeScript, but it's kind of nice to have the option to do some static stuff if you want to. Cool. So whatever. And we're all doing preprocessing nowadays anyway, so why not? Yeah. What about.NET Core? I think it's fine right now. It's got a lot of hype, but I think that's legitimate hype being cross-platform and all that. So I say it's fine. I'm going to say it depends.

Like, it could be totally overrated. You've got to pick one. No, no, no. Hear me out. If you don't need it for your particular application, it's totally overrated. I think it's what you're saying. So it's like if you're not a.NET developer or you're not doing things outside of Windows, it's like... Outside of Windows would be the thing.

Yeah. No, I don't even mean that. I don't even necessarily mean outside of Windows. You could be doing Windows development and just, you know, maybe you're working in an older code base or something like that, you know, and you haven't run into a need for the things that.NET Core is going to buy you. You know what I'm saying? Like that kind of portability, for example, that it's going to buy you,

then it's like, eh, it's overrated. It's nice. It's awesome. It's cool. I'm not taking any of that away from it, but it's a case by case. This one comes along with my Docker for the ride though, man. I can put my.net core in my Docker and run it on Linux on Mac on whatever.

If you needed that portability, but if you don't need that portability, you don't know you need it yet, but you need it. Yeah. I mean, now you're right. What about you, Joe?

What was your response? I'm going to go with under because of the Docker situation that's kind of evolving. I think it's easier to deal with it there. I think the way we're kind of building things is real cool. I like that I can deploy on Linux and work on my Mac easier. So I'm on board. It actually makes sense. So you're saying underrated.

Yeah, he's saying it's underrated. You know what? I mean, I think it's a huge part of the Microsoft strategy, right? Like when you look at their Azure cloud offerings, like it was initially all Windows type stuff, right? And they quickly started shifting towards containers and Linux and all that kind of stuff. And I think that is why.NET Core is such a big deal to them. So. What about functional programming?

Overrated over. I got to say over to, yeah, like I'm sure there's people out there that are using that and, uh, you know, that it's really important to them, but,

um, not to me and not to most programmers I know. So, well, here's my reason for saying over is that Is that there's some awesome stuff in them. I'm not trying to take that away. Not only... I know that there are a lot of developers out there that work in those languages.

And the languages themselves are elegant. And they have so many awesome features about them. But if they were everything that they're hyped up to be, then they would be the norm. I kind of feel right. Is that wrong? Maybe. I mean, that's almost like saying SQL databases or relational databases would have been replaced, too. Right.

I don't know. It's to me. It's more about the hype of it with. Oh, you should be doing functional programming. Why? I mean, Haskell isn't on the same level as a JavaScript or a Java or a C Sharp, right? And I'm not trying to take anything away from it. It's a crazy awesome, the syntax in it, the features in it are awesome, but it's not there in terms of the same popularity.

So why is that, right? Is it because it's being overhyped? Is it because functional language is being overhyped? Because if it was everything that it was supposed to be, wouldn't everybody have moved to it? Maybe that's just the wrong thinking. I don't know. I'm going to get some backlash.

So listen, if you don't like that comment, send your emails to Joe. That's right. That was Joe speaking. You can find him on the Slack channel. Did we end the – are we at the end of the list or we got some more? We got two more. Sorry, I didn't think it would be so long. No, let's do it.

No worries. This is fun. That's us. We like to talk. What about machine learning? Ooh. I think – You know I had to go there.

I think that one's fine. I think there's a lot of hype, but I think there's a reason for the hype. I think we're going to melt all the polar ice caps for this, but I think it's fine. Hmm.

I mean, it's definitely, if you go to some trade shows, it seems overrated when, like, every booth you talk to, you know, they're talking about their machine learning. You're like, all right, whatever. So, I don't know, man. Why did you have to ask? Now you hit his soul. He's not going to sleep tonight because he's like, did I answer this one right?

Yeah. There's no right answer, only wrong ones. He still hasn't answered them. I haven't, no. Joe, what's yours? I kind of want to say underrated because I think that it should be in more places. I think it should be more ubiquitous. It should just be everywhere. Okay, so underrated. So I'm going to go with underrated.

All right. You, Joe? I'm going to say overrated just because the hype is so high, man. If you listen to a machine learning podcast, like five minutes in, they're talking about like the singularity and aliens and time travel. So I just can't. It's hard for me to stomach when things take such a ginormous leap when I can't get freaking Siri to call my wife. I mean, let's not hold it to Siri, though. That's a bad example. Siri.

I was like, ordering a pizza. I'm like, nope, nope, cancel. Listen, I've already said Siri like three times, and my phone still hasn't lit up, nor has my watch. They're all like, I don't care. I said, call my wife. Pizza on the way. What?

You go to anyone's house after they get their Echo Dot or whatever, you know, within that first week. They're like, oh, check it out. Play Bob Dylan. It's like added to laundry list or whatever. Ordering Tide Free. Like, man. Trying the Tide Cod Challenge. Oh, man. That's so true.

So I just, I think it's really useful and I agree with both of you guys. I mean, I think a lot particularly, like, I think that it could be used in a lot more places a lot more effectively, but it's just so oversold. You'll talk to people, they'll tell you about the machine learning and AI, and then you find out they're doing K-means in 1% of the application, and they've branded themselves as alien wizards or whatever. I do think it gets oversold a lot from marketing.

It does. Yeah. All right. Okay, one more. You do think it gets oversold a lot from marketing. It does. Okay, one more. You know what it is? No. How long you got to guess? Rockstar programming language. What kind of cheese would you have in your refrigerator? Cheese dust comes up all the time.

Obviously, it'd have to be powdered. The answer is powder. Okay, well, I mean, it's gotta be blockchain. How can we not talk about blockchain? I was going to say Bitcoin. Yeah. Okay, good.

Yeah. Blockchain. I think it's so misunderstood. I think that. Overrated. It's use cases. Man. Overrated.

I'm going to go with underrated right now. No, I'm going to go with just fine. I can't say underrated because there's too much hype. I'm going to say it's just fine. All right. I'm kind of curious here. Wait, what's yours? Oh, over.

Overrated. Okay. Yeah, for sure. It's just I hear it oversold. But I think a lot of it has to do with my echo chamber. I almost exclusively talk to programmers. I almost exclusively read like programming websites. And so it's like stamped into my forehead and eyeballs by now.

So, you know, I'm a little over it, but it doesn't mean it's bad. So who do you think had the most unders, overs, and fines out of the three of us? Oh, man. The most overs is you. Is this like a Cosmo test or something? The most overs was you. The most unders was Mike. And the most fines was me.

All right. Let's see. This is actually really hard to count up. I wish I had done this at the time. You should have had like a spreadsheet for it or something. Yeah, exactly. So you guys should talk amongst yourselves and I'll come back with the totals here. If you had just used machine learning, this would have been done, man.

Yeah. And the blockchain would have verified it along the way. And you could have written it in a functional language. That's right. Beautiful. It would have been easy. No state to worry about. That's right. It would have would have been easy. No state to worry about. That's right.

It would have always been verifiable. You'd have had item potent results. Actually, I think I'm pretty close here, actually. So if we just hang on for, if we just,

if I just keep talking long enough. So, as for the finds, Alan was number one with eight. And I think I got a total of 17 there. So,

half of those you said were fine. I said seven. Outlaw only said four. Oh, man. Does that say something about my personality then? That I'm like, you know, not that optimistic about life and everything? I'm like, everything's down.

Or it's everything's way up. Yeah. I'm either high or low. The peaks and the valleys. I'm bipolar. All right. And for unders, let me count mine. Okay.

So, Alan and Alan, you're actually tied. Both of you said seven things were underrated. Okay. Yep. So, now I can just do math here. What was yours for the unders? Four. Oh.

Yep. And the overs were him by a long shot. The overs were me. Nope. Not true. So the overrateds, me and Outlaw were tied. Both said eight. So Allen,

you were lowest low-balance total player. So none of us ever got below four on any of these. But it is interesting to see that we had a clear winner. Like Alan thought the most stuff was fine. You guys were tied on underrated. And Alan and I were tied on overrated. So I walked the middle line.

That's kind of where I stay. Yeah. Okay. Awesome. So I am totally bipolar. I guess I will go see a doctor about that. Thanks, Joe. Oh, man.

I ain't going to be diagnosed on the show. You don't have any weak opinions. They're all strong. They are. They are. Isn't that most developers, though? That is most developers. So it's that time of the show where we're going to ask you, please, if you haven't already, do go leave us a review.

As mentioned, we do read them. We appreciate the time, the feedback. And it is awesome to hear you folks share, you know, how it's helping you or, you know, getting you energized or whatever. So please do. If you find the time, you're sitting around, you know, tapping away on your phone, reading your Google News, you know, and you think of us, head to codingblocks.net slash review and drop us a few words. We greatly appreciate it. Yeah. And we've asked this before, too.

Spread the word. Tell it. Share it with a friend. Tell a friend about the show. You know, if you think that they might be interested, they listen to podcasts and you think that, you know, they enjoy listening to programming podcasts, let them know. And with that, let's head into

my favorite portion of the show. Survey says... We just did a survey. We've got to get you to work on the Steve Harvey voice now. Oh, the Steve Harvey voice? We've got to get that going. Okay.

I guess that's my homework for the next couple weeks is watch a lot of steve harvey family feud oh man it's amazing all right i guess it's just like the era of like when you grew up watching whatever you watch right so yeah yeah all right so last episode we asked what is your most productive time of day? And your choices were morning, got to get my work done before the rest of the office gets in. Or midday, let everyone else go to lunch. I'm getting this commit merged. Or evening, I'll let the traffic die down while I close one more ticket. And lastly, night. Now that all the meetings are over,

I can finally start my day. So, Joe, we'll start with you. What do you think the listeners picked? Morning, 26%. Morning at 26%. And he sounded confident. He wastes no time with that, Alan. You know what's funny is I'm going to go morning also at 27%. Oh, you're not going $1?

Okay. No, I'm going to have to go one over. But honestly, for me, it's night. But I think most people try and get a jump on it. Night for you. What about you, Joe? You're a morning person, Joe, aren't you? Yeah, I'm a morning person.

That's why you said morning. Yep. Yeah, I'm with both of you. I agree with Joe that morning is totally the time where I can be the most productive. Like you, you know, you're well rested, you're fresh and everything, but I'm a night owl by nature. So like it's hard for me to get up in that morning to do that. So yeah, I'm like torn. This goes back to my bipolar-ness. Well, Alan wins. Sweet.

Morning, 57%. Wow. Whoa. Nice. 57% of the vote. By far and away, the number one pick. Night was number two, wasn't it? No.

Really? No, it was evening. But they were really close. Night was number two, wasn't it? No. Really? No, it was evening. But they were really close. Okay. Yeah, they were like a percentage point away from each other. I remember going into an office. I would actually try and show up before everybody else so I could get work done.

Like that was... Yeah, but don't you feel like a seasbag leaving before everybody else? Even if you know you're good, you just... Did we ever? No, I'd still leaving before everybody else? Even if you know you're good, you just... Did we ever? No, I'd still stayed until everybody else was gone, right? That was the problem with being the early bird, too. It was like I was the late bird, the early bird. Yeah.

Yeah. No, see, that was another reason why I didn't want to be the early bird. Early in my career, I had no problems coming in, being the late morning person to come in, because I knew I was going to stay late. And it was like, well, why would I morning person to come in because I knew I was going to stay late. And it was like, well, why would I bother to come in early if I know I'm going to stay late? So yeah, lose my whole day. But even though like I knew that mentally I was more refreshed in the morning though.

Yeah. So, all right. Well, for this survey, and we give away a lot of books. So we're going to ask, what's your favorite book type? Hardcover, because I want to protect my investment, or paperback. I like to curl the cover back with one hand while I read it. Or ebook, it's the only chance I won't lose it. Or books, I ain't reading no books. I love the, it's the only chance.

It's so true though, right? It is. Cause you know that Amazon's got that backed up for you. You don't have to worry about it. I can't, I can't say what mine would be cause I feel like I'd be swaying the vote, but I'll do it next time.

Yeah. And this episode is sponsored by airbreak.io. When your website experiences an error, Airbrake alerts you in real time and gives you all the details you need to fix the bug fast. And I love that I can see all those details in one spot. I think I've got four apps hooked up now, so I can just log into the website and see everything right there, and I can drill into the apps as needed. And really, I should say, the spot that I mainly monitor my apps from is just my email because they send me notifications when errors first occur

and they also send a really nice daily digest email that sums everything up. So I'm not getting overloaded with information. It's just really convenient. Right now, Coding Blocks listeners can try Airbrake free for 30 days, plus get 50% off the first three months on the startup plan. To get started,

visit airbrake.io slash coding blocks. That's airbrake, A-I-R-B-R-A-K-E dot I-O slash coding blocks. All right. So into the next part here again. So my second thing was we've talked about a lot of patterns on this show over time. We've described them, gone into detail, whether it was good or bad, and gone over a bunch of patterns. And one of the things I've noticed, and this came up with caching specifically that I saw, is a lot of times that would be very localized to pieces of code. And so if you saw that you're updating somewhere, you would update the cache right there and then nothing else would be aware of that particular data. So it would go somewhere else to get that data. And, and so you would have

these caches that were out of sync, right? The same data in two different places were referencing, you know, one was referencing a cache but there's only little places where you do certain things to them, like a cache or something like that. I think it's important to remember the patterns that exist. So for instance, one of the ones that we talked about was the PubSub, right? The publish subscribe. When I look at that, I look and I say, well, there's got to be a better pattern, right? Instead of having all the cache happen and say like a controller or something, there should be a higher order type place where the caching takes place so that if you change

the data somewhere, fire an event off that gets caught by an event bus or some sort of event event actioning system that gets floated up. And now whether it's a repository or what knows that, Hey, there's something that just changed, refresh, push that into the cache. Right. And then that way, every place in your code doesn't have to know about it. There's a more centralized place that is handling that kind of thing. And, and I've just seen that I've seen, uh, I've seen like sprawl of code like that, where, you know, it started off pretty small and it wasn't that bad. But then over time,

as more people start adopting those caching mechanisms or, or whatever it might be, then you start having these little bits of, you start finding these bugs all over the place because wait, it says this over here, but over here it's different. And it's because, oh, well, they didn't implement the same cache or they did the cache a little bit different or it's not using the same key or whatever it might be. And so when you start seeing situations like that, it goes back to the whole code smell thing is, okay, how can we put in something that will, that will centralize this or, or give us a way to have, have better insights as to what's going on. So just curious what you guys

thought about that. I would tell you guys about my cushing strategy. No, don't do it. Don't be the one to do it. Uh, this is probably pretty good. Give it to Allah. I mean, give one to do it. That's probably pretty good. Give it to Allah. I mean, give it to somebody else. No, I mean, it's definitely interesting. You know, I've written, I've been tasked with writing a couple caching abstractions before. And it's not, it's no fun task because like you kind of get blamed for everything you know you do it's always your fault when it when it doesn't work so

it's it's like yeah kind of like what joe said is like you don't want to be the guy that has to do it well somebody always wants it to be done differently it's always like just kind of messy when it comes to things that kind of overlap. Yeah. And you can't help the – I mean, you were talking about the keys and someone might be using the wrong key. And it's like, yeah, you can't – there's only so much you can do to protect the end user from themselves. And in this case, the end user is another developer. But there's only so much you can do to protect them from themselves. And in this case, the end user is another developer. But there's only so much you can do to protect them from themselves.

And that's why it's weird, because I think this actually goes to better overall system design. And it's something you don't typically find out at the beginning of a project, right? It's something you find out as a project goes on is, oh, wait a second, we've got this user object and wait a second, they've got a different user object. They should probably be the same user object, right? Like whatever they're trying to do with it, they should probably be using the same thing. And so it kind of goes back to proper design saying, okay, now we have a user object that everybody should use.

And if properties change on that, there should be some sort of event fires off and then something knows to go update a cache or whatever. And I think it just goes to a bunch of disconnected silos of code is where you typically see this problem. And you only find out about that as time goes on, and you start seeing these problems, right? Or maybe it's just a pattern of like, if you had, this might be the wrong word for it, but maybe if you had like a repository in front of it as to how you would even get that, that user object, then that repository would know whether or not it wanted to cache something. And if a chain, if the property changed that it needed to add it or update the

cache with the new value or whatever. Right. Um, but you know But by not having that repository abstraction layer in between it, then yeah, you could have some places where it's like, oh, I'm just going to go and directly get it and other places where it's like, no, I'm going to try to get it from the cache, right? And so there's that disconnect there. Yep. And that's what I'm talking about with the design is just over time, if you've got a bunch of people working on it, it doesn't even have to got a bunch of people working on it, it doesn't even have to be a bunch of people, but one person's doing it differently than another, you have this disconnect. And that's when you almost have to take a step back and start drawing some boxes and say, hey,

how is this thing being used and where is it being used so that we can start identifying these problems and get these bugs out of the system? It kind of makes me wonder. Go ahead, Joe. You were going to say something. No, no, no. Yours is better. Nobody said a word yet. Well, I was kind of shifting the topic. That's why I was going to let you go speak on the caching thing. But it was kind of thinking like, because I've had this thought too. Like, is it better to have a, a team of people, like regardless of what your size, your team is where everybody's working on the same thing and they're like,

all hands are in the same code base. Or is it better to where you, you split it up to where everybody has small pieces of the overall thing that they're responsible for. And that way, they can know their one piece of the puzzle interchangeable, and therefore, you don't really get the opportunities to… Specialize. Well, specialize is one word for it, but I was going and cleaning up an area as new features come in. Because before you know it, you're tasked with moving on to something else. And someone else is brought in after you to work on that area.

And they might not have known the things that you wanted to address eventually. I don't know. I struggle with what is the right answer there like your thought i was like the two pizza rule you hear that one okay well i mean it starts with pizzas so yeah are they the meat lovers no i guess the amazon thing is basically like tried trying to have teams that don't exceed two pizzas which for me is like three people and very large pizzas oh Oh, that's interesting. But yeah, just the idea of like keeping teams smaller.

Right. And not exceeding too many people, but just because it gets kind of the communication overhead is rough and it doesn't give people the same kind of level of ownership. Yeah. I mean, I remember I met a developer from Spotify at, I don't even remember which conference it was now. And he was talking about the way their teams were structured. And if I remember it correctly,

it was definitely very like, you might have had maybe a half dozen people total on the team, but every person on that team had a very specialized part of the overall puzzle. So they would work on that handful of people would be responsible for delivering one feature. Let's say if it was ad content inside of the application. And that was what they did. But one of the people on that team might be more about the graphics for it. Another person might be for the JavaScript part of it, you know, things like that.

Like it was, it was very, you're still kind of specialized. I have no good answer for this. I think, I think that I like the pizza thing. I've never heard of that, but I do like it. If you have a few people working on something, then it makes it easier to manage. Like you said, communication doesn't scale. Communication is probably the hardest thing there is, right? I like that.

Man, as a full-stack developer, though, it kills me. Like if somebody says you're working on the UI and you're the UI only, I would be like. It doesn't have to be like that though no i never said you had to work in one technology just like the area that you're working in could just be a feature yeah it could be but then then you're almost the one guy right like if you're working in one area and and you're not just in a particular stack which which correct you could be you could be going across the stacks, but then you're not really working with anybody on something. You know what I mean? Then, then it's more like you're doing it and that's, yeah, it's, it's more solo type stuff. So it's, it's a tough one, man. Like I do like the idea of a few people owning an area because then you can refine

the patterns. You can refine the design. You can refine the code. You can do all that kind of stuff. And what I like about that more than anything is it might be that you picked up something good from each other, right? You found some patterns that worked and now you go replicate that in other areas that you work on. And it might be that you're working together in another area, or it might be that you're working with somebody else, but you start getting good patterns going around.

Man, it's so hard because then the flip side to that is working on a small feature is, depending on how big your application is, this almost goes back to the whole caching problem that I even brought up here, is you're not aware of how they're caching things over there. And so you have the same type object or same need, but you're not aware of their cache. And so you're getting data differently than what they were. And this is where it's hard. I'm okay with that, though, because going back to the... But it's a bug in your app. No, I wouldn't necessarily

call it a bug no in this case let's say it was though let's say in this case let's say that you're over on one screen you see one thing you come to another screen where you're using the same data but theirs was cached and yours isn't it is a bug now okay but where i'm going with this though is from the point of view of like going back Uncle Bob's accidental versus true duplication, right? Just because one feature team writes something and the second feature team duplicates that same code, it doesn't mean it's actually true duplication. Yeah, fine with that. It might change for different reasons. Fine with that, but I'm sticking with the caching thing where...

Yeah, you're stuck on cache. Well, this is the problem. How do we flush that cache? This was the whole thing that was kind of driving me nuts is that because people aren't aware of how it was done, because it was done in a very localized spot, it wasn't done... But I think in your example, though,

once that bug is found, then it kind of highlights the problem. And now it's known like, oh, hey, team A, why aren't you doing this? And team B is like, oh, because we're doing it like, you know, that's when the two teams talk, figure out, oh, yeah, we found this. But do you figure out a solution or does team B just say, oh, okay, well, we need to cache it like this over here or something, you know? That's what I'm getting at is a lot of times you'll see things done in a very localized piece of code, as opposed to saying, wait a second, this needs to be brought up a level because this should be handled by

something else. This shouldn't be done down here in the weeds. This should be handled by something that, that knows about cash or knows about data access or something like that. I mean, kind of the takeaway I'm getting from this though, is like, like maybe the, where you're saying the team should be drawn or where the lines are drawn for who's responsible, where the responsibilities lie, is maybe the team is responsible for... Have the smaller team that's responsible

for this overreaching feature, right? So if cache is something that's responsible for this over reaching feature. Right. So like if cash is, is something that's needed across, you know, across all, it's a cross cutting concern across all of the parts of the application. And there's the one group that's like, Hey,

you know, we maintain that. And that's what, that's, that's our thing. We were cash money and you know, we're the cash money brothers and that's what we do. Now,

would you say that, um, caching is easier if you've got a strong, consistent API, like a firm REST API? I don't know that the API matters. Well, maybe if it goes back to when I mentioned the repository pattern in front of it. The pattern in front of us. In that case, that is the API.

The pattern backing it, I think, is... And so that could be another cross-cutting concern team, right? Is the data access layer team. Like how data is read or written to whatever your storage mechanism is. And that team could say like, oh, hey, we're going to cache these things. Okay. Yes. Yeah. okay yes yeah but you're still not on board with like the smaller teams more siloed and focused on particular areas no i actually like it i i do like that um because that's actually my biggest

complaint like what you said is typically when people are just moving all over the place there are no patterns established. Because it's literally, okay, I'm in here. You're almost like a task force at that point, right? You're on a special ops mission. Your mission was go in and get somebody to get out. That's what you did. You're gone.

You're never looking back. You're done, right? Whereas if you are camped out somewhere for a little while, you're going to tidy up. And I think that's important. And I really like that. I think trying to hit the balance for people that want to do that kind of stuff versus people that like to just be the ones that go and do other things. But I don't know,

man, that one's, I like the small teams in a nutshell. I like the small teams focusing on small parts of, of a product. I think that it overall will make the small teams. In a nutshell, I like the small teams focusing on small parts of a product. I think that it overall will make the product better. I think Uncle Bob said organize your code into layers, horizontal layers, and then you can kind of adjust your team as needed, however you like. That's pretty good arguments for that, if you remember.

I don't remember exactly what they were anymore. I don't either. But, yeah, I'm going to have to go back and read that. It seems like, too, I remember. If you want to be But yeah, I'm going to have to go back and read that. It seems like too. If you want to be around feature, if you want to be vertical, that's fine. Just keep the code in horizontal slices. Keep it the same. Yeah.

Yeah. It seems like I remember hearing something too about like the teams would start to match however the code was done. Does that sound familiar? Oh, yeah. It's like the code would grow to um kind of mirror the organization of the company vice versa yeah yeah all right so i'm gonna change topics on you guys do you guys do you remember napster everybody remembers yes sir right those are the best of times

everybody remembers the internet metallica versus metallica versus napster, right? Oh, man. Aim, Napster, and StarCraft. Like, take me home, please. Aim, yes. So I wrote this, like, you know, in the theme of, you know, that era of Napster versus Metallica or Metallica versus Napster. So Napster, good. Cobalt, bad. Yeah. So there was this interesting article, and I don't remember where I found this, but I'll have a link to it.

But what was your first programming language that you started writing in? Let's start with Alan first since Joe did the survey first. It was on a handheld TRS-80 Basic. Basic was your first language. Okay. Joe? Logo. Logo. Okay. Never heard of it. If you want to count, it was a little turtle. Oh! Say it again. A little turtle.

It was on an Atari. An old Atari, right? I don't know about Atari, but I had one of my classes had a logo, so a little triangle of my like classes had a like a it was like a logo so like a little triangle and you would say like write 10 and it would move 10 draw and you can say pin up or pin down and eventually you get into like looping and i think even recursion so you could draw some pretty cool patterns so i love just playing with that and trying to like draw cool stuff oh that's awesome oh and then they came out with

lego logo a few years after that where you basically um plug this like really obnoxiously big cable into like a little lego motor and you would sell the turtle things would be like turn left and the motor would kind of like try to turn it left and you use the same basic logo commands very cool sounds like scratch oh yeah yeah i've seen scratch uh okay so for me it was um pascal that, that was my first. So it turns out like it matters what your first programming language is, uh, at least according to this article in some of the research in this article. So basically the idea here though, is that, um, the language that you start with, right? The paradigms, the idioms, whatever, you know, that first language, they're going to dictate about how you think about everything else.

All the data structures you're going to think about, all the algorithms you're going to think about. I mean, honestly, Alan, listen to what Joe just said. Now we understand why he's always writing games, right? It's true. Because his first experience was with the game, right? That's true. So it makes sense, right? And so basically, we've made this quote before where it's like, when all you have is a hammer, everything looks like a nail, right?

And so if the language that you know is, that you know and you know well is Pearl, then everything that's going to come to you, you're going to be like, oh, I'll just write that in Perl. You want an e-commerce site? I'll write that in Perl. Right? You heard his reaction. Yeah, exactly. And so I joked with Napster, good.

Cobalt, bad. Because in this article, they were talking about how Dykstra was anti-cobalt, right? That there's a quote in here that said, he says, the tools we use have a profound and devious influence on our thinking habits and therefore our thinking abilities. The use of cobalOL cripples the mind. Its teachings should therefore be regarded as a criminal offense.

I get what you're saying. It's kind of like you can imagine an art school trying to teach students with crayons or some other tool that's just not very good. How are they going to get to the place where they need to be if the tools that they kind of grow up with are not suited now here's where it's about to get hilarious this is where it's going to take a hilarious turn you ready dexter goes on to say it is practically impossible to teach good programming to students that have had any prior exposure to basic

ouch as potential programmers they are mentally mutilated beyond hope of regeneration. That hurts. That's so funny that you said BASIC. Yeah. I couldn't have set that up any better. That hurts. But yeah, so, I mean, you can understand it, though. It kind of, like, let's flip this around, right?

So if you started off in a strongly, and we've even mentioned this before. Like, you know, I joked around, like, you know, earlier in this episode about JavaScript and, you know, my thoughts on it, you know, back in coding blocks year one, right? And even during coding blocks year one, when we would talk about things like JavaScript versus something like a C, I think I had mentioned then it was like, well, because I grew up in this like strongly typed, you know, language type of environment that that's, that's my preference. I like that versus if you grew up in a, in a Lucy kind of Python or JavaScript kind of world, you're like, yeah, this is cool, man. You know, JavaScript, like, you know, like take C++, for example, right?

Like, and you try to reference a property on that object and the compiler is like, no, this is wrong. This is wrong. Stop right now. You know, and where Python's like, okay, yeah, no, this is probably okay. And then at runtime, Python's like, whoa, okay yeah i know this is probably okay and then at runtime python's like whoa wait no this is wrong and you know javascript's like you know you write the code and it's like that property might be there and then at runtime it's like it wasn't but it's okay we'll move on right like javascript could care less right so if you if you come from that kind

of c world for example and then you look at something like Perl, you're like, what is all of this? What is this stuff, right? Like, dollar underbar, what are you doing? Like, how did that magically appear? How did that suddenly get a value, right? Like, what does that do? You know, weird things like that.

That's what I'm saying. I'm mentally crippled. I mentioned, like, Perl program, we're looking at something on Java for the first time and be like, public static void what? Import what? Throws? Why do I got to throw all these things? But it kind of goes in line with what I saw in a couple books. One thing

is that what you do matters. Your habits matter. So if you build up habits with those crayons or with those languages that don't have the kind of precision or whatever that aren't as professional, we'll say, or aren't as strict as some static languages, then those patterns that you build come out when you're working on other things and focusing on bigger problems, like those things slip out. And so that can be bad.

But the good news is that, you know, you're a human with a brain that's like super good at adapting to new situations. And so you can kind of retrain those parts of you and just work on the things that you want to improve. And you're really good at that. Like we're designed for that. So there's hope. True.

So do you think that being a, a polyglot fixes this? That's a good question. I remember when I first learned Ruby after working in ColdFusion for a long time, a little bit of JavaScript, and seeing how they did things and how they solved problems. And a lot of the tools were available in languages as I was used to, but seeing it being so common, just the different kind of patterns, it really kind of changed how I thought about programming.

I felt like it was a really good influence on me. So I think that being a polyglot is a good thing. I think it does fix it. Just for what he said, you see the other patterns, right? Things start to make sense like, oh, this is a better way to do it. The whole functional thing being overblown. I think there's value in learning functional programming to pick up the patterns, right? And to see that kind of stuff.

And so I think the polyglot side of this does help you become better at all of them, right? Like you don't approach everything as, hey, here's my hammer. I think it helps you to think differently. I think the downside is like if you're always looking at new languages you never go too deep in one then potentially your code could be really inconsistent kind of influenced by whatever you're reading at the time yeah true too i'm willing to take that what about you on the polyglot yeah i mean i'm kind of curious because i you know ultimately the whole article or this at least this portion of the article was about like, you know, whatever your first one is, man, that's what's going to lay the foundation for everything else, right?

And so in which case it's kind of a loaded question. Can being a polyglot fix this? No, it can't possibly fix that because you can't learn multiple languages at one time. So if you're truly influenced by the first one you learn, then that influence is there. Like, you know, there's that old expression about you only get one chance to make a first impression. Yeah. Right. So then it can't possibly fix that. I like what you're saying about, you know, the other patterns and whatnot. But at the same time, I'm thinking like, well, it kind of depends. What's that next language? Because if that next language is too much too similar to the other one,

then you didn't really change anything. If you went from a c++ to a c sharp to a java like i mean those are all like really close in the same wheelhouse like the same kind of concepts and things apply there they're not there's not a whole lot of difference there right i mean it's funny like i'd say all three of us are probably pretty true polyglots in this regard because I mean, even just thinking about in, you know, over the years. So I started with basic when I was a kid and then my next, I guess real one was probably C plus plus. And then after that, I think I was in cold fusion and then I went to C sharp and done some Java. So like literally you're talking

pretty opposite ends of the spectrum on all those things and then you got things like sql that's not a programming language but is you know it's it's a querying language so i i mean when you think about that that is a lot of brain massaging there to get those because they're all very different, right? Like super different. So I don't know, man. I do think being a polyglot fixes it. And no, if you're only spending a day in each one of them, no, that's not going to work. But if you spend any significant amount of time in them, you start to see the things that work and don't across those different, you know, programming paradigms.

So learn one new language a year. Some people do that, right? Like that was one of your goals at one point was to pick up a new language each year, which I think is crazy. But yeah, I didn't keep up with it very well. But it is cool. Like, I mean, even I played with Ruby for a little while and it was pretty neat, right? Like it felt a little while and it was pretty neat, right? Like it, it felt a little bit JavaScripty,

but on the same time, like they'd done some really nice stuff, like with some of their syntax was just awesome. So, you know, I don't know. I don't think you're screwed with the first one that you picked. I don't think so.

I mean, Ruby, Ruby kind of seems like Python, Ruby. They kind of seem kind of similar i've never done any python maybe like go kind of seems similar to like a c but like you know if you really wanted to get to something like mind melting then like you know go from uh you know c sharp to haskell for example, those are totally opposite ends of the spectrum.

And so maybe if that's where, if you started, if your first language was Haskell. You're done. Right? Well, no, I'm not saying you're done. But what I'm saying is it's totally going to, that's your first impression of how all code should be from then on. Yep. Right? And so, yeah, that's what you're going to, you know, that's your first impression of how all code should be from then on. Yep. Right. And so, yeah, that's what you're going to expect.

Readability. I remember going from playing with Visual Basic and going into C, C short, maybe? I don't remember. But thinking, why would anybody do things so differently? Like this doesn't make any sense. Dim variable as what is that? Why not just var? Why not just string? Or I mean, yeah, it is funny,

but yeah, you get into the functional things and it is my mouth. Dim variables. That's right. Oh man. So yeah, I think, I think we've been fixed of it. Whatever we started with, I think we've, we've all landed in a halfway decent spot.

So, I don't think it was the worst thing ever. I like it. All right. So, I guess I'm up again, and I've got another weirdo one because I can't just be normal. I got to always find the rules and then figure out how to make them weird. So, uh, I'm interested in your short term, midterm and longterm bets on,

uh, programming technology. Like, what do you think? Like if you, if you had like a dollars programming dollars to invest in the programming, like stock market, and you could put like your money into, uh, I don't know, mobile apps or cloud or JavaScript or React or whatever.

You know, so be creative with it. But you get to invest into three. One for short term. So one that you think is going to give you the most return in one year. A midterm, the one that's going to give you the most return in five years. And one long-term, which is going to be, we'll say, 20 years. So I have to invest some kind of money in a technology? Yeah, and don't worry about the amount.

It's just if you kind of had, like, imagine you're in Vegas and you're betting on what's going to be more popular one year from now. All right. I'll kick us off. Short term, I'm going to be more popular one year from now. All right. I'll kick us off. Short term, I'm going to go JavaScript. Okay. And you're going to go on broad JavaScript. Yeah, just in general.

Like it's the language that everything's adopting, tooling's being built around, all that kind of stuff, right? Yep. Midterm, should we – I'll do my three. Midterm, we'll go cloud because cloud, regardless, AWS, Azure, Google, whatever, pick your cloud of choice. Yep. That's just getting bigger and bigger. Long-term, I'm going to go AI. Okay.

Because you look at things like what I think MIT, didn't they just do another one of those dog things? Like apparently that thing's gotten even smarter. So yeah, I think long-term we want people to think, we want robots and machines to think for us. We don't want to have to think. So I think that's what's going to happen. We're all going to be super fat sitting down eating chips while our surrogates are out doing things for us.

Wally. There we go. Those are my investments. I like it. I definitely think that Python would be in there. Just because other articles that I've seen,

it's one of the more in-demand languages out there. So I think I'm going to bet against you on Zopster. Is that your short term though? Is that your short term, midterm or your long term? Yeah. Shoot. I don't know.

Because I like the other answers you gave, you know, but I kind of was like, yeah, I don't want to copy them. But I was kind of like, well, I don't know. Cloud would probably be like long term because that's going to be here forever. I think that's a long term play. So but I don't I don't know what my other two technologies would be, though, that I would I would bet on. You just say Python, Python, Python. Well, no. I mean originally I was thinking like well blockchain should probably be somewhere in that though. That would probably be like, maybe it would be like Python short term, blockchain

middle and cloud long term. Or would you say okay now blockchain, would you say digital currencies? Is that going to be the big thing, right? Like there's a bunch of different things we could go with. No, not digital currencies. I wasn't thinking of digital currencies when I was thinking blockchain, yeah. You could have said wearables. And I also think that Tesla has to be mentioned somewhere in that too.

Oh, did you say wearables? Like wearables, like, um you know actualized self or quantified self or uh uh yeah no i think we're over that i think we're over that i think like the whole phone thing we're done with like i don't think that's anything exciting about i think i think phone why technology wise like you know because phones are kind of like close to wearables because we keep them attached to our head all the time. I think the next thing we're really waiting for there is the reinvention of the flip phone. We're waiting for the flip phone to come back as a smartphone.

I think that's the next big thing that we're waiting for there that hasn't happened, but yet there's always rumors about, oh here's the next apple iphone it's gonna be full no cyborg implants nobody's going for that bit you know the only thing that that might make me change my mind on the long term would be something in the medical field regarding technology like uh oh are we going like all out yeah i don't know about years what's 20 years, like I don't know about treatments or maybe just genetics, right? Like it's probably not far from it to where they're going to be like, oh, well, we see these markers and that means that you're more prone to cancer or whatever. And so either we're going to treat you different or you're going to be on certain diets or what? I don't know.

Like that's the other thing, the other side of things where I think that further down the line, if I was going to put my money on something and it wasn't AI, it would probably be somewhere in the medical field. What was, what was the year thing again? Like what was the definitions for short for one, five and 10,

one, five, sorry, one, five and 20, one, five and 20.. Oh, sorry. One, five, and 20. One, five, and 20? Yep. Like within 20 years?

I mean, self-driving cars are going to be here. Yeah. That's definitely happening. That's supposed to be by 2022. So you're in five years. That could totally upset the economy. That would be a- That would be game changer.

Big deal. Like imagine if you lived in New York City, right? All the yellow cabs, if they just suddenly became self-driving cars, right? That's a whole industry gone. Well, workforce. Right, workforce. Yeah. Still the same need, but long-haul trucking, yeah.

But you know what's funny, though? I've read articles on this before. They always talk about when they automate things that people worry about, oh, I'm going to lose my job. But it creates more jobs in other areas, right? There's going to have to be people that maintain these things. So, I mean, there's other things that happen. It's been like that throughout history, though.

Right, exactly. So the self-driving car is an interesting one, too. Dude, oh, man, I would kill for like Jetson type cars, right? Like give me Skyways. That would be amazing. But that's not going to happen. We know some people working on self-driving cars in the Slack. So, I mean, it's like it's happening.

This is real. Yeah. So is that your bet for 20 years, self-driving cars? I mean, it's probably the best thing I've said so far. Yeah, I guess. Okay. All right. So what's your three, Joe?

In one year, my bet is on JavaScript. It was tempting to pick either React or Vue. I couldn't. So I'm just going with JavaScript. I think that'll give me the most ROI in one year. For midterm, I'm going to say JavaScript. So five years from now, I think we're still going to be talking about JavaScript. Probably won't be Node anymore, but I think JavaScript

is sticking around. And for 20 years, this was really tough because I was really tempted to say machine learning or AI. That was really tough. I think I finally settled on cloud. I think that computers are going to keep getting smaller and more distributed and more granular and kind of spread throughout our lives. And so I think the cloud is going to be like really important. And I think that's going to be a bigger, you know, economic or yeah, economic, ecologic and social kind of factor in our lives. So that's where my programming dollars are going.

Do you guys see, like, I just, you know, I read books like the guy that you turned me on to, Daniel Suarez. Like, do you think that, let's say, 15, 20 years from now, is it going to be something where everybody's wearing some sort of either sunglasses or some sort of implant contact type thing in their eye that they see somebody and they see their name? Is that where we're going? Like, I don't see it as being completely out of the question. Google Glass, right? I mean, that was the interesting thing about that book.

If you were lucky enough to read The Demon before, like when it originally came out, it like predated technologies that later came out. And so that idea about like wearing glasses where you could like see data and information about stuff that you're looking at. And then, you know, years later, Google Glass comes out. And you're like, whoa, it's just like in the book. Yeah. And Google Glass died. I can totally see something like that. And the cloud would be a big part of that, right?

The cloud would be the central nervous system of that. So I think the cloud is going to enable all these things that self-driving cars. That's going to be another one that the cloud is probably going to be heavily, heavily involved in. Right. So AI. AI will be. Yeah. So did you guys speak in a cloud and see the story about like it was Google, Facebook, Microsoft and, and the data projects that they're working on

to where you can take data out of one system and take it from one to another. No. So it's like an interchange of data. So this is kind of like keeping along with your cloud idea, right? Like as things become more ubiquitous and part of our daily lives, right, that that language between them becomes more common too

so that it becomes like, you know, just another socket in the wall that you can just plug in whatever you want to plug into. I mean, it's going to be interesting, right? Like, I'm trying to think, there's certain things that are almost just available now, right? Like if you go to Starbucks, you can get on the internet, right? I have a feeling that the cloud's going to be baked into many things that are purchased in the future you go to buy a car part of that cost is going to be the cloud subscription that came with it type of thing or you know i and maybe you don't even buy cars in the future maybe it's going to be something where you know all the cars are the same oh oh no no have you heard of this i

thought this is where you were going. Like car share type thing? No, Volvo is doing this now. There's a subscription service that Volvo is coming out with for one of their cars. Yeah, see, that's where I think things are going to change, right? I want to say it was like, depending on which model car you got, I think there was like two different options that you could get. And like the highest priced option was $600 a month. And included everything that's not bad you don't mean you don't change the oil in this thing you do no maintenance at all on it it's a subscription and when you're done with the car you don't it's not

like a lease where it's like oh well it's you know whatever it's like you just turn it in you're done i mean oh i forgot this part too i'm'm sorry. I keep interrupting. This is exciting. It also included the insurance. Oh, that's killer. I mean, but that's kind of what I'm thinking is if you look at the way that we've been going. So actually, you know what? If I could invest in something differently, it might just be subscriptions. Because look at everything that's happening now, right? Like if you start a software business, what are you going to do?

You're going to do software as a service because you want that monthly income coming in, right? It makes bookkeeping easier. Yeah, totally. And I don't know, man. It just seems like everything's going in that direction anyway. So cars, I don't know, maybe even learning institutions, right? Like instead of paying to go to college, you're going to pay a subscription to, to, you know, Hey, I'm going to pay my a hundred dollars a year from the time I'm, you know, plural site. Yeah. Coursera courses are like that. Like, I mean, yeah, they're kind of already, we're, we're kind of already getting to these subscription models

for these things that you're mentioning. So anyway, I got a 30 day free trial to the University of Florida. There you go. But, I mean, seriously, think about it, though. Education's been getting out of control, right, as far as costs and all that. There's articles coming out all the time. There's some dude that had a million dollars. I think I sent you guys the article. Yeah, he was a doctor. A dentist.

He had a million dollars in student loan debt. First off, how do banks let that happen? But secondly, paying the minimum payments in 10 years, it was going to double to $2 million. And it's like, okay, I mean, come on. Yeah, if I remember that article right, he was counting on the fact that after like 25 years, the debt was going to be forgiven or something because it was going to be so high or something. I think if I remember that right. It was something ridiculous.

But yeah, so I mean, I don't know. This whole subscription thing, I think with information becoming more and more available, going back to your cloud thing, that's not a bad place to invest. I think everything's going to be tied into it. And whatever you're paying subscriptions for is also going to be paying into that, right? The Microsofts, the Amazons, the Googles, they're all going to be getting a cut of all purchases that are happening because they're all going to be sending data up there. Yeah. And it kind of hurts to say, like a Jeff Reitz example, I used to just buy it every couple of years. And so it kind of hurts to have a subscription fee, but really it's better on both ends, I think, because on their side, it kind of lowers their risk.

They've got recurring income. They don't have a big burst when a product comes out and then a desert of income until another one. And as a consumer, I can pay $9 a month or whatever it is per month. And if I need that money back or if I pollute my job or something else happens, I can change that. And so I don't have to pay a big bunch of money up front. It just kind of evens things out.

Yeah, you guys remember when Adobe suite for Photoshop and all that was like 2,500 bucks a year. And now you can get that plus way more for 50 bucks a month, right? 600 bucks. We used to just download on Napster. Nobody ever did that. Well, yeah. I mean, i can remember like just buying photoshop alone was $900 by itself right now you spend 600 bucks a year and like you said they're not getting a huge influx of cash but they've got this steady stream of income that people even forget they're paying for like me yeah and you know 18 versions of adobe photoshop later that's right man right yeah i swear that adobe wanted people people to steal Photoshop back in the day. Not anymore.

Like, CS3 days were like, you know what? Let's go ahead and let the students, like the 20-year-olds, get the free copy and learn how to use it and edit their little crappy websites. And then when those guys are 30, they're all going to pay $900. That's right. You say that, like them wanting to steal it. I actually,obe was one of the first that i can recall where part of the license agreement actually spelled out that you

can install this software on multiple machines as long as you use them like you know at different times and the percentage of use was you know very right like you couldn't use both machines 100% of the time, right? Right. I don't think that would be possible. Right. Yep. So, yeah. That was fun, man. I liked it. Yeah, and let us know in the comments if you think otherwise or what your thoughts on any of these topics have been, really. Yeah.

So. With that. Yeah. We'll head into Alan's favorite portion of the show. It's the tip of the week. Yeah, baby. All right. So I've got several tips here for you, which is going to be kind of sad since I think Joe was hammering on the machine learning earlier.

So the first one is going to be, I found this really cool article from Google. The rules of, well, basically it was Google's machine learning overview, really. But one of the sections in it was their machine learning guides. And one of the sections in it was the rules of machine learning with a subtitle of best practices for machine learning engineering. And they had like all of these different steps for it that I thought was kind of interesting. Like one of them was like, you know, Hey, before machine learning, Hey, don't be afraid to launch your product without machine learning. Like that's not, that's not, you know, you don't have to, right. Um, and that it's good to just go ahead and get the design out there and implement metrics. And that way you can get data and you kind of get buy-in from your users early on about like any data that you might want to collect or whatnot right

and uh you know when it comes time to like choose machine learning over some complex uh heuristic right that that's when you need to start bringing it in because that complex heuristic is going to be unmaintainable and there's a bunch of interesting points in here. So I'll have a link to that. But then there was also this other cool one that I found that I think this was trending on like the programming subreddit, but it was Rico's cheat sheets. And it has like this whole list of like, okay, let's say for example, Docker compose, right? You want to know the cheat sheets on that. So it has like basic examples and commands that you're going to want to know just to get kind of started, right?

Uh, building with Docker compose, running it, how to set ports, environment variables and dependencies, things like that. Right. Uh, there's some in here for Docker file. There's Git is in here. Then there's like IDEs. So maybe you want to know about Atom or Sublime, and it'll show you like, hey, here's all the keystrokes that might be of interest to you, right?

So you can find this at devhints.io. There's just so many in here. I can't even begin, you know, from bash to react to a VS code. Uh, cron is in there. Uh, chef is in there. Just you name it. It's in here. There's a cheat sheet for it to get you started. So pretty cool little tip on that. And then one last little tip. I shared this with Alan like a couple of weeks back. And I was like, you know, I don't know if everybody realizes this. Maybe a lot of people don't know this. But if you have a Thunderbolt display, then on your Thunderbolt display, on the inside of

it that you can't see, so let's say you have your display just sitting in normal landscape mode, then on the left and right border of your display, one near the top corners and one near each of the bottom corners are magnets. And it's super awesome because you can use it to hold your stuff, right? So, you know, it can't be like too heavy. It needs to be somewhat lightweight. But if you are, you know, quote Apple fanboy, no judging, then you probably like me, you might have a dongle or two that samsung is laughing at you about and you need a place to keep your dongle so you can just stick it right there on that magnet right there under the display and it's handy it's right there where you want it

when you need it love it actually i saw his monitor i was like but do you have like a tape behind that he's like no it's magnet in there yeah so basically i have like the um the the what is it three no what's that the standard headphone it's one in point eight millimeter jack no three and a half millimeter jack to the lightning connector, right? That short little dongle. And it's just stuck to the side of the display. And you would think like, hey, how is that staying there? How is it not falling? And there's no trick.

There's just a magnet there and it's holding on to the lightning connection. It's pretty cool. All right. So on mine, I actually just thought of one that I meant to have in here. And I struggled this episode. It was one of my favorite parts of the episode. And I literally was just dying to try and figure out a tip. So the first one that I did, because it was the lazy man's way out, is it's not as cool

as Outlaws was. He's got dev hints.io, which have millions of cheat sheets. I have one cheat sheet and it is the ECMA 20. Yes. 2015 or yes. Six cheat sheet. It's on get hub.

There's some good tips in there. It's just, it's just a nice quick overview of some of the features in the S 2015. I don't think we've talked about those in quite a while if we ever went over them in depth at all. But so, you know, enjoy that. The other one is, so I've been trying to, Outlaw brought up the thing earlier about

should you have smaller teams working on one portion of a site or on an app or whatever. And I've been trying to like diagram out an application. And the problem is when you do that, you run into a lot of things like there's these verticals, there's these horizontals and just trying to even get it out on a piece of paper can be really mind bending, right?

It's almost as hard as programming. And yeah, you need more than one piece of paper, dude. It's ridiculous, right? Well, I found this tool because I was on my phone and I was like, man, there's gotta be a decent diagramming solution. And there's one called, uh, draw express and on Android, it has excellent reviews on iOS. It looks like it's about a four star, but it's really cool stuff. Like you can

open up this thing and you have, you can either do flow charging, do mind maps. You can do almost like UML type stuff, like class diagrams for software. And what's really cool is you can draw a shape on the screen and it'll plop it out there. So your standard boxes, your circles, your diamonds, that kind of stuff, it'll do it. But what I thought was even neater is the way that they've done some of the gestures with the thing. So let's say that I draw four boxes on the screen and those represent four portions of my app. I can now draw a box around those and it'll group them together and create like a little dotted grouping thing for it. And then I can move all those together. You can double tap to fill in the things and all. So at any rate, really nice little drawing tool

for doing diagrams and flow charts and whatnot in a fairly easy to use way. And they use gestures so that you can just, you know, if you want to delete something off screen, tap on it and draw an X and it'll disappear. So I thought it was really fun. I think it was $8 on Android, and I don't know what it is on iOS. Maybe it's about the same.

This thing looks like Gliffy, but for iOS. Yeah. Or for mobile, I should say. Yeah, dude. I love it. It's a lot of fun. And I think that – so there's a free version, and I think it limits you to a few diagrams. Or if you the paid version, then, then you get, you know, you can do as many as you want.

So again, it's mind mapping plus flow charts, plus other types of diagrams all in one. I really liked it so far. All right. And guess I'm up next. So I found a really interesting Android app. So another mobile app here, it's not on iOS, unfortunately. It's called Algorithms. And the

subtitle there is explained and animated. So it's like, I think, $2. You can pay another $4 to unlock all the algorithms. But it's basically just a collection of algorithms, like what things we talked about. Dexter's algorithm, Bellman-Ford, MergeSort. And you can click on it and step through

line by line and actually see it do a nice little animation with the little objects and the numbers and everything's nice looking. You also hit just kind of play and it'll play through and do the whole animation at a nice reasonable speed. But it's also just got some really nice background info. So I could say scroll down to the security section

and say Encryption Basics and it's not really animated. It's almost like a little slideshow and kind of slip, like step through. And it's explaining, you know, public, private key security to me. So it's just kind of nice. And it's a real lightweight app. So it's just, you can kind of like keep under the desk and interview. So when they ask you about, you know, differences between stacks and keys,

you can just kind of look under the desk and give them an intelligent answer. Dude, that's really sweet. This thing has got a ton of reviews too. Yeah, it's really nice. And it looks like they're adding more stuff all the time. That makes me want to make it. Yeah, I'm downloading it right now. Yeah, I really like to program those algorithms that we did last time.

So I would like to get spare time and program a lot of algorithms. Most excellent. Yeah, that's pretty cool, man. All right. So with that, subscribe to us on iTunes, Stitcher and more using your favorite podcast app if you haven't already. And also along those lines, if you haven't already left us a review, we'd greatly appreciate it if you haven't already. And also, along those lines, if you haven't already left us a review, we'd greatly appreciate it if you would by heading to www.codingblocks.net

slash review where you can find some helpful links there. Yep, while you're up there, check out our extensive show notes, examples, discussions, and more. And send your feedback, questions, and rants to the Slack channel or join my guild in Warcraft

because the next expansion is coming out and that's where I'm going to be for the next couple months. And follow us on Twitter at CodingBlocks or head over to CodingBlocks.net where you can find all our social links at the top of the page and also the Warcraft guild. And we keep forgetting, if you want some swag, some stickers, something, head to CodingBlocks.net

slash swag and we'll get those sent out to you. Oatmeal. Cheddar.