Speaker 1: Hey, folks, welcome back to another episode of JavaScript Jabber.
Speaker 2: This week, on our panel, we have Steve Edwards.
Speaker 3: You know, from a cold and rainy Portland, which is
Speaker 3: typical for this time of year.
Speaker 4: A j O'Neil yo ya yo, coming at you live
Speaker 4: from a beautiful day in the shed.
Speaker 3: I thought it was the purple room.
Speaker 4: It changes every time, you know that.
Speaker 3: No, it doesn't. It's always purple.
Speaker 4: Well yeah, I mean it's obviously it's purple for those
Speaker 4: that can see.
Speaker 2: Right. Yeah, he won't tell us.
Speaker 1: Where he is, but folks just look at the counting
Speaker 1: records that he Healan's house. I'm Charles Maxwood from Top
Speaker 1: End Devs and we have a special guest this week,
Speaker 1: and that's Corey Brown. Corey, do you want to say
Speaker 1: hello and let people know who you are and kind
Speaker 1: of what your background is?
Speaker 5: Sure? Hi, Corey Brown, I'm coming at you from Saint
Speaker 5: George currently, not where I regularly live. That's where I
Speaker 5: am right now.
Speaker 2: It's supposed to be warm down there.
Speaker 5: It's warmer than where I Yeah, it's warmer than up north,
Speaker 5: that's for sure, which is why we're here.
Speaker 3: I have a friend that lives down there. I'm always
Speaker 3: so jealous.
Speaker 5: It's it's love.
Speaker 4: Yeah.
Speaker 5: I I am a well currently I'm architect at a
Speaker 5: place called Omni. We are a GPM company, JP Morgan Company,
Speaker 5: and I've been in the industry for about fifteen years.
Speaker 5: I enjoy speaking and sometimes on occasion, arguing with people
Speaker 5: about childscript stuff.
Speaker 1: Yeah, you picked a fight with our friend Dan and
Speaker 1: then he ran away.
Speaker 2: That's right. Well it was either that or he had
Speaker 2: something else going on.
Speaker 5: But you know, it reminded me of the argument and
Speaker 5: a Family Guy where the rich guy rolls up and
Speaker 5: he says, oh, Reginald, I disagree and peels off those
Speaker 5: kind of the extent of the argument.
Speaker 3: Ouch.
Speaker 2: Yeah. Yeah.
Speaker 1: So anyway, so yeah, from what I am gathering, and
Speaker 1: it looks like AJ was part of the conversation on
Speaker 1: Twitter as well, and so you all can tell me
Speaker 1: where I get this wrong.
Speaker 2: But there was a conversation.
Speaker 1: AJ was suggesting maybe we do an episode on some
Speaker 1: of the less understood dom APIs, and then Dan asked
Speaker 1: the question, do React developers really need to understand the
Speaker 1: dom APIs because React does a lot of these things
Speaker 1: for you, and you said, yeah, they do, and he
Speaker 1: kind of disagreed and So the idea was you could
Speaker 1: come on and that conversation with you, and then he
Speaker 1: ran away because you're so intimidating.
Speaker 2: I think it's weird, but it's.
Speaker 5: Got to be. It's very a little bit of gray
Speaker 5: right there. Really, Oh, you rus really know what he's
Speaker 5: talking about.
Speaker 2: That's right. You've got a real gray beard in the house, folks.
Speaker 1: So anyway, let me know if I missed anything important there,
Speaker 1: and then if you or AJ want to chime in
Speaker 1: and give us a little more context.
Speaker 2: We get going on talking about this because I think
Speaker 2: it'll be interesting. Yeah.
Speaker 5: I think that's the sum of it. And had I
Speaker 5: known that you could get on this podcast just with
Speaker 5: a simple I don't think that's quite right comment, that
Speaker 5: would have done it a long time ago.
Speaker 1: But no, it's good, all right. So yeah, so is
Speaker 1: there anything more to it? Did miss anything?
Speaker 4: No?
Speaker 5: I think I think that is the That was the
Speaker 5: conversation we had on Twitter. But you know, should I
Speaker 5: guess the premise of the argument is should dude react?
Speaker 5: Developers need really need to understand the dom is is
Speaker 5: react sufficient for your needs? I think there's there's a
Speaker 5: bigger question under that. More like, given the rise and
Speaker 5: the universality essentially a frameworks out there. The NILA jobscript
Speaker 5: crowd has grown increasingly smaller. So given that you really
Speaker 5: a lot of people make the argument you really can't
Speaker 5: do jobscript work anymore without working inside of a framework. Therefore,
Speaker 5: do you need to know the platform upon which that
Speaker 5: framework is built or those frameworks sufficient to accomplish everything
Speaker 5: you need? Do you want to live in the abstraction
Speaker 5: or do you need to be able to dive down
Speaker 5: into the metal Sometimes, at least that's the way I
Speaker 5: am thinking about the problem.
Speaker 1: The question, and your answer, it seems is obviously, yeah,
Speaker 1: sometimes you need to get into the metal. So do
Speaker 1: you have examples or do you have an argument for that?
Speaker 4: Yeah?
Speaker 5: Actually I had. It was interesting just a couple of
Speaker 5: days after that conversation, which made it sound like it
Speaker 5: was a it was a monumental thing. It was kind
Speaker 5: of a passing thing. But with that said, just a
Speaker 5: couple of days later, I was working on a problem
Speaker 5: and just it was attaching a pop over a drop
Speaker 5: down and kind of anchoring it to a to an element,
Speaker 5: and I was refactoring something that'd done this, and the
Speaker 5: original the old version was using just pure react as
Speaker 5: much as React as they could, so using all the
Speaker 5: hooks and all that stuff. And even then you have
Speaker 5: to you have to do some some event listening. Even
Speaker 5: when you're trying to go completely into React, you have
Speaker 5: to do event listening, so you ad event listener on
Speaker 5: scroll and and that sort of stuff. But in the refactor,
Speaker 5: I just ripped all of that stuff out and I
Speaker 5: did a very simple event listener on scroll and an
Speaker 5: event listener on on resize and use the same handler
Speaker 5: for both. And it was not The previous version had
Speaker 5: a lot of bugs. It would not track well, it
Speaker 5: would drift, and when things things would get out of whack.
Speaker 5: Ripping all of that framework stuff out and dropping just
Speaker 5: down into the very simple I mean scroll eventlisteners and
Speaker 5: reset event listeners are not like new domain pies. They're
Speaker 5: super they've been around forever. But just leaning on those
Speaker 5: like fixed all of the bugs that had with it.
Speaker 5: It is now buttery smooth. And it was kind of
Speaker 5: a lesson that these frameworks they're designed to do something
Speaker 5: that like a specific thing, and when you're doing what
Speaker 5: those things are designed to do, they work really well
Speaker 5: and you should lean into them, but they they aren't
Speaker 5: designed to do everything, and when you try to force
Speaker 5: that square peg into that round hole. For everything you
Speaker 5: try to do and you are not aware of your
Speaker 5: disregard the platform upon which it's built, which is designed
Speaker 5: to do a slightly different thing, you can you over complicated. Actually,
Speaker 5: I was just reading this morning. I was rereading out
Speaker 5: of the tar Pit that that old article I can't
Speaker 5: remember the author's names. That's really about complexity, about the
Speaker 5: difference between necessary complexity and unnecessary complexity, and depending what
Speaker 5: you're trying to do with the frameworks, can introduce a lot
Speaker 5: of unnecessary complexity. And that's what I found. That's what
Speaker 5: I happened then was fifteen years.
Speaker 3: You know, check I have to add the obligatory joke
Speaker 3: in here that this seems like a really overreaction.
Speaker 5: Oh to this question.
Speaker 3: Wow, there it is, But you know, I mean, so Corey,
Speaker 3: My background is I started out with PHP straight PHP World,
Speaker 3: and I got into droupil for a while and then
Speaker 3: Angular and View. I have never played with React myself,
Speaker 3: but to me, I'm like, my answer to this question
Speaker 3: is duh, yes, you need to know both. I'm just like, yeah,
Speaker 3: how would you not need to know the underlying basics?
Speaker 3: Of any given language. There's no way that any framework
Speaker 3: I think, is going to be able to do everything
Speaker 3: that the underlying platform can do. And you know, I
Speaker 3: listened to as woke as he is. I still listen
Speaker 3: to Chrispherd Nandy quite a bit, and you know, I
Speaker 3: get his newsletter. He makes a lot of great points.
Speaker 3: You know, you listen to other podcasts and people talk
Speaker 3: about using the platform. You know, use the platform, use
Speaker 3: the dom APIs, use what's already there, and even in
Speaker 3: view and uh and uh Lara Bell and Drupel. You know,
Speaker 3: there's a lot of helper functions. There's a lot of
Speaker 3: things that will do stuff. But time and time again,
Speaker 3: you just got to get down to the basics and
Speaker 3: use some of the basic tools. I mean, a framework's
Speaker 3: not going to do everything, and why should it, you know.
Speaker 5: Yeah, yeah, and more than that, a few more things.
Speaker 5: I add a little bit of color to that. So
Speaker 5: the original the new one uses the new popover API.
Speaker 5: I don't know if any of you guys know of
Speaker 5: it or used it. It's fantastic, it's lovely.
Speaker 2: I keep wanting to play with it.
Speaker 3: Yeah, I've seen a lot about it, haven't had a
Speaker 3: chance to get down and use it yet, because that's
Speaker 3: a you know, that's one thing that javascripts had to
Speaker 3: do a lot of anytime of pop up, pubble or
Speaker 3: stuff with dialogues, modals, whether it's date pickers, you know,
Speaker 3: you name it, that's always something jobscripts.
Speaker 1: I saw that was in the spec and I was
Speaker 1: just like, oh, my life just got better.
Speaker 5: But oh it's it's a delight. And ninety percent of
Speaker 5: the code I was able to eliminate from the pure
Speaker 5: React version was just state management, which again goes back
Speaker 5: to the out of the Tarpet article where it identifies
Speaker 5: this primary source of a necessary complexity of state management.
Speaker 5: And you can just eliminate all of that. You do
Speaker 5: not have to worry about it. And so you have
Speaker 5: the scroll handlers and the research handlers. But the thing
Speaker 5: that really reduced the complexity of it entirely was the
Speaker 5: pop over API, which is not a vailable it's not
Speaker 5: a React thing, it's a platform thing.
Speaker 2: Right.
Speaker 5: It reminds me very much of I mean, you guys,
Speaker 5: I'm sure you all remember the the left pad incident.
Speaker 3: Comes up with eight lines or something like that. Yeah,
Speaker 3: the Internet.
Speaker 1: But can you give people context because I'm sure we
Speaker 1: have listeners.
Speaker 5: Yeah sure, so I okay, So I love jobscript I
Speaker 5: love the jobs community. I have been doing it for
Speaker 5: fifteen years. I have I've learned of the languages, but
Speaker 5: I have only ever been professionally paid to write JavaScript.
Speaker 5: And but one thing that the jobscrip community does, I
Speaker 5: think poorly or has done poorly is an over reliance
Speaker 5: on abstractions, overliance on libraries, overliance on on frameworks.
Speaker 1: What is not just a JavaScript problem. I'm just gonna
Speaker 1: point that out. No, everybody does this.
Speaker 5: Well there, Yeah, I think the some do it better
Speaker 5: than others, but fair but yeah, So what it happened
Speaker 5: is in this over aliance on on foremeworks, you know,
Speaker 5: the hyper hyperrization of don't repeat yourself. We have created
Speaker 5: libraries so we never have to write the same thing
Speaker 5: over and over. Of course, so I'm tangenting a little bit.
Speaker 5: The libraries end up all the overhead of importing it
Speaker 5: and do this all their stuff, end up writing more
Speaker 5: code sometimes then it would be just to write the thing.
Speaker 5: In this case, that's exactly so. This library literally pads
Speaker 5: the left side of a string, so the beginning of
Speaker 5: a string with some characters that you give it right.
Speaker 5: Turns out that there has been for a very long
Speaker 5: time a native way to do this in JavaScript, but
Speaker 5: we designed a lot of people decide yeah, shocker, a
Speaker 5: lot of people decided, no, no, we're gonna use library because
Speaker 5: because this is going to be better tested. I don't
Speaker 5: really understand the logical.
Speaker 4: Well, I think that pads start came after left pad
Speaker 4: it may. I think that pad start was one of
Speaker 4: the when they were calling it ECMAScript six where they
Speaker 4: were just before they went hogwild crazy, and they were
Speaker 4: just introducing things that the language actually needed. That was
Speaker 4: around the time that pad start was introduced, and then
Speaker 4: of course that didn't get implemented by browsers until what
Speaker 4: you know, six years later or whatever, because they prioritized
Speaker 4: dumb stuff that we don't need over stuff that we
Speaker 4: actually do need.
Speaker 5: In any case of the time, at the time this happened,
Speaker 5: pad start was has art had already been a jobscript
Speaker 5: for some time. So yeah, if if and this gets
Speaker 5: the problem of like transit dependencies and deep dependencies and stuff.
Speaker 5: A lot of people didn't even know that they had
Speaker 5: a dependency on this library. So what happens is this
Speaker 5: the owner of this library, uh, for reasons I don't recall,
Speaker 5: and history we'll probably forget, got upset and pulled his
Speaker 5: his library and at the time INPM allowed you to
Speaker 5: do this. He just belieted it, and all of a sudden,
Speaker 5: everybody's builds in the entire.
Speaker 2: Yeah, the internet world.
Speaker 5: Well everyone said the Internet broke. The Internet never broke
Speaker 5: the builds. Everybody's build it would Yeah, well the pre
Speaker 5: release part of the web break. So nobody's site went down,
Speaker 5: but nobody could deliver anything anymore either. For a little while.
Speaker 5: They could figure this out, and it was it was
Speaker 5: a huge joke in the whole software community. Oh job ascript.
Speaker 5: You know, they don't know what they're doing over there,
Speaker 5: which is probably something great true, But so anyway, so
Speaker 5: that's how it all went down.
Speaker 2: Yep, as I recall.
Speaker 1: Right, So the point you're making then is if people
Speaker 1: had been relying on the underlying core API of start
Speaker 1: pad instead of using the left pad library read, then
Speaker 1: their stuff would have just kept on work.
Speaker 5: It goes, it goes deeper than that, even because to
Speaker 5: to AJ's point, if you it the if you look
Speaker 5: at the the if you ever looked at the code
Speaker 5: for left pad, it was very, very few lines of codes. Yeah,
Speaker 5: very simple, very straightforward. Anyone could have wrote this, but
Speaker 5: we used the library instead. Instead of everyone writing writing
Speaker 5: it themselves, writing their own utility library, we used a
Speaker 5: third party library, which created a dependency on someone else, who,
Speaker 5: at their own whims could do whatever they wanted our
Speaker 5: our insistence on like outsourcing our code. This way that
Speaker 5: the simple code kind of created this problem. Everyone could
Speaker 5: have written their own left pad and then updated as
Speaker 5: they felt ready to to pat start when it came
Speaker 5: into JavaScript. But instead it got very deeply, deeply deeply
Speaker 5: into these dependencies that nobody even knew was there. We
Speaker 5: don't keep up, we don't update our stuff. They didn't,
Speaker 5: you know, left pad didn't update there to use the
Speaker 5: native or anything like that. And so we got into
Speaker 5: the system where there's these blind corners of things that
Speaker 5: were relying on. We have no idea what we're relying
Speaker 5: on them, because we've outsourced even the simplest of stuff.
Speaker 1: I can I clarify something here, because what you're pointing
Speaker 1: out is not just the people who like in their
Speaker 1: project said I need left pad right. It was a
Speaker 1: dependency of a whole bunch of the other library. So
Speaker 1: even if they were making the kind of decision that
Speaker 1: you're talking about where they're saying, you know what, something
Speaker 1: like left pad, it's simple. It's simple for me to
Speaker 1: write my own little library that does it, or you know,
Speaker 1: if I'm late enough, i can use the native JavaScript
Speaker 1: API that does it.
Speaker 2: But I had other things that.
Speaker 1: Were solving more complex problems for me that also relied
Speaker 1: on left pad. So even if I was making some
Speaker 1: of these better decisions, I still fell prey to this
Speaker 1: because my my other underlying stuff wouldn't build.
Speaker 5: That's right, because because of a more of a community problem.
Speaker 5: I guess, uh, we we as a community have kind
Speaker 5: of fall into this and so yeah, uh, which which
Speaker 5: is why I do think that like dependencies come with
Speaker 5: a certain amount of cost, it's often very hidden that
Speaker 5: we don't we don't acknowledge, we don't recognize. I'm not
Speaker 5: saying we shouldn't have dependencies, we shouldn't rely on frameworks
Speaker 5: or libraries. We definitely should. There are great things that
Speaker 5: come with them, But but to do so too often
Speaker 5: or without acknowledging that there is that there's a cost
Speaker 5: associated with that I think has bitten us as a
Speaker 5: community and individually several times, and we still haven't learned
Speaker 5: the lesson that maybe we should be a little bit
Speaker 5: more intentional about the the dependencies that we bring on board.
Speaker 1: Right, So let let me summarize a little bit because
Speaker 1: I have some thoughts here too, but I want to
Speaker 1: make sure that we've kind of covered what you've already covered.
Speaker 1: So you've basically pointed out that you can use the
Speaker 1: dom APIs to simplify the path that your code takes
Speaker 1: and get more reliable results.
Speaker 2: You've pointed out that.
Speaker 1: Depending on somebody else's code can wind up causing you
Speaker 1: issues if they change things in a way that you
Speaker 1: don't expect, including having the library go away. One thing
Speaker 1: that I've picked up on some of this, right, So
Speaker 1: I've I've learned not not I guess at the level
Speaker 1: where I was getting paid to do it, you know,
Speaker 1: I've learned angular, I've learned view, I've learned react, mostly
Speaker 1: because I was doing the podcast and I wanted to
Speaker 1: sound like I knew what I was talking about, because
Speaker 1: I at least kind of knew what I was talking about,
Speaker 1: and in those cases that I as I was picking
Speaker 1: things up, and also with with my history with like
Speaker 1: Ruby on rails or some of the other you know
Speaker 1: systems or frameworks that I've used a lot of time.
Speaker 1: When you're learning them, they give you a way of
Speaker 1: doing things, and so you kind of do things the
Speaker 1: React way for a lack of a better way of
Speaker 1: doing it, right, And as you build those apps, it's
Speaker 1: often appropriate for you just to use those and not
Speaker 1: think too deeply about, Hey, is there a simpler way
Speaker 1: to do this or is there a better way to
Speaker 1: do this? And so there's a lot of value in
Speaker 1: kind of doing the accepted happy pathway that the framework
Speaker 1: gives you, right. And I think this is where Dan
Speaker 1: is saying, you know, for a lot of developers, if
Speaker 1: they never learn deeply learn a lot of these dominpis,
Speaker 1: they're gonna be fine. They're gonna be able to write
Speaker 1: code that works. It's you're gonna be able to deliver
Speaker 1: working features.
Speaker 2: Is this just I mean, is that wrong?
Speaker 1: Or is there a certain point you get to where
Speaker 1: all of a sudden it's becomes really really valuable to
Speaker 1: know these APIs Or is there some other X factor
Speaker 1: that you know about that I'm not thinking of that
Speaker 1: makes the difference right that It's like it's like Okay,
Speaker 1: you're totally good using the react way until you have
Speaker 1: to do this or until this changes, or until your
Speaker 1: code is a certain size or whatever.
Speaker 3: I think.
Speaker 5: I think people in situation. Life is complicated, so there's
Speaker 5: no there's no one answer here. But obviously you can
Speaker 5: you can be productive in straight react or straight view
Speaker 5: or straight angular, whatever it is. You can get some
Speaker 5: stuff done, particularly if you're kind of a junior engineer.
Speaker 2: But good get paid, right.
Speaker 5: Right, exactly right. There's a there's an element of practicality there, immediacy,
Speaker 5: immediate practicality. But I'm reminded of my actually of my
Speaker 5: calculus classes in college. CALC one we spent an entire
Speaker 5: semester going over how how to do by hand like
Speaker 5: derivatives and summations and all this stuff. And it was yeah, yeah, yeah,
Speaker 5: it was so hard.
Speaker 2: I'll get my mom on the show. She teaches this
Speaker 2: at the high school.
Speaker 3: This is giving me nightmares.
Speaker 5: But then I had I had the same teacher for
Speaker 5: first in CALC one, Cup two, and the second semester
Speaker 5: we went into CALC two. On day one, he said, okay,
Speaker 5: so last semester we learned all this stuff. Now I'm
Speaker 5: going to show you how to do that real fast,
Speaker 5: and in five minutes he taught the entirety of CALC
Speaker 5: one with some simple like do this, you know, move
Speaker 5: this down here and do this multip and that's it,
Speaker 5: and everyone grown. And he just got a kick out
Speaker 5: doing that every year. You could tell because he taught
Speaker 5: the entirety of CALC one in five minutes in CALC two.
Speaker 5: But then he pointed out, like why did I why
Speaker 5: did we go through all this stuff? It's important to
Speaker 5: understand why and how we got to this point because
Speaker 5: I can just show it to you do this and
Speaker 5: it works, but you don't know why it works. But
Speaker 5: now you do. You had calkawan, you know why it works.
Speaker 5: You have you can now have inferences and understandings that
Speaker 5: you wouldn't have had otherwise. And this is exactly the
Speaker 5: same thing when you when you jump into a framework
Speaker 5: and you learn the frameworkisms, the reactisms or the anbulisms,
Speaker 5: whatever it is, you can be productive. You know, the
Speaker 5: incantations to make to produce something, but that's what they are.
Speaker 5: They're incantations. If you know the platform, if you begin
Speaker 5: to understand how is this thing built, what is it
Speaker 5: doing under the hood, it ceases to become incantations and
Speaker 5: it starts to become recipes and you say, oh, okay, cool,
Speaker 5: that's a cool bread recipe. I'm going to do this
Speaker 5: thing and create like an orange loaf or a sour
Speaker 5: dough or whatever it is. Whereas if you're just heads
Speaker 5: down this, you don't exactly know how bread is produced
Speaker 5: or how your application is, how it functions under the hood.
Speaker 5: It's it's you're less useful than you could be.
Speaker 3: Well you know, yeah, I mean this is like music
Speaker 3: to my ears, and I could probably talk for a
Speaker 3: half hour with examples of how all this is true,
Speaker 3: going from my days and literally in banking and tech
Speaker 3: support and anything. The more you know the platform you know,
Speaker 3: the more function the more the better you can do
Speaker 3: just because you know how things go underneath and you're
Speaker 3: not relying on layers and layers on top of things.
Speaker 3: But I think you know and not even when it's
Speaker 3: when you're building stuff. The bigger issue that you're going
Speaker 3: to come across those when you're trying to troubleshoot. So
Speaker 3: if something breaks and you have no clue how it's
Speaker 3: functioning underneath, then how are you going to fix the problem. Yep,
Speaker 3: you know where are you going to look at? What
Speaker 3: are you going to look at? I can, you know,
Speaker 3: vouch for any time I've been whether it's tech support,
Speaker 3: whether it's you know, being as a developer, and I've
Speaker 3: written stuff and I've had to go back and fix it,
Speaker 3: you know, right, I'm today, I'm you know, better in
Speaker 3: this day, and I'm going to be fixing some bugs
Speaker 3: in a in a out aplication that I have. But
Speaker 3: I know where to go. I know pretty sure I
Speaker 3: know where to fix it because I know how it
Speaker 3: functions underneath the hood. And you know the example I've
Speaker 3: given before, not to belabor this one is language. You know,
Speaker 3: I'm a Spanish speaker, and to me, learning language came easy,
Speaker 3: but the way I learned it was learning verbs. Learning
Speaker 3: now is learning how verbs are conjugated, learning the rules
Speaker 3: of the language. Instead of the people that amaze me,
Speaker 3: you know that can learn conversational They can come in
Speaker 3: and just take some you know, quote unquote conversational classes
Speaker 3: where they learn phrases and start of piece them together,
Speaker 3: but they really don't know the underlying rules and concepts
Speaker 3: of how those sentences are put together. So that's always
Speaker 3: been my tendency, but I mean just to validate what
Speaker 3: you're saying. Yeah, anytime you know the underlying details and
Speaker 3: concepts of how something is put together, you're going to
Speaker 3: be much better not only at developing, but also figuring
Speaker 3: out bugs because bugs are going to happen if you're
Speaker 3: not writing. If you're writing, bug free, cod would let
Speaker 3: me know. And I want to know how you do it,
Speaker 3: because it doesn't happen very often.
Speaker 1: So I want to jump in here because I feel
Speaker 1: like there's still a little bit of nuance or play
Speaker 1: within this argument, right, And I'm going to use fixing
Speaker 1: cars as an example, right, just because it's kind of
Speaker 1: a concrete thing that people understand.
Speaker 2: Right.
Speaker 1: And so when I married my wife, I knew how
Speaker 1: to change the oil on my car.
Speaker 2: That was about it, right.
Speaker 1: And her dad knows how to change I mean, pick
Speaker 1: a thing on the car, right, he can make it fixed.
Speaker 1: And you know, and so the first time our car
Speaker 1: broke down, he came up and we pulled it out
Speaker 1: and put it back in.
Speaker 2: You know, we fixed it, We replaced the part.
Speaker 1: And you know, I was proficient at making bolts go
Speaker 1: in and out right, and so you know I could
Speaker 1: I could open the clamps or whatever you know on
Speaker 1: hoses or you know. So I could do all of
Speaker 1: those things, and so for a lot of the simple things,
Speaker 1: I really, I really was okay fixing my own car,
Speaker 1: but the issue came in when I had to diagnose
Speaker 1: the actual problem. And in fact, I'm still kind of
Speaker 1: at the point where about half the time, if I
Speaker 1: run into a problem with my car, I call him
Speaker 1: up and say, this is what's what it's doing. It's
Speaker 1: He goes, oh, that sounds like the whatever, right, And
Speaker 1: so then I can go figure out how to change
Speaker 1: it out. But a lot of it just comes from
Speaker 1: a deep understanding of how the car operates, how the
Speaker 1: engine works. But a lot of it also comes from experience, right.
Speaker 1: And so I'm hearing Steve talk about, you know, if
Speaker 1: I'm in this code base and I need a troubleshoot it,
Speaker 1: I can figure it out because you know, I know
Speaker 1: how everything kind of goes together. And I'm just I guess,
Speaker 1: I guess the feeling is is, you know, and I
Speaker 1: see this. I mostly work in rails, and so I
Speaker 1: see a lot of people do the same kinds of things, right,
Speaker 1: and they you generally mostly use the rails APIs until
Speaker 1: you get you get to the point where they don't
Speaker 1: do a thing well, and then you kind of reach
Speaker 1: into the tool bag of Okay, now I'm into the
Speaker 1: underlying stuff, but I mean, you can go a long
Speaker 1: ways with just what the framework gives you. And so
Speaker 1: I guess, I guess what I'm saying is is that
Speaker 1: And it sounds like you, Corey and Steve and aj
Speaker 1: We're all kind of of the mindset where it's like, look,
Speaker 1: I want to master this domain right. I want to
Speaker 1: be able if there's a thing to be done, I
Speaker 1: want to be able to do it right. If I
Speaker 1: run into a problem to be solved with JavaScript, even
Speaker 1: if I'm working and React or view or Vanilla or
Speaker 1: you know. We did an episode where I talked about
Speaker 1: the framework I use, which is Stimulus and hot wire.
Speaker 2: You know, I want I want to be able to deliver.
Speaker 1: Whatever it is need it right and Stimulus and hot
Speaker 1: wire so lightweight that you have to use don APIs
Speaker 1: you don't really have a whole lot of choice. But
Speaker 1: the point is is that I think there are a
Speaker 1: lot of people that get by just on react right,
Speaker 1: and then they're the handful of don APIs that react
Speaker 1: kind of pushes you, Hey, we're not going to invent
Speaker 1: a better way to do this because this is kind of.
Speaker 2: The way to do it. And so.
Speaker 1: Anyway, the point I'm getting to is, I think there
Speaker 1: are a couple of reasons why you may or may
Speaker 1: not really deeply care about deeply learning some of these APIs.
Speaker 2: And one of them is is.
Speaker 1: A lot of people really are just comfortable showing up
Speaker 1: and just doing, you know, doing what it says on
Speaker 1: the REACT ten. And you know, they know, maybe they
Speaker 1: know react super duper deeply, and so they never really
Speaker 1: reach into that because they can either find somebody else
Speaker 1: to solve the problem for them that way, or they're
Speaker 1: not really driven to understand how all this stuff works
Speaker 1: under the hood.
Speaker 2: And on the other hand, you know, maybe you just
Speaker 2: get people.
Speaker 1: And I worked with people this way too, where I mean,
Speaker 1: whatever the bare minimum was to just get the job
Speaker 1: done was what they learned.
Speaker 2: Yeah, And so.
Speaker 1: I guess what I'm gonna ask next is is that, Okay,
Speaker 1: I mean, are you handicapping yourself Like I'm not talking
Speaker 1: like morally right, but are you really deeply handicapping yourself here?
Speaker 2: Right?
Speaker 1: Is this going to hurt you in the long run,
Speaker 1: or can you just get by doing that for the
Speaker 1: rest of your career.
Speaker 5: Yeah, actually that's something I have thought a little bit about.
Speaker 5: So they're all I think software development is a little
Speaker 5: bit unique in the world of like work. Most people
Speaker 5: that I run into genuinely love what they're doing. Right,
Speaker 5: This is not normal. I think for most of the world,
Speaker 5: a job is a job for them. They go there,
Speaker 5: they are mildly depressed while they're doing their thing, they
Speaker 5: get it done, and they just are so glad to
Speaker 5: clock out and go home. I mean, either that's not me,
Speaker 5: but but some people, most people like to live that way.
Speaker 5: They find they derive their life. They're satisfaction and joy
Speaker 5: outside of work. And I do too, to something said,
Speaker 5: but I do derive joy at work as well, and
Speaker 5: meaning and satisfaction. But there are still many people in
Speaker 5: software development, especially the ones that were kind of sold hey,
Speaker 5: go go write software, you make a whole bunch of money.
Speaker 5: And they want to go make a whole bunch of money,
Speaker 5: and now writing software, they don't really love that. They
Speaker 5: could have done other things make a whole bunch of money.
Speaker 5: But uh, it's just it's just a job for them,
Speaker 5: and I think for those people that's fine, it's fine.
Speaker 5: Just go do your job, clock out, go home, and
Speaker 5: don't worry, worry about it, like no problem. But understand
Speaker 5: that that that just means you're going to be perpetually
Speaker 5: a mid level engineer. That's just you will. Whether you
Speaker 5: get paid more than that, I don't know, but you
Speaker 5: you'll never really be better than mid level. And that
Speaker 5: is actually fine, because.
Speaker 2: Okay, hang on, hang on, hang on.
Speaker 1: So I just want to clarify, you're saying that you
Speaker 1: really can't be a high level I don't know what
Speaker 1: the term is senior architect level engineer without understanding the
Speaker 1: underlying don API s.
Speaker 5: Yeah, I don't think you can because because I don't
Speaker 5: think you can. You mentioned before someone who really knows React,
Speaker 5: can they and just lives in that. I don't think
Speaker 5: you can really know React without knowing how React, without
Speaker 5: knowing the platform and how React works with the platform.
Speaker 4: Yeah, there's there's no there's no such thing as a
Speaker 4: React expert that doesn't know about pad start. You can't, like,
Speaker 4: you can't be an expert and React and not know
Speaker 4: basic core APIs of JavaScript or basic core APIs of
Speaker 4: the dumb. I I. I mean, I guess maybe maybe
Speaker 4: you could be an expert in React and not know
Speaker 4: insert adjacent HTML. But I actually find it hard to
Speaker 4: believe that either because to be an expert in React,
Speaker 4: you must have come against cases where React doesn't solve
Speaker 4: the problem well or performantly, and then you would have
Speaker 4: had to have learned insert adjason html.
Speaker 1: I agree with you, but I think this is a
Speaker 1: case that people make, and I think a lot of
Speaker 1: people think they're getting by on it.
Speaker 4: So well, I want to challenge the very premise, which
Speaker 4: is that that somehow you're you know, your laziness, or
Speaker 4: you're you know, you're just getting by, you know, not
Speaker 4: doing deep dives. I don't. There's so many things that
Speaker 4: I I it's so so to your to your talk Corey,
Speaker 4: when you were talking about the difference between something that's
Speaker 4: intuitive and unintuitive. I actually disagree with you on a
Speaker 4: lot of points that talk, but because I watched it
Speaker 4: once I got posted. But I agree with you probably
Speaker 4: more than I disagree with you. And there's a certain
Speaker 4: amount to like, okay, which is more intuitive left pad
Speaker 4: or pad start. Now, in that particular case, I'm going
Speaker 4: to argue that left pad is more intuitive because pad
Speaker 4: start is directional based on locale. So if you're doing Japanese,
Speaker 4: then it's going to pad the top. If you're doing
Speaker 4: a reverse language and RTL language, then it's gonna pad
Speaker 4: the right. But in general, yeah, pad start and pad
Speaker 4: pad left and pad start are and and for someone
Speaker 4: that is in one of those languages that's top to
Speaker 4: bottom or or right to left, then than pad start
Speaker 4: would probably be more intuitive. But in general, in general,
Speaker 4: at the face of it, without going into the nuance,
Speaker 4: is pad start or left pad more intuitive? Neither one
Speaker 4: is more intuitive. They're they're they're equally intuitive in terms
Speaker 4: of I want to in my language add some padding.
Speaker 4: That's gonna be what I think the start is. And
Speaker 4: you're gonna pick left pad or right pad based on,
Speaker 4: you know, what your languages are, pad start or pad
Speaker 4: in based on whether you want to be at the
Speaker 4: beginning or there or whatever. But but there's not like,
Speaker 4: it's not that's one's more intuitive. It's not that one's
Speaker 4: more difficult to learn, Uh, you know, it's it's that
Speaker 4: which one did you encounter first? And I think a
Speaker 4: lot of this stuff it's not a matter of well,
Speaker 4: isn't the framework just fine because it's not even an
Speaker 4: issue of the framework because if you're using the framework,
Speaker 4: well you should still be using pad start. Like there's
Speaker 4: nothing about React that has anything to do with pad start.
Speaker 4: There is a reason that if you're using React, you'd
Speaker 4: never encounter insert adjacent HTML, But there's not a reason
Speaker 4: in React that you would never encounter pad start. Right,
Speaker 4: So next question, and so a lot of this stuff
Speaker 4: is just it's not a matter of well, do you
Speaker 4: have to be more of an expert? Not expert is
Speaker 4: going to go back to first principles and learn or
Speaker 4: maybe not first principles, but like an expert is going
Speaker 4: to get down to, okay, what is the thing when
Speaker 4: all the fluff is removed? I think that's that's a
Speaker 4: quality of an expert. But even if you're not an expert,
Speaker 4: it's not like, oh man, huh, I can't believe I
Speaker 4: had to go on MDN. Can you believe it? Like
Speaker 4: instead of hitting up GPT or stack overflow, I typed
Speaker 4: MDN in my search career. Oh oh man, I got it,
Speaker 4: and I need some advil, you know, Like that's that's
Speaker 4: not what's happening. It's just a matter of what your
Speaker 4: muscle memory is, are you hitting Chad GPT first? Are
Speaker 4: you hitting MDN first? Now, granted a lot of the
Speaker 4: articles on MDN could stand to be improved because they
Speaker 4: kind of went back backwards a few years ago and
Speaker 4: now they've gone forwards again. So I think MDN is
Speaker 4: is back on par with W three schools because they
Speaker 4: were better and then they got worse and now they're
Speaker 4: okay again.
Speaker 2: But you know, so what do you think, Corey Steve.
Speaker 5: I'm trying to suss out the the the question there. So, yeah,
Speaker 5: I agree with it. Sounds like you're making the argument
Speaker 5: that kind of like what I made before, that React
Speaker 5: or these other like UI frameworks are designed to do
Speaker 5: a certain thing. It's like, if you remember when React
Speaker 5: first came out there, they were marketing themselves as the
Speaker 5: the V and NBC. Right, they don't do that anymore,
Speaker 5: but at the time they were, that's what they were.
Speaker 5: They were kind of marketing themselves as and by implication
Speaker 5: that means they don't do the M and the C.
Speaker 5: That's your job to under fan. We just do the V.
Speaker 3: NBC being mod view controller.
Speaker 1: Yeah, so they did the interface, they didn't do the
Speaker 1: data and they didn't interface the data to the view
Speaker 1: that was.
Speaker 3: The top layer. They save view library. I think that's
Speaker 3: why I've always heard it described.
Speaker 5: Yeah, I don't. I don't think that's an accurate description.
Speaker 5: It probably wasn't an accurate description at the time either,
Speaker 5: but certainly not now. But regardless, they were making a
Speaker 5: concession that we don't do everything, but we do do
Speaker 5: this thing. And all frameworks are kind of that way.
Speaker 5: And if you live in as long as the problem
Speaker 5: to be solved is something that the framework aims to solve,
Speaker 5: you can live in that framework and you don't have
Speaker 5: to to dive down. But to create an application, you
Speaker 5: will have to do more than what the framework solves. Charles,
Speaker 5: you mentioned you do a hot wire stimulus and it's
Speaker 5: very lightweight, and therefore you have to learn DOMINPA. It
Speaker 5: doesn't it's not aiming to solve all the problems, react
Speaker 5: all the problems.
Speaker 1: It claims essentially to be the c in MVC, and
Speaker 1: it leaves the V up to you writing HTML and
Speaker 1: the m up to your APIs and you can do
Speaker 1: those however you want.
Speaker 5: Yeah, so, so in that sense, I think you know
Speaker 5: you're right. You cannot become an expert at your job,
Speaker 5: even if your job is to write React, unless you
Speaker 5: understand more than just React, more than just the framework
Speaker 5: that you're operating in, because your job. I don't know
Speaker 5: of a job whose whose definition would keep them only
Speaker 5: within the bounds of a framework. That just unless maybe
Speaker 5: you're working in a very batteries included framework like Rails
Speaker 5: or something.
Speaker 1: Right, Well, even in the battery you said Rails, but
Speaker 1: even in the batteries included frameworks like Rails, you still
Speaker 1: frequently have to deviate from what the framework gives you,
Speaker 1: either directly or because it just doesn't have a piece
Speaker 1: of the framework that does the thing you need.
Speaker 4: Well, addition is not part of Rails, right, string concatenation
Speaker 4: Actually I think st I think I think Rails did
Speaker 4: hijack stream cocttination.
Speaker 2: A whole bunch with active support.
Speaker 4: But yeah, but in general, in a sane language, you
Speaker 4: know the language, the framework isn't taking over edition concatenation.
Speaker 4: You know it's basic string and number support.
Speaker 1: Well, active support was written for Rails, but it's mostly orthogonal.
Speaker 1: I mean, it's required by Rails, but you can use
Speaker 1: it in other projects without having Rails and give all
Speaker 1: the niceties it gives.
Speaker 4: You, and now the rails or Ruby has UTFA by
Speaker 4: default active support doesn't hijack those things, right.
Speaker 2: Not as much it it has it. It touches everything we.
Speaker 1: We could we could talk about whether that's a good
Speaker 1: idea or not, but that that's not the show. I
Speaker 1: was us, Steve, if you had anything to add before
Speaker 1: I kind of push this to the next question I
Speaker 1: have on this then.
Speaker 3: Not really, I mean I'm still a bit confused about
Speaker 3: the what the question that AJ said anyway, which is
Speaker 3: par for the course.
Speaker 4: But I didn't ask a question, no idea.
Speaker 1: That a common question, and it was it was effectively,
Speaker 1: can you know can you be a high level senior
Speaker 1: developer without knowing this stuff?
Speaker 3: You don't think I don't think it's knowing it. I
Speaker 3: mean I pretty much said that up front. I mean, yeah,
Speaker 3: I think the general percentage that I can remember seeing,
Speaker 3: like for instance, going back to the jupil world was
Speaker 3: eighty twenty where the framework, the CMS whatever, out of
Speaker 3: the box is going to do eighty percent of what
Speaker 3: you need and the last twenty percent is what you need.
Speaker 3: You know, you're going to need to do yourself with
Speaker 3: a little customization with some writing code. In this case,
Speaker 3: I think it could be you could translate that to say,
Speaker 3: React view Angular rails is going to do eighty percent
Speaker 3: of what you need by itself, and in a lot
Speaker 3: of cases maybe it's one hundred percent, depending on the
Speaker 3: simplicity or the complexity of what you're doing. But that
Speaker 3: last twenty percent, you're going to need to know how
Speaker 3: things work under the hood in order to be able
Speaker 3: to get to what you really need to do.
Speaker 5: Yeah, just as a quick example of that, if you're
Speaker 5: writing in React and you're you're writing out HTML or GSX,
Speaker 5: one thing that doesn't cover at all is aria, Like
Speaker 5: you need to understand aria. You just that that's absolutely necessary.
Speaker 5: That's not React.
Speaker 2: Nope.
Speaker 3: Yeah, that's a whole can of worms where you get
Speaker 3: in to uh, what's the term you can believe disibility?
Speaker 3: Thank you? Accessibility?
Speaker 2: Right?
Speaker 4: Yeah?
Speaker 2: And why yeah?
Speaker 5: Yeah. And also just to be clear, like, depending on
Speaker 5: what your goals are in life, there's nothing necessarily wrong
Speaker 5: with never becoming a senior like engineer like go do
Speaker 5: your thing, man, do what makes you happy. And if
Speaker 5: if being a mid level engineer for you know, for
Speaker 5: your career get you the money you need to do
Speaker 5: it makes you happy by all means, go, you know,
Speaker 5: do that. That's fine. But if if you're going to
Speaker 5: your manager and like I think I should be a
Speaker 5: senior engineer, I want to get paid like a senior engineer,
Speaker 5: well you're gonna have to learn some stuff outside of
Speaker 5: that framework.
Speaker 2: Yeah.
Speaker 1: The example I've used with a bunch of people is
Speaker 1: some people want to learn to code because they love
Speaker 1: it and they just want to dive into every piece
Speaker 1: of it. And some people want to learn to code
Speaker 1: so they can make enough to go live on the
Speaker 1: beach and go surf in the afternoon. And there's nothing
Speaker 1: wrong with either one.
Speaker 2: Just know who you are. Yeah.
Speaker 1: Okay, so it sounds like and I think AJ most
Speaker 1: directly touched on this, but let's say that somebody is
Speaker 1: you know, they accept the argument. Okay, I do have
Speaker 1: these ambitions for my career. I do want to be
Speaker 1: able to expertly solve these problems, So I need to
Speaker 1: start learning these dom APIs, and I'm also going to
Speaker 1: deliver the premise and you can argue against it if
Speaker 1: you want that. A lot of times people don't learn
Speaker 1: these APIs because the framework does give you a way
Speaker 1: to do it, and so you just never become aware
Speaker 1: that the API even exists to do the thing. So
Speaker 1: how do people And you can tell me if I'm
Speaker 1: wrong about that as part of your answer, But how
Speaker 1: do people then go? Okay, I'm a React guy, or
Speaker 1: I'm a view guy, or I'm an Angular guy, and
Speaker 1: I want to deliver elegant, well written, well engineered solutions,
Speaker 1: and so I need to learn these do APIs? Which
Speaker 1: ones they learn first? And how do they learn those
Speaker 1: things so that they can start to become this high
Speaker 1: level engineer.
Speaker 5: Oh that's good. That's a good question.
Speaker 1: And is my premise wrong that people aren't learning it
Speaker 1: because of the framework just does it for him.
Speaker 5: I don't think it's that the framework does it for him.
Speaker 5: I honestly, I think it's I'm most familiar with React,
Speaker 5: and so I'll speak for React here.
Speaker 3: That's fair.
Speaker 2: I think most people listening probably do React.
Speaker 5: So the ecosystem has solutions for it, so React doesn't.
Speaker 5: For instance, I talked before about using the popover API,
Speaker 5: and one of the reasons we started doing that is
Speaker 5: because we have a library in our application that handles
Speaker 5: pop ups and it is flaky as all get out.
Speaker 5: When it comes to tests, it does not perform well.
Speaker 5: There's all kinds of problems with it, and so that's
Speaker 5: why we're looking for more native solutions. But the reason
Speaker 5: it exists at all is because someone came in. I'm
Speaker 5: a react engineer. I need this thing. Someone created a
Speaker 5: library to do this thing inside of the reacting ecosystem.
Speaker 5: All I need to learn is this simple little API
Speaker 5: for this library, rather than all this complex API for
Speaker 5: the dominant I think this is the conceptually what people
Speaker 5: get wrong. They think that the lower level stuff is complicated,
Speaker 5: this library has a much nicer API. Many times that's true.
Speaker 5: Many times that's not true or not as true as
Speaker 5: people seem to want to think it is, And so
Speaker 5: you end up with this bloated situation where I'm gonna
Speaker 5: I'm gonna get a library that has a nicer API
Speaker 5: rather than learning the platform API. I think that's what
Speaker 5: tends to happen fairly often.
Speaker 1: So, so what what should people be picking up first?
Speaker 1: And how do they make sure they're learning the right
Speaker 1: things that are going to move in the head.
Speaker 5: Yeah, I wish they were a good, like simple answer
Speaker 5: to that. It's kind of reminded when people ask like,
Speaker 5: I'm just starting out as an engineer, what what books
Speaker 5: should I be reading? What sources should be reading? I'm like, oh, man,
Speaker 5: I mean there isn't a book that I used to have.
Speaker 5: I used to point people to, like you know, Jobs
Speaker 5: of the good parts. That's way outdated. I would not
Speaker 5: recommend reading that.
Speaker 2: Now right.
Speaker 4: There.
Speaker 5: There isn't a compendium of you want to get great,
Speaker 5: here are the resources, Unfortunately. I what I tend to
Speaker 5: do now is point people towards resources like email, newsletters
Speaker 5: or podcasts or things like that where people are talking
Speaker 5: about stuff, and I send them to Honestly, ah, you
Speaker 5: mentioned Indiana. I send them to Indian all the time.
Speaker 5: That is the unofficial or maybe it's now the official
Speaker 5: platform documentation go that. I tell them like, look, you
Speaker 5: always need to be looking for stuff. I will sometimes
Speaker 5: go to like Indiana and look at the eighth the
Speaker 5: list of hmail tags, just like what have I forgotten
Speaker 5: about and go through and just read them and say, oh,
Speaker 5: I told I didn't know that existed. I'm going to
Speaker 5: try to incorporate that in there. And this reminds me
Speaker 5: so I thought of this earlier when you were talking
Speaker 5: about something else. But one thing that is incredibly useful
Speaker 5: for understanding how things work or maybe what you should
Speaker 5: be learning. Remember years ago, Paul Irish.
Speaker 2: You guys know we've had them on the show. I think, yeah,
Speaker 2: so Paul, maybe not anyway, in.
Speaker 5: Any case, years year ago he wrote or he made
Speaker 5: a couple of videos on the first one with ten
Speaker 5: things I learned from the Jquerry source code and what
Speaker 5: he did. He just did this little video where he
Speaker 5: opened up the source code for jquerry and just walked
Speaker 5: through it. And I was like, oh, this is cool.
Speaker 5: Let me tell you about what's going on here and
Speaker 5: what I learned about this, and it was it blew
Speaker 5: my mind of like, holy crap, this is amazing. I
Speaker 5: didn't kind of even it didn't occur to me to
Speaker 5: do that. And I started kind of doing that more.
Speaker 5: I'm going to look at the source code, how are
Speaker 5: they doing this? How is this library that I like
Speaker 5: doing this thing that seems magical to me? And I
Speaker 5: figured it out and then take it a step farther
Speaker 5: and you know what I'm going to recreate? I recreated jQuery.
Speaker 5: It was crap. It was not performance, but the act
Speaker 5: of doing it like opened my mind widely to all
Speaker 5: kinds of new techniques and interesting things. And I think
Speaker 5: that is a good exercise. I think, I think doing
Speaker 5: that building into your career. I do this. I also
Speaker 5: tell engineers that I meant to do this every day.
Speaker 5: Spend the first hour of your day on company time learning.
Speaker 5: Go read it, read some articles, go go build some
Speaker 5: throwaway thing, but spend that first hour learning something new
Speaker 5: every day. You The act of seeking out, I think
Speaker 5: is going to expose you to uh, to these kinds
Speaker 5: of things. But I don't have, like I said, a
Speaker 5: compendium of like here are the things you need to
Speaker 5: know necessarily.
Speaker 3: So we did an episode about five years ago with
Speaker 3: a guy named Karl Mungazi JavaScript Jebber number four zero eight,
Speaker 3: all about reading sorce code.
Speaker 2: He was also a host on React around It for
Speaker 2: a while.
Speaker 3: Right, So the whole I remember, and I can still
Speaker 3: remember doing this episode where we talked to him about
Speaker 3: reading source code and how to do it and the
Speaker 3: benefits of it and so on and so anyway, I
Speaker 3: put four zero eight if you want to listen to.
Speaker 5: That, Yes, I think it's more about the practices you
Speaker 5: build for yourself as an engineer, less than the sources
Speaker 5: you turn to. The sources are good, but I think
Speaker 5: the practices helped to help give you those sources, I
Speaker 5: guess is a way I might put it, help you
Speaker 5: discover those sources because I think they change over time
Speaker 5: a lot.
Speaker 4: I think one of the best things that front ends
Speaker 4: people can do to improve their their craft is to
Speaker 4: listen to people that just do programming and more importantly
Speaker 4: engineering and architecture outside of the front end space, because
Speaker 4: I think the front end space is assess pool, and
Speaker 4: the thought leaders in the front end space are oftentimes
Speaker 4: just people that have I don't know, really cool socks
Speaker 4: and like I don't.
Speaker 2: But I would people off.
Speaker 5: I don't know.
Speaker 4: How they become these thought leaders, but so many people
Speaker 4: in the front end space they're not people. Let me
Speaker 4: rephrase it. You'll get a lot more out of listening
Speaker 4: to people like Rob Pike and Jonathan blow Casey Moritory, uh,
Speaker 4: you know, like listen to people that do game dev,
Speaker 4: listen to people that do server side dev, listen to
Speaker 4: people that do GO or rust or zig or you know,
Speaker 4: because most most of you know. Anybody that asked me
Speaker 4: how do I learn to program? What I'm gonna say
Speaker 4: is here's a bunch of great resources for Go. Because
Speaker 4: goes a language you can learn in a weekend. You
Speaker 4: don't have to have previous programming experience to get into
Speaker 4: Go quickly. You can write actual real programs and go
Speaker 4: that uh, you know, you can write terminal games like
Speaker 4: tip tac toe type of stuff or whatever.
Speaker 2: You know.
Speaker 4: It's a it's a really great language. And once you
Speaker 4: learn Go in particular, then you go back to something
Speaker 4: like JavaScript and you're like, whoa, whoa, whoa, whoa. I
Speaker 4: don't need this ninety five percent of the language. This
Speaker 4: five percent does everything I need, and it's faster and
Speaker 4: smaller and easier to learn.
Speaker 5: They used to say the same thing about JavaScript that
Speaker 5: you just said about Go. It's interesting. I a thing
Speaker 5: I've often said about JavaScript is JavaScript has within it
Speaker 5: this very beautiful and elegant language. If you if you
Speaker 5: stay within the bounce, it's a wonderful language.
Speaker 4: And there's a whole lot of.
Speaker 5: I'll take some issue with with I guess the way
Speaker 5: that you you positioned the in the front end space.
Speaker 5: I do think there is a lot of value that
Speaker 5: comes from many of them, I think, But what I agree,
Speaker 5: but I will agree, Yeah, There's a couple of points
Speaker 5: I would add on top of it, and that is
Speaker 5: that it took me. I had an experienced earlier in
Speaker 5: my career where I realized that even the most experienced
Speaker 5: and knowledgeable people in the industry are just people. Like
Speaker 5: they're just and they're almost kind of They're making it
Speaker 5: up as they go in many the same ways that
Speaker 5: we are. They just have been doing it longer, and
Speaker 5: we tend to idolize the wrong word defer to them
Speaker 5: maybe too much at the expense of our own rational thinking.
Speaker 5: And I think we could do more rational thinking rational
Speaker 5: thought there. But with that said, I will very much
Speaker 5: concur with you AJ on expanding your horizons beyond the
Speaker 5: domain space I mentioned before the seminal paper Out of
Speaker 5: the tar Pit, and I also mentioned before that there
Speaker 5: isn't a compendium of resources. However, I have been thinking
Speaker 5: for a long time about put together a list of
Speaker 5: these like must reads going back to the beginning of
Speaker 5: computer programming, that are, like Quintin like thinks you really
Speaker 5: really should read because it's going to shape in a
Speaker 5: positive way the way you think about programming in a
Speaker 5: broad sense. So you know, you know, out of the
Speaker 5: tar Pit you have the the Orsons, cut Cards, the Beekeeper,
Speaker 5: and Algae I always forget the name of it. You
Speaker 5: have many white papers from the seventies and from the
Speaker 5: sixties that are like mind blowing that they have they solved,
Speaker 5: they solved problems that we have today and we've completely
Speaker 5: forgot about it. I would, you know, point people to
Speaker 5: to Brett Victor and a number of his his presentations
Speaker 5: that illustrate some of that. There are some really kind
Speaker 5: of everyone should really be reading this regardless of what
Speaker 5: you're programming kind of stuff. And maybe one day I'll
Speaker 5: put that together, but I don't have that with me.
Speaker 1: So is the Beekeeper with Orsus Scott card House software
Speaker 1: companies die.
Speaker 5: Yeah, that's the one. That's the one, and it's really short.
Speaker 1: I put both of these in the comments on Facebook
Speaker 1: and YouTube, so yeah, if you're if you're looking for those, well,
Speaker 1: hopefully we get them in the show notes too, but
Speaker 1: they don't always.
Speaker 5: So there's a yeah, I wish, I wish I had
Speaker 5: a longer list of uh a hand, but those are
Speaker 5: those are It is really amazing to go back to
Speaker 5: the fifties and the sixties and the seventies and read
Speaker 5: some of the papers that people wrote about software programming
Speaker 5: back then, and the elegance with which they solve the
Speaker 5: problems that the current problems that we have today, and
Speaker 5: you start to think, why is everything so complicated now?
Speaker 5: It doesn't need to be that way. It's kind of wild.
Speaker 1: Yeah, so I think J had a question, and then
Speaker 1: we're kind of getting toward our time.
Speaker 4: So yeah, so this this was something that you'd actually
Speaker 4: brought up, either in the two or in some of
Speaker 4: the pre pre chat email or something. But request animation frame,
Speaker 4: so that it's totally switching gears to a technical topic
Speaker 4: request animation frame? Do I really need to know about it?
Speaker 4: Is it really that important? How should I employ it
Speaker 4: or not? And as react using it behind the scenes?
Speaker 5: Oh, that really really depends. I'll tell you what I
Speaker 5: know about request animation frame. I don't think I've ever
Speaker 5: actively used request animation frame. No, I may have once
Speaker 5: or twice, But it depends. It very much depends on
Speaker 5: the kind of programming you're doing. Ay, are you doing
Speaker 5: a lot of animation? You probably do need to know
Speaker 5: that there's a lot. There's so much nuance in the
Speaker 5: kinds of things, and you can go so deep into
Speaker 5: one area when become an expert in that area, is
Speaker 5: such that you almost never touch this other stuff that
Speaker 5: maybe most other people do. And this is what a
Speaker 5: lot of.
Speaker 4: So I was thinking. So I've I've been using it
Speaker 4: by default lately, like anytime that I'm going to be
Speaker 4: doing anything with a DOM, I'm doing it inside of
Speaker 4: a request animation frame. I might even do the calculation outside,
Speaker 4: but then I do the actual Okay, replace children, insert
Speaker 4: adjacent HTML, text content equals, like any of that stuff.
Speaker 4: I just shove all of that into a request animation frame.
Speaker 4: And I was under the impression, which might be wrong,
Speaker 4: that that means that when it's inside of a request
Speaker 4: animation frame, that it actually is gonna get cued and
Speaker 4: batched by the browser and done all at once, rather
Speaker 4: than it cutting the browser's redraw. Because essentially, every time
Speaker 4: you do a dot text content or a dot ner HTML,
Speaker 4: well I guess not dot text content, well maybe potentially,
Speaker 4: but you are causing the browser to do a redraw.
Speaker 4: So if you do one online five, and you do
Speaker 4: another one online six and another one line seven, then
Speaker 4: you're telling the browser to redraw three times. And I
Speaker 4: thought that the deal was if you use request animation frame.
Speaker 4: It's saying, Hey, anything that I'm going to do that's
Speaker 4: going to redraw, wait until this complete before you do
Speaker 4: any redraws, and that maybe maybe the browsers are optimizing
Speaker 4: that way when I don't use it.
Speaker 5: Yeah, that's that's not quite right.
Speaker 4: Actually good.
Speaker 5: So if you do it outside yeah, no, if you
Speaker 5: do it outside the request animation frame. So we used
Speaker 5: to talk a lot about screen thrashing, you know, in
Speaker 5: the front of it. Yes, and that happens when you
Speaker 5: alternatively read and write to the DOM. So if you
Speaker 5: if you read and then write, and then read and
Speaker 5: the write and the read, then the DOM has to
Speaker 5: paint so you can read the new update and the
Speaker 5: paint so you can read the new update. However, for
Speaker 5: a very long time, if all you're doing is reading,
Speaker 5: or if you have a batch of reads and a
Speaker 5: batch of rights, it will do those like in batches.
Speaker 5: You'll do the reads, and then if you have sequentially
Speaker 5: so rights, it will do the rights in one draw.
Speaker 5: So it'll it'll do it all in one frame. Essentially,
Speaker 5: what request animation frame does for you is if you
Speaker 5: do it outside the request animation frame, it'll it'll do
Speaker 5: it kind of immediately, but if you do it in
Speaker 5: the request animation frame, it waits until the browser is
Speaker 5: about to do a paint anyway, and then we'll execute
Speaker 5: on that. And that can be really useful. However, if
Speaker 5: the what you're doing within that request animation frame takes
Speaker 5: longer than sixteen milliseconds to accomplish, you end up getting
Speaker 5: screen thrashing again. It pauses the like it becomes jarring
Speaker 5: and janky, and so you have to pay close attention
Speaker 5: to the amount of time it takes to do those things.
Speaker 5: So you have to be doing all the you know,
Speaker 5: the performance testing to make sure you're you're staying inside
Speaker 5: of that's sixteen milliseconds.
Speaker 4: Okay, yeah, all right, yeah, because that's that's something that
Speaker 4: I've just started using because I have heard about its benefits.
Speaker 4: I'm not they don't apply to the stuff I'm doing.
Speaker 4: I'm I'm but I don't know. Here's the thing here,
Speaker 4: this is the reason that my brain went to this. Okay, Angular,
Speaker 4: you could have one hundred items in a drop down
Speaker 4: list and change something. An Angular would take noticeable time
Speaker 4: to redraw those one hundred IDEs. I'm like, that is insane.
Speaker 4: There's no way that's real now I think that the
Speaker 4: people that came up with those demos, I think they
Speaker 4: must have been doing something that was horrendously wrong. But
Speaker 4: I think they were doing something like writing each of
Speaker 4: the hundred items into the drop down list or I
Speaker 4: don't know. I don't exactly know how it happened. I
Speaker 4: just know that Angular used to get ridiculously slow. And
Speaker 4: again I don't think it was Angular's fault per se,
Speaker 4: but people using non angular patterns in Angular or whatever.
Speaker 4: But it was one of the criticisms that drove React
Speaker 4: success was it was easy to do really dumb things
Speaker 4: in Angular, where simple modifications to the page would freeze
Speaker 4: the browser.
Speaker 5: Yeah. Yeah that if you can, you can find the
Speaker 5: the weaknesses and just about any of these frameworks. So yeah,
Speaker 5: I remember doing Angular and the problem was always the
Speaker 5: dirty checking. If you're not managing your state well and
Speaker 5: you're forcing anguler to do the dirty checking all the time,
Speaker 5: then it's going to have super bad performance. And I
Speaker 5: ran to the exactly these problems. At the same time.
Speaker 5: React with a virtual dog means that they can calculate
Speaker 5: off of the paint thread what needs to be painted,
Speaker 5: and then in one fell swoop, you know, paint as
Speaker 5: they do the reconciliation. That's kind of their their thing.
Speaker 5: But you see, now you have things like use effects
Speaker 5: and all these hooks where it becomes very easy to
Speaker 5: use them poorly, and you can get the same kind
Speaker 5: of really bad performance, really jank experience, and taking a
Speaker 5: long time to accomplish what should be pretty simple work
Speaker 5: because you're just using these use effects in really poor ways.
Speaker 5: And I'm sure the same thing can be said of
Speaker 5: a view. I'm much less familiar with that, but I'm
Speaker 5: sure it has its own situations like that. If you
Speaker 5: have these foot guns and all these frameworks need to
Speaker 5: have foot guns somewhere in there, that except well, I
Speaker 5: can imagine a few scenarios in which HTMX would fall apart,
Speaker 5: but is a pretty interesting.
Speaker 2: Yeah.
Speaker 1: Yeah, but again, the surface area on HTMX is considerably
Speaker 1: smaller than say a react or an angular, so.
Speaker 2: That that's one thing to consider. The other thing is
Speaker 2: is that.
Speaker 1: So I I'm not as involved in the angular community
Speaker 1: as I used to be, but they've rewritten like you
Speaker 1: mentioned that, try checking. They've written that like I don't
Speaker 1: even know how many times right, and made major forward
Speaker 1: progress on that, And so I mean That's one nice
Speaker 1: thing about a lot of the frameworks is they see
Speaker 1: the warts a lot of times as quickly as we do.
Speaker 1: It just takes them time to figure out how to
Speaker 1: make it work for people who are.
Speaker 2: Using the framework.
Speaker 1: But then at the end of the day, a lot
Speaker 1: of times you get that update or upgrade for free
Speaker 1: or for you know, a tiny bit of change when
Speaker 1: you update your framework. And so, I mean there are
Speaker 1: some really nice reasons to use a lot of these frameworks.
Speaker 5: And you can see that happening right now with React
Speaker 5: as well with the React compiler. That is going to.
Speaker 2: Yeah a lot.
Speaker 1: Yeah, it's gonna make things a lot nicer for a
Speaker 1: lot of people. We're kind of toward the end of
Speaker 1: our time. I think I'm gonna push just the picks.
Speaker 1: The one follow up I have, and so maybe we'll
Speaker 1: have you back on Corey is.
Speaker 2: I would love to get into.
Speaker 1: Now that we've kind of talked about, you know, APIs,
Speaker 1: do you need to know them? You know, what are
Speaker 1: some of the trade offs? You know, where's that going
Speaker 1: to get you and things like that. I'd actually love
Speaker 1: to have you back on and actually talk about the
Speaker 1: dom APIs you think people should know, right and so
Speaker 1: you can give us a list of you know, a
Speaker 1: dozen or so, AJ can throw in the ones that
Speaker 1: he thinks. I'm assuming that most are the ones that
Speaker 1: most people come up with on that list. You're if
Speaker 1: you give us a list of twelve, probably eight of
Speaker 1: them out of anybody's list are probably gonna be the same.
Speaker 1: So then we can get in and we can say, Okay,
Speaker 1: these ones are the slam dunks. These are the ones
Speaker 1: that I surprised myself by reaching for often that you know,
Speaker 1: most people wouldn't think of, but they just pay off.
Speaker 1: And yeah, then we can give people a direction if
Speaker 1: you're working in a react or a view or an
Speaker 1: angular start here.
Speaker 5: Right, Yeah, that'd be fun.
Speaker 1: All right, let's do it. Well, we'll talk to you
Speaker 1: after the show on how to line that up. But yeah,
Speaker 1: let's move into picks. Steve, do you want to start
Speaker 1: us with picks?
Speaker 3: Oh, we're going to the high point right off the bat.
Speaker 2: Huh all right, that's right. I couldn't wait any longer.
Speaker 3: Right, Uh See, you didn't have any other external picks
Speaker 3: that I can think of right now, so I'll just
Speaker 3: go to the dad jokes of the week. I shall do.
Speaker 3: I'll do four today instead of three. So here is
Speaker 3: proof that the annual Missed Universe pageant is fixed. Every
Speaker 3: winner has come from Earth.
Speaker 2: That's Steve.
Speaker 5: Yeah.
Speaker 3: My wife told me the other day that I should
Speaker 3: sign up for my company's four oh one k I said,
Speaker 3: not a chance. I can't even run a mile. That's
Speaker 3: right up Chuck Sally with his running and half marathon
Speaker 3: stuff he's doing. Man. Anyway, Now, from the moment when
Speaker 3: I first got married, from the moment I saw my
Speaker 3: wife's abacus had to I knew I could count on her.
Speaker 2: No, you can't. Those beads don't move.
Speaker 3: Right, that's true. And then finally, I've been seeing my
Speaker 3: psychiatrist for a while and he finally diagnosed me as
Speaker 3: a kleptomaniac. And I said, is there anything I can
Speaker 3: take for it? Those are the dad jokes of the week.
Speaker 2: All right, AJ, what are your picks?
Speaker 4: First thing I'm gonna pick is grug Brain dot dev,
Speaker 4: which is one of the most recent editions that I've
Speaker 4: added to Creedsaccraftsmanship dot com. It is I believe it's by.
Speaker 4: I don't want to say who it's by. I don't
Speaker 4: want to give any bias, but I think it's pretty
Speaker 4: clear who it's by once you reach the end of it,
Speaker 4: because I think he says so, but it is if
Speaker 4: you've ever seen the grug brain meme, it's you know,
Speaker 4: like like big brain think multiple inheritance, multi layer system,
Speaker 4: very good, but grug brain know, grug brain too stupid
Speaker 4: for big brain inheritance. Grug brain used simple object and
Speaker 4: get work done. It's a little bit hard to read
Speaker 4: because the whole thing is written in that style, which is,
Speaker 4: you know, it's great for a joke, but it's not
Speaker 4: good for an entire article. But the entire articles written
Speaker 4: that way, and I don't think there was a single
Speaker 4: thing I disagreed with in it, because yeah, I'm definitely
Speaker 4: I'm definitely a grug brain dev. So if you think
Speaker 4: that you might be too dumb to understand all the
Speaker 4: stuff that's going on in web dev these days, you
Speaker 4: might find great relief in joining the geniuses of grug
Speaker 4: brain dot dev.
Speaker 3: Well, as he says at the end, under the category
Speaker 3: of imposter syndrome, any young grug read this far probably
Speaker 3: do find in program career, even if frustrations and worry
Speaker 3: is always to be there.
Speaker 2: Sorry.
Speaker 4: Yep, another another pick is you know, we're talking about
Speaker 4: what's what's a good place to find material to learn.
Speaker 4: So I've been compiling creeds of craftsmanship. Uh. Most of
Speaker 4: the stuff that's on there has been on there for
Speaker 4: a while. Every once in a while I add something
Speaker 4: new and the most the most recent two things are
Speaker 4: the grug brain dot dev and then that it was
Speaker 4: actually the original talk that inspired can see Dodd's AHA
Speaker 4: programming that I can't let me go look at it
Speaker 4: real quick to bring what the name was. But anyway,
Speaker 4: I add stuff to this and it's it's non denominational
Speaker 4: other other thing that it's all pretty much grug brain.
Speaker 4: But you know, it's it's not really favoring a particular
Speaker 4: framework or or UH language. It's it's pretty much just
Speaker 4: the keys of success to becoming a great developer. Yeah,
Speaker 4: one of the one of the most recent ones, it's
Speaker 4: really old from twenty fourteen rails comp all the Little
Speaker 4: Things by Sandy met and that was that's actually cited
Speaker 4: in the UH the in one of Kensey Dodd's resources
Speaker 4: on avoid hasty abstractions. But I hadn't I hadn't put
Speaker 4: it on there before. It was really good. There were
Speaker 4: a couple of things towards the end, I disagreed with uh,
Speaker 4: But then again, she's giving such a small example of
Speaker 4: her her toy project where she's implementing she starts to
Speaker 4: implement inheritance in it, which you know, I'm I'm definitely
Speaker 4: in the camp of inheritance is evil. But but maybe
Speaker 4: maybe there's a larger example where where there is an
Speaker 4: exception to an inheritance is evil that she she she
Speaker 4: she makes a case that it's not always evil. I think,
Speaker 4: you know. Anyway, So there's that. And then lastly, I mean,
Speaker 4: we're talking about high performance jQuery alternatives. You've got to
Speaker 4: try aj query. Uh. It's been released on Twitter, the
Speaker 4: latest incarnation. Unfortunately, because it's now AI enhanced, it no
Speaker 4: longer fits in a tweet as texts. So I had
Speaker 4: to take a picture of it because now we've got that,
Speaker 4: we've got types in there. It's fully documented and yeah,
Speaker 4: it really really you know, ran it through chat GPT
Speaker 4: too to make sure it's it's up to snuff. But yeah,
Speaker 4: and and you know, uncompressed, it's kind of big. It's
Speaker 4: like I don't know, uh, two hundred bytes or so,
Speaker 4: but but uh, you know, you you you g zip
Speaker 4: that down and deliver it. It's the best, the best
Speaker 4: thing ever, hot, hottest thing since since sliced bread. So
Speaker 4: you know, get it while it's hot. A j query
Speaker 4: three point zero point three, it's a big one, y'all.
Speaker 2: A I to it. It should be a j P
Speaker 2: t query.
Speaker 4: Yeah, that that one's taken.
Speaker 1: That's already okay, just trying to I'm just trying to help,
Speaker 1: and I don't know, maybe you're not the aj behind it. Anyway,
Speaker 1: I'm gonna are you done? I was gonna just jump
Speaker 1: into my picks, and then I realized I might.
Speaker 2: Have cut you off.
Speaker 4: Now that was it. That was it.
Speaker 1: So every year I go to a board game convention
Speaker 1: here in Utah in Provo. It's called Timpcon, and I
Speaker 1: wind up helping out with the hot games tables and
Speaker 1: teaching people how to play board games. I usually take
Speaker 1: Friday off and go play board games all day Friday too.
Speaker 1: This year, I'm not gonna be able to do that,
Speaker 1: but so I wind up learning like six new games
Speaker 1: every time. I'm gonna pick a game that I've already
Speaker 1: picked on the show because I know how to play
Speaker 1: it and we've been I taught my wife and my
Speaker 1: kids how to play yesterday. It was funny because my
Speaker 1: fifteen year old was like, I really wantay, you know,
Speaker 1: because if you have fifteen year olds, you get it?
Speaker 1: Do you want to understand? It's like, I don't know,
Speaker 1: it's gonna be cool, and anyway we can miss her
Speaker 1: sitting down, play it right, It's like, looks forty five minutes.
Speaker 2: Okay, over.
Speaker 1: And by the end she was like, this is fun.
Speaker 1: So anyway that that's my testimonial for it. Like she
Speaker 1: was smiling at the end of the game. Of course,
Speaker 1: she also won, so that that might have helped too.
Speaker 1: My seventeen year old enjoyed it. My nine year old
Speaker 1: kept wanting to play. It might have been the deck
Speaker 1: building piece of it might have been a little beyond her.
Speaker 1: But we could literally just tell her, look, try and
Speaker 1: get all of the same color and get the highest
Speaker 1: numbers you can, and I think she would actually do
Speaker 1: okay just playing that strategy. But effectively, what it is,
Speaker 1: it's it's a blend of capture the flag and war
Speaker 1: in a tournament style and and then there's the deck
Speaker 1: building component, right, and so you basically curate a deck
Speaker 1: and what you do is somebody starts, they play a
Speaker 1: card deck card capture the flag, and then they're oponent
Speaker 1: plays cards until their cards total equal to or more
Speaker 1: than the top card of the other players pile that's
Speaker 1: captured the flag, and then they capture the flag from them.
Speaker 2: The cards in the other players pile go on to
Speaker 2: the bench.
Speaker 1: You can stack cards at the same kind on the bench,
Speaker 1: and you have six slots on your bench. When your
Speaker 1: bench is full and you can't place another card on it,
Speaker 1: if you need to place another card on it, you can't,
Speaker 1: you lose. If you can't, If you run out of
Speaker 1: cards and you can't beat the other players.
Speaker 2: Pile, you lose the round.
Speaker 1: And then you get the trophy that's on top of
Speaker 1: the trophy pile on that field that you're playing on.
Speaker 1: And so it's basically a one on one. So if
Speaker 1: you're playing eight players, there are four one on one fields,
Speaker 1: and then you each have a schedule where you rotate
Speaker 1: to play against the other people and you play seven rounds.
Speaker 1: The two top scorers at the end of the seven
Speaker 1: rounds go on ahead to head for the final, and
Speaker 1: whoever wins that wins. And so in the final, it
Speaker 1: was my it was me versus my fifteen year old
Speaker 1: and she'd beat me.
Speaker 2: So anyway, it's it's super fun board game.
Speaker 1: Geek says it's a one point seventy nine, so that's
Speaker 1: it's it's pretty approachable for the casual gamer.
Speaker 2: The setup's pretty simple. There aren't a ton of pieces.
Speaker 1: You know, you have different color cards that do different things, right,
Speaker 1: So that's that's where the deck building comes into play.
Speaker 1: Is like one of them say will say if this
Speaker 1: is on your bench, then you get a certain ability,
Speaker 1: or you might get a card that says when you
Speaker 1: play this, or you know, sometimes it doesn't even say
Speaker 1: when you play this, which means that if it's as
Speaker 1: soon as you play it or whenever it's out, it
Speaker 1: does the thing right. And so I had a card
Speaker 1: that said, if there are any other purple cards on
Speaker 1: your bench, then this card has plus three power, right,
Speaker 1: So it was a one. But if I played another
Speaker 1: purple card and had it on my bench, then a four, right,
Speaker 1: And so anyway, so that's the rest of it. Some
Speaker 1: of them let you collect points towards the end of
Speaker 1: the game because the trophies are worth points, but you
Speaker 1: also have a pile of just loose points and so
Speaker 1: some of them say, if if this card captures the flag, right,
Speaker 1: if it's the last card you play before you capture
Speaker 1: the flag, then you get points. So anyway, whoever has
Speaker 1: the two people that have the top number of points
Speaker 1: at the end of the seven rounds, they go head
Speaker 1: to head and you win. You're probably wondering can you
Speaker 1: play with an odd number of players?
Speaker 2: The answer is yes.
Speaker 1: It has a robot deck, and so you're if you're
Speaker 1: playing against the robot, you play both sides, and so
Speaker 1: that robot deck has stuff in it, like this card
Speaker 1: is as powerful as the current round, so if you're
Speaker 1: on round one, it's a one, right, And so since
Speaker 1: your deck isn't strong, the robot's deck isn't as strong either,
Speaker 1: but he gets round six, and it's got some cards
Speaker 1: that before weren't giving you a whole lot of problems.
Speaker 2: And now they are.
Speaker 1: But you should have a stronger deck by then too,
Speaker 1: And so you just play the robot through and then
Speaker 1: the two players with highest scores, right, But if you
Speaker 1: lose to the robot, it gets the trophy.
Speaker 2: Right.
Speaker 1: So anyway, super fun, really enjoy it. I'll probably have
Speaker 1: we're doing six games at the board Game Conference, So
Speaker 1: for the next five or six weeks, you're gonna get
Speaker 1: a whole bunch of other ones. One of the other
Speaker 1: games is another version of Challengers. I just haven't played it.
Speaker 1: It's called Challengers Beach Cup. So I'll let you know
Speaker 1: when I learned that how that goes. But I'm imagining
Speaker 1: it is pretty similar to Challengers as.
Speaker 2: Far as other picks go.
Speaker 1: I've got a couple of other things. So I think
Speaker 1: Steve mentioned Chuck's half marathons or whatever. I just want
Speaker 1: to clarify I'm training for an iron Man. I'm gonna
Speaker 1: do it next year. I plan to break my body
Speaker 1: over a Saturday or a Sunday, depending on when the
Speaker 1: race is and right, and then I'll show up the
Speaker 1: next day for this podcast and you'll hear me talk
Speaker 1: going out of the puddle of whatever's left to me.
Speaker 1: But no, it's okay. So I've been doing a couple
Speaker 1: of things, and I'm just going to quickly shout out
Speaker 1: what those are. I've been using training Peaks, and then
Speaker 1: I bought a forty eight week training program for an
Speaker 1: iron Man that just goes into training Peaks. It scenks
Speaker 1: up with my garment app which means it goes on
Speaker 1: to my watch and so I just tell it I'm
Speaker 1: doing the workout for today on my watch, and then
Speaker 1: it times me and does on my laps and everything.
Speaker 1: So that's that's pretty nice. I've also been doing some
Speaker 1: strength training I've been using.
Speaker 2: I signed up for.
Speaker 1: A Transformation Challenges what they call it, with a company
Speaker 1: called First Form and they spell form pH or M.
Speaker 2: And man. Their stuff is just it's awesome and kick
Speaker 2: kick butt.
Speaker 1: They do sell a bunch of supplements, right, so I
Speaker 1: wound up buying a bunch of their other stuff.
Speaker 2: But their trainer has been terrific.
Speaker 1: Any questions I have, She's walked me through all the
Speaker 1: stuff I need to learn and know.
Speaker 2: It's just been amazing. So I'm gonna pick that.
Speaker 1: I'm gonna put a link in YouTube and hopefully get
Speaker 1: it into the show notes. That's my referral link. Now
Speaker 1: I don't get paid for the referral link. I think
Speaker 1: I might get some free swag from First Form if
Speaker 1: I'm entered into a drawing or something. I think that's
Speaker 1: how that works. But anyway, I'm just putting it out
Speaker 1: there because it's been amazing, and if you use my link.
Speaker 1: Then you join my coaches. You joined under my coach,
Speaker 1: and she's been amazing. So I just want to get
Speaker 1: you what I'm getting because it works and it's great.
Speaker 1: So far, I've lost like eight ten pounds and that's
Speaker 1: over like three weeks, two three weeks. But the other
Speaker 1: thing is is my gym has an inbody body scanner,
Speaker 1: and so I've lost like a dozen pounds in fat
Speaker 1: and I've put the rest back on and muscle and
Speaker 1: so I and I'm feeling terrific.
Speaker 2: My diabetes is well under control. It's just it's been
Speaker 2: it's been a really good thing for me.
Speaker 3: What are you type two diabetes?
Speaker 1: Two diabetes? Yeah, so it's it's been awesome. I've been
Speaker 1: type two diabetic.
Speaker 2: For like eighteen years.
Speaker 3: So yeah, I know if I was to do an
Speaker 3: iron Man, they would measure my time in days instead
Speaker 3: of hours.
Speaker 2: The course, after a while, Steve.
Speaker 3: Right, I might get kid. Yeah, they'd be okay, step
Speaker 3: go home, you know. But I mean I could do
Speaker 3: the swimming really well, on the biking pretty get the running.
Speaker 3: They just have to follow my holes in the pavement,
Speaker 3: you know. That's how I'm heavy for you.
Speaker 1: Yeah, the the bike is what I'm struggling with. I
Speaker 1: have a Wahoo trainer that I bought and it's it's
Speaker 1: been great, and I'll pick that next time and tell
Speaker 1: you what I bought.
Speaker 2: And then there was something else that I wanted to
Speaker 2: shout out about. H oh yeah.
Speaker 1: So this weekend I went to It was a retreat
Speaker 1: for faith based entrepreneurs. It was three days amazing stuff,
Speaker 1: big breakthroughs. You need to go and find the best
Speaker 1: link to kind of put you into the community that
Speaker 1: I connected.
Speaker 2: With for that.
Speaker 1: But yeah, I just got a lot of clarity on
Speaker 1: who I'm supposed to be and what I'm supposed to
Speaker 1: be doing. And I encourage people to just find if
Speaker 1: you're a person of faith and you're trying to be
Speaker 1: an entrepreneur, find people who are doing that. If you're
Speaker 1: not a person of faith and you just want to
Speaker 1: be a better programmer, go find people who are doing that.
Speaker 1: If you're right, I mean, whatever your ambition is and
Speaker 1: whatever your identity is, go find that and go find
Speaker 1: people who are being excellent what it is you want
Speaker 1: to be that you have a lot of things in
Speaker 1: common with, Because I guarantee you if you get with
Speaker 1: those people and you go deep You're going to have
Speaker 1: some really really eye opening breakthroughs. So that's my pick,
Speaker 1: or those are my picks? Corey, what are your picks?
Speaker 5: Yeah, so this one isn't my pick yet. But did
Speaker 5: you guys, did you guys hear about the circus? I
Speaker 5: understand it's going to be intense.
Speaker 3: I heard that coming.
Speaker 5: I appreciate that. It's my favorite. Uh No, my my
Speaker 5: pick is a absolutely shameless self plug. I mentioned at
Speaker 5: the top that I'm in Saint George. I am at
Speaker 5: a vacation rental that we recently bought and is now
Speaker 5: recently now ready for for renters. So if you are interested,
Speaker 5: and it's in this really cool community called Desert Color.
Speaker 5: There's this beautiful lagoon and it is fantastic. We have
Speaker 5: a condo. It is it sleeps seven, it's three bedrooms,
Speaker 5: and it is available for rent. And I can give
Speaker 5: a promotion code that maybe we could put in the
Speaker 5: in the show notes. So if you want to come
Speaker 5: down to Saint George, man, this this is the place.
Speaker 5: This is the place.
Speaker 3: Now are you bo.
Speaker 2: George?
Speaker 3: You're near what Bryce Canyon and Zion.
Speaker 5: So yeah, we're not far from not far from Zion,
Speaker 5: not too far from Bryce Canyon. It's probably about an hour.
Speaker 3: Oh, you're you're right in the corner on the border.
Speaker 5: We're on the border.
Speaker 3: Area literally, okay, yeah, so Lake Palace to the east,
Speaker 3: and yeah, it makes a bit of a drive.
Speaker 2: It's as if you're.
Speaker 5: Going to going to Tuacon out here. Yeah, it's real short.
Speaker 5: There's there's actually.
Speaker 1: Concerts and in place performances.
Speaker 3: I thought maybe it was that Hawk girl. Okay, no,
Speaker 3: not her.
Speaker 5: There's a lot of a lot of arts out here,
Speaker 5: and there's surprising number of like state parks that are
Speaker 5: really really great as well that that arts Zion.
Speaker 1: So yeah, but you're definitely within striking distance of Zion
Speaker 1: National Park.
Speaker 3: Yeah, you're just southwest of there.
Speaker 2: Okay.
Speaker 5: Yeah, yeah, you're from the airport. So if you're flying
Speaker 5: in in uh, you know, we're real close to that.
Speaker 2: There's a top golf right there too.
Speaker 5: It's a it's a we call it bottom golf. It's
Speaker 5: a big Shots. It's a it's not top golf.
Speaker 2: Oh, it's not top golf.
Speaker 5: It's called big Shots. Yeah.
Speaker 2: Yeah.
Speaker 1: Well, my wife and I and my father in law,
Speaker 1: my sister in law and her husband, we go down
Speaker 1: to Saint George every year for the parade of homes
Speaker 1: and yeah, so we'd be driving past it every year
Speaker 1: and oh look it's almost done.
Speaker 5: Yep. Yeah, and we just adore this community out here.
Speaker 5: And in a week and a half or so we'll
Speaker 5: be getting a hot tub here in our condos. So
Speaker 5: it's going to be even better.
Speaker 2: Man, all right, good deal.
Speaker 1: Yeah, I might have to pick your brain on how
Speaker 1: to buy one, because that's kind of my new dream
Speaker 1: is I want to own a bunch of real estate.
Speaker 5: But anyway, they don't make money month of a month
Speaker 5: right now, not down here, not yet really, Yeah, I don't. Well,
Speaker 5: we'll see, but that's we don't expect it to. We're
Speaker 5: in it for the the equity.
Speaker 1: Okay, Well, if people want to follow up and check
Speaker 1: out what you are doing, maybe in the programming space,
Speaker 1: how do they find you online?
Speaker 2: Corey?
Speaker 5: So you can find me mostly so I'm very quiet
Speaker 5: actually online I don't really get on too much. Kind
Speaker 5: of an accident. I swooped into too Twitter and made
Speaker 5: the comments that I did. But most you can find
Speaker 5: most of my stuff at three sixty five js Things
Speaker 5: dot tech. That's my website. I have all of my articles,
Speaker 5: my my talks, presentations slide decks up there, and that's
Speaker 5: probably at me on Twitter. If you want to talk,
Speaker 5: I'll respond to that, but.
Speaker 3: I won't say what your email is, but I like it.
Speaker 5: Well you can you can email me at Corey at
Speaker 5: three sixty five GSS dot tech. That's not the one that, uh,
Speaker 5: you're referring to.
Speaker 1: But yeah, yeah, all right, good deal. Well thanks for coming, Corey.
Speaker 1: This was great, and yeah, let's get that other one
Speaker 1: book because I I'd love to dive into. Hey, you
Speaker 1: may not know that madam did this, yeah something the
Speaker 1: browser did this for you, So all right, well we'll
Speaker 1: wrap it up till next night, folks, max out