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