How We Learn

How We Learn

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

PublishedDecember 6, 2021

Episode#45

Make impossible states impossible
Teaching elm episode
Dillon's first Elm project, Mobster pair/mob programming timer

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

Transcript

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

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,

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.

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.

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.

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

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.

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.

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

jfmangles.net 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.