From Learning New Languages to Learning New Technologies - JSJ 629

Hey, folks, welcome back to another episode of JavaScript Jabber. This week on our panel we have Dan schupp here. Hey, coming from a warm and sunny Tel Aviv. No rockets pulling on my head for a change. Yeah, I heard you had a little stuff coming your way. What yesterday? Yes, it was interesting times. It will come up again in the picks, So if you're listening in, you know it's worth waiting till the end. Yep. Absolutely, but thank God for the Iron Film. We'll

just put it that way. Steve Edwards, how you doing? Coming from a not warmon sunny Portland. And I'm Charles Maxwood from top End Evs and we have a special guest this week. It is Tony Alicia. Tony, do you want to say hello? Let people know why you're so awesome all the stuff you've done on you to me and plural site and all the other places that you show up. Hi. Great to be here. Yeah. I'm twenty five years of development, mostly web and database oriented, as well

as the psychology of human computer interaction and user experience design. I've got about it. Yeah, and I've got about ten years as a tech educator. So if anybody out there does know who I am. It would be based on probably my you to me courses. Principally I'm a plural site instructor as well. Most popular courses has been like JavaScript Understanding the Weird Parts is probably the number one, and JavaScript Weird Parts shocker. I know a shorter book

if you listed the not weird parts exactly. So anyway, yeah, that's that's me. Happy to be here. Yeah, absolutely, I feel like I live in the What Developer Education mecca because it's headquarters is like an hour's drive from here, and John Lindquist lives in my neighborhood. So anyway, yeah, and then it seems like there are a bunch of other places that

do kind of the same sorts of things in different ways around here. But one thing as we get into the topic of how to Learn that I'm just going to put out there is it must have been what like eight years ago, nine years ago, we had Katrina Owen. Now you all probably don't know her as well just because she's she was in the Ruby community, but if you've used Exorcism dot io to learn stuff, she's the person who created that. And anyway, we had her on and we did how to Learn

episode and it gets downloaded easily more than just about any other episode. I mean, new episodes, especially for JavaScript Jabber, get more in a week than that one does. But that's about it. Like everything else just comes in behind it. And if you go look at the stats, it's usually whatever the latest episodes are for JavaScript Jabber, Ruby Rogues, and React round up, and then it's that one, and then it's the homepage for JavaScript

Jabber. So just give you an idea of how many places are telling people to go listen to that episode. It's definitely a topic that people are interested in, so for sure. So yeah, so enlighten us. How do you learn tech? Easy question, now, right, I think well, for starters, I think it's good to define what we mean when we say that we've actually learned something until I find huh useful because people have different ideas

about what they think it means to have learned something. So in the context of software development, and I have tips on learning things, but as far as that idea, in the context of software development, I would say that you've learned something when you have a precise and accurate mental model, as opposed to they or inaccurate mental model, meaning how do you think the thing that you're using works, And maybe a more practical definition is that you've learned something

when your knowledge and your mental model enable you to effectively deal with novel requirements and debug problems while you're using that tech. So the reason I say that I have an illustration I like to use. Let's say you move to a new city and you want to learn the streets. When do I say, I've learned the streets of the city. Well, if you just use your GPS to get from home to work, and you memorize that route, the GPS has turned right here, then turn left there, etc. You might

say, hey, I've learned the route. I've learned the streets of the city. But really all you've done is imitate what the GPS is telling you to do. As soon as there's construction on one of those streets, you have no idea what to do, and if your GPS isn't working, now you're going to start trying to figure way around. If, on the other hand, you had looked at the map, you got a feeling for the major streets, the major areas, this is the financial district, this is

the business district, and you have a mental model of the city. Now, as you're using the GPS, you're also refining that mental model, and you end up being able to say, Okay, I know what's happening. When I need to go somewhere that I've never been, or when I have construction and I need to get around it, I can do that more effectively. And that's the same way with coding. When a lot of people learn a tech or even say this, how they want to learn tech is just

by doing, which is everybody learns by doing. That's important, But a lot of content out there, even on the internet, is about watch me code, and you code the same thing, and that's the equivalent of the GPS. You can get from one route to another. But as soon as you have novel requirements, something you know, your boss, whatever it is, comes at you with something you've never seen before, or you've never done before in a tutorial, or there's a problem that you've never seen before,

and now you have to debug it. That's when it shows whether or not you've just been imitating and you have a vague or inaccurate mental model, or you understand to a reasonable degree how this technology works, what it's doing, so that you can then use that mental model to reason on how to accomplish a task or fix a problem. So, yeah, now this is a topic I've I'm pretty interested in and have talked about in various places over the years, and I prefer to think about it as along the lines of what

you're saying. But the more completely you know what you're dealing with, then you know when something's wrong right. If you know that something, you know how it's supposed to work, then something's wrong with like Okay, that's not right, and then you can figure this is what it should be. This is you can narrow down to this is what's wrong and go from there.

You know. One of the classic examples that I've heard given before, and I started out my career after college in a bank and I used to train tellers for a little while, and they didn't do this when I was in there, but in the past what they would do to train tellers is they would just have them to sit there and count cash, count cash, count, cash count cash. Then after a while they throw in a counterfeit. And because you know the real one so well, you can easily spot when

something's wrong. You know the same is true when you're dealing with tech support, with you know, whole websites. I can remember dealing with a huge one when I was at Fluke and people would say, well, what's wrong here? And I think about it and realized it should be doing this. Okay, I bet the problems right there, not because I knew what the problem was, but because I knew the base, I knew how it operated, how it should operate, and then I could tell you right away,

okay, this is where something's going wrong. So it's not so much to a certain degree when coding, it's going to be yeah, how to do things. You know, how to write and function, how to do this, how to accomplish this, But at the same time, you got to know the tool, and the better you know the tool, then it's a lot easier to be able to figure out what to do with it once you know it. Yeah. I just want to jump in on this too, just for a second, because I've had people Usually the question I get is

how do you stay current? Not how do you learn new tech? But you know, you get pretty quickly into okay, well here's how you know what you ought to learn, But then how do you learn it right? And you know so then you talk about books and videos and all this stuff, and I think, I think the imitation is part of the process. But yeah, at the end of the day, then it's okay, Well,

how do I know if I've learned it well enough? And I really liked your definition there where it's hey, look, I can find my way around the problems that I'm going to run into, right, so you know, I mean, I've been doing most of my experiences been in Ruby, right, and so if I run into a hiccup, I have seven other ways that I can think of off the top of my head to try and work around the problem. I know at least six or seven different tools that

I can use to figure out where the problem even is. And maybe it's just a dumb typeo, but yeah, I like that as your level of proficiency. Okay, can you do this without the training wheels and solve the problems that are going to come up? I have a question about that, because your initial definition kind of said that your mental model is accurate, that it actually properly matches the way that the system works. How do you know.

I've seen, especially in web technologies, which tend to be fairly forgiving, I've seen people have really incorrect mental model, yet you know somehow managed to model through. And you know, how do you overcome that situation? How do you realize it even to begin with that you're in this situation? And then once you realize that you're in it, how do you deal with it? Yeah, that's a great question. And I want to say first that I agree that invitation is part of the process. It's just as you're

imitating, are you reinforcing a bad mental model? Are you only having a vague when are you reinforcing a good mental model? And that's a big difference into how useful that imitation will be because I have to the short, really short story imitation. So my first course in the university the you know, and I'm talking right back when where people were a lot less computer proficient and

computer literate than they were than they are now. So even though it was CS one oh one, for some of the students back then, it was literally their first time, you know, working with a computer. And the inster literally wrote on a whiteboard an example Hello World program and basically the first homework was to enter that into the computers in the university and get it to run. Now, his name let's say was Joe. So he wrote a Hello World that basically wrote, hello, my name is Joe. Have to

students handed in a program which said hello, my name is Joe. So yeah, now please go on. Yeah, that's a good example. So your question or your thought about how do you know? I think you made an important phrase which, as you said, you muddle through. One of the you could say great things about the job as a developer. It is possible to muddle through and get things to work without truly understanding what you're doing

to a degree. Right, It's possible to have a bad mental model, and either because the system is allows you to or simply because there's so much information out there on the internet, you know, eventually you can kind of figure what your way through it. What I would say is that as a community, in my experience, and I've been doing this, like I said, twenty five years, lots of different dev teams. I know a lot

of you guys have been doing this a long time. We've normalized banging your head against the wall and not really knowing what's going on, and then having a degree of stress, maybe even if you're under you know, some kind of pressure, and that's a degree of normalization that I think other a lot

of other professional areas wouldn't have. Like you wouldn't expect a doctor to muddle through, right, you would say you need to understand anatomy, as opposed to let's try different meds, you know, not knowing what one does or the other. So but we've kind of accepted as development, right, and that does happen. But we've kind of accepted diabetic And every time I switch doctors, they do this, Right, we're going to try this medicine.

Now, we're going to try this medicine and I'm going you don't know what they do? Yeah, yeah, that's true. And but but don't we kind of do that as devs all the time? Right, Like there's there is a muddle through when you when you look at a development team. Oftentimes in the development team, there'll be somebody that's the guy you go to when

you're trying to debug a problem. Right, There'll be somebody that in this You know, I can sit here for two days and he'll or she or she will come up behind me look at it and like very quickly be able to figure it out. And what I find is those people are the people with the most precise and accurate mental model. So whatever it is that you're doing based on experience, based on what they're looking at. So if we're saying I'm going to learn something, I like to distinguish that from I'm okay

with muddling through. And I think a lot of devs have only not maybe only ever, but most of their career, have only experienced muddling through and have normalized it mentally. This is what it's like. I have a bug, and I bang my head and I don't understand why, and eventually we figure it out. And a really experienced DEV team that has a really strong mental model actually has less of that and therefore is more efficient, less stressed.

And I would say, then really learns what the technology is. That's my personal experience. It can I share an example here, in fact, it was yesterday. So in my church, I'm one of the technology specialists, right, So we do everything from helping with like Facebook groups and stuff.

But our steak and a steak is a group of wards and wards are just congregations, right, So we get together twice a year, you know, with kind of the larger area, and we have a conference, right, And that's the other thing we do is we set up the audio visual

stuff for the conference. And so there's another technology specialist and he's been doing this for a while, and so I went and I helped him set things up on Saturday night in the main building where the conference was going to be held, but we were transmitting it to the other building that's over here by my house, and so, you know, I helped him set everything up.

And I've done enough audio visual stuff. I mean, I've been pot casting for what like eighteen forever and so, right, so a lot of the stuff was familiar, but then when I came over here, the part of it that I'm not familiar with is the PA system. And so I got everything hooked up to the computer so that I could stream from the other building. Right, I had it hooked up to the projector. I had it hooked up to the little TV so that people sitting on the rostrum could

see it. And I couldn't get it to play through the PA system, And so he helpfully sent over the correct chord so that I could hook the the projector up to the PA system, and I hooked it up and it still didn't work, and eventually he had to come over and show me what to do right, because I had hooked it up wrong. And yeah, you know, now I know how to do it, but you know that

the muddling through didn't work right. Yeah, I had to have somebody come in and say, no, this end goes in the projector and this other end goes to the PA system and if you hook it up this way, then you know. And as soon as I saw it, it was like, oh, right, that's obvious anyway. Yeah, but that's the thing, Chuck, because sometimes, and I've seen this a lot in over my career. It it's when you know something doesn't work and you find the expert

and you and you know, you ask what do I do now? And then he shows you a certain way and you ask why, and they say, well, that's just because that's the way it works. You know, that's just how it works. And I literally hate that. Now. Obviously a lot of times that person potentially doesn't really know either they got this information maybe from somebody else, you know, maybe this is secondhand or third hand or what or what not, and that's just the way that they've been doing

it. And for me, understand, you know, if something is really important for me. Then I have to understand not only the how, but also the why. And I think that's kind of heat to the to the whole thing. If if you recall a while back, I think it's over like a few years now, we did this whole series of episodes on on react uh and instead of talking about you know this React API or that React API, we spoke about why React works the way that it does, Why

does it have a virtual dawn? Why what what's what's its role? What's its purpose? What are the implications? Stuff like that, trying to you know, understand the reasoning rather than the specific APIs, which are you know might change over time and you know and are you know you can't really remember them anyway, you can always google them, so, but but the understanding is something much The under understanding, the underlying approach is much more fundamental.

Yeah. So the first tip that I because I wrote these down so I wouldn't forget, but the very first tip I was going to give was that a lot of times devs learn what and how what am I going to do and how am I going to do it? But when you really learn something, you should learn why, when, what and how? Why does it exist? What is the problems that it's designed to solve? Every technology exists for a reason. Somebody coded it for something, right. The win win

is the what are the best circumstances under which to use this? Which helps keep you from, you know, using a tech that maybe isn't the best solution for the problem that's in front of you. And then the what and the how, which is what most people learn, like the APIs and that, et cetera. Where do you go to find that? Well, what I find very useful is to go seek out the earliest introduction of that technology out there on the Internet. It could be an RFC, it could be

a blog post, it could be a conference talk somewhere on YouTube. When was the first time somebody said, hey, introducing and then the tech that you're talking about. Sometimes the documentation will always have it will have it as well sometimes, but you can definitely in most cases these days, find some

original introduction of the technology where they get into the why. For example, I just I had I released the course a couple of years ago on HTML and CSS, and in the course we go to the PhD thesis from one of the inventors of CSS where they talk about why CSS works the way it does, and it's fantastic because it gives you that the beginning of a good mental model, so that all the things that a lot of developers find weird with CSS actually make a lot of sense. Interestingly, we recently had an

episode with the Rich Harris, the creator of Swelt. Excellent episode, by the way, I think it was one of our recent bests. And I brought that that I first met him when he gave like the first introductory talk about SVELT. It was Felt three when he just came out. It was coming out with Swelt three. It was rethinking reactivity. He gave it in a conference I was attending, and it's an amazing talk and if you want to understand like the why of SVELT, that was an awesome place to start.

And indeed that you know, that video has something like three hundred and fifty thousand views, and I highly recommend it even today, even though they're now rethinking all of it with the selt vive and ruins. And if you want to learn more about that, you know, you can definitely listen to our podcast with him. But it's a great approach what you're suggesting and there's also a similar talk about React with the person who created React. I forget

the name of the talk. It's Jordan's they gave the talk, or was it somebody else? I forget, and I'll need to check. But he he goes on afterwards to all to start talking about what's that other program that programming language? Oh, my head isn't working. Never mind, but I'll try to find it and post a link if in what I do. But but I totally agree, and I think it's a it's a great approach. And I've not you know, now that you're you've said it, it seems

to make so much sense to me. That's great. Yeah, And I love finding those things right because then you you set yourself up because a mental model is built from the foundation up what we're what we're doing a lot of times when we're learning via a PI is we're trying to infer a mental model from like the leaves of this decision tree where all the decisions are made on

people designing this technology. But if you can start at the roots, somebody had a problem and they were trying to solve a problem, and if you can be there with them, if you can be in the head of the people that invented these things. It's going to make it so much easier to learn everything. So that's the first tip. The second tip that I have is to be I like to call it, be curious about how something works.

And what that means is a few things. If you're dealing with front end web technology, look at what's being delivered in the network tab right, look at the things that you're actually using, a lot of people just sit in these abstractions. But the problem is, in order to be able to just sit in an abstraction, the abstraction has to be perfectly contained with no leaks. There does not exist a front end web technology that does not have

streaky abstractionness going on. You always have to understand the fundamentals. And I know you guys had a really great episode on fundamentals. So my definition of fundamentals is one or two abstraction layers below where you're working. So if you're sitting and react, a fundamental would be the browser, APIs and JavaScript,

right, those are fundamentals. So if you can be curious and look at how are the fundamentals being used with this technology, and that means, like I said, oh, looking at what's in the browser tab, stepping through code beyond your own. That's a great thing about JavaScript libraries and frameworks.

You can actually step into them and see what's going on, and not being afraid to read source code, which that can be controversial, and I'm not saying you have to read every line of source code for everything, but having a good model can be so useful. So I just released a sixteen and a half hour React course and in it now we literally step through React source code. I read every line of React eighteen to prep for this course.

But it is so useful. It's so incredibly power to start to get a mental model and to not see things as just this thing that just happens in the ether, but as just other people's code. And that's incredibly powerful. So for React and for any for example, for any JavaScript framework, talking about connecting fundamentals to the substraction, how do we figure out how a JavaScript framework works? What we know one of the fundamental things that's doing is updating

the dom. So you pull down all the code because it's open source, right, it's free education. You can pull down all the code for React or any other framework, and you can do a search for something like a pen child, which is a DOM browser API. You know, somewhere in the code wherever it's actually updating the dom that is a pen child or insert or something else that's going to happen to the dom. Find the spot where it's updating the dom, and then look for where that functions being called,

and then look for where that's functions being called. And all of a sudden you're going to say, oh, now I see how it's making these choices. It may be complicated, it may not be like I'm going to read every line and immediately understand it, but you can start to get a feel.

One of the things I say in the course is like the rules of hooks is a thing that people memorize and react, well, I can't put it in a loop to do. And sometimes something that one of you was mentioning where well, an expert might tell you the answer, but say, well, that's just why it works. But often it's because they don't really understand it themselves. Fully, I see a lot of people say, well, hooks are kind of a thing that well, they can't be in a

loop because they're kind of like a raise or different things. If you go in the code. What you see is that a hook is a series of hooks, is a link list sitting on this JavaScript object called a fiber, And every time the function runs, it's going down the link list and executing all of these hook functions. So it has to be the same every time.

It's just going down a link list. And I talk about it in the course, and we do, you know, diagrams and things, But ultimately, when you have a precise and accurate mental model, as opposed to a vague or inaccurate one, you can infer the things that other people are memorizing. I can infer the rules of hooks because I understand how it works. Oh, of course it works that way. Of course I can't do that. You don't even have to tell me that, because I understand how

it works. I had another experience recently. Versell, I think, updated their documentation based on a conversation I had with them on Twitter where they had a verseell. You know React server components come out and the idea is, oh, we're not going to send JavaScript to the browser for the components that you run in a server. But if you know how React works, you know that it's keeping two big trees, the DOM and this fiber tree in

sync and they have to be complete and match. So there's no way there's not some JavaScript going out server rendering to fill out that tree that React needs in order to do its work. As it turns out it is. It's called the RSC payload or the flight data. And when you go to oursells like issues that people submit, there's a bunch of people going, I have my all on my server rendered HTML is doubled in all these script tags at

the bottom. Can we turn that off? And the answer is no, because that's how React works, right, It's but because you know how it works, you look at that and go, yes, that is a cost of initially sending HTML because I need to somehow put together the fiber tree. And so when we have that mental model, we're also not surprised, right, we make better architectural decisions because now we're not just going to go I'm going to switch to this new tech because everybody says it's great. No,

we're gonna say, well, how does it work? What is it doing? Oh, I'm actually outputting a bunch of big svgs and a very little JavaScript I'm using for that This may actually be a bigger download size for my use case right as opposed to a different use case where an RSU would be great. So again, so that's like kind of two tips in one is

to be curious, look at what's going on. Take the time, and people will say I don't have time, but the muddling is also time and my and in my experience, the time you invest in understanding will over you know, a period of time, eventually you will make up that cost and then much greater because you will muddel less. Hey check, just as a shout out, you're talking about reading source code. We did an episode exactly on that. Yeah, not too long after I started it, Episode four

A Way to Reading source Code with Carl Mangazi. Yeah that was an awesome episode. Yep, reading source code and why and how and so on. So yeah, Carlo is great. He was a host on React Roundup I

think for a while a while he was yep. Yeah, So Tony, I have a question for I wanted to clarify something that you sort of skipped over early on when you were talking about learning and you were talking about muddling and how you know, dev team generally has one person that sort of can come along and look at it and say, okay, this is a problem because they have that venture better model. There's a big gap between getting from here to hear and to be And I guess what I'm curious to hear is

your viewpoint on learning by doing and failing. So you talk about muddling through and that sort of waste of time, and how generally you want to go back and understand. Ideally, in a perfect world, you want to be able to understand how everything works. So then when you understand that, you can infer what's going on. And so I get that at the same time, based on my personal experience, and I'm like many people, many Java script or devs of any type, I learned by doing, you know,

by getting in and mucking around with something. And based on my experience, not just with coding, with the fire servers, with any other thing I'm involved with doing something and failing will imprint the right way to do and learning to do it right let me correct that will imprint it on my brain and help me remember much more than doing it right the first time. And so

you know, people say practice makes perfect. And my choir director in high school had a great sign that said no perfect practice makes perfect because if you practice the wrong thing, then you're going to end up doing the wrong thing later when it really counts. And this is true in athletic competition when you don't have time to think about something, you just have to do. So I'm curious to see your viewpoint on how that fits in where doing it and

failing and doing it okay now it works. It's like the famous quot that Edison said is you know I failed four hundred and ninety nine times, but each time I didn't think I failed. I just learned one thing that didn't work. Right, you know it doesn't work, and so then now you finally you know what does work. So my point is doing in muddling does have its benefits. You know a while ideally you would want to go back. And that's how I am is wanting to know how everything works. A

classic example that I've given force learning the language. I'm a Spanish speaker and languages came really easily to me, and if I had wanted to learn more languages, I could. But I have seen there's two different way kinds of ways to learn a language. There is the what people call conversational, and then there's the learning the verbs and the nouns and the conjugations and the different tenses and all that kind of stuff, so you can learn a conversational learn.

Okay, if I say this, it really means this. I'm like, Okay, I want to know the verbs. I want to know the adjuctives. I want to know the pronouns, I want to know the conjugations. I want to know the tenses so that I can easily put something together that's my but not everybody's that way. So I'm rambling. So hopefully all this makes sense. But I guess I just want to get to the point of saying the muddling have benefits at some point, and I'm to an extent.

I'm going to say it's an extent. I'm curious to see what you think. No, I have one agree. I'm a muddler, right, We're all muddlers at some point, right with anything. And when I think of it as an iterative process, you have a degree of understanding, hopefully from the why and the win. And then you start to muddle, right, maybe imitate somebody else's code, you start to work through it yourself. You come across something you do it wrong. The issue, I think is

the feedback loop being accurate. During the muddling. It is possible to reinforce an inaccurate mental model because it's possible for you to do something that you think works for reason X it actually works for reason why. But it worked, so you just say, see, my mental model was correct, but it's actually not. So that's I think is a little bit of the danger. So oftentimes in real world right, in a real world scenario, you're just trying to get it to work because you have a job to do, so

you do have to get it. You have to get it working. And if you get it working without fully understanding why it's working, it's not the most comfortable foundation to sit on as a developer. Right. I don't know why this is working, but it is. We've all been there, probably right at some point in our in our lives. But we're also can be under under different pressures, right, business pressures, work pressure, client pressure.

So what I like to say is win a team or you as an individual, get something working, and you have that moment where you do a retrospective on a problem or on something that you're working on, even if it's just you by yourself, try to see if you can plug in what just happened back into your mental model, and then the failure will have its maximum benefits. Like for example, I'm thinking like, I'm going to go way way back, Like one of the earliest examples I ever had of this in

my personal development career, I'm going back to asp dot net. That's how far that's how far back we're going. So asp dot net would keep your form data in the form after you submitted, even though it was a page refresh, right. A lot of people didn't care how that worked, But what it actually would do is was a big hidden variable, a hidden input in the form that encoded all of your form data so that it could pull

it back up again on the refresh. But if you did a form get instead of a post, it would go up in the URL and you could actually get a URL that was longer than was allowed by the browser. And then when it went to de serialize that data, everything explodes. That's one of those things for you had to figure it out. Right, you're doing, why isn't this form working? This giant form that we're building for this government business, and you look at all this reasons. And then when we

finally realized it was the browser. For me, that was like a fundamental moment in my DEAV history where it's like, Okay, I muddled through, we figured it out, but now I need to plug back into my mental model. This isn't some amazing Oh the form, the data just stays there, no somebody coded so that all that form data gets stuffed into an hidden input. And then now you got to think about your fundamentals. Now you've

got to move an abstraction layer below to see what happens. So now my mental model is whenever I'm using it was using, you know, building a form, is that that form construction process is also has this other piece to it that I have to think about. And from that point on, I think that really influenced how I dealt with the after effects of the muddeling.

Right, is what am I learning from the muddeling? Is there an abstraction layer below that I can now clarify in my head, Oh, this is how this is working, and then I have to model less the next time. One thing that I'm a bit concerned about in the context of this smuddling and getting something that works and leaving it as kind of as is and just

moving on. Is the impact that AI is having and might have, where people are using AI to generate some code, get it to work, and then just move on without really necessarily understanding, you know, the code that AI wrote for them. Yeah. I think that's a major problem. People have asked me. You know, as a tech educator, people ask you, should I still be learning the code because of AI? And my statement is, now you actually need to understand the code because you're going to have

an AI generate it for you. Somebody's still going to have to figure out why it doesn't work. And sure AIS will get better at debugging over time, but there's always going to be something novel that the AI doesn't know about, whether it's a new framework or a new technology, those things take time. Current ais don't reason, They just predict based on previous code, right.

So really the danger the dev that's in the most danger I think in the AI age is the dev who just copy paste code without understanding it and learning a tech so that you understand what's happening under the hood, so that you understand how it works. I have a phrase that I've used for ten years, don't imitate understand, which is, don't just follow along, understand

what's happening as you follow along. It's okay to learn by doing, but actually learn why you're doing right, as opposed to I give the GPS six sample again, if I GPS my way to five different locations in the city, I now have a broader level of knowledge, more APIs, but I still don't have deep understanding, right, I have a vague mental model. And so it is possible to just keep on adding GPS routes to your experience in the city and never learn the city, and you know, get away

with it. You know, you do okay, but you're going to run across less dead ends and less turning around and less stress and getting to where you need to on time if you just learned how the city was laid out. That makes sense. To expand the illustration, yes, it certainly does, and to kind of exasperate this issue, a lot of web technologies, first of all, the core fundamental web technologies and a lot of the stuff

built on top of them, like frameworks, are actually really forgiving. So for example, if you take if you look at React and you know, I review a lot of React code and I see, you know, and I always look at it from a perspective of performance, and I see, for example, a lot of re renderings going on. Now, re renderings you usually still end up with the correct rendering that you want to achieve, And that's what the developer is looking for. Did I is my end state

the one that I wanted to get to? But they're going through so many renderings in order to get there, and a lot of these are you know, could have been avoided given a better understanding of how React works and how and when and how it updates stuff. Yeah, I've just been talking about this a lot, and it React, I think, because of its nature, actually requires you to understand how it works to use it well, build performance applications, to avoid footguns. There's not a ton of a I like

to say, do and put this the right way. I like to say, make it hard to do the wrong thing and easy to do the right thing right. If you're building an abstraction falling into the pit of success, that's another way to put it. Yeah, React React, as popular at is as it is, is not great at that right. You really do need to understand how it works in order to be performant. What it is good at is you can just get something working right, which is two different

things. So the degree and I think that's pretty true with all of these abstractions that we live in as web developers is we just add abstraction layer, constraction layer on top of HTML, HGCP, CSS, JavaScript, browser, APIs, and SQL. Those are that's our bottom line. Everything else, for the most part, is just layers of abstraction on top of it. We're rarely introducing a new ability or we're introducing is somebody else's code that uses

those baselines to do something. So getting your fundamentals really strong is also going to enable that. So when you look at React and you look at rerenders, that's really connected to pure functions in a lot of ways, right often oftentimes, and it also is connected to understanding objects and passing by reference. Right, it's understanding shallow versus deep equality. And if you have those fundamentals, then then you can explain how to avoid rerenders. In the context of

the fundamentals. You can actually go look and React source code to me, and I went and did this, and you can find where it shallow compares props, and you can say oh, there it is. And if the shallow compares is equal, then it doesn't do this other work again. And now your mental model makes it so much easier to remember how to do these things. And that's maybe the other piece of the puzzle when it comes to muddling versus understanding, When you don't have something to connect to in your mental

model, I find that it's easier to forget a point. Don't do this. Do that. We're not good at memorization as humans, right, as people, we prefer recall versus reminder. Right, So recall is just like, oh, I remember this thing, but reminder is, oh, this thing connects my brain to this other thing, and now I remember, like you tie a piece of string to your finger, and now it's a reminder. When you have the fundamentals, those become reminders on top of the abstraction

layer. Whereas if you're not connecting back to your mental model, then and you end up just trying to remember everything and that's actually really hard. So what I say is, as far as a tip is how do you even do this? Another tip is find the blogs of people who are building the thing that you're using. You can often find somebody that is explaining it, that's writing a blog post, and sometimes you'll find that blog post has like

ten hits, like people aren't really reading it. It's just somebody that's just working on it and they're like, hey, we did this cool thing. Go to the re repo, find the major contributors, and then go find them online and see if they're talking about it. You can find treasure tros and inside the source code. I mean I found this inside React eighteen.

Sometimes you can find nice large comment sections where people are explaining themselves because these are just people writing code, right, So sometimes even the comments and the

source code of the thing you're using can be clarified. So that's another way to An interesting way that I use to try to test my understanding of a topic is to see if I if I can explain it, if it and without going into handwaving you know stuff, you know, can can I you know, if if somebody were to ask me why does something work a certain way? Am I able to actually provide a good enough answer and answer that I'm okay with? If I can't that, I cannot really say that I

understand that topic. Yeah, you understand you And not everybody is a has experienced teaching, right, So there's teaching techniques is one thing, but can you teach it from a standpoint of not just what to do, which I think Steve had mentioned. There's not a person that comes along just is because it works the way it works, But can you say this is why it

works that way? Then you actually do. And the handwaving is really interest because I see this all the time where somebody at a conference told me something, or I saw something in a YouTube video, and I think it kind of works this way. But you can tell when it's vague. Now, you can tell when whether somebody really understands it or doesn't. And that's not

a knock against anybody. We learn over time, right, somebody introduces an idea to us and they think, Okay, I've got this kind of vague notion, now, that's cool, and then over time we get deeper and deeper. That's just iterative nature. It's not bad right to have a vague notion. It's just that our goal is to have a more precise notion and to be aware of the fact that your current level of understanding is vague.

Now you might decide for a particular topic that's good enough for now. Obviously I can't know everything, and I do need to prioritize my time and effort. So maybe it's okay for me to just have a vague understanding of a specific you know, Let's say it's a framework that I'm not currently using, so I want to understand its benefits, maybe like gabble with it a little

bit, but I'm not going to invest any significant effort in it. But if I'm going to say this is something that I'm going to be using regularly at work, and this is a core, you know, aspect of my job description, then I'm going to delve into that. I'm really going to try to get a good understanding and a lot. Again, it works for me because I actually kind of am an extrovert. I like to talk.

I will often actually just schedule internal talks within my company even to explain a concept to the other developers, and you know, getting there requires me to become proficient in that particular topic. Yeah, one hundred percent agreed. And I think that that distinction between I need this from a moment and I'm going to use this more often is also a good way of determining how deep do

I need to go. If you're going to learn a new framework and you're going to build an application with it, then you want to go deeper. You know, if you NPM install some little library that does something that you know has many many downloads and everybody knows works and is fairly innocuous, then maybe you don't have to go that deep. Right It's we're all limited on our time and our energy. So sometimes people hear this kind of discussion,

and I find people pushback. It's like, I don't have time now, I don't have time for all this. And again I say, well, how much time are youre going to be spending in this thing? And that means how much time you're going to be muddling through or struggling with a problem. Then you're pulling from the future. There's another way to call it. You can buy that time from the future right now and help yourself in the future. And that doesn't mean not going to make mistakes, fail run across

problems. All it means is that as you iterate on that, you find a problem that challenges your assumptions. We all make decisions on assumptions, and I think I know how this works. I have a set of assumptions in my head and I make a choice. So we come across something that challenges our assumption with the tech, Well, there you go. There is the whole in your mental model. You just found it. So now we're going to go try to fill it in at the sources that we can, whether

it's stepping through code or finding somebody online. In some cases, you can go to a discord and people that are working on this tech are available to answer questions, which is amazing, right, so you can or or some other place like Facebook or Reddit or something like that. So I think it's it's also important to note that we're not alone in the endeavor. There are

other people out there who can also help us to understand. I just want to chime in because I think there's another reason to be doing what you're talking about me and being proactive and picking up this other stuff, and that is that. In fact, there's a comment on YouTube from Alri and he says,

no one has the patience anymore though they want now. But the point here is is it's for me, Like what motivates me is not the Well, if I learned this now, then I'm gonna have built up all of the building blocks, right, or I've got kind of the what framework fitness, you know, because I'm in a running and stuff, right, and so I'm thinking I've built up the stamina and the skills, and right,

I know how to make it through a long distance run. For me, it's also part of the reason why I go out to run or do whatever else I'm doing, is that there's a certain aspect of the kind of person I want to be. There's a certain aspect to the kind of discipline that I want to have, and this is just another manifestation of that for me.

Right. So it's yeah, it's good that I can you know, I can get in there and I can muscle through a program problem and that I know how to handle oh gosh, I have a blister on my foot or a figurative programming blister in my code. Right. But there's the other part of it that's just I want to be excellent at what I do and this is just table stakes for that. Right. I want to be just

the top notch developer. I can be a top end dev if you will, and so aha, right, this is part of that, and this is part of that philosophy for me, is just Okay, you know what, I'm going to get in and understand it. Now. Am I ever going to have to dig into this code and write something against it? Probably not, But like you're saying, it does help me understand what's going on, and that ups my game and it helps me become the kind of programmer

and manifest the kind of person I want to be. That's such an interesting statement. And I I've had plenty of students over these years, and so now you get into kind of a human issue. We all are going to fail and muddle and muscle through. You know, nothing against that at all.

Nothing is a necessary part, and it's valuable. I do find that sometimes a person's willingness to dig in actually has to do with their self view as a developer, kind of like I do a lot of done a lot of tutoring of kids in math over the years, and you have kids who just say, I'm bad at math. That's my saying. It drives me crazy. Yeah, and it's and when you go and look and help them,

you realize the book is terrible. Uh huh, right, it's it's it's not teaching them well, but they instead make it a problem with themselves and I think that out there in my experience, there are devs who got themselves a job. No, maybe they have some imposter syndrome, and they see themselves as this is how I have to do it, because I'm not capable of understanding any deeper than this, right. And my statement is the same as those kids who say they're bad at math. You've just been taught

poorly. It's not few. That's the message I just often give to my students in that as instructors of technology, we often suffer from something called the curse of knowledge, which is a user experience design concept that once you know something, it's very hard to remember what it's like not to know that thing.

Yep. So you may have people at your job online and they're talking to you and they're using words that sound big and complicated, and they're not, but you just don't know the vocabulary, and so now they're lost in the conversation. So I have this thing in my courses for years, but I call it the big word alert, where as soon as we hit a phrase that you may not know, we stop and we explain it and then we move on. Because you're totally capable of understanding this vocabulary is not intelligence,

right, It's just vocabulary. So we as developed are often taught poorly because teaching is a whole different skill than coding. So you may feel like you're incapable of understanding at a deeper level. But if you start to approach it little by little from building your mental model and you work on your fundamentals, then the better your fundamentals are, the better you can read source code, the better you can step through code and understand what's going on, and

you'll start to develop self confidence. And that's what I've seen happen with people is that they're like, you know what, I feel like I can understand this, and I've started digging around in source code and I saw this, and I saw this technique I never knew you could do in JavaScript, and so I started doing it myself. That I love that because that is the kid who says he's bad at math realizing in an hour explained a different way that he can actually get it. And I think that there's a lot of

devs out there that looking for that experience. Well, and to your point, I mean, this is what I've gone through with my son with his math classes, right, is he'll be like, I just don't get it. The teacher didn't explain it, right, blah blah blah blah blah. Right, And so we'll sit down and we'll work through a few problems, right, because I happen to be very good at math, right, and

so you know, or at least I have confidence. And I mean I did the math competitions in high school and you know all of that stuff. I have a degree in computer engineering, and so I had to take the advanced math classes. So I don't know if good at math is so much as that I've just done a lot of it, and so I see the patterns, right, But whatever the case is, right, and so we work through a few of them. Well, this isn't how my teacher told me to do it. But does it make sense to you? Why?

Yes, yes it does. Okay, Well, do three or four more of these, and then come back to me with where you get stuck on any of them, And inevitably on the three or four of them. He works out two or three of them, and the last one has some little niggelely trick to it that is like, Okay, you've got to think about this in this way. And then the light comes on again and you go

through the same process in a smaller way. Yeah, and I've had the exact same experience, and I think the difference is memorizing, right because the class and the math class will say, use this formula, and then they're given a novel problem right where it's not very clear how to use the formula. But when you go backwards and go, well, actually, this formula represents this triangle. Let's draw the triangle, or this formula represents this happening

on the number line. Oh, that's what that means. And then now there's a mental model to rely on to lean on when dealing with novel circumstances. And I think it's one to one with development. But and here's kind of the thing with development, to an extent, it's always a novel circumstance. You're not solving a textbook problem where there's a textbook solution. You know, the whole point is you're creating new software where that software did not exist

before. Now, you know, obviously we're creating a lot of similar solutions. You know, frameworks exist because there's such a huge overlap between the products and design patterns exactly. But still at the end of the day, there is something unique about what you're building compared to every other program that's ever been written. You know, it might just be the color of the UI, but it's still unique. So that I think is a really key aspect.

And Henry just made another interesting aspect. He said that devs are also asking to learn only what they need to get a job. Nothing, nothing more, nothing counciliary. So and to be honest, to some extent, I really can't blame them. I mean, if you're a junior looking to find a job and there's just so much to learn, you know, it's kind

of you know, it's easier for us than extent the senior. We've seen it all, but you're just coming into the field, and so many devs have so little experience, you know, like I don't know, like the median experience is like what two three years? So, you know, how do you deal with the quantity? How do you prioritize? Yeah, that's a great question. And I thought about this one before this, uh this recording, and I think it I think that really is a practical question.

If you do not prioritize based on social media, please, because social media a thank you thank you. Yeah, where is it on the hype cycle. It's right at the top. Go for it, Yeah, exactly. So the funny thing is, if you're on social media, you will be led to believe that all one dev jobs is building new stuff on the latest and greatest thing. If you've actually been a developer for any good period of time, you'll realize that a good portion of your job or jobs out there

is maintenance of things that already exist. I have a course. My first course I ever made was on a JS, not Angular Angular JS. Do you know that course is still popular? Why is that course still popular? Because there's a bunch of Angular JS apps out there that need maintenance that people aren't rebuilding yet, that are probably very important to some company. So the prioritization is basically what jobs are available and what are you going to be working

on in those jobs. So, yeah, there's plenty of React jobs out there, right because reacts been around a long time, not because React is the latest and the greatest. It's just there's a lot of existing software or existing tooling. But you may look up a job and it's something that's not the latest and greatest, and that's okay, you know, if you were to post it out there on social media, they might say, oh, well, you're going to be hurting yourself in the future for future jobs and

things like that. My response to I need to know this latest and greatest abstraction in order to get a good job is show up your fundamentals, because if you show up your fundamentals, you can learn anything, any abstraction on top of the fundamentals. Amen. Yeah, I always look for that whenever I interview. I'm looking for a person that has a good grasp, that

has the capability to learn. You know, the fact that you happen to memorize a particular technology is a lot less interesting for me than your ability to, you know, learn new stuff as it comes your way. Yeah. I'm also a Spanish speaker, and I learned the language as an adult, and so I kind of relate it. I think Steve was mentioning it.

You may not know every word in the Spanish dictionary, you may not know the entire vocabulary, but if you understand conjugation and sentence structure, you're going to be able to add vocabulary very easily. But if you just memorize words and phrases with no concept of sentence structure, you have a much harder time. So getting the fundamentals is your sentence structure, your grammar, it's your grammar of the web. And now all of these things, whatever framework it

is, and you know, maybe like one over the other. It's fine. It's about ergonomics and about how it works and its goals. Great, but it's still just an implementation, right, It's still just vocabulary on top of the grammatical structure of the web itself. Yeah, but what fundamentals looks less appealing in your in your resume than yeah, I want to add a couple of things to this, so you know, to the spoken language example, I took French for six years in junior high in high school, right,

and I was fairly proficient. My grandmother was French, and so I would go practice with her. I'd just sit and chat with her. And I wasn't great at it by any means. But the fundamentals are the same in all of the Romance language is Likeanish or Italian. And when I was eighteen, I got a call from the church to go serve a mission in Italy, and so you know, I went to a missionary training center and they taught us Italian for eight weeks and then you know, dropped us in

the middle of the country where you realize you really didn't know Italian. But the point is is that because all of those concepts were the same, I picked it up a lot quicker than a lot of the other people, because you know, it didn't matter that I had spent all the time doing react Romance language. Right, I could pick up view or you know, French and learning Italian. And so it really does help because the more you see and the more you have some of the similar problems solved. Yeah, a

lot of these pieces fall into place. But the other thing is is that and this is to your point of what are you going to use right? I knew for two years I was going to use Italian because I was going to live there, right, and to a certain extent, though, I also want to extend this to what you want to eventually be using right. And so some people they're just like I've coached I don't know how many people

right. And one poignant example that I had there was a guy that was working for a company and he's like, look, this is a great company, but they're using x JS. I don't even I don't know if you guys even remember it. It's this oldish framework. It's kind of got some dot net roots. It was really clunky. I did a little bit of work in it way back in the day. And anyway, he felt stuck, right because he knew that nobody else, right, finding another job using

x JS was just not going to be a thing for him. And so that's where I was encouraging him. Okay, Right, So if you're working in Angular JS and you're like, well, maybe my next job will be Angular like Angular fifteen or sixteen or whatever they're on now, right, go learn it, right, Go learn it and then and then you can parlay that into that next position that you want to be in. Make that your current position, right, And I encourage people to do this all the time.

I want to be a well known developer, all right, well you know that's not a programming framework, but go to toast masters, right. Or I want to write a book, okay, well, start writing a blog every day and start building those skills. Right. This applies to everything. But the point is is that you know, it doesn't just have to be what am I going to use? But what am I going to use? In the next stream job that may be what you're spending some of your

time on. Yeah, one hundred percent. It's the job that I have and the job that I want, basically, right, And so the be open I say, when you show up your fundamentals, you can be open to any job that you have because it's always going to be building on those fundamentals, and it'll make it easier to have the time to learn the thing for the job you want, right, because your time is limited, right, and if you have whatever your personal circumstances are in order to make best

use of that time. Let's say I want to learn whatever the new thing is, and I don't use it at my current job, but that's where

I want to eat. Okay, how quickly can you learn the new thing will depend on how good your fundamentals are and then yeah, and then so it may take you months versus literally weeks, right as far as a difference or days in some cases, because you can just look at it and go, oh, this coder did a thing, and essentially you sit at the level of the person who invented it, instead of sitting an abstraction layer above

where you don't really understand what's happening. Another illustration I like to use is that of a drain. If you drop something down the drain in your sink and you have no mental model of how plumbing works, it's like, oh, well it's gone. But if you understand how plumbing works, you might have a chance of getting to it. And if you're a guy that works for the city and understands how the whole sewer system works, you have an even better chance. Right. So it's it's how how long will it take

you to retrieve the thing? Depends on your mental like the depth of your mental model. So learning and implementing anything is just time. And and these frameworks have a lot of crossover. These concepts are not like one hundred percent unique to every framework. They're implementing it in different ways. There's different quirks, there's different uh everybody. Yeah, signals. Signals is a great example. I want to learn solid yes, or I want to learn signals an

angular or quick well you can learn if you know JavaScript. Well. Signals is just implemented in JavaScript. It's not a new web technology. I mean, there is a proposal now for signals in the browser, but uh, it's it's just some JavaScript code. You could make your own signals. Now you know, maybe you probably shouldn't do that because other people are doing much more robust ones. But if you understand it conceptually is just other people's JavaScript,

you can learn any of this stuff much quicker. Yeah, all right, Well we're kind of getting toward the end of our scheduled time. Is there anything else? Like? I'm just thinking, you know, something that is fundamental to understanding how do I learn? What do I learn? That kind of a thing that we haven't touched on yet. I think, honestly, I think curiosity is and I mentioned it before, but I really do think curiosity is the differentiator. You're going to ultimately do better the more curious

you are as to how something works. And because the more curious you are is how something works, the more motivated you'll be on how something works. So working on building curiosity usually comes from experience. You know, the first time you break something down and realize how it works and you get that huge light bulb, that's addictive. You're going to want to go back to that feeling, and so work on you know, even if you're not motivated too

much, try it for something. Some aspect of something you use in your work every day, feel that light bulb moment and that will help you go back to it again. I love it, honestly. That curiosity makes it more fun anyway, It's true, all right. One of the main reasons that I love this field that we're in is that it's like solving a riddle. Like every day people are paying me to solve riddles, and that curiosity and that sense of accomplishment is something that I'm really addicted to. Yeah,

and the riddle is cross discipline as well. Right, I'm the director of education for a company called the smythe group s Myth, and I work with a lot of these people for a long time. And you have devs, and you have user experience, and you have dev ops and you have all

these things, but getting all of it to work together well. And that's another aspect of understand and learning tech is the more curious you are, the better your team dynamics will be, the easier time you'll have interacting with other people on your teams, including other developers and other disciplines. It turns into less of this kind of vague notion of how things work, into a complete notion of how things work, and that actually makes it easier to have nice

interactions, enjoyable interactions with your team. At least that's that's my experience in my work with those folks and my work over the past, you know, over many years. It just has a it just is beneficial overall. So before we stop, I think we owe it to Henry's made of so many

excellent comments throughout this episode. He raises a question specifically about the WordPress community, but you might apply it to anybody who's working within legacy tech, Like, is the WordPress community curious or is you know, if I'm like kind of unquote stuck in some legacy framework, how curious am I? It's an interesting question. I think my experience is that your curiosity will yield less stress

and faster production as a as a developer. So even if you're let's say a WordPress and I've seen this happen, you're using some kind of CMS and you're kind of stuck in that place, but you can be the person that figures out the problem really fast. For example, and you might have a CMS where other people are writing content and you're kind of working on the tooling for them to write that content, and the widgets and whatever else, and

they manage to do something that just breaks a page. The curiosity comes in now or again with the fundamentals. What's happening with the CSS? Can I make the HTML more cement and accessible while I'm doing this? What is WordPress generating? What are the problems with the way WordPress generates HTML? How can I maximize my use of it? There are places you can find that I've

seen it happen. Right. You can be a dev in a situation like that, and it's maybe not the latest and the greatest, but you can still say this is still somebody else's code, This is still somebody doing something for me, and I can still see these problems not as these huge frustrations, but as opportunities for me to step an abstraction layer below and figure out how to solve these problems much more quickly, because these problems are my stressors,

Like I don't want to be spending my time with these problems. So another way of saying it was figure out what your stressors are in these technologies, even if their legacy, and be curious about how to solve those stressors more quickly. And I would like to add to that is that in some case says, you know, if people are just looking to deploy something and then move on, it's a legitimate approach, but it becomes a race to

the bottom because you're dispensable. There's nothing unique about you. On the other hand, if you're that person who is able to delve deeper and be able to solve the sticky problems and be able to integrate those legacy technologies, for example, with some new stuff that's coming out that gives you an amazing leg up. I knew this guy like twenty something years ago. He was one of the last AS four hundred developers. Like certainly in Israel, but probably

in the world those of you are not familiar. It's this legacy system from IBM was really popular back in the day, but then kind of fell off, as you know, as the PCs replaced it. And he just he didn't just understand AS four hundreds better than anybody else. He knew how to integrate them with new and modern technologies. So organizations that had AS four hundred systems when they brought him in, it was beyond just keeping the lights running.

It was also a stepping stone to the future. He would show them how they could take their existing system, integrate it with new services and capabilities that would eventually enable them to actually move off those as four hundreds into those new technologies. But along the way he made a ton of money. Yeah, and this is an excellent point. And I've seen this multiple times.

Somebody will in my own coursework, I always try to teach fundamentals up right, and so somebody will come to me and something as satisfying for me as somebody will say, I went to work, I didn't really get if what you were teaching me was useful. But I went to work the next week and I was able to solve this problem super fast. And the thing is that when you're the person that solves the problem faster, there's no guarantees,

right, there's no guarantees on jobs. But if I'm the boss and I'm looking at a dev team and one of my members of that dev team is the person that bounces around and quickly helps people figure out problems because they're so good at understanding what's actually happening, integrating old systems, all of these things, they're they're fundamentals up. That's not the first person probably I'm going to

think about when the company has economic difficulty to start laying off. Again, no guarantees, but you do help you help your There's a difference between getting a job and keeping a job, and maybe that's the big that's to me as kind of like the clincher. People are so worried about the getting a job, but all of these things that we're talking about help you keep a job. Yeah. I want to throw one more thing in, especially on

the WordPress question. Right. So, I've I've gone through a bunch of iterations with top top end devs, and we've been on WordPress twice and the second time I actually had to write a plugin to manage having multiple podcasts on the same system and all this stuff, right, And then I've also worked

with other organizations. Right. So right now I'm the vice chair for the Utah County Republican Party and our websites on WordPress, right, the state parties the website is also on WordPress, incidentally, and I've been doing some stuff with that, right, And so what's really been effective there? Yeah? Am I doing anything technically innovative? No, But these organizations that have gone from we just need a web presence, right, which is where a lot

of people reach for WordPress. Right, So they reach for WordPress and it's okay, I put up a theme, I filled in all the blanks, and I have a website. Now it's hey, how do we engage people? How do we serve the people who need our resource versus how do we write? And so it's much more of this communication and marketing problem than it

is a web and technical problem. And so the innovation and the innovation curious thought is as much how do I put something in front of people that's going to give them what they need as it is how do I find the right plugins or combination of things or write my own code to effectively do what needs to be done. And so the curiosity doesn't have to look like I'm not using plugins, I'm running my own code. It doesn't have to look like,

you know, I'm doing things the way everybody else does it. You can do everything the way everybody else does it, but because you have a unique grounding in your problem or in the thing they're trying to solve, whether external or internal, and you can be curious about, Okay, how do

I take this to the next place? And what that may mean is that you start picking up skills beyond the technical skills, right oh, it's okay, what's going on in the wider world of marketing, what's going on with the wider world of outreach, prospecting, sales, you know, whatever other

function this WordPress site supports. And then you start coming back and saying, okay, now what are the solutions, and your curiosity technically might be there are eight different membership plugins that I can use, which one best fits my problem? And then from there it's okay, well, how can I make this better fit my problem so that it works best for the people who are going to use it? And so, yeah, you're not out there reinventing

or inventing some new technology. But what you are doing is you're finding that novel way of solving the problem with the tools that already exist that now that you understand the problem better, right, you have all the pieces to bring together, if that makes sense. And I've spent many years straddling the line between user experience, design and development, and that is really the sweet spot. I think. As a developer, what we're there to do is solve

problems. We're not there to try to figure out the code to work. Like the code working is part of the job, but you're actually there to solve the problems that the software is solving. So even if you're in a legacy system, get to know it really well so that you're spending most of your time with Hey is it accessible? Hey is it Oh there's a problem that they're trying to solve and they can't figure it out. I know that we can solve this problem this way. And it's not about implementation, like

how can I do it in the code? It's more about what's the right solution to solve that problem, and that can be very satisfying. Absolutely. Yeah. Already asked also what to do when the plugins create technical hurdles? And I don't know exactly what he's seeing, but what I've seen, especially in WordPress, is that sometimes your plugins conflict, right, and so then you get unexpected behavior, and that to me goes right back down to those

fundamentals, right, Yeah, how does WordPress work? How does it put this together? How does it load the plugins? What order does it load them in? You know, how does it execute the code that comes in the plugins? Right? And so when you understand those then it's okay. So what's probably happening is is I'm seeing this functionality stump on that functionality. And now that I understand how everything goes together, here's why it's probably happening.

Yep. And it goes back to that initial question, right, It's not what and how, it's why, when, what and how? And if you can answer all those four questions, your development life will change. Yeah. All right, we're we're really getting up to our hard stop. So I'm going to push us over to picks. This has been awesome, Tony. Before we do picks, where do people find you online? Uh? Okay, So Anthony aliseya dot com A L I c e A my

new chorus. You can find an understandingreact dot com if you want to spend that time with me. I put a js Jabber coupon in there for for people too. And the smythe group dot com s m y t H is the company that I'm I'm working with as well that helps devt be their best selves. Some interesting things there. Yeah. So those three planes, and then on Twitter, I'm Anthony p if he is in Paul or Peter, i'lly say I al I see a awesome all right, we're gonna do the

picks. We'll let you go last that we can kind of see what we're talking about here. I have a joke for Steve before he does his picks. And I've heard this one before, but somebody told it and they thought it was hilarious, which made me think it was hilarious again because they were just laughing about it for like twenty minutes. But the joke is, how do you catch a unique rabbit? Can I give you an answer? Yeah? Unique up on him? How do you catch a tame rabbit? Tame

way unique up on him? Yeah, exactly. All right, go ahead, Steve, what are your picks? Okay? I have one pick one dad joke for today, and it's a little longer one, but it's well worth the wait. So there were three kingdoms, each bordering on the same lake. For centuries. Those kingdoms had fought over an island in the middle of that lake. One day, they decided to have it out once and for all. The first kingdom was quite rich and sent an army of twenty

five knights, each with three squires. The night before the battle, the knights jousted and coborted as their squire's polished armor, cooked food, and sharpened weapons. The second kingdom was not so wealthy and sent only ten knights, each with two squires. The night before the battle, the knights caborted and sharpened their weapons as the polished armor and prepared dinner. The Third Kingdom was

very poor and only sent one elderly knight with his soul squire. The night before the battle of the knight sharpened his weapon while the squire, using a noosed rope, slung a pot high over the fire to cook while he prepared the knight's armor. The next day of the battle began, all the knights of the first two kingdoms had coborted a bit too much. One should never covort while sharpening weapons and jousting. Illd on I gonna eat my sound effector,

and could not fight. The squire of the Third Kingdom could not rouse the elderly knight in time for the combat, so in the absence of the knights, the squire spot the battle raised well into the late hours, But

when the dust finally settled, a solitary figure limped from the carnage. The lone squire from the Third Kingdom dragged himself away, beaten, bloodied, the victorious, and all that just goes to prove the squire of the high pot and news is equal to the sum of the squires of the other two sides. Oh man, wow, that was a long row to hoe, but well worth it. That amazing And I got one more. Sorry, Tony is dad jokes. But so interviewer says, forget everything you learned in college,

you won't need it working here me. But I didn't go to college, and he said, well, then you're unqualified for this job. Yeah, that's too close to the truth for me to laugh at it. Anyway. So I've got two picks. I'll start with the first one is this show that we're watching on Netflix. It's called Ripley. It's spelled our I p l e Y. It's really interesting, kind of out there. It's

black and white. It's about this grifter in the sixties that goes to Italy to you know, on a mission for this wealthy family to return their kind of wayward sun. And it goes into really odd and dark places. But you know, it's it's it's really interesting. We're joining it in, but it's it's kind of out there. So it's, like I said, it's

called Ripley. So that would be my first pick. My second is I mentioned the fact that you know, yesterday as a time of this recording, Iran fired a bunch of rockets, well actually missiles at Israel, so something like one hundred and seventy something like like one hundred and ten ballistic missiles, some cruise missiles and whatnot, and Israel was actually, with the help of others like the US and Jordan and other countries, was able to actually shoot

down the vast majority something like ninety nine percent out of all the rockets fired, something like seven made it in. And the reason that I'm kind of mentioning it in, you know, the relation it has to me is that when I served in the army, I was actually in the Israeli Army. I was actually heavily involved in the experiments for the arrow anti ballistic missile. So actually shooting down the ballistic missiles. You have like a layered defense system.

You use different ways to shoot down different things, like the drones or the cruise missiles, but for the ballistic missiles, you actually want to intercept them in outer space possible, which is kind of pretty amazing. Think about

that. You're you're you're shooting down missiles in outer space. Uh and uh, like I said, I was heavily involved in the in the UH, the test for the UH for the arrow Anti Missile Experience missile and now it's really gratifying to see this, you know, protecting my country and saving lives. So you know, that would be my my second pick, although I'm not sure what I'm picking, and uh, those are my picks for today. Yeah, as a freelancer, sometimes my projects don't ever get used.

I guess it's pretty gratifying to seeing it used in that way, on that level, So that's awesome. I'm gonna pick. I've got a bunch of picks today, so I'm just gonna just work through them. My first pick, I usually pick a board game or a card game. This one's a card game. It's called Doomlings, and it's kind of loosely based on kind of genetic genetics. So you have different traits. You have trade cards that

you collect. Is effectively how you win. You get however many points they say they're worth at the end, So some of them it's this is worth one for every one of them you have, right, so if you have twelve, then you get twelve points. Some of them it starts as worth seventeen points, but every trade card you have diminishes it's worth by one, right, and so then you're trying to play other trade cards that allow you to discard trade cards that you have or play them on other people or things

like that. Anyway, and there are different colors, and so some of them give you bonuses for having more of one color than another. Some of the trade cards allow you to penalize other players. And what you do is effectively, you have three catastrophe cards in the age deck, and so every time you hit a catastrophe, it has some effect, right, so you have to get rid of one of your trade cards, or you have to get rid of one of a certain color, and it usually decreases your gene

pool, which is your hands. And then at the third catastrophe, whenever it shows up, the game's over and you do the game end effect on that card. Unless somebody has something that totally this is getting complicated. That's the whole game. That is the whole game has a board game weight of one point seventy five. So it's pretty easy to pick up for a casual gamer. I mean, and I basically just told you all the rules right

there in like one minute. Yeah, it sounds a little complicated altogether, but if you sit down and play through it once, it's it's pretty easy to pick up. It's definitely something that I think my eight year old could play, though I don't know that she'd really get the interplay between some of the trade cards, but yeah, anyway, it was a fun game played with my twelve year old. We had a good time. So I'm going to pick Doomlings, and then I have a couple of other picks. One

of them is an app. And this is one that my wife and her friends were playing with each other and then she got all my kids on it, and so I got on it because I wanted to participate with them on it. It's called Finch and it's a self care app. And so what you do is every time I get into it and ask me how I'm doing right, how motivated are you? Or how do you feel right now or something like that, and then you can put a bunch of tasks in.

And they're usually supposed to be self care tasks, but I've been putting tasks in for things like do an hour of sponsorship outreach or do an hour of just regular developer outreach. I usually do both of those on LinkedIn, or you know, my truck had a bunch of garbage in it, so it was remove at least one piece of trash from the truck every day, right, And then you get points for that, and you send your Finch on adventures and he grows up and stuff like that, and you can send encouragement

and things like that to the other people that you're connected to. And so anyway, if you want to pick it up, it is I think it's Finchcare dot com. Yeah, Finchcare dot com. It's an iPhone and Android app, and I'll put the link here in the comments on YouTube and Facebook. And then if you want to add a friend to your they call it your tree town, you can. You just have to have their code.

So I'm gonna put my Finch code in then as well. And so if you get Finch and you want to add me to your tree town, right, so that you can send me encouragement and I can send you encouragement. In order for me to be able to do it for you, you have to send me your code too. But that's fine. You could just email me or something and I'll add you to my tree town. I don't particularly care, but yeah, So it's just kind of a fun way to be friendly to other people. And so I'm going to pick that. And then

I've decided that I'm going to run another marathon this year. It's been about five years since I ran a marathon, and so I'm using a system called training Peaks. It's free. They do have a paid version, and it gives some features that are kind of nice. I used to have the paid version, but I don't anymore. And then the nice thing about training Peaks is you can go and buy a training plan. So I already owned a

sixteen week training plan for marathon, and so I plug that in. The marathon I want to run is Saint George and that's at the beginning of October, and so sixteen weeks is the middle of June. And so I just picked up another plan for five dollars. That's a ten k plan and it's an eight week plan and so it finishes and then I have a week one week break and then I get right into the marathon plan. But it just gives me that workout, so I go do it. And so, yeah,

so I like to go out for forty five minutes. My first workout's thirty minutes. So I'm gonna go walk for fifteen minutes and then run thirty the thirty minute workout that it gives me. So anyway, really dig training peaks, and so I'm gonna pick that as well. It's just a lot of I guess self care, live your best life kind of stuff. And then the last pick is seventy five hard. I'm gonna do that again.

I've done that like three or four times now and it's awesome. There's a full live hard program that comes on after it, so you do the seventy five days and then you can do the other three phases. Last year, I made it through phase one and just had trouble getting started again because there's

a mandatory break between phase one and phase two. And so I think this year, I'm just going to keep doing the stuff even though I can't track it for the thirty days, and that way, when I get back into it, I'm not so out of practice on the habits that right that I can just stick with it. And I think that's kind of the idea is you know, even if you slack off for a little while, you have

the discipline to get back on and go. So I'll put links to Training Peaks and seventy five hard in the in the comments, and we'll let Tony share some picks with us. Yeah. Well, you guys usually mentioned some board gaming stuff. I'm a big board gamer. I'm also a tabletop RPG game master, so I wanted to give my picks on Let's be friends. I want to get my picks on high to get into it or get your

family into it, kids friends. My favorite real quick for board gaming Forbidden Desert by Matt Lee who who did a Pandemic, and other games like Forbidden Island. There's a new one, Forbidden Jungle, but Forbidden Desert is still my favorite by far cooperative game. You can tell a story with the kids. It's fantastic and the game is very different every time you play. So let's a stand out of that game. Yeah, so love that. And then when it comes to tabletop RPGs, if you want to get into that

two recommendations, there's something called Fate Accelerated Edition. Fate is a tabletop structure. Accelerated Edition is a very fast, easy way to run just about any story you want to run with some dice. There's even a bunch of kids RPGs that are built on top of it, but it's also great for adults, so Fate Accelerated Edition FAE is great. And I also highly recommend Tales from the Loop, which is absolutely fantastic. It's like free music you can

find online that goes with that. There's great imagery that you can use with it. But it's basically kind of like a cross between Stranger Things and The Goodies where your kids solve the mysteries. Absolutely wonderful RPG Tales from the Loop, and there was also a TV show. It's based on some art some artwork and things, but the RPG is is absolutely fantastic way to get into it. So those are my picks. Awesome, I kind of expected you to pick gloom Haven or something, you know. I am. I like

my big heavy board games. I'm a big assertive guy. I've actually I have some stuff out there I've built. If you go to games with Tony dot Com, I've I've built helpers and solo modes and stuff like that. But I am I really love certain themes. I love sci fi, Okay, I love adventure. Those are themes that really appeal to me. Awesome. Yeah, well, next time, we're both at a conference. We'll have to fit whatever game we can in our bags and see how it goes.

Sounds good, all right, Well thanks for coming. This was fun. Yeah, I had a great time. Thank you for inviting me. Yeah, it was excellent. Thank you very much. All right, folks, we're going to wrap it here until next time. Max out