How We Learn

We look at the techniques that helped us learn Elm and that help us continue to learn new techniques today.
December 6, 2021

Ideas for Effective Learning

  • Have a playground to try out ideas
  • Try a new tool or technique with a familiar problem or exercise
  • Small scale exercises and real world projects
  • Small scale exercises are helpful for quickly developing a skill
  • Feedback loops
  • Tiny steps shorten the feedback loop
  • Use code katas like bowling, tennis, roman numeral katas
  • Analogous to empirical scientific method (hypothesis, test, analyze)
  • Call your shot
  • Don't forget to analyze test results after
  • Listen to smart people, but come to your own conclusions
  • Try two alternate ways of doing something out for yourself
  • Failure is part of learning
  • Follow your curiosity
  • Look at the source for projects you depend on or come across
  • Growth Mindset vs. Fixed Mindset
  • You have to make knowledge your own (synthesis) - connect it to what you know
  • Just in time vs. just in case learning - focus on what you need or seems important now
  • Flexbox Froggy game
  • Demystify things (for example custom type constructors vs type alias constructors)
  • Mind mapping
  • Elm Radio Opaque Types episode
  • Zettlekasten second brain
  • How to Take Smart Notes book
  • Make declarative statements in second brain system
  • Dillon's use the platform note from his digital garden
  • Digital gardening
  • Learn in public movement
  • Richard Feldman's talk Scaling Elm Apps
  • Richard experimenting with dream writer in a component architect
  • Make It Stick book (and some notes summarizing key ideas)
  • Elm Radio API Design Lessons episode
  • Let your background processing do some work for you
  • Dan Pink's book When
  • Early bird vs night owl thinking
  • Jeroen's blog


Hello Jeroen. Hello Dillon. And what are we talking about today? Today we're going to
talk about learning. Ooh yeah, I love this topic. So we recently talked with Richard Feldman
about learning Elm, or teaching Elm actually, and now we're going to talk about learning.
Other side, yes. So, all right Jeroen, I've got a question for you. How did you learn
to make impossible states impossible? Do you recall that experience? I'm guessing it was
earlier in your Elm career? Yeah, definitely earlier. First of all, it was Richard Feldman
who taught me that in his talk. Yes, introduced the concept, gave it a name, which is very
powerful. Coining a term is very powerful for learning. But I did not know it before,
that's for sure. I didn't, it wasn't on my radar either before that talk. So it wasn't
even something that I was trying to do. But I was not even doing Elm at the time. So when
was the talk again? 2017? 2016. 2016. Okay. So 2016. So I did not watch it in 2016, I
think. I watched it later on. But how did I learn it? I guess I was just trying to reenact
whatever Richard was saying in his talk, and thinking about it, and then put it into practice
in some of my projects, like thinking about what can go wrong in some particular model,
and then trying to make that impossible. I'm not sure what more I can tell you. Yeah, I
think, well, that's pretty similar to my experience. So I think conference talks are such a powerful
learning tool. But similar to your experience you just shared, in my experience, I think
that conference talks are only as useful as you're applying them to your own context.
So that's part of the equation. So I remember when I was learning Elm, I think I started
learning Elm around 2017. So there are a lot of great conference talks out. And I think
I started learning Elm around when the ElmConf 2017 talks started coming out. So I had this
fresh batch of new great talks coming out. But I went back and watched all these talks.
And I was building my first real beyond hello world Elm project. I actually chose to create
a project in order to become better at Elm. And the project was Mobster, which is this
pair mob programming timer tool that I built. It's an electron application. And I built
it because I wanted a fun side project that I could use to explore some Elm techniques.
So the first thing I went and did when I learned about make impossible states impossible was,
oh, what can I do to my Mobster code base to apply this? And so I think that that's
such an important part of the learning process is to have a playground to go apply some ideas.
You can read all the books you want. You can watch an online course. You can watch a conference
talk. Those things are very important. And without those things, you wouldn't know the
concept of make impossible states impossible. And you wouldn't have all these great ideas
about the steps of test driven development and things like that. Perhaps you learned
some things from a podcast, hopefully. But that's an important step. But then you have
to put the fuel in the tank, but then you have to drive the car. And you have to apply
the learning somehow.
I know that a lot of people, when they try to learn a new language, they redo projects
that they know or that they have written before, but in a new language. So you're familiar
with JavaScript. You want to learn Elm. Do the same project in Elm. So you won't get
stuck by the same issues. You don't have to restyle everything. You don't have to think
about database interactivity interaction. I mean, so you don't have to deal with all
the problems that are not language specific. Right. So you only the only thing that is
different is the language. So whatever you will learn is language specific.
Yes, you can learn on one dimension because the dimension of solving that particular type
of problem and getting data from some back end and all those types of things you've done
before and you're familiar with. Yeah, I've used that technique a lot actually. I really
like creating focused exercises to apply learning. I think these are two different interesting
contexts for learning, which I think are both important. There's the small scale exercise
and the real world project. And I think they both play a role. I think that small scale
exercises are very good for developing a skill. So one of the most important things about
learning is the feedback loop. So, you know, what does that mean for learning? It means
that you have a way to tell is the technique you're working, is the technique you're applying
effective? Do you like it? Do you like how it looks? Is it solving the problem you expected
it to? Is it breaking your code? Is it introducing a bug? If you don't know those things, you're
not really learning. If you just start trying to do make impossible states impossible and
you're applying it in a context where you don't really know if it's solving the problem
you think it's solving, you're not very familiar with the types, it's a little bit over your
head the area you're experimenting with, you're not really learning. So you need that feedback
loop. And having very small scale exercises and problems can be good for getting that
very tight feedback loop. So I think creating a focused exercise for learning the specific
thing you're trying to do might be like, I'm going to make a to do list application. I'm
going to create this storefront with the UI and I'm going to try that with Elm UI and
with Elm CSS.
I remember that Richard in his Elm in Action book. So from start to finish of the book,
you write an Elm application, but you do it so in chunks. So you do a pretty short exercise
in each chapter. So same idea, I think.
Right. Yeah. Having a focused exercise with a clear goal is so useful. And I mean, as
we talk about often also breaking it down into tiny steps and tiny commits, that's another
thing that increases the feedback loop. You know, if you're taking big steps, changing
a lot of things at once, then it's hard to evaluate the technique you're applying.
Yeah. Like what I have, what I've just done. Yeah. I did too many things.
You did too many things. And if you're doing, if you're trying to learn, make impossible
states impossible, that philosophy, and then you are also fixing a bug somewhere and changing
something in the UI and like you're diluting that learning. So doing too many things at
once doing too big of steps, all these things that lengthen the feedback loop, they're diluting
learning. So I think that's a really core point that just keep in mind when, when you're
learning, are you giving yourself a nice feedback loop? One of my favorite things to do when
I'm learning a new technique or a new language is to do a test driven development exercise,
you know?
What kind of thing do you then do?
You know, the bowling kata where you're doing bowling or like tennis kata where you're doing
a tennis scoring system or Roman numerals kata. Kata is that, you know, I've done hundreds
of times, but applying it, let you know, as you were saying earlier with applying a familiar
problem with a new concept or technique. So that's, that's one of my favorite techniques.
If I'm just pull out a test room and development exercise. And that is one of the best feedback
loops you can imagine because you have a very simple exercise. You can experiment, you have
tests to tell you if your experiment is safe or not.
You also learn how to do right tests in that language.
You also learn how to write tests, which is very important as well. Yes, exactly.
Which may dilute the learning a bit, but it's in its own step, I guess.
If you're trying to do too many things at once and test driven development is unfamiliar,
then it may be too much. Then maybe you should do some test driven development exercises
in a familiar language. Yeah, absolutely. Absolutely. But whatever you're doing, I think
if you just keep in mind, are you, are you setting effective feedback loops for yourself?
I think that's, that's essential. Another thing I've noticed, I used to run a learn
to code meetup in my hometown here and and we'd get a lot of, you know, people who were
self taught or bootcamp graduates, that sort of thing, which was great. And I saw a lot
of, you know, a lot, a lot of those people ending up very successfully having programming
careers and, you know, being just as good of a contributor to the team as somebody with
a university degree, right? But the thing that I noticed that people who didn't go the
university route struggled with the most was I think that the university programs can drill
into you doing these exercises and sort of you're learning a specific technique. You're
learning how to write a linked list. You're learning how to do memory management. You're,
you know, learning these techniques and you say, hmm, what's going to happen if I do this?
What's you know, what happens if I have a memory leak? And then you see what happens
if you do, you see what happens if you don't. There's this scientific method. There's this
like empirical approach where you sort of are doing a tailored exercise where you have
a hypothesis, you create an experiment to test that hypothesis, and then you evaluate
that hypothesis. And then you learn that you're wrong. And actually learning that you're wrong
is just as important as learning that you're right. If you only learn that you're right,
then you're missing out on all these things you could learn. Yeah. It's almost better
to be wrong, but you need to be right sometimes. Otherwise you're never learning. Well, if
you're always wrong, I guess you could always just flip it and say, yeah, you always know
how to be right. It's just not what you initially think. Should I write a let or a const? I
should write a let. Okay. Let's do a const. There you go. There you go. Yeah. So I think
that scientific approach is it's sort of built into the curriculum in a lot of, you know,
university programs, whereas people going through boot camps or self learning, often
it's more just, you know, going through boilerplate for a rails application or react application
and trying to figure out, trying to find the needle in the haystack that gets things working.
And it's not as much like these focused exercises. So sometimes they don't learn those skills
of like, what do I expect to happen? How would I know if what I expect to happen happened
or not? And then importantly, doing the final step of evaluating the results, what actually
happened. So, so I think that like calling your shot. So let's take the example of making
impossible states impossible. You know, what do I expect to happen? Well, I expect this
particular state to not be possible. How would I know? Well, if I try doing this thing, I
constructing this thing and it doesn't have at least one of these items, then that should
be invalid. I should get a compiler error. And then you try that, right? And it seems
very basic, but I think just setting it up that way is so important. So, so a lot of
these, you know, self taught and bootcamp students, I would sort of give them that advice
to, to slow down when you're learning something, instead of just trying a bunch of things,
slow down for a second and, and say, what do I, what do I expect to happen here? How
would I know if what I expect to happen has happened or not set up some mechanism to evaluate
the success of the experiment and then actually do that afterwards. I think that's one reason
why TD might be very good for learning, as you said before, because every time you, you
save where you start running your tests, you kind of call the shots. Okay. I think this
test is going to pass and that it's not going to break one of the other ones. And you get
very rapid feedback telling you that no, you messed it up and things didn't go as you expected.
And maybe here's why, or you need to figure that out. Right. Then in any case, you're
learning something.
I totally agree. And, and in addition to, you know, giving you feedback to evaluate
whether your experiment was successful or not, you know, TD has this sort of set of
ideas for breaking the work into smaller pieces, like doing the simplest thing that could possibly
work, which means you're not doing a hundred things at once. You're doing one thing at
a time. And so you're better set up to evaluate your experiments.
Sure. I guess when you're learning, you don't know how to cut things as small as you could
be, but yeah, definitely.
Yes. Right. It is, it is difficult, but also just, um, yeah, I mean, applying one technique
at once is really valuable. And like, I, something that I have found myself doing a lot from,
from the time I was learning Elm to now is having a technique I want to experiment with,
you know, Phantom builder technique. Wow. How would, how would that work? And would
that work nicely in application code or just in package code or, you know, I think it's
so good to be curious about those things.
And even if someone smart tells you that something is a good idea, you're in, you're a smart
guy, but I think that we should come to our own conclusions. None the less.
Yeah. This is something I keep telling people, and I've mentioned this on podcast before
when some people argue whether they should, or are still undecided whether they should
try pattern a or pattern B to do something like, Hey, should this be a maybe, or should
this be a new custom type?
I just tell them, try out one of the ways, the one that you feel most comfortable with.
And then if it works out, great. If it doesn't work out, you will know soon enough. If you
are, keep curious and keep wondering about it, keep reflecting. And then when you find
finally feel the pain, then you know that you've, it wasn't the right choice.
Yes. And that's a win.
And that's a win. And thankfully with Elm at least, it's easy to backtrack. So Elm is
a great language to, to try out things, be curious and then fail.
But then we factor and get it right.
Or writer.
Because you might not find the right solution right away either.
That's a good t shirt. Be curious and then fail, then refactor and get it right or writer.
Boom. T shirt.
Yeah. Do you want me to get it longer or?
Yeah. It might be a, it may be a tall vertical.
Right. It's also in the back. But I mean, being curious is part of the scientific method,
And if you're wondering about the effects of something or the causes of some of something,
then you're not really going to figure out new things or learn a lot.
Yes. And you can't bypass failure. So, you know, you should, you should celebrate the
failure because it means you're learning. Like if you, you know, like really, if, if
you're like, why can't everything just be maybe in my model? Why not? Well, great. Like
don't let somebody tell you that having too many maybes in your model is a code smell.
If you're like, why, why couldn't I just have everything be a maybe what's wrong with that?
And then I'll just do maybe with default a bunch of places, try it, try it. Maybe try
it in a side project. Maybe try it in a place where it's low stakes to fail, you know, don't
go change the production code base to have everything suddenly have a maybe everywhere
and make your coworkers unhappy, but try it in a, in a safe place.
Yeah. And reflect on it at some point.
Exactly. Exactly. That, that's, that's the other thing is like people forget the last
step of the scientific method. They forget to evaluate the results. So don't, don't skip
that step. That is a very important step. I think, you know, another, another thing,
are you familiar with this term growth mindset?
A tiny bit, but let's let's imagine I don't.
I'm very fond of, of this concept. It's something by Carol Dweck, psychology researcher. She's
written a lot on this. And so the idea is that growth mindset is it's the attitude that,
that you have something to learn from being challenged and putting yourself in a position
where you might fail, that that's a positive thing that you can battle test your skills.
And that might involve failure. And that's a good thing because it means you're grown.
Fixed mindset is the idea that, wait a minute, I don't want to put my failure out there because
then people will see that I'm a failure. And it's basically the idea that, you know, putting
myself out there and failing means that I'm incompetent, not that I'm growing. So it's
the idea that your, your abilities are sort of fixed. I'm good at math or I'm bad at math
rather than, so basically like saying, saying I'm good at math, the idea would be don't
do that and don't encourage other people to do that and don't use language that implies
that. So instead of saying like, wow, look how smart you are, you got an A on the math
test. You say like, wow, look how, how your hard work paid off on this test. You focus
on the reward of, of challenging yourself because it's the idea that your abilities
and intelligence are not fixed things. They're things that can grow over time by going through
challenges and learning. So I think that's really essential to, to all these things we're
talking about because again, like if you're, if you're viewing putting too many maybes
in your model as a sign that, oh, maybe I'm just not good at Elm. Maybe I'm just not good
at data modeling. Well, then you're, you're limiting yourself because you're not allowing
yourself to experiment and fail. Like, and if you think that quote unquote smart people
are smart because they never went through those failures, it's just not the reality.
Like people who seem smart are smart because they try those things and fail. They say,
why can't they, why can't I put maybes everywhere? And then they try it. That's what makes them
smart is they, they went through those failures. So don't limit yourself.
Maybe they also got a good teacher, but you're going to find one as well.
Yes, that's also true. Yeah. And you know, another thing that's been coming up in, in
all the stuff we've been talking about here is I think things need to be hands on. You
can hear a conference talk, you can hear a podcast episode, you can hear some interesting
idea, but like if you hear Yaron give some brilliant summary of the Phantom builder and,
and you follow everything he's saying, that doesn't mean you've actually learned the Phantom
builder technique.
Because I'm a bad teacher.
Right. Exactly. Cause you're a bad teacher.
This should also be a t shirt.
Yeah. You're in a bad teacher t shirt. Yeah. We're going to have to make a lot of t shirts
here. Yeah. So these, uh, like you, you need to take learning into your own hands, no matter
how brilliant an explanation is the way that our brain consumes information is it's just
that it's, it's not about consuming information. It's about engaging with information and making
it your own knowledge. Isn't something that you get from someone. It's something that
you build up yourself with someone's help. So someone can guide you through, but you
always have to make learning your own. You have to internalize it. You have to connect
it to what, you know, to your mental models, your way of understanding things. And there's
just no, there's no way to directly transfer knowledge. And so if you think that you can
just read a book or watch a conference talk and just matrix style, I know Kung Fu it.
So unfortunately not how it works. You don't just install this knowledge in your brain.
You have to, you have to engage with it. You have to, um, you have to like test it out
and be skeptical of it and say like, you know, is this a technique is the Phantom builder
technique like, doesn't it have these problems? Like if you don't ask yourself, wouldn't it
have problems in these situations? Even if it doesn't, if you don't ask that question,
do you really understand it?
Yeah. There's some topics where you don't have to interact with it directly to, to,
to grasp it. Uh, but you're not going to learn it unless you apply it actively. But I'm,
I imagine that there are some topics where you just, just knowing about it and the, and
keeping it in the back of your mind will help you cross pollinate it with other topics and
then give you a brilliant idea at some point. But imagine it's much easier if you make it
it's an active practice.
Right. Yeah. There's certainly value to just knowing that something exists as an idea,
even if you don't apply it. So knowing that Phantom types is a thing and having some sense
that, Oh, it can help you, you know, enforce certain things about types without actually
changing the underlying data that it contains. If you have that concept somewhere in the
back of your head, maybe you don't know exactly what it means or how it applies. Maybe when
you run into a problem around that, then you can apply it. Yeah. So there's value to that.
And then you just delay the practice in a way.
Yes, yes. Right. And, and I think to a certain extent, that's one of the roles of things
like conferences, many conference talks, you know, they're not tutorials. They're not going
to, they're not going to help you master a topic, but they let you know that it exists
so you can explore it further on your own.
Yeah. I think you mentioned that you view them as motivational inspirational, which
I think is a pretty good way to view them.
Yeah. And there's value to that. And if you, if you watch a conference, like I think it's
worth stating just because you need to apply things to learn them, test them for yourself,
experiment all these, all these things. It doesn't mean you need to do that for everything.
No, no, no.
And in fact, I think you should do them for things that seem important at the time because,
you know, Richard was talking a lot about motivation for, for teaching Elm. Well, he
was talking about motivation because he was saying for somebody to learn something, it's
important to have motivation that that thing is meaningful. So this is, this is essential.
Like don't just learn. I think don't learn things just because learn things because they're
interesting and meaningful to you and focus your efforts on that. And if some, something
can always become interesting and meaningful in the future. Don't feel like you just, Oh,
I have to learn SQL. I have to learn database stuff. I have to learn fun. I have to learn
this CSS technique. If it seems important and interesting, then learn about it. If it
doesn't, then there's always going to be some relevant problem, some relevant technique
at the time. Focus on that.
So if you find a practical use of a technique or a concept, then learn it. Otherwise just
go with your curiosity, right?
Yeah, absolutely. Absolutely. I think a lot about like just, just in time versus just
in case learning. And actually this is a problem that I personally have with a lot of university
programs and school curriculums is that they often are learning you. They're, they're learning
you. They're often teaching you a lot of things just in case you need them. Oh yeah. And another
problem often with, with school curriculums is that they don't focus enough on project
based learning. So they're not giving you opportunities to apply the techniques. So
you're just doing sort of exercises out of context. You know, if, if a train is traveling
this speed and another train is traveling this speed, how long will it take for them
to hit each other? And it's like, all right, well, but you should apply that to a meaningful
problem when you need it. And so,
But what if I'm working at a real company, real way company?
Then that's important knowledge. Then you should, then you should learn that really
I wish that my school curriculum taught me that.
I think, I think you would. Yes, absolutely. Yeah. I would hope that would be a requirement
beforehand. So yeah, no, but I think pressuring ourselves to learn things just because I should
know that, you know, once, once you're working as a developer, I think you can, there's plenty
of stuff to learn constantly. So you may as well prioritize the things that are immediately
relevant and applicable. And those are things that naturally have motivation. So you're
going to learn them better because you have a reason to care about them. So they're going
to stick better and you have a place to apply them and experiment with them. So you're going
to be able to actually fully synthesize that knowledge.
So what about things that feel hard? For instance, I have a lot of problems with learning CSS.
Yes. What do you, what would you recommend me as to how to learn it? Because on a case
by case basis, I can learn, Oh, here I need flex here. I need CSS grid and here I need
absolute position. And I can learn that in isolation. I'm going to forget it. I'm going
to learn it again, but at some point it's going to stick, but I still need to learn
plenty of things around it that I don't need right now. And that I don't feel motivated
to learn about.
Right. Yeah. I mean,
Don't tell me just learn L U I.
Yeah. CSS is, CSS is such a, such a challenging one because you really do like, it's hard
to pick one topic to learn because things are so interconnected. You know, but I mean,
I do, I do, I do notice this sometimes when, you know, when I'm learning something and
I'm thinking I'm kind of banging my head against a wall here. Like I need to get a little more
systematic about how I'm learning something. And to be honest, you know, things like flex
box and grid layout and absolute and things like that in CSS are, are something that I,
I could benefit from learning a little more systematically. So sometimes I think we need
to step back from the everyday, just trying to figure things out. I mean, this gets back
to this empiricism, calling the shot sort of thing. If, if we're sitting there going
through these flex box options and just randomly changing things and ho and then we finally
get it working, we're like, okay, good. Then take a, take a moment and read, read a thoughtful
flex box tutorial that, you know, explains things with a clear mental model. Try to learn
a little bit, try to call your shot and say, okay, what set of magical attributes are gonna,
gonna give me the expected behavior? Did that actually happen? If it didn't evaluate, why
not? And then you can learn instead of constantly making the same mistakes over and over.
Yeah. I don't know if you've encountered the games for CSS flex and this grid, like
the carrots and the frogs and frogs. I love the frog one. Yes. Those were, those were
good because you get feedback really quickly. Exactly. Yeah. Yeah. I totally agree. I'm
pretty sure that the amount of knowledge I have about those techniques come from that
and yes. One or two blog posts that are very good detailed summaries of those techniques.
Yeah, absolutely. Yeah. So, so one of my favorite learning techniques, I don't know, this is
just like a concept, very clear concept in my head that I gravitate towards often, which
is demystifying things. So if I noticed that something is fuzzy in my head a little bit,
for example, I noticed this often with, um, you know, in Elm, people are a little bit
fuzzy about custom type constructors and type alias record constructors, you know, so it's
like, Oh, people will mix up. There's like the type space and the, and the expression
space. Yeah. Value space. I call it value space. That's a good word for it. Yeah. Yeah.
Value space and type space type space can live in type signatures and, and type aliases
and value space can live in the body of functions. And people will mix up, you know, when you
say type user equals user, they'll mix up the thing on the left and the thing on the
right. The thing on the left is in type space. The thing on the right is in value space.
And um, and so in cases like that, I think it's really important to demystify things.
That's, that's the term I, I think of when I'm going through that process myself, I noticed
something being a little fuzzy. It feels a little bit magical and break down that magic.
So it's not magic because if it feels magical, then what ends up happening is you end up
flailing around trying things rather than being able to just sort of, you know, build
up a clear model. It prevents you from building up a clear mental model cause you're constantly
trying things in a way where you're sort of guessing and there's one little piece. And
if you demystified that tiny little thing, you know, in the case of like these custom
types where there's a thing on the left and a thing on the right, the variants on the
right, the type on the left, it really takes five minutes to demystify that if you do it
systematically and, and what does demystifying look like? Like I've got an exercise I sometimes
have people do where, you know, you just sort of, you know, play around with that and see
what happens and do these experiments with, with things on the left of custom type declarations
and things on the right, the variants and just break it down and poke holes in it and
see how it works. You take five minutes, you demystify it and then every time you deal
with that issue, it's no longer guesswork and, you know, trying to get it to work. You
can just demystify it once and then you've got it.
Because after demystifying, you have probably, probably a good grasp of what it means. You've
learned it.
Mm hmm. Yeah. Learn it once and for all with these tiny little things. They're these, they're,
they're these small things that, that trip us up. And so I think it's worth noticing
when you have that little fuzziness on a small little thing, it can go a long way. Cause
if, if a tiny part of it feels confusing and magical, then everything feels confusing and
magical. So hone in on that one thing that's confusing.
So you have now demystified value type, value space and type space. You've learned it, you
understand it, but at some point you forget it.
Mm hmm. Mm hmm.
What do you do against that?
Or how do you relearn it?
Ah, good question. Well, I've got, I've got a lot of secret notes here that I've hidden
from Jeroen. So he, he read my mind and jumped to one of my bullet points.
Very nice.
Or did you anticipate my question?
Then you are much better than I am.
No, no. I think, I think you read my mind a little there. So I think note taking is
something I'm trying to be more deliberate about recently. I've really invested in my
note taking strategy. Do you have a note taking system Jeroen?
I do. I have an app or two or three.
Mm hmm.
Sometimes it's where I write most things that come to mind. Well, I say most things, but
not too many things.
You have notes on performance, Elm performance, things like that.
Yeah. I don't have anything deliberate. Sometimes I watch the conference talks for instance
and I try to write down stuff that is written on the, on the slides that I think could be
interesting to keep in mind. I, yeah, for instance, for benchmarks, performance, I usually
write that in Elm, in the, in the code so that everything is in the same place. So I
guess code is in a way a note taking app.
It can be. Yeah. I mean, if you apply a particular technique to something or if you have a little
repo that you use to experiment with something, you can always go back there. That's a, that's
a good point. Yeah. I really like this technique of mind mapping as well, where you have, you
know, you start in the center with the core topic of the notes, you know, make impossible
states impossible and then it branches out to things and you say, you know, custom types
and then custom types branches out to phantom types and et cetera, et cetera. They all kind
of have these, the idea is that it allows you to have like free flowing ideas that are
just short one or two word summaries rather than long form notes. So it's like quick to
take the notes. It's quick to at a glance, see what you've written. I think that's a
very effective learning technique and for, for recall as well.
Yeah. And I guess that silos the, the concepts as well. So you can learn about custom types
in isolation and then learn about type ADC's in isolation, learn about phantom types in
isolation. And when you've learned all of those, you know, kung fu, making impossible
states impossible. Exactly. Oh, it's a fine line between kung fu and making impossible
states impossible. We should just rename making impossible states impossible. It's too long
to say as well. How about umfu? Umfu. Yeah. Yeah. I think, um, so you know that your system
is working when you know where to look to find something you can't immediately remember.
I think there's something to be said for that. There's a very controversial post going around
the day that we're recording this. I don't know if you've seen it by DHH37signals. Maybe
no. He's basically saying don't be copypasta pirates who are incompetent and celebrating
your incompetence by not being able to do anything yourself and having to just search
for everything and copy paste it. And come on, don't be a jerk. Don't tell people what
to do and how to be. Yeah. And especially when you're just so wrong about it. Come on,
like, like copy, copy pasting is okay. Like it happens all the time, but hopefully your
learning and your mental models can make it easier over time to find the information you
need. You don't need to store it in your brain. You just need to be able to know where to
find it and understand the bigger picture of, of when it would be useful. So, you know,
like if you forget how to do phantom types, that's okay. But if you know when to look
for it and have some sense of when, when it applies, that's what you need. If you, if
you sort of forget how you do opaque types, which that's a tricky, tricky thing when you're
first kind of learning that concept, you don't have to feel bad for like looking something
up or copy pasting something to start with an opaque type. You know, you can, um, you
can just start the episode two of Elm Radio again, which you really should. Yes. Cause
opaque types are so useful, but however you, however you arrive at that, if you, if your
brain knows to go to look for it in that place, that's great. So just being able to navigate
things, however you do that, even if it's like searching for the same stack overflow
post every time that you need to like, remember whether you should do like a script tag with
a defer in it or, you know, or not with defer, or if you should put it in the body at the
bottom of the body in the head where you should put it, you don't need to memorize that. You
just need to be able to find that information when you need it and know that you have that
information that you should find because there's something important you need to do. That's
all, that's all you need. Please send me the notes for that one because I don't remember
that. But, uh, but if you have something that like, as long as you know, you need to get
it. And if you have a system of notes that helps you find that that's great, but notes
are not cheating, you know, notes are not cheating. Happy pasting is not cheating. If
there's like a useful go to blog post, I actually find that often there'll just be a really
good blog post and that becomes my reference for something. And like, I'll go through my
like browser search history and find that blog post over and over and that's fine. That
works, you know? Yeah. But just taking notes is not enough. You need to practice afterwards.
Right. Yeah. Practicing. So increasingly something that I've been developing a lot recently is
a system around this sort of second brain ideas that'll custom second brain and the,
the idea like there's a, there's a really great book, I think it's called how to take
smart notes. Kind of a strange title. It doesn't fully do it justice, but it's about this second
brain concept. It's, it's about the guy who kind of created this Zettelkasten system.
So it's a very interesting read. And one of the things it talks about is interconnecting
notes and concepts and the important of this richness of referencing things. You know,
this sort of Rome research has sort of popularized this idea of like back references and notes.
Yeah. Okay. So in my own incremental Elm site, I've created a back referencing system.
Yeah. So, so kind of like a, you have a Wiki page, you write notes in your Wiki page and
then you have sources and citations at the bottom.
Yes. Yes. And you, and you interconnect the information richly within, within itself and,
and you can create sort of index pages where, you know, you say, here's everything I know
about data modeling and Elm. And you link that to make impossible states, impossible
phantom types, opaque types, you're in hierarchy of constraints, which we've talked about
many times. And so now one difference with like Wikis in this sort of second brain philosophy
is that you're well, similar to Wikis, you're trying to create sort of atomic notes that
can cross reference each other, but unlike a Wiki, you try more to make declarative statements
about things, sort of propositions about your, your beliefs about things. So like, for example,
I've got a note on my incremental Elm site called use the platform. And it's about this
idea of you know, if you, if you create a form, that's not actually a form tag in HTML,
then what happens? Well, you submit it with JavaScript. But what happens if you click
enter? Well, maybe nothing, right? But, but a form is supposed to have certain behavior
when you hit enter. So you've missed that enter key handling. And now you need to manually
go create that with on enter handlers. But also, more importantly, you need to remember
what those things are, you need to be aware of what what happens in a screen reader, if
it's handling a form element, and then you need to make those things happen manually.
So use the platform, because if you just make a form tag in Elm, and then you add a an on
enter or an on submit handler, and you use a proper submit button, that's a real submit
button in the form, even if you even if you intercept the on submit action and do something
in Elm, that's okay, but at least you're using the platform as much as possible. So, you
know, but that's this sort of stake in the ground that I'm putting a flag down and saying,
here's a here's a claim I'm making. Now that claim might evolve, maybe maybe somebody,
as happens on the internet, you put out an idea, and people are going to push back on
that claim. But that's great. That strengthens it. Now, I'm not trying to make bombastic,
rude, aggressive claims, but I'm trying to make sort of verifiable claims that somebody
could in earnest, push back on and and but so that's a difference with a wiki. It's not
just like the platform, the entry on the platform or on form tag, it's a sort of statement of
a belief or an idea, use the platform. And so it sharpens your ideas on things, and it
gives you a place to look. And in the process of writing those posts, I tried to do, you
know, more rigorous than casual research into examples of that finding examples of places
where using the platform saves you from having to do, you know, several things manually that
they come for free when you use the platform. And I try to support it with ideas like, what
if a future platform comes along and uses these declarative things, assuming you're
using the platform? And what if future features come from using the platform, you have to
anticipate those and handle them in the future. So I can sort of like, really develop this
idea and it gives me a place to develop over time support my idea. If somebody says, what
are your thoughts on on this concept, I can link them to something. And anyway, I've been
really enjoying that as a technique for learning and developing ideas.
So basically, you're trying to write opinions, not maybe not instead of information, but
information plus your opinion on it?
Yeah, I would say maybe like claims, just to Yeah, just just to sort of harden a stance,
you know, I guess what's the what's the phrase like, for firm beliefs loosely held or something
like that? If you just have sort of fuzzy ideas about things, then you're not going
to really crystallize your thinking.
Yeah. So if you put me if you write claims or opinions or them in your mind in the first
place, then you're more likely to remember them. Is that kind of the idea?
Yes, you're more likely to remember them. And you might learn by somebody pushing back.
And I think it's, again, very important to do it in a respectful way, in a way where
you're not being antagonistic to anybody, but just making a claim and, and see it as
your current thinking and be open to changing that belief of better information comes along.
So then also means that you need to put it to make it public in a way?
Yeah, that's increasingly a part of this second brain philosophy, at least this digital gardening
philosophy. That's, that's been part of it for me, at least. I don't think it's necessarily
a requirement for second brain. But I've been really enjoying, you know, people talk about
this sort of learning public movement and digital gardening. And I've, I've enjoyed
it. I've enjoyed I've enjoyed having a public place to, to share thoughts and back them.
Like sometimes people will ask a question or they'll, you know, say like, why? Why is
SEO important? And I can sort of formulate my thoughts and then share a link. And I love
So do you have a comment section on your, on your notes?
I've been thinking about adding one. There are some systems for doing that with like
GitHub issues where you can have like a repo for your blog that is just for the issues.
And then people can just post a reply on the GitHub issue and it shows up as a comment.
I may do that. That would be fun. Yeah. Yeah. If you wanted to, you could reply about Jeroen's
hierarchy of constraints and set the record straight if you need to, if I misrepresent
I mean, you coined the term.
I did. But see, that's to my point, coining the term. Now it's like a meaningful concept
That is true. It was a recurring thing. It wasn't even a concept in my mind all that
But it was something that you brought up often. And so by noticing that, giving it a place
to live as a phrase and as a URL, that's, I think that's really powerful.
That is true. Or that just made me more opinionated on it being true when it might not be true.
But you know what? I think that we have like opinions and beliefs naturally. And if we
don't give them some concrete formulation, we don't give them the opportunity to evolve
and change. So I don't think it makes us any less opinionated to not like state our ideas
and beliefs and claims. I think it just allows us to be more cowardly about them and not
really put them to the test.
All right. I have a claim.
I would claim that Elm is easier to learn than other languages because it is simpler.
It is, it has fewer features and fewer keywords and just less things to learn. Meaning that
when you write Elm code, you encounter and therefore practice the same concepts more
than in other languages.
I like this idea. Yes.
It is a claim. It is true.
It is true. Proven. Sample of approval. I do like that. I do like this idea that reusing
a set of constructs and techniques is very powerful, very powerful stuff. Good sign of
an API in general, whether it's a language or a library.
I mean, do you know how the with statement works in a JavaScript?
I don't even know what a with statement is.
I'm just checking whether it's not a thing only Python. No, there is a with statement
in JavaScript. Yeah. You never encounter it because JavaScript is too big and people say
it's a bad thing anyway.
So the with expression, the with statement in JavaScript. Fascinating.
Yeah. Don't use it. I don't remember what it does, but I know it's bad.
That's so interesting. Yeah. And speaking of, you know, with regard to learning, I think
another another useful idea in learning that I try to keep in mind is technical communication.
I think it's worth, now again, don't be a jerk. Don't judge people and be rude about
this. But I think we can always strive to be more precise with our technical communication.
So you mean don't communicate on Twitter?
140 characters or 280? Well, perhaps. Perhaps don't venture out
there. But I think there can be good discussions there. But for example, one thing that I find
myself reaching for that I always have to try to be precise about is statement versus
expression. So, you know, an expression being something which has a value and a statement
does not have a value. So like I think in Elm, you know, statements include import statements,
port declaration statements. Those are things that don't have values. You can't like use
them somewhere. But it's not a case statement. And sometimes I have to correct myself. I
start to say case statement because I'm used to switch statements in JavaScript and other
languages which they are statements in JavaScript and Java. They're not expressions. They don't
have values. It's an if statement. It doesn't have a value. You can't say var username equals
if but in Elm you can. Well, you can't say var because it's not var. But you get the
idea it's an expression that you can use. And anyway, just being precise about that
I think has value. I think it keeps, you know, it helps you sharpen your mental models about
things, keep things demystified, keep things from being sort of blurry fuzzy things. So
I think, you know, try to hold yourself to a high standard of being precise with how
you think about things and communicate things.
Yeah, but it goes a bit counter to what we discussed with Richard about being precise
all the time. Dilute the details. Don't mention all the details at once. Teach them as they
need to, to learn them.
Right. Well, I guess there's the distinction between accurate and precise where, you know,
accurate means that you're not straying from the truth. You're being correct and accurate
and precise. It's the precision. So how fine grained is your accuracy? How specific are
you being? So I think we should always strive to be accurate.
Yeah. Or tell people this is not entirely accurate. I'm simplifying things.
Yeah. But ideally we can avoid that, right? Ideally we can find a way to present information
that is, you know, where it naturally unfolds in a way that we don't have to give all the
details at once, but we don't have to give any incorrect information. But yeah, I mean,
I think in subtle ways we can, like, I don't know, saying that something is an expression.
I think that's a good thing to be aware of. At least I try to be, you know, aware of that.
Yeah. So we talked about applying techniques, actively doing exercises, but when you are
learning something, do you write small exercises to yourself? Like trick questions for later
you, for later Dillon. Like, Hey, what can I do with the custom type? Are you able to
do X with custom types? Yes or no? Later Dillon, please reply. Please answer the question.
I would tend to do more like code exercises or solving small problems than like writing
questions. But yeah, I mean, I'll try to write some notes on things like that. But often
like, for me, you know, we're, we're a little unique in this regard. I think you're in probably
that our, our side projects have taken on lives of their own, that they've become more
than side projects for us a little bit. And not everybody needs to be that, that way with,
with how seriously they take their side projects and how much they invest in their side projects
were a bit extreme. But, but I do think that there's value to side projects, you know,
however, however modest or simple a side project may be. I think that that's a really great
place to experiment with ideas. And I know for me that it's been absolutely essential
that whenever I have a new concept, you know, I remember my early days of Elm, like watching
Richard's Elm Europe keynote one year where he was talking about extensible records and,
you know, passing through as little information as possible to try to narrow, you know, narrow
types down and narrow where you need to follow data to understand what it depends on and
what it, what it can affect by what it returns, if it returns a command or not, if it returns
the whole model or just part of the model, things like that, right. He gave a great talk
about that. And it really was like a lot of new information. When I first saw that, it
was like, wow, I have a lot to process that is very much not part of the way I think about
Elm. And I need to really sit with this. In fact, I remember like watching that talk more
than once when, when I first saw it, when it first came out, because there was so much
information for me to process there, so much new stuff. But I went through the mobster
code base and I applied that as many places as I could and probably too much in some cases,
like I probably used extensible records a little bit too much because he sort of introduced
this idea of narrowing what something depends on and what something can affect, like what
fields it can change in a record using extensible records. And perhaps I went a little too far
on that, but you know what, like you can't bypass the failure to learn. You need to try
things. And so for me, side projects have been really important for that. Just creating
like, just going a little bit crazy with a side project. Like I remember Richard talked
in one of his talks about using, what's it called? Dreamwriter? His Dreamwriter app.
And he was saying that he kind of like, he's like, well, why couldn't you have like these
mini architectures nested like components? And he like experimented and basically started
hating working on the app after like, he really got it to a point that he loved working on
it and making changes there. And then he started to hate it because he did this like big refactoring
to componentization. And he like, and he like talked about like having all these bugs at
one point in Dreamwriter with like state being mismatched. And then he started, I think he
started trying to like derive state rather than duplicating it and passing around. And
so, I mean, I think this is really how people explore, figure out new techniques, learn
new techniques is you try it, you experiment and having a safe space, like a side project
to experiment is very valuable in my experience.
Also having a safe state of your side project. Like a good good history. So Richard could
have backtracked out of all this. He would be happy and he would be working on Dreamwriter
right now. Right. Yep. Sometimes, sometimes our side projects pay the price when, yeah,
when we get a little too eager. So another thing I find myself doing a lot is we talked
about being curious and I think being curious is huge. When you're curious, go look at the
source code, even if you don't understand it, even if it makes no sense to you, just
if you ever find yourself one, it's just a little habit that you don't have to fully
understand it, but just be a little bit curious and be like, hmm, is that even possible? How
does it even do that? Like, how does, you know, like if you see something that looks
a little funny, like I remember, I remember figuring out this technique about what I like
to call a package opaque types where it's like a type that you can create anywhere within
the code for an Elm package, but you can't create that type. That type constructor is
not exposed outside of the package. I remember seeing something like in Elm UI, like that
it's like type alias element equals element. I'm like, yeah, what the heck is that? You
just look at something that looks a little bit weird and follow your curiosity and you
know, you don't have to, you're not on the hook to perfectly understand everything about
it, but just a little bit, get curious and say, that seems weird. I wonder what it is.
Click view source in the package and go to that element module and see type alias element
equals where's that defined? Oh, it's follow the import. Oh, it goes to this thing. Oh,
it's in this internals dot something module. And oh, it's just a custom type. It's just
a custom type, but it's defined in an internals module. Is there something special about internals?
Oh, I see. No, the only thing that's special about it is that it's not an exposed module
in the Elm dot json for package. You can have exposed modules and the internals package
by convention are not exposed. That's all it is, but you can learn new techniques that
way. You can, you can learn a lot just by clicking view source.
I mean, it's so nice that it, that almost every, yeah, all packages in the Elm community
are open source and you can look at the source code that lowers the barrier to learning and
you learn so much from, from doing that. I've been recently digging into the compiled code.
So learning how compiled code works, the compiled JavaScript from Elm code, I mean, and yeah,
some things become demystified. Yeah. Even things like, hmm, I think pattern matching
works this way. And if you think you know something, but you're not really sure, then
you start assuming things and hypothesis, making hypothesis about things. And they may,
they may be wrong. For instance, I was thinking if I do pattern matching this way on lists,
then or something else, then the compiled code will be more performance because I ordered
this before that, for instance. And that turned out not to be true when I looked at the compiled
code. Sometimes the compiler was smart enough to do things in a more performant way, or
it didn't do it the way I expected. So yeah, looking at the compound source code or looking
at package library code removes those blurry, those fuzzy images that you have in your mind.
And when you look at them, you know, you learn and everything becomes clear.
Yeah. Yeah. Yeah. I think, you know, you want to think at a high level of abstraction, but
it can be really valuable to understand what's under the hood a little bit to just get comfortable
peeking under the hood a tiny bit. Yeah. I don't recommend looking at the 10,000, 20,000
lines of code of, of compiled code. I should have spent better spend my time.
But if you, if you take something away for that mental model, you know, it's, it's super
valuable. You know, the second brain stuff has this, I think controversial stance statement
claim, if you will, which they wrote in a note. Well, absolutely. Basically the, the,
the author of this how to take smart notes book said that he basically wrote the book
by just taking his notes and sort of organizing them differently and rewording some things,
but he basically just took his notes that he already had and his book was just boom,
you know, which the the guy who originally created the Zettelkasten system was known
for being like a prolific writer that he was like a sociologist, I believe, and wrote hundreds
of books. Even after he passed away, he posthumously published dozens of books, I think, because
people just went through his notes and there were all these ideas that they were just able
to extract books out of. It's very interesting. So prolific that people are publishing your
things afterwards. Isn't that amazing? Yeah. It's fascinating.
And so this sort of second brain philosophy has this, I think, sort of bold claim that
you, if you're not writing, you're not learning. And I'm not sure if I agree with that yet,
but I, it's definitely challenging me in a good way. I think it's good to be challenged
a little bit to have your beliefs challenged. So if the listener to this episode has not
written everything down, exactly. They haven't learned anything.
That's right. Please press replay and start writing things
down. That's right. That's right. I mean, we've got
to build up our mental models and writing can certainly help with that. To me, that's
one technique, but I think it's a powerful sentiment and I think there's definitely value
to that concept. And by the way, I should reference that a lot of the ideas on learning
this book, Make It Stick has been a really big influence on me. I really enjoyed this
book. It's written by like a couple of neuroscientists, just sort of evaluating the literature on
what we know about how the brain learns. And so a lot of these concepts come from there.
I'll leave like a little link to some notes from that book from the internet. But yeah,
there's a lot of good stuff in that book. So maybe like a kind of wrapping up a little
bit here, but maybe on a final note, like another thing which we talked about, I think
in our API design lessons episode, we don't do all our learning in our conscious brain
prefrontal cortex, inner monologue. A lot of learning happens when we sleep in our background
processing of our brain. Our brain is doing all these things in the background without
us knowing about it. Yeah, especially you ride before sleeping
in my case. Yeah. And that's good. And we should optimize
for the way our brain works, which is it does a whole bunch of stuff in the background.
And we don't have to do everything, but we can tee things up for it. And so these things
like writing notes can help it sort of have some things to chew on and process in the
background. We can sort of pose questions and let our background processing work on
that in the background. Another thing, there's a really nice book by Dan Pink called When.
And I had a really nice takeaway from that book that really stuck with me, which is this
idea that we have different modalities of thinking that our brain is most natural at
in different times of day. So if you're an early bird like myself, then in the mornings,
you're going to be more alert and analytical. And in the evenings, you're going to be better
able to make connections and think of innovative ideas. So that sounds right. That sounds about
right. And if you're a night owl, it's the opposite. Oh, no, that doesn't sound right
to me. Interesting. Maybe I should analyze that. But I should do that in the morning.
No, in the evening. It's complicated. It's interesting. So he says that the way you tell
if you're an early bird or a night owl is basically naturally if there's no work schedule
or anything like that to wake you up. Do you tend to wake up, you know, whatever, like
before 830 or after 830 or something like that anyway. But the point is like, pay attention
to how your brain naturally works and feed it problems that it's suited to solve. So
for myself, if I'm thinking about some problem that requires a lot of creative thinking,
I'm not going to do a great job of that in the morning. But I am going to be really good
at doing research, gathering prior art, thinking about a lot of ideas that will let my more
creative thinking kick in later in the evening. So, you know, I try to optimize for that a
little bit. Right. Yeah. So I was wondering, because we did an episode about teaching,
and now we talked about learning and you mentioned writing notes quite extensively. Do you think
that writing notes is a way of teaching yourself or someone else? So do you get the same benefits
when you teach someone or multiple people as when you write notes in a good way? I think
so. Very much so. Very much so. Actually, one of the things in this book, Make It Stick,
is it actually talks about how there's something different in your brain that kicks in when
you're learning something in order to teach it or when you're just learning it. So, oh,
okay. And this, I mean, partially this goes to the motivation question. Like if you're
learning something with a purpose, then your brain finds places to fill in that information
because the brain learning is not about transferring knowledge from one box to another box or copying
it. Learning is about making connections, making associations. Our brains are association
machines and the more things you can connect an idea to in your own mental model that's
meaningful to you, the more you understand that thing, the better you've learned it.
And so I guess when you try to teach someone, you will do so with your own words, obviously.
Yes. And when the teaching doesn't come across, then you try to find a new way to explain
things. So you need to find new connections, new metaphors, and that builds a new mental
model, I guess. Absolutely. Same benefits. Exactly. Yeah. And it is, you know, Make It
Stick talks quite a bit about this difference between following something and understanding
something. So we can, I mean, like I think a good analogy is if you're driving in the
passenger seat and you're like, okay, we're going, you know, we're turning right at this
light and we're, you know, going straight down this road and we go past these buildings,
you can follow the path, but would you be able to be put in the car at the starting
point and drive that route yourself? Probably not. Whereas if somebody is in the driver's
seat and they're following GPS instructions and you say, okay, go drive the road again
after without a GPS, they'd be much more likely to be able to do it because they're actually
making those choices where you might not pay attention to the fact that they're making
a particular turn because you're just following what they're doing. You're not actually evaluating,
well, I could have turned left here, I could have gone straight, I could have gone right.
It's the same with learning. If you're just like, oh, okay, I'm with you so far, I'm with
you so far, I'm with you so far, we have the illusion that we're comprehending what they're
saying, but we're actually just following it, but we haven't carved out those deep questions.
So then if you go to explain that to somebody else, if you explain phantom or the phantom
builder pattern, and then someone says, hey, what is the phantom builder pattern again?
And I go to explain it, then I might start explaining it and find myself getting lost
and saying, oh, wait a minute, but would you use it in this case or would it be a bad fit
for that? And would you be able to model this type of thing or not and getting stuck somewhere?
Because even if I followed everything you said, I hadn't taught it, I hadn't made that
learning my own. So yeah, teaching is a very powerful way to make learning your own.
But if your own was a better teacher, wouldn't know how to explain that.
Well, you know, perhaps if you had the opportunity to do some exercises in a workshop, it's limited
what you can do just by talking and somebody hearing you talk. It's just, that's not how
you get smarter. You got to that's part of it. That can be an important ingredient, but
it's not enough on its own. So is there anything on your radar that you are looking to learn
next in the Elm world you're in?
I tend to try and discover things like ways of improving things or forbidding things in
my case usually. And yeah, I guess I'm learning through that. Having a side project does take
a lot of time and it's not always teaching you a lot, I think. But when you reach new
edges, when I need to work with something that I don't know much, then I learn. But
when I'm doing pretty much what I'm already am used to, then I'm not progressing.
Right. Sometimes there's just grunt work that you need to do where you're not necessarily
learning a new technique. And sometimes you have to be deliberate about applying a new
technique and learning it. But I've noticed that, I mean, like your blog posts on your
[01:10:37] blog, you're exploring a lot of ideas there. You know, I mean, and you've
shared your learnings on this podcast about performance, tail recursion. Now you're looking
at like compiler output stuff, looking at code complexity and how to evaluate that in
different ways. And I'm sure those things have an impact on how you write code, not
just benefiting from having written those Elm review rules, but it changes how you think
about complexity in code or performance, things like that.
I don't even need my Elm review rules anymore. It's all in my mind.
Exactly. Well, that's the thing, isn't it? Yeah.
But I want a tool to take care of that. That's why I wrote them.
That's the irony. And you know, the more you love Elm, the more you write JavaScript to
help you write Elm. Right? That's the other, the curse of loving Elm too much.
Or Haskell. Yep. Yeah. The people who write the tools for Elm usually don't write Elm.
In my case, I made the lucky bet of trying it, writing it in Elm.
That is great. I think in your case as well, mostly.
There's both. There's both. Yeah. Yeah. Yeah, absolutely. All right. Well, I guess we've
sort of pointed out some books. We can kind of link to some articles about some of the
things we've talked about. Growth mindset, make it stick. Second brain. Second brain.
Really fascinating stuff. If you find any statements in my incremental Elm notes that
you'd like to push back on and be a part of the learning experience for me and be a part
of the discussion, I always welcome discussions on those. Love to hear people's thoughts.
And if you enjoy Elm Radio, don't forget to share it with a friend and rate us on Apple
Podcasts. That helps us a lot. And you're in. Until next time. Until next time.