Or help explain why I'm so enthusiastic about it. Who for context is she's a data scientist and loves Python? Yeah, well, she loves data science, not Python. But she likes it. Because she hasn't learned, she hasn't discovered Elm enough yet.

If someone would like to work on making data science available to Elm, then I would finally be able to convince her to use it. Otherwise, it's very hard. That's fair.

So the way that you chose to explain it to her, and which I would like to somewhat re simulate, is that you mentioned the ADD approach, or your way of working with code. So maybe let's start with what is ADD.

Right. And maybe before that, we should say I have ADD. And I think it's worth pointing out I am diagnosed with ADD. I am not trained psychiatric professional. So I'm not. So we're not, you know, I can share my experiences and what's what it's been like for me, writing code with ADD,

writing Elm code with ADD, how I've been able to manage that. I don't personally use medication, I know some for some people has been helpful. But I've done a lot of things to help manage my ADD. And Elm has been really compelling for me with ADD. So with that said, what is ADD?

Again, speaking from my layperson's experience with ADD, I think a lot of it has to do with your working memory. So you know, if you if you ask somebody, you know, hey, remember these, the sequence of numbers. Now let's have a conversation. Sometimes that's kind of what it feels like working with ADD when you're holding a lot in your head.

Like you feel that weight of these things that you want to make sure you're not forgetting. And there's like a, there's a there's a weight to the burden of the things you have to hold in your head. So a lot of it is related to like, the executive part of the brain. So managing time.

So I think it's hard for everyone to remember things and to keep them in your head. If you ask me, can you keep these 1000 numbers in your head right now? It's going to be very hard for me. But from what I got from your explanation from when you came by, is that the number of items that I can keep in my head is higher than yours, or at least it's going to cost me less effort to keep those in my mind than it will for you.

Right. Yes. I'm not sure if other people without ADD have this experience. But I can say for for me as someone with ADD, when you when you go to the grocery store, and you're trying to remember the list of things that you wanted to buy, you're really thinking like, am I going to forget something again, right? Because your brain just won't do it. So eventually, you learn to take a list with you write things down, as you think of things, put them there, make sure you get you get the right number of items.

Make sure you get you have everything you need to get on there. But then even so, if you're walking around, you've you've got your list, just going and making sure that you're getting everything on the list, you you keep looking at the list to make sure you have everything right. So yeah, now if you have a way to cross things off of the list and, and say, okay, this has been accounted for, then your brain can let go of it. So really, I think it's very important.

At least it has been for me to offload work from from your brain and into external systems. Because as people with ADD, it's just we don't have the ability to juggle as many things in our working memory. So we have to, you know, our RAM is not as large. So we have to write things to an external disk more often and and swap things out there. But if you get really good at using external systems.

Now, and this is this is one of the things I want to kind of address here too, for for anybody listening who, who doesn't have ADD or doesn't believe they have ADD, you know, anybody could have undiagnosed ADD, but is this relevant? So I contend that my ADD has taught me a lot of skills that are valuable for people who don't have ADD. And the analogy that I've used is that it's like a canary in the coal mine.

So, you know, back back in the day, miners would, who would be going down deep underground, you're drilling in these mountains, and sometimes there are toxic gases that come out, and they can be deadly. And so they would bring canaries. And why canaries? Because there are certain gases that don't emit a smell like methane, maybe doesn't have a sense that we can detect.

But you bring a canary down. And if the canary dies, you'd better get out of there because you don't realize that something bad is happening to you that you're being hurt, because you don't feel it. And I believe that my ADD is my canary. I know it's a very morbid analogy.

It is. I'm a little bit shocked here. I'm like, okay, it's it's a smart system. But also like there must be better ways to do it.

It's, it's pretty dark when you peel back the canary in the coal mine. But, you know, another way I think of it is, is nerves. If you, you know, if you were had the ability to prevent a child from from feeling any sort of pain being hurt, if they fall or something, it would be tempting to do that.

But then they wouldn't learn to protect themselves. When you feel pain, it teaches you in this very tight feedback loop, what not to do to exist safely as a human. So I believe that my limited, you know, cognitive like workspace is an early detection system and early warning system that lets me know when I'm placing too much burden in my working memory.

And other people lack that early detection system, which means they can get by without learning these techniques for delegating things to external systems and having systematic processes for working with things that allow them to do higher level tasks, allow them to do things with leverage because external systems let you leverage things to do more complicated tasks than you're capable of doing on your own, right?

It's like a like a pulley or these different mechanisms for physical leverage. Like if you if you're just really strong and you say, I'm just going to be strong and I can lift anything I want and you don't bother setting up pulleys or getting the materials to do so.

Well, that'll only get you so far. Maybe maybe there's somebody who's less strong and they come in and they're, you know, helping to ship cargo and move heavy items. And you know what? They're lifting heavier items because they figured out how to use pulleys to do that.

Are you saying that Schwarzenegger would not be a good engineer? Is that what you're saying?

Possibly. Possibly.

I can do it!

Necessity is the mother of invention. And so I can say at least for me, I do believe that and hope that these experiences are relevant for other people who don't have ADD because I think that they've taught me a lot of valuable skills that I've been forced to learn and approach in a very systematic way.

I believe people without ADD are not forced to do that. And so they're missing out on these really useful approaches.

Yeah, I'm curious when you say that you feel the weight, how does it feel for you? Do you get tired? Do you feel like you get a headache? Things like that?

That's a good question.

And also how quickly do you notice it?

Probably a haze and there's a little bit of avoidance. One of the big things I notice with my experience with ADD is that if something is not well defined, it repels me. So it's very important to give things clear definitions.

What do you mean it repels you?

I just want to avoid it. I don't want to look at it. If it's like, oh, I have to do something about this, but what do I have to do about it? Then I just want to be away from that thing.

Right. Yeah, I can relate to that.

Yeah, I guess everybody can to some extent. But with ADD, I mean, it's the kind of thing like and the way I think the way that people with ADD prioritize things is different than people without ADD.

You can't just brute force will yourself to put importance on something. If something isn't clearly defined and actionable, it's very hard to take action on it.

So we'll get into some of the ways that that relates to Elm. I mean, maybe we can kind of jump into that now. So I think like a few areas I wanted to address are like, first, how does Elm help somebody with ADD?

Because in my experience, it's been that's been really interesting. And then the second thing I wanted to get into is how do we make better use of Elm in order to leverage Elm for people with ADD or for people without ADD who want to have more leverage like that person who's not Arnold Schwarzenegger, but they know how to use a pulley.

They're only moderately muscular. I can only lift like 200 pounds, which I have no clue whether that's a lot or not.

Hmm. Sounds like a lot. I don't know.

Yeah, I think it sounds like a lot. Let's just say I can't count pounds.

Too much to hold in your working memory.

Yeah. So I know that's one thing that you've talked a lot about is following the compiler. I mean, I think that a lot of people like to do this in the Elm community, where you would just make a change and then follow the compiler errors.

And that is very relaxing in the sense that whatever you need to do, or most of the things you need to do, depending on how the changes made, the compiler will let you know.

So you don't have to keep things in your head about, oh, I need to remember to change this file, this file, this function call to rename this thing and to do plenty of other things.

You can just let the compiler let you know, do this, do that, and now it's all good. And then it compiles and it works.

Right. Exactly. And I talked about the importance of external systems for someone with ADD as sort of like a supplement or replacement for your working memory.

And in a sense, a compiler acts as that, especially a compiler you can truly trust.

Yeah.

And this is a very important point. So I talked about the Getting Things Done methodology. It's a book by David Allen in our productivity episode.

In fact, I talked about a lot of things that have been tools that have helped me navigate my ADD in that episode.

But I've been practicing this Getting Things Done philosophy for many, many years, and it's helped me a lot.

And I mean, one of the big ideas is to get things out of your head. And he has this concept that so he gives this example about like actionable items where he says, let's say you have like a stack of magazines.

That's not necessarily pulling at you. It's not that important.

But if you take that stack of magazines and now you put a bill that you need to pay, an urgent bill in the middle of those magazines, suddenly that entire big stack of magazines that was just noise that didn't bother you.

Now suddenly that whole stack is, oh, is there something I'm missing in there?

Yeah.

You've now tainted every single item in that pile because it's now suspect because you have no way to clearly separate out the actionable thing from the unactionable.

Imagine that it's not just one urgent bill, but it's several. So now you've got all these piles of things that aren't clearly separated between what needs action and what doesn't need action.

So you're going to go through all those magazines and they're not going to be just distracting at all.

Right.

Yeah. And there's like maybe there's something you wanted to pick out for an upcoming trip.

You wanted to glean something from a magazine and write it down, but it's kind of optional.

And then there's this other thing that's urgent.

And now suddenly everything goes into that same category of urgency or of becoming blind to it.

It's just unmanageable.

And so that's kind of how I feel with type systems that give me partial guarantees.

I feel like, OK, well, I can partially trust it, but I can't fully trust it.

And now my brain has to keep looping over to make sure I'm not missing something.

If I can 100 percent trust a guarantee, then it's out of sight, out of mind completely.

I can turn it off and my brain doesn't have to loop over it.

And so to me, there's a qualitative difference between partial and total guarantees.

Yeah, I'm guessing there's also I imagine that the way that you write Elm code will also differ because basically what you're saying is I want the types to help me out.

Right. I'm writing types so that the competitor helps me out.

And whenever I add a message variant, then the competitor will tell me, hey, you need to do this.

But you can still write Elm code in a way that the competitor won't help you.

For instance, if your message is just an Avis two strings, it's not exactly it's not idiomatic Elm code for good reasons.

But there are ways to write code in a way that will be more dynamic in a way or less statically analyzable and that the competitor won't help you, that Elm review won't help you with.

Yes, exactly.

Exactly. So, for example, like if you take parse, don't validate again, we see our parse, don't validate episode.

But for me, parse, don't validate is gold because it means you take you've reduced down the possibility space and the compiler knows that.

So instead of having to keep track of what are the possibilities in your head, you've delegated that to an external system.

So when you parse, don't validate, you're narrowing down the types to be more and more precise, more and more constrained.

There are fewer possibilities as you drill down.

And now suddenly you're in this space. And what can this be?

Well, it's one of these two things. And now you can manage that.

It's not repelling you. It's pulling you in to work with it because you're not worried that you're going to be forgetting something.

So, and yeah, I often find myself like, you know, building techniques in external systems and processes to manage ADD.

For example, like I know if I'm out somewhere and I have, you know, I have my jacket that I put somewhere or I have something on a trip that I need to remember to pack with me.

I know that I'm not going to remember when I need to bring that item with me.

So I put my keys with it because that is a guarantee that I cannot get farther than my car if I don't have that item, if I'm not reminded at the appropriate time.

And so that systematic approach, you know, as you said, like the Elm compiler gives you a tool for that and you can use that tool even more effectively to double down on that idea.

And so to me, that's what it feels like to effectively use types. I mean, think of like a case expression.

And if you do like a catchall, you lose that reminder at the appropriate time that you'll be reminded of something.

Well, where does that go? Now that goes in your head. Now your head is responsible for remembering at the appropriate time to do that.

That doesn't work for somebody with ADD.

But when you build in this alarm that's going to remind you at the appropriate time what to do, you can let go of it because you've put in an external system.

One nice thing with external systems is that you can share them, right?

You can write your code in a way that the compiler will help you.

You can't share that knowledge about, hey, if you ever do this, then you will need to do this as well.

That is possible, but harder.

Yes, absolutely. I totally agree.

Yeah, imagine like, actually, I remember briefly, I did some Rails development and for a brief period,

I worked at this Rails company before bundlers were a thing.

But bundler in Ruby being the package management system.

Okay.

Not like a JavaScript bundler.

Well, that's not confusing.

Yeah, sorry. It's a little bit ambiguous, but that was very chaotic because you say, well, it works on my machine.

Well, what version of this gem do you have installed this library?

Do you have installed on your machine?

Oh, it's at this version.

That felt so chaotic, especially as somebody with ADD.

There's all this implicit context and things are not in a repeatable automated external system.

So you have to have it in your head. You have to have it as this thing.

Every time you're thinking about something's going wrong, now you have to think,

well, am I just on the wrong version of this gem? Did I forget to update?

Do I have to do it?

Now that's another thing in your mental checklist that you have to run through every single time.

But when you have a repeatable, deterministic, externalized, automated process,

those are all ways of externalizing things so your mental checklist doesn't have to think about it.

And that's the case for your whole team.

And your whole team knows that they're on the same page and doing the same thing

and don't have to think about that space.

So for somebody with ADD, eliminating certain areas from things that you have to have on your mental checklist is huge.

But again, I contend Canary in the Coal Mine that this is a lesson that I'm able to give people

because I'm forced to learn this lesson, but other people, I believe, benefit from it.

How does debugging work for you? I feel like that would be a mess because you need to keep so many things in your mind

because you're discovering things, because you're exploring ideas, ways that the bug could have been introduced.

So I think you need to be very organized, right?

But organization and explorations are things that are hard to combine, in my opinion.

Yeah, that's a good question. I think it's probably forced me to be more systematic about approaching debugging,

but I think we can be very systematic about debugging.

I think it's very easy to get in the habit of not having a clear intention with debugging steps

and not looking at what is the search space that I'm debugging and how do I systematically reduce that search space?

How do I do a binary search through that where I'm slicing off as much search space as possible on each step?

So being required to be a little more deliberate about those things in a way,

maybe it's more natural for me because I have to approach things in a systematic way.

It reminds me of the Scaling LMAPS talk that Richie Feldman did,

where you can say, well, these functions will only look at these pieces of data,

so whatever else will not impact my code.

So this function can only do this, it can only return this,

so you can eliminate a lot of things and don't have to think about those.

Yes, exactly. And Elm is huge for that.

And I definitely find myself quite often trying to externalize the process,

so you can externalize debugging with notes, comments in your code that point out the places you need to search through,

tests, and narrowing down your search space using tests.

Also, if you think about an externalized system and also this leverage effect, unit tests.

Unit tests allow you to split work into two parts.

So the same amount of work, discovering the problem in a repeatable way and fixing the problem.

Now you break that into two steps. You're not fixing the problem right now, you're only discovering it,

you're only reproducing it. And then once you've reproduced it, you're no longer focused on reproducing it.

That part's done, it's externalized, now you are solving it or exploring how to solve it.

So unit testing is absolutely huge for people with ADD, but again,

I believe that it's extremely beneficial for teams and my ADD has allowed me to feel the pain of holding things in my head.

You can imagine, if you have a project and something breaks, you fix it, another thing breaks, you fix it,

another thing breaks, you fix it, the same thing breaks, oops, you fix it again.

If you have a robust test suite, you don't need to be somebody with ADD to benefit from having a test

that captured that thing that was broken and it stays fixed.

But it's extremely powerful leverage for someone with ADD.

So another thing about Elm that is huge for me with ADD that really...

So the thing with Elm, my experience discovering Elm, it really just clicked with me.

I became very interested in functional programming and when I discovered Elm and got into it,

it really worked for my brain and it really made sense.

So in my Rails development days, I felt very uncomfortable with the amount of magic in Rails apps.

It was very painful to work with because again, it felt like standing at a grocery store without my shopping list

written down and without remembering like, wait, did I...

Okay, I did get that thing, so am I done with that?

And looping over and over and over in my head.

That's what it felt like working with Rails magic because...

Do you have an example of Rails magic?

Yeah, just having... So Rails has this thing called method missing which allows you to invoke something

when a method is not defined, it calls method missing with the name and the arguments that it...

Something was attempted to be invoked with.

It didn't exist, but it says, well, here's your last chance.

You want to run some code.

All right.

A lot of the Rails APIs use these things.

So you have like path for users, like path underscore four underscore users,

and that would link to users.

But now that's an implicit thing that's just in the global namespace.

You just call this thing with this convention, no parameters passed to it, and it just exists.

Where does it come from?

How do you look it up?

Well, you have to either just know that it exists or find the right place in the documentation

or it's very untraceable.

And that experience for me with ADD was very painful because you have to internalize all of those details.

You have to hold them in your head constantly.

If something is externalized, you have auto completion for it.

There's a clear traceable place where it comes from and how it's used and what are the possible ways to use it.

And these are the types that it works for.

And you can't overload a method with five different ways to call it that have subtly different behaviors

based on what you pass in.

But wouldn't these be things that you would learn?

Like, oh, well, path underscore user.

At some point, you get used to the convention and you learn that it will link to the user.

Doesn't that get automatic in some way in your brain at some point?

Not really.

Like, for me, you learn it and you know it, but it takes mental effort to pull that out.

And so like with Elm, it's inputs to outputs.

And with Rails, there are all these different ways to solve a problem,

all these things you can do with, you know, global state and all of these,

like things in the framework are really designed to be very fluent for people

who learn all of these things and hold all this knowledge in their heads.

And it's just dependent on building up an internalized system, which I mean, sure,

like people with ADD can learn things and they can build up an internal mental model of things

and that doesn't necessarily take up their working memory,

but it's just a lot of implicit knowledge and also a lot of different ways

you could do things that you have to consider.

Is it approaching this problem this one way?

Is it doing this other way?

There's this implicit thing that could be affecting state or causing subtle behavior changes here.

And I mean, even if you're the most experienced Rails developer in the world,

you're going to Google things.

You're going to Google things a lot and you're not going to remember every subtle variation

of parameter types that you can pass to something in the subtle behavior differences between them.

It's designed to be like very fluent to write.

If you have this specific knowledge, you can fly through it.

But then when you're trying to make sense of what's happening,

now suddenly all those things have to be running through your brain

and you have to build up this picture of what's happening as opposed to these are the inputs,

these are the outputs.

With Elm, if you narrow down the problem in some Elm code,

you can narrow it down like is there some state problem,

is there some UI problem, is there some function that's computing the wrong value.

And you're going to eventually narrow it down to inputs and outputs or incorrect state changes.

So it's just much more constrained and much easier to externalize.

In Elm, there's a lot of things that you don't have to care about because they will not be a problem.

For instance, the fact that you don't have side effects that grants you referential transparency.

If you compute a value, then the value is the same as calling the function itself.

So you can change the two.

That can maybe make your processing data in your head a bit simpler.

But also because you don't have side effects, the order of things doesn't matter.

So you can evaluate this expression in isolation,

you can evaluate another expression next to it in isolation.

You don't have to care about, well, first I execute this thing,

that creates a global state that is like this, and then I have this state, this computation,

and now my global state is in this way, what has changed between the two, all those things.

So you can view those in isolation and then see how they are used.

Right. Exactly.

If you think about imperative versus declarative through the lens of working memory,

imperative is, you know, create a list, add this item to the list, set this flag,

oh, is this flag true? Okay, then add this item to this list.

Otherwise, add this to the list, then do this, then do this, then do this.

And to process what is happening in imperative code,

which always felt very uncomfortable for,

it required a lot of looping over things to make sure I wasn't missing a detail

in my Ruby on Rails days, to, you know, just imperatively adding something

to a list with the shovel operator and things like that.

The what? The shovel operator?

Yeah. And there are a lot of special operators and things in Ruby,

and you have to remember all of the subtleties of the different things it does

and when you're not supposed to use this because it has subtly different behavior

and what, you know, if behaves this way with these falsy values and things like that.

It's just a lot of stuff to hold in your head.

And yes, you learn them and internalize them to a certain extent,

but you're still processing that when you're thinking about where a problem could be.

Is a for loop, especially like the C style for loop,

a lot easier for you to understand or to read, I guess, than list.map?

No. Other way around.

There's a declarative. Yeah, map is easier.

Okay.

By far. And that was my gateway drug to functional programming

and to Elm was the innumerable methods in Rails and Ruby

where you can map and filter on lists.

I loved that pipeline style of processing data because it's this declarative thing

that let me look at things and say, okay, given a list with these things

in a high level thing, then call, you know, process the list in this way.

It's just much more declarative and you can chunk things where you're saying,

okay, if I understand this, if I take it at its word that this function

is doing this thing, then I can read it this way.

Instead of this imperative thing where you really have to create

this state machine in your head that's able to like execute this code

and now you're holding all this stuff in your working memory.

So declarative programming and especially with immutability

and without implicit states and things like that is amazing for people with ADD.

But I do tend to think that it's just a very manageable way

to write code for anybody.

But you can double down on that by being more declarative

and creating nice high level abstractions that describe what things are doing.

You can write Elm in a more imperative style or a more declarative style.

Joelle has talked on some of our past episodes about this idea

of extracting the let variables for conditions in a conditional.

So you can have high level names for them instead of just having like

direct code in your if conditions and having things at the same level

of abstraction where you have like, you know, if variable then function call

else if variable then function call.

And now you read that at one level of abstraction where everything

flows at a very high level and if you want to dive into more detail, you can.

That means less to hold in your working memory.

So that is a very powerful technique for people with ADD

and that's a way you can double down on that style with the way you write your Elm code.

One thing that I'm wondering about is that Elm has a lot of boilerplates, right?

Compared to other languages.

Is that harder for you to understand than magic that would prevent that boilerplate?

Because it's a lot of code, it's dumb code, right? Very often.

But it is still code that you need to read and to get into your mind.

Yeah.

Do you think that is easier or harder to understand than something that abstracts it?

Like code generation or macros or magic?

That's a good question.

Well, I think magic can change the mental model and require exceptions

in the way you think about something.

Whereas Elm, it's like, yeah, there's a JSON decoder somewhere

that is doing something with a lot of code, you know.

But it doesn't break my mental model about what's happening.

There's something that takes this data type and turns it into this other data type

and that's what everything is.

And so, you know, it doesn't break my mental model and add things to hold in there.

There's like a very simple set of core primitives that we have to work with

and everything follows the same simple set of rules.

So, like, for example, I find it very uncomfortable to work with code

that might throw an exception.

It's just like extremely anxiety inducing, like, you know, working with JavaScript code,

which I do a fair amount, like, you know, working on like Elm pages and things like that.

There's plenty of, you know, as you know, when you love Elm enough,

you often sacrifice yourself to write JavaScript for people to enjoy Elm more.

And when there's like, oh, does this code throw an exception or not, right?

That's like a subtle exception, you know, like a literal exception

to the mental model of this code from top to bottom, runs through and executes these things.

Unless something throws an exception, then that could stop the flow of execution

unless something catches it above the calling point and that could change the flow there.

So, when it's just like, hey, this thing returns a data type,

you can do, you know, you can do pattern matching and case expressions on data types

and do code flow based on that data type.

But at the end of the day, it does return this data type and the calling function

does receive that data type and can choose to do something based on the data type it receives.

It's one flow, it's one mental model, and it's not these, I mean, to me, like,

exceptions feel very much like go to statements in the sense that suddenly it breaks the mental model

of the flow of your code and introduces a new paradigm to them.

And to some extent, there are, just a go to, a conditional go to, like only go to if you have an error.

Exactly, exactly, which is in a way like more complicated to think about.

And then you have to have the context of like, well, what does, like, does it go to this place?

Because is it being handled elsewhere or not?

If there's an exception at this line, then what is the global state?

And if I throw an exception on this line, is the state different?

Exactly, right?

And so, like, I mean, you don't have ADD, but you feel the pain, right?

Oh, yeah, yeah, absolutely.

It's not just me, like, it's painful.

But for somebody with ADD, you really feel that.

And so Elm is incredible for that reason.

So there's a lot of things that I find like easier to read, easier to understand,

and I feel like they often complement your, an ADD person's mind.

But it's hard for me to understand where lies the line between this is easier

and this is less things to hold in your head.

Yep.

Right.

That's what I'm trying to figure out with this conversation.

Yeah.

So you said that there's a lot of less things in Elm, right?

There's inputs and outputs, and from there on, you basically have the same things over and over again.

And that's partially due to Elm's design, no side effects, immutability all the way.

But also, Elm is a very simple language, right?

There are few things, few constructs.

You only have, if you want branching, you only have if,

you only have case expressions and function calls, recursion.

That's pretty much it, right?

Does the fact that Elm is a very simple language make it easier?

Yes.

Or is it just, well, it's easier, but it doesn't reduce the number of things in my head?

No, it's both.

I mean, it's easier because there are, I mean, it's like that checklist at the grocery store.

You're standing there with the checklist, and it's a lot of effort to keep looping over things

because you know you might miss something, you might forget a detail.

You're looking at your list and trying to figure out which ones do I have already taken.

And every time you look at one item, you look in your baskets,

and you say, okay, I have it, and the next one.

Exactly.

And in other languages, you would have four baskets to look into instead of one.

Right.

And even better, if you have like a list on your phone,

and as you check things off, you know, I check this off, it goes out of my list,

I'm no longer looking at it, I know it's in my basket.

And when there's nothing left on the list that's visible,

then I go pay for it, and I'm good, and I know I didn't miss something up.

You've externalized that process, and that's what it feels like with Elm.

But, you know, you, so like there are fewer language features to think about.

Is there some exception to this rule?

There's less state, there's less, you know, like an if takes a Boolean,

and a type is explicit about, you know, it's a tagged union type.

It can't be any type, you can't cast it, it can't break the rules.

You, you know, you have, you have just a much more constrained system.

You don't, you don't have to worry about using double equals or triple equals.

You don't have to worry about, and even just like the design

of the standard APIs and all these things.

And it's really like, I was just, I was just working on something in Elm pages

with the v3 API for managing cookies.

And there, so there's this, there's this flag you can set on a cookie for HTTP only.

If a cookie is HTTP only, then it can't be read through JavaScript,

which is a potential attack vector that you remove.

So if you can only manage reading state on the server side,

then you can reduce a vector there.

So I made a tweak where, like in the browser platform, it's an opt in flag.

You, if you add HTTP only, then it won't be visible in JavaScript.

If you do document.cookies, but I made it in, in the Elm pages API,

I made it opt out.

So by default, the initial settings for, for creating a cookie is HTTP only.

And then you can set a flag and you say exposed to JavaScript.

And so if you think about the workflow, somebody is going to be creating cookie

options if they're intending to use it from JavaScript, then they're, you know,

and they haven't used that API or forgot how it works.

They're going to run their code.

They're going to try accessing in JavaScript.

It's not going to work.

Then they're going to look at the docs for that and say, did I do something wrong?

And then they're going to see opt in to JavaScript.

So that's just a subtle design choice that makes it safe by default and sane

by default, and that I think is an undervalued, underappreciated aspect of,

of Elm is how sane and well thought out the core APIs are and the package ecosystem.

There's so much love that's put in by package and framework authors to making

these subtle design decisions that make it more intuitive to do the right thing

and constrain the space to be a valid space to make impossible states,

impossible states, impossible to, to just make it safer and saner to work with.

And that makes a huge difference because suddenly that's, you know, that's not this

like PTSD experience where you're like, okay, I've been bitten by this operator

before.

I forgot to use triple equals here and, and you just have to constantly

hold that in your head.

So is condition something that gets easier with programming experience?

For instance, do you get less distracted by things that you have become familiar

with, like for instance, the some pieces of magic in language or even just the

syntax of a language, right?

I think a very clean mental model is just qualitatively different.

Like you, there are certain models of programming that require you to hold more

in your head, and I think you can design your code in a way that it requires you

to hold less in your head as well.

And, and, you know, for example, I think opaque types are huge for reducing what

you hold in your head.

So you, I mean, if you think about, so, so I've mentioned the getting things done

philosophy, and I think it's really at its core.

The idea of the getting things done philosophy is get it out of your head and

into a trusted system.

That is like the whole that that's it.

If you understand that you understand the philosophy.

So the idea is like your brain will keep bugging you about something.

If you have something you're like, oh, I have to buy batteries.

Your brain is going to keep remembering that, but not at a convenient time.

It's going to remind you in the middle of the night when you're, you can't do

anything about it.

But if you have your grocery list, now, if you have a grocery list and it's

shoved off in a corner, it's shoved off in your pile of magazines, that's not

a trusted system.

A trusted system is a system, you know, will present you with the appropriate

thing at the appropriate time.

And so if you have a trusted system, you have a grocery list and you trust

yourself to see that at the appropriate time when you're at the grocery store

and can buy batteries.

It's trusted because the habits you build that that is your system.

You go to the grocery store and you use that list.

So you trust that you will get there.

Now, in the middle of the night, your brain isn't going to remind you of

that.

It's going to let go of that.

So you get it out of your head and into a trusted system.

And to me, that is what the Elm compiler allows me to do.

And that is what opaque types allow me to do even more.

If I can have an opaque type and I say, OK, well, this is a username.

Well, is this a valid, is this string a valid username?

Did I remember to to check that it's valid?

Am I going to be presenting this thing in the wrong place and pretending it

or is it an empty string or is it a guest logger or whatever it is?

Opaque types allow you to put it into an externalized trusted system.

And to me, that is the power of opaque types.

It reduces the space where you have to think about something and where you

don't have to think about something.

It's putting the urgent items in the stack of magazines versus having it

in a trusted system where these are the things you know you need to be

focused on and need your attention right now and everything else does not

urgently require your attention.

Now onto a topic that I don't care at all, linting.

Yeah.

So a lot of linters one way or another through code formatting, code linting,

code style linting or enforcing code style rules, they basically try to

make your code consistent, right?

Yeah.

And I feel like that would probably help you, right?

Yeah.

Because you get less unexpected code constructs and you can go from one

pattern that you know to another pattern that you know because it's the same.

So do you try to have some pretty exhaustive linting rules when you code

usually?

Yeah, I mean, definitely.

Having the no unused Elm review checks are amazing for that.

I mean, just for one thing, just for the process of tidying up your code,

it's really nice to have that, you know, helping you do that, to have that

assistant to help you.

That's one less thing to have to be cognizant of.

So you don't have to have that in your mental checklist.

Oh, make sure if I delete some, if I stop using something, I have to be

thinking about am I removing it?

But also, if you trust that there is a tool that at every small step is

removing unused code, that's another thing that simplifies the mental model

of how you reason about your code because, oh, there's this bug.

Well, here's this function that looks like it could be suspicious.

Is it getting called anywhere?

You don't have to ask that question.

That's one less question you have to ask.

And this is a very cumulative effect.

So something that seems like a tiny cognitive load adds up over time.

And again, you know, I think these, you know, ADD gives you more nerves

for sensing that cognitive load and any everything helps.

It's cumulative.

And the more you can reduce that, I mean, we all have a small working

space in our minds.

That's just a fact of the human mind.

And I believe we're all more powerful when leveraging external systems.

That's one of our superpowers as humans.

And so using that makes us stronger.

And yeah, a linting tool, Elm Review, is an external tool.

It's an additional tool that removes some of those things from our

working memory and holding it in our head into a trusted system.

Now, that said, yes, it's trusted.

Trusted system, it's only as trusted as you make it through automation

and a consistent workflow.

So, for example, like to me, I would say that a code formatter, a linter

Elm Review that is applied in a non systematic, non automated way.

It doesn't run in CI.

It's run occasionally.

But like, there's not really a quick feedback mechanism or anything

that's like sometimes it just doesn't get called and there's just,

oh, this code didn't get formatted.

And then somebody goes on this code base and saves it.

And there's this diff that has all these changes or something.

That is not a trusted system.

It's not a system at all.

It is trusted.

If you remember that you have to run it.

Exactly.

Exactly.

So if you're requiring your brain to be the trusted system, then that

is not ADD friendly.

I think it's not brain friendly in general, personally.

And not seem friendly as well.

Exactly.

Exactly.

So I think it's crucial that you have your source of truth and that

that be your trusted system.

And also the more you can make things actionable.

So again, like getting things done, getting things done, if anybody

listening has ADD and has not read getting things done, there are

definitely some details about managing paper based systems.

I think there's an updated version that's like a little less paper

based, but there's so much gold in just how to think about working

with your brain.

So what about code style?

So Elm Review is not very keen on code style rules because we have

Elm formats.

But recently, like someone realizing that there's difference between

code style and code layouts.

Yeah, code organization.

Yeah, which functions to use versus how is this curly brace positions

compared to something else.

Yeah.

So a lot of lenders have a lot of rules on how to enforce code style

and code formatting.

Does that part, is that part useful as well?

Yeah, I mean, it's one less thing to be thinking about, to be juggling

in your head.

I remember, again, in my Ruby on Rails days, I'm sure this has

changed with automated formatters now, but I remember spending a lot

of time in code reviews talking about subtle style changes.

It's just more to think about and more distractions.

So yeah, the more you can build those things in to be things that

are automated and taken care of for you, it's going to be more

manageable.

So like automation is huge and it's getting things done has this

concept of amorphous blobs of undoability, they call it.

And I love that phrase.

Say it again.

Amorphous blobs of undoability.

Actually, we talked about this briefly on our productivity episode.

The idea is that if something is not clearly defined in an actionable

way, it will repel you.

And that's very true for me with my ADD.

So if you say like the classic example, I probably gave this

example in our productivity episode, would be mom's birthday.

If you have that written down on the list, you're going to be

having a lot of anxiety about what about mom's birthday?

And for somebody with ADD, you shove that off somewhere and don't

think about it.

But now if you change it to so getting things done would call this

processing that item, turning it into something actionable, a

physical actionable next step.

Like, what are you doing about mom's birthday?

Are you planning a surprise birthday party?

And what is the next thing you do for that?

Are you sending out an email to somebody?

Or are you buying flowers?

Or what is the actionable thing?

So you say, OK, buy flowers and a card for mom's birthday.

Now you're like, OK, I need to go to the store and buy flowers and a card.

Now that's your actionable thing.

And it's not repelling you.

So having things be actionable is huge.

And sometimes when things are when you don't have clearly defined

styles, it feels like that's another thing you have to think about.

Like, what is what is the next action I'm going to take when you

don't have like a clear guide for organization?

You know, things like a style guide or a clear process for how you're

doing something can really help with those things.

And I think it can benefit any organization if you have, you know,

a clear set of steps for doing something and then automate it as

much as possible.

That clarity can help the whole team.

It's not just something you have to reinvent every time.

Like, that's a lot of effort.

And the way our brains work also, like, you know, there's the

there's the hardware and the software.

Like, the hardware is our habits.

And if you can burn something into a habit, it requires less exertion

and less willpower.

And there's less of a cost on our brains.

So I think that benefits any team to, you know, to be a little more

systematic, you know, not micromanaging people, but figuring out

effective processes that reduce the amount of things you have to

reinvent every single time.

Yeah, that brings me to another point that I was going to ask.

So we've talked about things to make it easier for you with ADD or

without ADD to work with code and doing your groceries.

What would you do if you had someone on your team with ADD or lack of

attention problems?

Would you change?

Yeah.

What would you change to your code or to your process?

You said automation.

That absolutely.

Would you write shorter functions?

Would you have meaningful names?

Basically, what else?

Except what people just call better code.

Right.

Well, I mean, to me, it's very hard to separate the two.

In fact, I've sort of like built my career around that concept.

Like, in a sense, I'm like, you could call me an ADD consultant or

like a technical practices consultant, right?

Like, what's the difference?

That's my secret sauce that I use my ADD as my canary to discover

these systematic approaches that I can then teach.

And now it's software craftsmanship.

Ta da.

But yeah, I mean, writing things down and getting them out of your

head is very effective.

Like, for people with ADD, having things in a continual state of

completion is amazing for ADD.

You know, we've kind of talked about that in the context of shipping

side projects.

Like, for me, if I have code in a place where I can step away from

it anytime, there's a talk by Llewellyn Falco that I believe you

might have watched this one.

It's called Practical Refactoring.

Llewellyn Falco and Woody Zuhl set up a five minute timer.

Oh, yeah, yeah, yeah.

And then they do refactoring on a code base that, you know, is a

legacy complicated code base.

And they do these refactoring steps without understanding the code.

So rather than saying, OK, let's understand the code so that we can

then change the code, they say, let's change the code so we can

understand the code.

If you think about that through the lens of ADD, what does it mean

if you have to understand the code so you can change the code?

It means it's more amorphous undoability.

What are my next steps?

There are all these things combined together.

It's more working memory space.

You have to hold in your head, what is it doing before you can refactor?

But then you also have to be thinking about, what am I going to refactor?

Yeah, exactly.

You're not leveraging things.

You're doing two steps in one.

And also, like, what are the possible consequences of your changes?

Are they going to be problematic in some way?

Do you have something to worry about?

Additional steps that you will have to do afterwards?

Exactly.

So now you're looping over that checklist in your head.

Every single step you're making, you're looping over that checklist.

Now flip that on its head.

And now we're going to change the code so we can understand it.

So what does that mean?

It means we have to do safe changes.

What do safe changes mean?

They mean you don't have to understand it in order for it to be safe.

Because you're using an automated tool to change a method name.

You are using an automated tool to extract a variable.

And those are safe.

You don't have to do anything else than just activating that refactor.

And following the compiler's errors,

and he's introduced by that,

if you rename something and then it tells you,

oh, there's now a shadowing error,

okay, well, now I know what to do.

I don't have to think about it.

If there will be a shadowing error, I will be notified.

Right, exactly.

Yeah, and you can use these safe refactoring steps.

You know, Martin Fowler's book refactoring talks about

the manual steps of what a safe refactoring looks like.

For example, introducing a new function and things like that.

And ideally, your tool is safe.

Your tool does have these things built into it,

so it's offloaded from your head.

It's externalized into a system that you trust.

But if not, a close second would be doing repeatable safe steps.

As you say, you know the things to check.

You know the one thing you're focused on.

And so I'd say that's huge, is working in that way.

I highly recommend that people check out this video practical refactoring.

They put on a five minute clock, and at the end of the five minute mark,

they have to be in a committable state,

where they could ship it to production and it goes live.

And that is extremely powerful.

The idea was that you could do this before a meeting or something

and then be done right.

Exactly.

And if you think about that from an ADD perspective,

if you say, hey, I can walk away from this,

well, what are ADD people known for?

Getting distracted by shiny objects?

Well, yeah, that's kind of true.

But if you design your workflow in a way that you can walk away from it

at any time, that is huge.

It turns out that it also just makes the next steps more clear

because you start by reducing the number of things

you need to hold in your head,

and then suddenly things are more clear and your next steps become more clear

and you're thinking about one step at a time, breaking things down.

So yeah, I highly recommend that video.

Now, there are organizational things often that need to happen

in order to get to that state, right?

And that's sort of what I did in my past career as an agile coach

was helping teams and organizations with these kind of big boulders

that you have to move to make that possible, right?

Like, oh, well, this team doesn't have permission to touch this area of code

or to ship this or to make this change or to...

Or we don't have the automation to deploy to production

without doing a two week QA process first.

Those aren't things you can flip a switch and change overnight.

Those are processes that you need to really deliberately work on as an organization.

But I think they're essential for an effective software process

and particularly helpful for people with ADD, but for everybody.

Quick feedback loops, right?

Yeah, exactly. And quick feedback.

You know, another thing for people with ADD,

if you have... People with ADD tend to have this concept of time blindness

where it's hard to see the bigger picture and piece things together

and just take a large task.

That's a lot to hold in your head and it's too much to process.

So it really helps if you break things down into smaller milestones

and it also helps with the motivation if you have lots of small wins.

And so that's huge for people with ADD.

So if you can chunk things down into small wins,

a commit is a small win, a tiny slice of a feature is a small win

that is shipped to production, by the way.

If it is a tiny commit to one system that is not going to be used

until one month of QA at the end of the year,

that doesn't feel like a win for somebody with ADD.

And it's not a win for the company either

because nobody's getting value from that code you wrote.

Yeah, because you will have to remember all the things that you did

when QA comes back.

Exactly. And you might have messed something up

and you will find out about it later.

And now that's another thing you have to hold in your head.

So the faster you can validate things,

the faster you can get them out of your head

and move on to focusing on the next thing

without being pulled by this distraction of,

did I mess something up?

Do I have to have this checklist and keep this in my head?

You can let go of it.

So what is time blindness?

Time blindness, it just, you know,

people with ADD tend to do things last minute

because their sense of time is skewed

and it's harder to manage.

From what I understand, ADD is related to the executive functioning

in your brain and impulse control.

And so some people might hear a distraction

and be aware of its existence, but not like,

oh, hey, that reminds me of this other thing I want to talk about.

Somebody with ADD is going to go off

and they're not going to filter that out

and they're not going to filter those distractions

so they can't filter out those noises and say,

this is the thing I'm focused on, not that sound I heard.

And their sense of time is,

they're not as good at managing time

and chunking things in to manage that effectively.

So suddenly a talk that you were going to give five months from now

is a talk that you're going to give tomorrow, for example.

It's that concept of time,

it's hard to kind of break it into those milestones.

So it's very helpful to do that in external systems

where you're getting rewarded for those things,

where you're feeling the joy of accomplishing those smaller milestones

and especially if they're real accomplishments

where you've actually done something.

Maybe the big conference talk you're giving,

maybe you give a meetup talk

and that's like an intermediary milestone

that represents a meaningful thing that you've accomplished

but it brings that time scale more into focus

because it's very hard to see time clearly in the big picture.

So I have not been diagnosed with ADD,

but I do feel like I have a lack of attention.

I'm guessing a lot of people listening to this will also feel like that.

How does one get diagnosed with ADD?

Oh, that's a good question.

I mean, I'm very much not an expert on this.

I was diagnosed in high school.

I'm guessing it will also depend on your country.

Yeah, your country. There are like online services,

but from what I've heard, there can be a sort of financial incentive

for them to tend to diagnose you

and so it might not be the most honest way to diagnose yourself.

So I don't think I can give effective advice on that one.

I think people are going to maybe need to do some research on that themselves.

But it's definitely a very interesting thing to know

and I will again recommend to anybody getting things done as a goldmine.

So if you feel this type of pain,

I would highly recommend checking out the book, Getting Things Done,

or audiobook if that's easier for you.

And I would highly recommend watching

Llewellyn Falco and Woody Zool's Practical Refactoring Talk.

Those things have really changed the course of my life.

A lot of these strategies, I'll also say like in a non technical sense,

like regular exercise for people with ADD can be huge

for having more ability to, you know,

you just feel more grounded and regulated

and it's easier to focus.

Meditation can be extremely powerful, mindfulness meditation.

I've also come to really embrace some of these ways that my brain works

and rather than feeling guilt or shame about them,

I've just learned like these things are things I know about myself.

I know I'm setting myself up for success when I take that into account

in the way I do things and when I put things into external systems

and I just accept that there's no shame about it.

It's just this is how I work best.

And so I need to like if I want to remember to pack things for my trip,

I need to write a list. It's not a big deal.

It's just something I need to do.

I have a much clearer picture now.

Do you have anything else that you want to ADD to the topic?

Are you trying to distract me with shiny new topics, Jeroen?

Shiny new puns.

I know that will distract you.

That's fair. That is fair.

Yeah, I mean, I would love to hear other people's experiences with ADD

or without ADD.

Do people subscribe to my canary in the coal mine theory?

Every time you say that, I feel like you're going to kill a bird.

It's just it's horrible.

No birds were harmed in the making of this podcast.

But please don't mine.

Yeah, so I wonder if I've now been exposed as a secretly

is Elm Radio actually just an ADD podcast?

Because we're kind of talking about the stuff that we normally talk about.

That is true.

Yeah, so, you know, if anybody listening to this wants to learn more,

check out our productivity episode.

We talked about a lot more specific things that, you know,

Pomodoro Technique and some useful tips there.

Listen to our incremental steps episode.

That one's huge.

And I feel like we have a lot of episodes that go into that direction as well.

Absolutely.

Big types. Always listen to our big types.

Mandatory listening.

And get things out of your head into a trusted system.

Write notes, separate actionable notes from non actionable notes

or a, you know, to do list.

I really like keeping a to do list as I write my code.

That really helps me stay on track and stay focused and slice things down

in smaller pieces.

Keep that looping checklist out of my head so I can focus on the task at hand.

So and just, I mean, yeah, Richard's scaling Elm applications talk

really hits at this too.

It's about reducing down the possibility space,

you know, reducing down the constraints of what data you might be dealing with

in a function. Parse don't validate.

Opaque types.

Making the impossible states impossible.

Making impossible states.

If it's impossible, then it's out of your head.

If it's improbable, then it's in my head.

I will tell you that.

Yeah, actually most of the good techniques that we love in Elm are valuable, right?

In this context.

Very much so.

Yeah.

So if anybody listening to this has ADD, I would love to hear more about your experiences

and your room.

Until next time.

Until next time.