Coding Blocks - Job Hopping and Favorite Dev Books

Episode Date: December 5, 2022

We talk about career management and interview tips, pushing data contracts “left”, and our favorite dev books while Outlaw is [redacted], Joe’s trying to figure out how to hire junior devs, and Allen’s trying to screw some nails in. The full show notes for this episode are available at https://www.codingblocks.net/episode199. News Thanks for the reviews […]

you're listening to coding blocks episode 199 subscribe to us on itunes spotify stitcher more using your favorite podcast app and leave us a review if you can and uh we have a website codingbox.net where you can find show notes examples discussion and a whole lot more yep send your feedback questions amrants and comments or no two comments at codingblocks.net and follow us on twitter at codingblo. This is our first time doing this. Yep. And we got a website. Oh, crap.

I think I'm repeating. Anyway, we got social links at the top of the page. This is what happens when we don't have Outlaw. So I'm Joe Zach, though. Oh, yeah. I'm Alan Underwood. And so today, no Outlaw. So we're just going to kick back, take it easy,

and talk about a few different things. So each one of us grabbed a couple topics to bring to the table today, and we're just going to see how it goes. But first, a little bit of news. Yep, we actually got a couple of reviews this time. We got one from Ryan Barger on iTunes. Thank you very much for that. And we got one from an Amazon customer over in Audible in the UK. And fortunately he said he was going to leave a three or four star review uh based off joe's lovely oh it's selling capabilities in the previous episodes but

fortunately left a five all right thank you yes we very much appreciate that for for both of you took time to do it yeah appreciate that and hey guess what? You had fire warning. Gave it a little tremors, some premonitions for this episode. But the January link for the Coding Blocks third annual Game Jam is now live. You can go sign up right now. The dates are January 20th to the 23rd. Let's make a game. Seriously. You don't have to have three days off, whatever, to

go make a game. You can do whatever you got time for. Do whatever you want. Make a text game. Try something new. Try something old. I don't know. Just sign up. Have fun. We'll have a link in there. Also, I got a couple links to videos from past years so you can see all the cool

stuff that you'll be partaking in and being a part of and uh yeah and oh by the way i set up a friendly link here so you can go to codingbox.net slash cbjam and it'll take you right to that link so of course we'll have the link in the show notes but if you also just remember cbjam it's the hashtag and also codingbox.net slash cbjam killer hey and for those interested january 20th through the 23rd is a friday through a monday so you would actually have some weekend time there to mess with it so like he said you know even if you've never done it before like tried to create a game or anything it

might just be a fun experience so give it a shot um all right so with with additional news we we have established i think both joe and I's love of Costco, all things Costco on this show. Well, I have more love for it. And this might be a little bit late considering Black Friday just passed by. And a lot of people go buy appliances on Black Friday because you get crazy good deals. But I at least wanted to drop this out there. There is a really good reason, actually several good reasons to buy

appliances from Costco. One is the return policy is unreal. Like if you get, if you were to buy a washer and dryer, you have a 90 day return period. Um, now I can't remember exactly what Home Depot and Best Buy and those were, but to put it into perspective, I believe that Home Depot was 48 hours. I think that Best Buy is like 14 days. So you're talking about really small windows compared to the other. On top of that, a couple other reasons that are just absolutely amazing is if you were to buy a washer and dryer

from home depot or best buyer wherever you also have to buy the hookups so you have to buy your water line hookups you have to buy your gas line hookup you have to buy your um dryer vent and all that kind of stuff so with costco it's all included and costco will do hallway for free so like it's just when i was searching for things, it was unfortunate that it worked out like this, but I actually narrowed what I needed to get to what Costco had for that reason. Yep.

I did that with TVs. I was like, let's see what Costco has gotten. It's going to be one of these. Yeah. Yeah. They threw in an extra year of a warranty on the thing too. So it's like,

it's like a no brainer. So my Costco love has grown even more over the holiday season. Um, I thought I'd share it and maybe, you know, anybody that's looking to, to do something like that, I would highly recommend looking into it. Yeah. I bought something from Google's online store once and, uh, it was non--turnable by the time I opened it. It's so ridiculous, man. Yeah, it's frustrating as heck. One more thing about Costco. I haven't told you this.

They made my Costco bigger. I didn't know they could do that. How did they do that? They took away some of the parking lot, which, you know, risky move on their part because that thing is a madhouse but yeah they they uh they built more costco onto my costco it's amazing what did they add to it they just made everything a little bit bigger oh that's amazing they moved the veggies over a little bit and they made it bigger and then now they have like a whole dairy section that's unreal man oh so check it out i'm actually in between two costco's like

almost equidistant from the one that you used to live by and another one that's out out near my That's unreal, man. Oh, so check it out. I'm actually in between two Costco's like almost equidistant from the one that you used to live by and another one that's out out near my house. There is something very interesting. If you buy your gas at Costco, make sure you look to see who has the best price. The one that's by your old house is like 40 cents cheaper than the one that is in the opposite direction. Wow. Makes no sense. Yeah, man. Like it was significant, especially for my gas hog. So, so yeah, I digress. We need to create a podcast for, for Costco.

I don't know if we get any sponsors or anything. Yeah. And then, and then one other thing I wanted to share. So I, I didn't ask the person that shared this with me if, if I could mention his name. So I won't ask the person that shared this with me if I could mention his name, so I won't. But there was an interesting article that came out about Amazon potentially replacing a lot of their HR with AI driven software. We'll have a link to the Vox article here. But it's really interesting. Basically taking a look at the profiles of the people that have been working at

the company for a while and what their resumes look like and what their, who knows what else, like their LinkedIn profiles or whatever. Like I don't know what the input parameters to this thing would be, but they feel like they've fairly well nailed down who would be somebody that would work out in the longterm. Wow. nailed down who would be somebody that would work out in the long term wow just by comparing who's there and the applicant pool out there so that's some gattaca stuff right there yeah it's crazy man

so uh yeah all right with that let's uh let's go ahead and jump in what's what's your uh what's your first topic all right yeah so um i uh yeah. I always think about junior developers and what it takes to bring them on. And if you're on Twitter, if you're on Hacker News, if you're on Reddit, if you're anywhere in the tech scene, you are just inundated in social media

with ads or tweets or whatever, basically targeting people that are trying to get into coding. How do you get that first year experience. If you're on Dev2 or that website, Dev2 or, you know, Medium or any of these, Hacker Noon, I mean, every day you're going to see like how to get your first job as a developer, like tons of those. But I was thinking you never see or you don't see a lot of articles about how to hire junior

developers, like how to find ones that are going to be decent how to actually kind of get people in there and support them so i did a couple uh did a couple googles and i couldn't really find a lot so i thought it might be interesting to talk about like what do you think uh either the problem is or what do you think it takes to to be able to hire and support junior developers? That's interesting. I mean, we've, we've tried to do that before at various companies we've been with. And if you don't have the infrastructure in place, like you don't have a good mentorship program in place for that, that makes it almost a non-starter, right? Like who's going to be spending the time doing this?

What are they going to be working on? What, what are the metrics? What are the, the things that you're going to measure their progress by? Like it's, you really have to be set up for it, right? Yep. Yeah. Totally. I think, um, you know, well me personally, like when I think about like, maybe I should, you know, we've got a rec open, maybe I should argue that we should lower the, the, um, you know, level down and try to hire someone new and i don't want to argue for that because i think immediately oh this is taking more of my time and i already don't have time right and so that's what i always think back but and i think you know well maybe maybe that's an anti-varon maybe that's a problem on my side that i don't feel like i've got the time to invest in somebody

that's going to pay dividends. So, you know, I don't know, but then you, you worry like how many developers, how many junior developers work somewhere one year and then they go somewhere else and get like triple the pay as like a mid junior role, you know? Yeah. Well, that's, that's sort of the problem too, right? Like I think we've talked about like, if you're in college going and doing an internship somewhere right i i believe or i want to believe that those companies try and get somebody in see if they're good see if they're advancing you know uh fairly quickly and they're doing well at the tasks are given and then hopefully after they're done with their college degree or whatever, they get offered a, a reasonable competitive salary coming out.

But like you said, especially, especially in the tech scene, it doesn't seem like there's, there's loyalty. Like, you know, if you worked in the car industry for years,

you might've worked for GM for 40 years. Right. And then you retire there. That doesn't really seem to exist in our space. Yeah. Pensions are gone. Like there used to be these incentives for you to stay at a company for a long time and you see it a watch for 10 years you know like that's the kind of stuff doesn't happen anymore the average person stays three three years at a job yeah oh yeah in the tech tech world yeah it's tough and and it's hard too because i think part of that and i I mean, I don't guess this is

just junior developer type stuff, but I guess it's as you're going up the ranks, regardless, a lot of times it's easier to hop to another place and get that promotion you're looking for than it is to get promoted from within. Right. Because companies have already set their budgets for, for their year. Right. And, and going somewhere else, you know, they have open budgets, they have open recs for whatever. And, and internally they may not. And again, it's like you said, I mean, it's tough. If you get a good junior developer, it's an amazing experience. Um, because you can, you can sort of see that glow, that light going, and they're excited and they're thirsty to learn more and do more. The problem is when you get one that isn't great, then it feels like a ball that's just dragging you to the bottom of the sea.

I mean, you could say that about any developer, but especially with, with junior level developers, it can be way more difficult because if they don't have the background knowledge on some things, like you could spend days just explaining why you even look at doing something, you know? Yeah. And if I hire a, if we hire a senior developer, right. I'm, I'm able to give them some of my responsibilities, right. If I, and you know of my responsibilities right if i and you know within a couple months you know i expect them to be able to kind of like be taking stuff off my plate junior developer i kind of expect the awesome opposite at least for a long time like several months maybe years before it's actually saving me time and people you know job hopping

so you know i don't mean to make it sound like that's an excuse for me not wanting to hire junior developers you know i don't like i haven't really really had – no one's really asked me, like, should we hire junior developers or not? So I don't really have that question in practice. But if I just try to think, like, what it is that I worry about when hiring developers and kind of project that out to other organizations, that's the only thing I can really think about. Yeah. I mean, there is a super positive side there. Like I said, you can get somebody that's you know excited they are they'll work themselves to the bone and i'm not saying that they should

but they will because they just love it so much like the people that that really love to program like i mean jay-z we've talked about it in your spare time you'll be playing video games and right after that you'll be looking into some other technology right and and it's that desire that thirst if you can get it when somebody's fairly new to it and you can sort of help shape how they need to look at things going forward you can help them skip several years of of mistakes or or just hard learning and get it done quickly and fast track them to being an awesome, you know, regular dev or senior dev. So it can be an amazing experience, but you do, I think you have to be set up for it. Yeah. And so what I was thinking, hey, you out there in podcast listening land, if you have any tips, if you have any articles, if you had anything that you've seen

other orgs do or that you've tried that worked out well for you uh let us know because i think that would be really important to share and i think that seems to me like it should be equally as important as telling people how to get that first job it's like how to tell people how to give people that first job yeah totally i like it oh yeah And I got another topic here. Similar vein. How long do you need to stay at a job? Like I mentioned, part of my fear with junior developers, you invest a bunch of time and then they take off after a year and they get 25% more pay.

And I don't know if that's actually the number, but I wouldn't be surprised at all to hear that people with zero experience get one rate and people with one year experience can double it. That would not surprise me at all but uh i know there's a lot of fear around or at least a lot of talk around having like a job hopper resume so if you see a resume where someone's had 17 jobs in the last 10 years like unless they're a contractor like that might set off some alarm bell alarm bell so i was kind of wondering like what do you think the line is like how long should you stay at a job man that's that's really interesting so i can tell you from people that i've worked in the worked with in the past there were people that if they were looking at resumes

and somebody had had more than two jobs in in a year they basically just threw the resume away. Yeah. And I mean, for better, for worse, I've known people that do job hop and they're very successful and they're, they're very good at what they do. Um, I don't know, man, this one's tough. I'd say, would you agree that you're usually not hyper productive at a job till you've been there at least like three months? Oh yeah. So somewhere in that hyper productive, like six months maybe.

Okay. Yeah. Hyper productive. So being productive to where you feel like you're actually accomplishing things, probably three months. So hyper probably six. And so to even really get a good footprint at being at a place,

I'd say you have to be there at least a year. I'd say one to two years, at least in my mind, seeing somebody at a place that long usually is a good sign that, that they're getting along with people. They know what they're doing and, and life is good because honestly, the, the getting along with teammates and all that is, is just as important as, as the work that they can put out right oh tell you i was thinking a big part of it's like the story you have to tell if assuming you get into an interview with that kind of resume is like if you go in there and say like why i left this place because it was toxic and i left the place before that because it was toxic and the

place before that and suddenly you know i mean that's just like you know goodbye see ya like obviously this is more than just the jobs right but if you can say well i worked at this place one place for one year or two years and you know i can show that i've learned to kind of get along with people and make place but then you know the next place uh got um you know had big layoffs and the place after that um you know something else happened like you know and i left or i got a new opportunity or whatever i think if you can kind of spin it in a positive way so that each change looks like it was like something you know good or whatever that you something good came out of it for you then i think that's good and like you just have to be really careful with that

in the interview like how you phrase it but that means that assumes that you get into the interview so i was thinking about like what do you do about, you know, if you do have like kind of a job hopping resume and you want to, you really want to get a job, like, what do you do about it? That's, that's interesting. I mean, I guess one of the, one of the things that would at least keep my interest for somebody that does have a job hopping resume is when I asked them, Hey, why, why have you had so many positions in the past, you know, two years or whatever? Um, their answer would weigh heavily on, on my, on my thinking at that point, right? Like if somebody said, Hey, I, you know, I took this

job because I thought I was going to be doing heavy cloud services and it turned out it wasn't right. And I went to this one and they said it was going to be that. And it wasn't then, then I could sort of, I can sort of get behind that because I know I've seen it happen where people get sold a bill of goods when they come into a company, right? Like,

Hey, you're going to be writing the next CMS. And it turns out all you're doing is styling things all day. Right. And so I can totally get it, but it definitely sends off warning flares a little bit, you know? Yeah, I definitely like the idea of at least having or, you know, trying to get, you know, trying really hard to get at least one job where you've got a couple of years on there. And obviously, if this is your first job, you know, that's a tougher thing. But just so you can kind of have that experience and be able to relate to kind of having to live

with the bugs that you've written and having to learn to get along with people like long-term just so it doesn't look so bad. But I also think if I'm going to be interviewing somewhere, like I'm going to try to find an in somewhere where I know somebody that can be referral or some other way. You know, ideally, someone can take my resume and say, like, this is his resume.

You know, we know it looks like there's a lot of jobs in here. But the reason is because, you know, they're all good reasons. So just, you know, let them in that door. And so that would be my way of kind of getting around that that resume problem. Hey, so it's interesting what you said. like your, your initial question was how long do you need to stay at a job? Um, but you said that as long as somebody shows that they were able to stay at a job or maybe a couple of jobs for a decent period of time, then it wouldn't bother you as much.

So is it, is it, you feel like they need to show that they can be established somewhere at least once or twice and then, and then you're a little bit more open to whatever it is. Or do you think there is a time period that that people should stay at a place before moving on? Yeah. Yeah. When you put it like that, it's like what I'm really trying to get after and like what I'm trying to watch out for is basically the personality problems. Right. uh the personality problems right which is you know i'm waving the red flag on myself because that's you know there's all sorts of problems with trying to kind of ferret out people based

on the personality but you know ultimately it is really important that you're able to get along with the team that the people that you hire are able to to get along and get you know work done and be productive with uh various other different personalities and so on one hand i am trying to look out for personality problems on the other hand i think you i am trying to look out for personality problems on the other hand i think you're not allowed to look out for personality problems you know like you don't want to say you're hiring for a culture fit because that's how you end up with a monoculture which is bad so i i really don't know what the answer is but hey i guess uh if you have any ideas let's know in the comments well you know it's funny though like i think what you said is important

like you don't want to get stuck with a monoculture, meaning that, you know, it's just everybody with the same mindset and all that. However, there is a thing to be said for people who can communicate well and are personable and all that, right? Like you don't want to be clashing and butting heads with everybody every day of the week. Right. So, um, I don't know that that's, I mean, if, if you're going to be hired for a waiter or waitress at a, at a restaurant or something like that,

like they're not going to hire somebody that comes in being rude and brash to everybody. Right. Like, so there's that. Um, but, but I agree.

I think I want, I want somebody who's at least passionate about what they're doing. And I think you can tell that a lot of times, even in an interview, even if they're a job hopper. And, and nowadays for, for better or for worse, you can see most of this stuff online, right? Like you can look at somebody's Facebook profile, you can look at their LinkedIn, their Twitter, all this kind of stuff. And you can sort of get an idea of, Hey, is this person, you know, rubbing the entire internet wrong? Are they, or, or are they just, you know, Hey, they're just out

there being a regular person. Right. And, you know, I've said it before on this podcast, I'll say it again, be careful what you're putting out into the, uh, into the digital world. Right. Yeah. It's funny though. Like, um, I think companies like the big companies like microsoft and amazon and google and stuff like in a way they're almost like trying to cut off that personality when the interview process it's like they almost like don't want you to go google the person and see what their twitter's like because they don't want it to bias your opinion on the interview you know but uh on the other hand most um uh nice guy that anybody's ever worked with i don't know i've only ever heard him get upset maybe twice the years that we've all worked

together so you know but you know uh i just imagine like if uh if i was interviewing someone i'm like so i see you got three jobs in two years like what happened there you're like oh all three of them were just really chaotic. I'm like, oh crap. Well, this isn't going to go well. That's awesome. We'll save us both some time. Yeah.

I guess you want to be here then. Yeah. Awesome. All right. Got one more for you. So this one, buddy of ours, Chrisris recommended a podcast a couple weeks ago i checked it out and i thought it was really good this is a show that i hadn't subscribed to before uh called uh that's um the notes the show notes are wrong here i the link is right and the title

is wrong uh the name of the podcast is the analytics engineering podcast and it's podcast all about uh you know analytics so big data you kind of type stuff the kind of stuff that we do and that we talk about all the time and the podcast itself was called uh the episode why you'll need data contracts with chad sanderson and uh something like that. I apologize. I won't do it again. And I'll get that link in the show notes eventually. But anyway, so the podcast was really interesting and

it wasn't anything like, you know, crazy deep or, you know, whatever. It just had some people kind of talking about their experience with data contracts. And both of them were arguing for pushing schema left. And that phrase pushing left, that's something we've talked about several times. We talked about it with DevOps, pushing DevOps left.

Basically means moving something earlier into the process and early into the kind of design lifecycle and pipeline security. We talked about moving left, starting with it. Schema, same thing. Starting with the schema and not only in your development process, but also in the data pipeline process. So when they say move your schema as far left as possible,

they're talking about the producers of the data. So ideally, rather than having like your consumers of the data being in charge of saying, basically dealing with schema problems from different producers. So you can imagine like a website or something or a database, like querying for the last couple events, where create date is greater than this, or create date is null, but insert date is greater than this,

or time is greater than this. Basically what I'm talking about is having a bunch of events with similar, not quite lined up schemas and it's a real pain to deal with it on the client side because you can have more than one client right so you've got your website doing that and you've got these scheduled tasks doing that and now you've got a mobile app and these rules that you've kind of put in place to like deal with data integrity problems spread out and get worse over time and so one kind of common thought a couple years ago was like having this kind of translation layer having an api uh in place that would normalize all that into you know say hey time create date and insert date it's all the same thing let's all just move it into a new

column called timestamp and and that was all well and good but to me that kind of the revelation the reason i'm talking about this podcast was they said take it back as far as you can if you can do this on the producer if you can have them agree to a scheme up front then it's going to save you so many problems and they talked a lot about nullability too and being able to have those rules as close to the producers of the events as possible because otherwise you're always messing with that layer and building all those crazy rules into that layer and so if you can come up with like some sort of common schema like elastics got their ecs or elastic common schema and they're always trying to push vendors and just everyone

into trying to fit your like security event data into this single format because it makes it so much easier for everything to work downstream. Not just your clients, but the entire pipeline. If it can rely on timestamps being in a certain format, certain fields not being null. So I thought, I didn't really have a question there. I just thought it was interesting.

I actually like that a lot. This is one of those things that I think it's ideal if you can do it, but you can't always do it right. Like that's if, if you're creating a new platform and I mean, just, just for kicks, let's say that you're going to create a podcast platform.

You could pretty early know what kind of say that you're going to create a podcast platform. You could pretty early know what kind of information that you'd want to be in your data, your API, your schema, right? Like it's, it's a decently known, um, sphere of data that you can get out there. So I think that's pretty easy. Um, it gets way more difficult when you're taking data from multiple sources. Right. Like so if you're producing the data, like you said, I think I think it's fantastic because at that point you can. It's like you said, oh, man, how much time have as all of the significant time has been spent on that. Yeah. I mean, it's, it's a crazy amount of time. I remember, I mean, just something as simple as trying to load data from Excel into SQL server. Um, as many times I've done that, I can't tell you how much time I wasted on, Oh, well that data had line breaks or this had this, or this,

like if you could define that kind of stuff and the column names and all that up front and be like, hey, this is what you've got. You're going to have to use our API to even push data into this thing. Then you're good. That would save a ton of time downstream. So I love the idea. But when you start getting into things like unstructured data or you're pulling from agnostic systems out there, right? You're kind of at the mercy of it. As a matter of fact, one of the interesting things, we haven't talked about this stuff in probably a year or two now, but like the Uber blog,

when they were talking about creating their data lake and their data warehouses, one of their biggest problems was they get data in from all kinds of devices, all kinds of things. And it's exactly what you said, right? Like one set of data might have created time as the name of the field. Another set might be inserted time. Another one might be something else, right? Well, one of the biggest problems was to make that data useful for consumers of the data is they needed to normalize that. And like you said, doing it when it's coming in from a bunch of different places, that's a whole lot of data mapping and a whole lot of error prone processes. But the problem is, if you don't do it somewhere, then then you have this data lake that has a bunch of raw data that is almost impossible to use. Right. Because it's you know, you got it all.

But what are you going to do with it now? So, yeah, I love the idea of it. I love the idea of moving moving the contracts left if you can. Yeah. The only kind of counterpoint I can think of there is that as a developer it hurts me to not take all the data i get so you can imagine you're like creating a you know a new producer for some sort of new device or something and these are the four fields that you collect from the device oh but there's three that maybe someone find interesting someday what do you mean i can't just pass those along because no one else has them like i you know i hate the idea that someday someone would come

back and say like what do you mean you haven't been collecting i don't know temperature or something like that's it's producing it and now i want to use it and you're saying you haven't been collecting it because it didn't fit some stupid schema so i mean that that is a very good argument against it right like even the elastic common schema that you mentioned which is sort of their um security related schema right for for uh security events and that kind of stuff. If your bits of data don't map somewhere one-to-one in that, then it's exactly what you said. You almost have like this anxiety about, well, I don't want to just drop this on the floor. I want to cram it in somewhere. And, and then things get

nasty, right? Because I'm sure people would come up with all kinds of workarounds like, well, let's just have custom fields one through five or a custom collection where people can put whatever they want in it. And then what you end up with is a half-filled-in schema because people didn't want to have to deal with mapping at all. And then they threw everything into the custom properties or something like that, right? Like, I mean, yeah. Yeah. It's tough. But but hey there's a podcast we'll have a link in here you can check it out listen to what they have to say about it and uh you know think about it excellent all right so i think it's that time of the show where where we beg for reviews um and and family feud uh i didn't prepare anything hey we can't do it there's only two of us right

like i mean that's right yeah we can't yeah we can't so there will be no game time um put it on the board or anything like that like we're not gonna have it this time but we can ask you if you if you haven't had the chance you've been listening you somewhat enjoy the podcast you know and you have a minute later if you haven't had the chance, you've been listening, you somewhat enjoy the podcast, you know, and you have a minute later, if you haven't already, please go to codingblocks.net slash review and click one of those links there and drop us a hello and leave us a rating on, I think we have Audible and iTunes. I think we tried to do Spotify, but I don't really understand how that one works. So at any rate, yeah, if we do love getting them, it really makes us smile. And

it's really nice to know that, you know, these 199 episodes, very short episodes that we've done, you know, are impacting people and, and, and putting smiles on other people's faces. So indeed. Oh, all right. So I had a couple here in one sort of tailors or dovetails into what you were talking about earlier. But the first one I wanted to ask you is we, we, so we're like I mentioned, we're 199 episodes into this thing now. Right. And, and I don't think we set out to do this when we first started i think like when we first started this podcast we called it codingblocks.net because we were dot net guys and and that's that's sort of what we were going to do initially and then we started realizing hey why why tie us into just dot net because most of the stuff that we want to talk about is more about how to become a better

software developer not not how to become the best.net developer it was how to be a better one right and so in that time we sort of accidentally turned into a bit of a book club as well right like i don't again we didn't plan to do this it was like hey what's a good topic well people are talking about clean code let's let's go look at it um so with that what are of the books that we've done if you could name let's say a top three and in order what would have been your most impactful and why? All right, I'll start with number one while I think about the rest. Okay. And that's designing data intensive applications.

And like you said, when we started, we had like a kind of a more narrow focus. I mean, even if you look at the first couple episodes, it was very focused on like, you know, like garbage collection and boxing and unboxing and interfaces and things that were very like kind of low level kind of, you know like garbage collection and boxing and unboxing and interfaces and things that were very like kind of low level kind of you know like language constructs not like very much like the kinds of things that you typed in order to make the you know compiler happy whatever you know we probably argued about semicolons and taser spaces you know whatever as we've grown like you know our careers changed and things we've been interested have changed and, you know, things have been flowed. And so designing data intensive applications has been really good for basically the kind of stuff

that has been plaguing me for the last couple of years, which is kind of more like, I guess you could say like system design type problems and the kinds of things that I'm struggling with now. And I don't really think too much about like language features. And, you know, I can't even tell you the version of Kotlin that's newest or what got released in because I don't really think about that stuff anymore. I'm sure there's nice stuff in it and I would probably be happier if I knew it.

But that's just not where I'm spending my time. It's like the code has become the easy part and the actual like data architecture and making things like resilient and logging and alerting and dev ops like all that stuff is it's just where i'm putting my time in now and that's the stuff that i'm wrestling with so that's you know what i've been kind of going after i i'm still working on what number two is i'm kind of tempted to say the git book just because i learned some things there that i didn't know but i think there's some recency bias there um so i think i'm just not going to have a number two okay all right but number three for the same reasons i kind of gave it above is clean architecture one of the uncle

bob books where he kind of took some of some things from clean code which you know i still really enjoy but it's just not really that applicable anymore and kind of apply it to architecture and kind of pushing things out to the boundaries and kind of how to have things working together in a bigger system. And I think that's been a good one. Okay. Second, DevOps Handbook. Okay, the DevOps Handbook. Hey, before you say on the, you said it's not applicable anymore.

I think what you mean by that is you sort of got your coding habits because we've been doing it so long that that's not necessarily a book that you go back to anymore. So it didn't impact you as much in the past 10 years as it would have, you know, 20 years ago. Right. Yeah. Like now, if I open up a code file, I don't think like, oh, my gosh, what was I thinking with these 10 lines or like, what does this function do? I just don't like it. I don't think that about my code i don't really think that about other people's code now what i do think is oh my gosh why did

i put this code over here when i should have put it over there in some other service or some other layer or some other kind of um more architectural kind of higher level system design thing and so that's that's the kind of stuff that i'm thinking about. So less, less about variable names and more about like, uh, you know, dependency injection and, you know, like they're using the right tools for the job than I am about like how many methods, uh, or how many lines are in my method or whatever. Yep. Totally. And then, all right, so now go to your number two.

Oh yeah. DevOps handbook. I just thought that was really good. Uh, it's, um, like there's, I don't, it's not my favorite that was really good uh it's um like there's i don't it's not my favorite book by far but it's just i really needed it at the time and so it was good to kind of have that influence and so i'm gonna just go with it all right um i'm actually adding another thing that we'll talk about here in a minute, because you said something that triggered it. All right. So interestingly enough, and I think this, this speaks to

just how, how important and how good these books are. So before you just put your list together, we have two of the same and the same positions. So for me, designing data intensive applications is my number one also. And for the very reasons you said, and even more importantly, so all the reasons you said, absolutely. And then on top of it, you don't realize like when, when earlier in our careers, and I say earlier, I mean, probably the first 10, 15 years of our careers, you could almost say that the relational database kind of owned all your data storage, right? For sure. And it wasn't until things like Google and Facebook and these kind of things came up that you started looking at, oh, well, there are different storage technologies that have to meet, that have to exist to meet different needs, right? And knowing about the different, there's data structures and data science that

you need to know about, right? Your arrays, your objects, your structures, all that kind of, you need to know that stuff. But taking it like 10 steps further and knowing the different types of technologies that exist out there to answer different types of problems is so key and that book does it in a way that is never dry it's always an interesting read and i can't say that about many technical books right and that's that's a big one for me. And then on top of it, to talk about how the storage behind the scenes for these various different things work, like SS tables and dictionaries

and all that kind of stuff and hashes. And like, when you start looking at it, you go, oh, I get it, right? Like I understand why RocksDB exists, right? Because you'd almost go, well, why do you need that? I mean, you got, you got a database server over here and it's like, oh no, no, no, no. This is answering a very specific problem. And, and that's what that book did for me and continues to do for me. And, and probably in this world where data reigns King, um, you need to know that information.

So that one, that one is number one for me. Um, the second one, man, I actually thought about DevOps handbook and, and it was impactful to me and open my eyes to it. But I think the one that for me worked out really well was the imposter's handbook. Oh yeah. There were a lot of things in that book. It taught things the way that I wish computer science in college had taught things. Um,

and that's saying a lot because I felt like in, in college they would throw out a bunch of ideas. Um, you know, there was the, uh, God, I can't, the Bellman-Ford. Is that it? I can't remember which one that was. Or Wyman-Ford.

I can't even remember the name of it. There were all kinds of algorithms, right? Like the graph algorithms. Yeah, graph algorithms, all that kind of stuff. And when you're in computer science, you don't really understand why you're going through a lot of that stuff, right? Because you're fairly new to it. You're like, who cares? Like, why? And when you come back to it, I guess, at least in the intention of the author who wrote this book was, hey, you're somebody that's out there writing software now you probably want to know what these things mean and and it puts it into a context that i think was really good for a lot of people to where you don't feel like you're lost when people start talking about big o notation and all that kind of stuff and and so for me i think that was one of the better reads, one of the better covers that we've gone over.

Yeah. Yeah, totally. I forgot about that. And so what? Yeah, it hasn't been a minute. I thought your number two was going to be DDD. No, no. The vocabulary just, yeah.

Yeah. You know what? In all honesty, DDD would have made my list and probably would have been pretty high on my list, like maybe number two, if it hadn't been how hard of a read that book is. Yeah. I mean, that book caused me to look up other books on the subject. Right. And that's,

that's never a good sign, at least for me. Amazing, amazing concepts too thick to get through. And then the third one for me also was clean architecture. And's again what you said it's once you once you learn how to program you learn the ins and outs of your programming languages that you've chosen it doesn't even matter which ones they are c-sharp javascript um you know java whatever pick it doesn't matter once you've learned those and you know how to make methods and functions and you know how to put them together and make things make sense.

It's then how do I piece this thing together to where it's not a ball of spaghetti anytime I go to run it. Right. Oh, and now something else needs to use this library over here. How am I going to do that in an intelligent way? And I think that's where clean architecture sort of stitches all that stuff together that you probably learned over the years but if you're working on smaller systems you didn't have to think about in that way and i just really like that about that book yep so um yeah so i thought it was really interesting that two of ours landed in the same spots on that list because i mean that just tells you how good those books are.

So hopefully if you haven't picked up either one of these, actually, we should put links in the show notes here. I also have a link to our resources page. So if you are curious about any of these books that I just mentioned on our resources page itself, I have links to the various episodes to where we talked about different portions of the books. And we've done a number of them on designing data-intensive applications. It might be the only book we ever end up finishing. True.

That also says something. Next section is on what you call transactions. Man, that's going to be big. That's going to be good. I think you said that one was pretty dense, too, though. That was like a 40-pager, right? Yep. That's like 24 hours of material for us. Yeah. Um, I'm not advocating for everybody to reach out to us to ask us, um, you know, personal advice on interviewing and, and things that they should ask or whatever.

Um, but I'm also saying that we are there and there's a huge community in our Slack. We've, we've mentioned it before and, and I'm not kidding. If you haven't been there, go to codingblocks.net slash Slack and join because there truly are an amazing group of people that are on there all the time. Somebody did reach out to me recently and asked me about questions that they should ask during an interview. And so I gave some feedback and tried to help. And I'll give a little bit of information. I'm not going to tell who it was or anything, but it was going to be working for a company that was sort of in startup mode,

not, not completely startup. They'd already gotten a round of funding and, and we're doing some more stuff. And so some of the questions I wanted to, to throw his way and, and you can attest to this too, Jay-Z is if you're ever working for a company that's sort of in growth mode, they take on investments, right? And that's called a series A, B, C, D, E, right? Whatever. All the A, B, C, D is what number of funding they got. So if they've only had a series A, they've got an initial round of funding. If they got a B, then they got a second round of funding. What's interesting about this is it's, it's, it's a double-edged sword, right? So the first side of this sword is, okay, they've got people interested enough in what you're trying to build to where they're willing to throw some money at it.

That's really good, right? That's, that's really good because now you have capital to be able to build this thing out. Um, if you start seeing a series B, then it's like, okay, well they're in growth mode. They're trying to hire, they're trying to build this thing out faster, which means you're taking on, you know, more costs to be able to do so. But this is where you have to start looking at it from somebody that's looking to take a job like this is with every round that they come in, a lot of times when you come on, they're going to give you options in the company, right? And say, Hey, um, these options are worth 50 cents if, if they vest, right. And, and if the company's worth

$3 at the time that it all vests, then you just made $2 and 50 cents a share, right? It's, it's pretty awesome. Um, what happens though, as more series of funding come in that dilutes the pool and it drops the value of the overall shares, right? And so your original 50 cents, if there was only ever a series a and it ended up going public, it could be worth a ton of money. If you get into a series D, um, and all of a sudden there's, you know, uh, 500 million shares out there or something, then what, what you got at 50 cents when it goes public, maybe the company's only worth 20 cents a share. And so you end up with nothing. So it's an interesting thing to think about. Um, just be aware of stuff like that. If you're looking for startups startups there's a uh what is it is it thompson's i forget there's there's a there's a website that you can look at that will actually

give you information on on companies uh is it the one that has the event every year um ah i'm trying to what's a good startup was a, I can't think any right now. What are any new startups? Pitchbook.com. That's probably not what you're thinking now. No, it's like. Crunchbase, is that what you're thinking? Crunchbase will show some stuff too. Yeah. I think that's a good one. But they'll actually show you like how many series of investments there's been,

how long it's been around, how much money was put in and that kind of stuff. So it's really good to do your research on that kind of thing. And then the last thing I want to say here is and this goes back to designing data intensive applications and interviews in general. Know before you go in what the company makes. Right. So, so I mentioned like earlier in our careers, like everything revolved around the database, whether it was SQL server or Oracle or whatever, right? Like it was all the database. Well, if you were to go into an interview and they said, Hey, how would you design Twitter? And you start talking about, well, I'd put this table in, in the database.

I'd probably design these five tables, and then we go from there. And then they throw the question out there that Jay-Z, I think, brought up initially on this podcast a while back is the celebrity problem with Twitter, right? Well, what do you do now when a celebrity puts a post out there and now there's 10 million people that need their timelines updated? How do you design that? And if all you've ever looked at are relational databases, you're kind of going to be stumped because honestly, I mean, Jay-Z, can you think of a good way to design that in a relational database? No. I mean. Well, the only thing I think of is kind of rendering out.

So basically when someone makes a post or something, just spit that stuff out so that it's ready for consumption. But not really. Right. And even then, rendering it out. So let's say that the only thing, the only tool that you're thinking about when you're in this interview is, is your SQL server or whatever. Well, you get this message in from

Taylor Swift and now you're going to have to go pre-render. Um, you know, I don't know how many followers she has a hundred million. I don't know. Yeah. A few, um, you're going to have to go write a hundred million records out, but this thing needs to show up in everybody's timeline pretty quick. Like you have a problem. So. Um, and there are different type of indexes and there's different types of storage systems out there. You have search engines like elastic search, you have already BMS as you have, um, uh, columnar storage indexing, you have key value pair it like there's all kinds of different ways to do this. And you have to learn that, Hey, you need different tools for the job, right? Like if, if you're used to the world where somebody types something on a website and then it's just calling an API that calls directly to the database and writes it, you're probably not going to be able to answer a scale

question very well, because that's, you know, they're going to be like, well, what if the database is unavailable? I don't know. Right. So. So I say all that to say, look at what the company is creating. What is their product? If you're going into interview. What are they building so that you can at least go in and figure out what it is you need to know before you even go into the interview.

You know what I mean? Yep. And yeah, also I think if you're going into, you know, a riskier startup and you're not sure of, uh, you know what the longterm is going to be there.

Uh, you've got to think about like what you need to do to make your family or, you know, like whatever life resilient to those kinds of, uh, dynamic changes. Cause it could blow up in a good way or a bad way, either way. And so you just, you know, have to be ready for that.

And it's good to do that at a time in your life that you can take that sort of risk. And so, you know, if you end up doing that, I hope it works out for you. Yeah. But also, I guess on that same front, right, if you're going into a riskier situation, you should be compensated for that, right? If you're going into a riskier situation, you should be compensated for that, right? Like there's a difference between going and working for a company like Microsoft that's been around for a while or Amazon or whatever. And somebody that's just come, come up off of, you know, the newest startup fat out there. And you should probably get paid a little bit more in upfront compensation, you know,

meaning your salary than if you went to one of these more stable jobs. Like we've talked about the big ones out there, like they usually load you up with stock to try and force you to stay around with the golden handcuffs for a while. Whereas the startup is probably going to pay you more cash in your salary because they know they're a riskier investment, right? Yep. And if they don't have salary, you better be getting a lot of options or stock or something. Yeah. Something to make it worth it. So yeah, know that going in. All right. And then the last thing I got here is we've talked about this, man, the hammer and the nail. When you have a hammer,

everything looks like a nail. We've talked about this. You've got a cabinet hanging on the nail. When you have a hammer, everything looks like a nail. We've talked about this. You've got a cabinet hanging on the wall. All you got is a hammer. Well, you're just going to start hitting that cabinet until the screws break and you pull it out, right? That's what you're going to do. May not be the most effective way to do it. You'll probably get it done eventually, but it wasn't going to be pretty.

Be careful about that. We as developers have a tendency to fall in love with whatever new thing that we're doing, right? And it's not a bad thing. It's a good way to really learn the limits of a technology. So, I mean, we talked about this, man, it's probably been three years ago now i guess i don't know um when we were talking about elastic search a lot right oh yeah and like episode 80 ish was it really man it's been a while and outlaw would know too yeah outlaw would know um but i i say this because it's easy when you've been frustrated by another tech stack that you want to go all in on another one. Right. So,

so the relational database that you were using and abusing the wrong way has been failing you. So now you want to go all in on elastic search. Right. And, and then you find out, well, you can't do joins over there. Um,

well, we'll figure something out. Right. And and then you find out, well, you can't do joins over there. Well, we'll figure something out. Hopefully you will. Right. Hopefully you will. Maybe you won't. So I just say that to say in and it's driven home and designing data intensive applications a lot throughout that book is you can't be afraid to duplicate data because different storage engines exist for different reasons, right? So if you are using something like an elastic search or a solar, it's because it has that index that you can search differently than if you're using something like a SQL server. If you need something that deals with tons of relationships, then maybe you need to be

looking at a graph database, right? If you're looking for analytic type stuff, then maybe you need to be looking at a Pino or a Druid or something like that. Clickhouse, isn't that another one of them? But don't fall into the trap that, oh, well, we have the data over here in, in Clickhouse. Now we can put everything there. Um, or it's all an elastic search. We can put it all there. And it's like, wait a second, but now you can't do your joins or now, uh, you can't update things properly because this isn't supposed to be a mutable set of data. Like don't, don't be so quick to jump all in and throw away what you do know and what you do have working.

Um, just because you have something else that's answering a very specific problem very nicely. You have any thoughts on any of that? The only thing I would add there is that it's gotten so much easier to add technologies that it gives you a chance to experiment with things like Docker Compose or

if you're working Kubernetes or just containerization in general makes it easy and cheap to experiment. So, you know, that's a good thing to have in your back pocket. If you're not familiar with that stuff, I definitely recommend it. I think we talked about this a couple of weeks ago, too, where there's something that sometimes when things get popular, there's like a backlash, you know, like the Nickelback problem or whatever. Like the more popular something gets the like the more critical the critics get the haters gonna hate right so so i think sometimes like

lc's like backlash against like containers or you know kubernetes or docker just because it's you know complicated and people it doesn't solve you know their particular needs which is you know flat they're entitled to that opinion but even if you don't like it even if it's frustrating even if you don't think it's useful to you uh it's a tool don't neglect it and uh it yeah it's it's so powerful just in terms of experimentation if even if you don't use it for a production that it's it's worth getting into so that's a total other tangent there but just wanted to say that uh you can you can experiment with things and see how you like him and uh you know you don't have to fully commit to something before you you know try it like do a little bake off or something and uh you know like try out uh screwdriver once in a once in a while

it's it's interesting you say that because i mean we both we've both teetered on on either side of this right like i don't want to add another piece to my stack. And it's like, well, but I don't want to write my own piece of this either. And it becomes difficult, right? Like, where's the line? And that's something you have to feel out. There is no right or wrong answer to it. Totally.

There's been times when I've been like wrestling with some pieces of technology. I'm like, oh man, I hate this thing, this open source tool or this service, whatever. Like, all I do is spend time like configuring it and trying to figure out why it doesn't work and dealing with problems and reading its docs and stuff. It seems like a real drag on your time. But then you have to remember that if you had written your own thing,

that not only would you have had that development time there, you also would have had trouble configuring it and deploying it and figure out why it's not working and good luck with documentation right so there will be none it's easy to it's kind of like think about the things that you're missing out of when you're using some other tool it's easy to forget about all the time you would have uh you had you know spent in not fun ways had you built something custom yeah totally all right so one one last bonus question for this for this episode um what would you say is we we did the books like what was the most impactful book what is the most impactful technology that you've used or that

that has come into your view in the past several years? Definitely Kubernetes. Kubernetes? Yeah. I was curious whether you'd say Kubernetes or Docker. Yeah, Docker's in there, but Docker, there's some alternatives, you know? And, like, aside from mining a Docker file, like, I don't really use it that much, you know? I'm kind of abstracted from it. It's definitely there.

It's core to my everyday experience, every blood-sucking day but i still really enjoy it you know what i think uh i think i would probably be right there with you i think that that kubernetes is the thing like once you once you dip your toe in a docker then then you start going oh man this is amazing and then you get into docker compose and you're like oh this is the greatest thing since sliced cheese right um i guess bread's the right way to say that but cheese is better we all know it um but it's not until you get to the i mean theoretically hands-off capability of kubernetes that you're like oh this is how it's supposed to be right yeah and i think for that reason i'm there with you now there is i feel i feel like you can become reasonably proficient with docker in maybe a month yeah i don't think that's possible kubernetes no No. No, I still feel like a baby.

I feel like kindergarten. There's so much stuff I don't know. Yeah, it's crazy. And then you start thinking about extensions, all the plug-ins. It seems like every day I'm hearing about some new tool that people have been using for five years that I've never heard of that is so amazing and so great. Yeah, it's pretty crazy how big that that um world is but yeah i think too i would also be in the kubernetes um camp for what the most impactful is all right so i think that was it for uh for the meat of this episode so that brings us to what is typically my favorite part of the episode,

and that is the tip of the week. All right. And so I've got another Obsidian tip here. And if you don't recall, Obsidian is a note-taking app that's all based on Markdown. You can run it just locally on Markdown files, and it's got really nice tools for interlinking. And it's just a nice interface and involves searching and other things. It's really nice and uh it's also got some features you can pay for to kind of give you like you know mobile syncing and some other you know kind of nice to have whatever um but one thing i don't know if i mentioned before is that it has a command palette it's kind of the way that vs code does where you can hit command p it's's even the same shortcut and And start typing what you want to do. So if you want to like edit settings Don't go looking around in the UI

Command P and start typing settings earlier today. I realized I didn't know how to do a strike through and markdown I just thought something I do often. Well, I just did command P. It's our typing strike through. No. Hey, there we go So it's really nice some for features that you know exist, but you're not really quite sure how to do it. Just start typing. It's like VS Code. Like, now I don't want to use anything that doesn't have a command palette. I remember CodingBox sponsor Shortcut.

That was like part of the whole big thing. It was like the ticket management system that had a command palette so you could do like shortcuts and stuff like that. And it's so, so nice just to be able to kind of think what you want and then be there like a half second later. Dude, that's amazing. I did not know that existed.

I mean, just earlier today, which by the way, I don't remember who it was that recommended obsidian, but, um, we should give a shout out again to whoever it was because I know you use, you use it to death.

Yeah. I use it a lot.'s amazing um but i had a website open with markdown um cheat sheet or something earlier today because i couldn't remember how to do something and if i'd known that i could have stayed within the within the tool yeah it's really nice oh that's killer all right so for me i'm i'm actually stealing some from some people on our slack channel, which again, our coding blocks.net slash Slack is amazing. Um, so from Aaron Jeske, Hey, it's double a, uh, he mentioned the ghostry plugin for Firefox. Now he mentioned there's something coming up in Chrome and I didn't, I didn't actually read exactly what, or I didn't see what he meant by it, but there's some sort of privacy thing coming in Chrome that he didn't like. And so he switched over to Firefox

and he mentioned the Ghostery plugin because not only will this thing block ads and all that kind of stuff, it'll also block those super irritating cookie settings things that pop up on every site on the internet. Now, too many times I've accepted just stack overflow alone.

You can't escape it, man. That site stack overflow stack exchange. I'm like, why can you not remember what I just did two tabs ago? Like I don't, I don't get it. So that looks pretty amazing to have a link to that

for the mozilla plugin or the firefox plugin and then this one dude this one's amazing so you got to click this link down here so this is from scott harden also in our in our tips and and tools slack channel it's fake update.net so if you're me for a second man i swear to you if you ever want to screw with somebody this is assuming you're in the office with with with people right you can take their their browser and go to this fake update.net and he has a link to the win 10 uh upgrade you open this thing up and it's got this working on updates thing with the windows and f11 that baby and put it in full screen and i promise you oh my gosh that is amazing that is that is absolutely phenomenal and and i want to say that uh jamie even said he did it to

somebody and they they looked up and they saw it they made it to like 147 percent and they were like wait a second yeah nice so so this thing does i don't know how frequently it jumps a percent but it's definitely some interval of time so yeah yeah if you really if you really want to mess with somebody just just load this up on the screen and put it in full screen that's amazing your pc will restart several times you're like oh man man it's so good um oh and and one other thing so uh my uncle he got two new dogs time at timex and rolex um there's watch dogs nice nice oh man is that micro g that is micro g yes nice that's awesome oh it's so beautiful oh all right so that that is our dad joke of the episode i don't think my son gave me any this week so we'll have to go with that one all right well i guess we can just call it here then

yeah how about that i think we're in under an hour and 30. This might be the shortest episode of the past five years. Yep. All right. Well, uh, no, I, now I guess we can say, uh, to who causes the show length, right? Yeah, that's it. The outlaw. All right. So we got to do our outro here. Yeah. All right. So, uh, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app. Hey, and be sure to head over to codingblocks.net slash review and leave us a review if you haven't had the opportunity.

Hey, and while you're up there at codingblocks.net, check out our show notes, examples, discussions, and more. And send your feedback, questions, and rant to the Slack channel. All right, and make sure to follow us on Twitter at Coding Blocks or head over CodingBlocks.net and find all our social links at the top of the page. And maybe by the time you're hearing this, we'll have one of those fancy blue check marks finally. I don't know. Ooh. Yeah. We could do that.

We'd be ballers. Yeah, eight bucks a month. Verified CodingBlocks. That's right.