Incremental Steps

Incremental Steps

We talk about the value of taking small steps, and techniques to help break problems down in Elm.

PublishedOctober 19, 2020

Episode#15

Dillon's Elm Europe talk Incremental Type Driven Development
Test driven development
Fake it till you make it
elm-markdown GitHub-Flavored Markdown table live stream
Succeed is the key to success
Practical refactoring with Llewllyn Falco and Woody Zuill
Llewllyn Falco doing Gilded Rose kata with TCR and snapshot testing
Dillon's article on Relentless, Tiny Habits

Transcript

Hello Jeroen. Hello Dillon. How are you doing today? I'm doing quite well, how about you?

Doing good and today we're talking about one of my favorite topics and hopefully something that

people are practically bored of hearing me talk about. If that's the case then I've done my job.

So what are we going to talk about? Today we're talking about incremental steps. So this is really

a way of life in my mind. It's been something that I have been very influenced by this way of thinking,

working in tiny steps and I just find it so much nicer and I find that I'm so much more productive

when I use tiny steps. So I'm looking forward to diving into this topic. Yeah, we met last year at

Europe and you were doing a talk on this subject exactly. Yes. So I know you as this guy. Oh nice,

that's not a bad thing to be known as. I like it. It's definitely on brand for me. That and ElmGraphQL

all the time. Yeah. The more I know about you, the more it's incremental steps and that Elm pages

you can't stop talking about. That's true. That's true. The JAMstack has been a fun one too. But

yeah, incremental steps are huge if you will. Pardon the... Yeah, I had to. Okay, so can you

can explain what tiny steps are? Yeah, so to me a tiny step is a way of breaking down a larger problem

into a small action that makes visible progress, not theoretical progress but concrete progress.

So I think of it like a pulley that you know, I can't lift a car. That's actually not really true.

I actually can lift a car very easily if I use a pulley. If I have a pulley and I spread that work,

that force I need to apply over a large enough area, then I can very easily lift a car, right?

And to me, that's what the power of tiny steps are is I can take a problem that's too difficult

for me to solve, just flat out, okay, go solve the code. Go lift that car. Lift that car. I can't do

it. But if I break it down and stretch it over a larger area doing many, many tiny steps, then I

can do it with ease. So to me, that's what a tiny step is. Okay. So what does that look like in Elm

code for instance, or in programming in general? There are so many forms it can take. I think one

of the clearest forms of this idea is this concept in test driven development of fake it till you make

it. But as I sort of showed in that Elm Europe talk, you can apply fake it till you make it,

even if you're not doing test driven code. So like, I mean, there are many cases when I wouldn't,

for example, test drive, like writing my view code, like, I mean, you can use Elm program test

to do that sort of thing that I generally don't test drive my view code, because I sort of just

change it until it looks like I want it to. And that's, that's, that's usually fine for me. I

usually instead try to test the logic behind the view code, because that's the interesting part and

separate those out. But so like, you know, like I showed in that Elm Europe talk, without actually

writing tests, you can apply that same principle from test driven development of fake it till you

make it to to write your view with all the right values, that the values are completely faked out.

So you haven't done any logic to drive those values, but you know, they're the values you'd

like to have. So it's sort of like wishful thinking that you wish you had this interface to grab this

data, you make it so by just wishing it into existence, and faking it till you make it and, and

that allows so in that process, you have done nothing, right? You've done no logic, no difficult

work, but you've also done everything because you've completely wired it in, you've got working

code, you can look at it in the browser, you can make a change and see it reload. So you've done

none of the hard work. And yet you've done all of the sort of wiring and all of those things. So you

don't trip up on those details. And you have a point to iterate on.

Gotcha. Well, when you say fake it until you make it, you do need something that tells you whether

you made it or not. So in yes, in test driven developments, that is when the test the tests are

green. And when you what you showed in that Elm Europe talk is that you were using the compiler,

if the compiler tells you that it's that everything is okay, then you've made it.

Right? Yes, exactly. You need some sort of feedback loop. And I think in that talk, I was also using

live reloading as a type of feedback loop. So we sort of had the view, presenting the information

we wanted, we weren't actually looking at the JSON value to start. And then we started actually

pulling out that JSON value. So anything so there are many ways to, to break things down into

smaller problems like that. And I just find like, you can think of it as a sort of putting all the

risk upfront. Because you, you want to find out, if you're going in the wrong direction, you want

to find out earlier. And so taking smaller steps allows you your the goal is to get to working code

as soon as possible. And so there are a number of like techniques that then make this easier. Like

one technique is, you know, if you're processing a list, maybe you can have an empty list, or maybe

you can have a single item in that list, right?

Yeah, and it could be hard coded.

Exactly, you can hard code a value. I do this often with like, when I'm working on Elm parser stuff,

like Elm Markdown, I will start with, hmm, I really wish that this part of the parser that I'm

working on, you know, like if it's a GitHub flavored Markdown table, actually, we did a we did a live

stream where we built that initial code for that feature. And we used a lot of these techniques. So

you, you know, you say, Well, I wish that I had this data structure coming back from this parser.

When I go over this GitHub flavored Markdown table, I want to get this data so I can turn it into,

you know, the rendered Markdown, you know, the the destination, the goal, and you just sort of

short circuit getting there as fast as you can, by passing through a fake value. And then you've,

you've wired things through all the way. So like, you can't get feedback until you've wired things

through. So the goal is to have as short of a window of time, where you've cut off your feedback,

you want to be in a constant feedback cycle.

Yeah, the main idea I get from tiny steps is shorter feedback loops, the shorter, the quickest

you get to your feedback, the happier you will be, because you will be able to check whether your

assumptions are right, whether things are possible this way, you will notice problems early on, just

like when you're doing startup, like you do an MVP, but the smaller your MVP, the easier, the

quicker you will get your feedback. And exactly, the better you will be able to be flexible around

your choices and everything.

Yes, exactly. I completely agree. I think it's the exact same principles at play with, you know,

that sort of MVP thinking, it's just a way of shortening the feedback loop. And like, to me,

these, these are the physics of the software world, or maybe maybe not even just the software

world. If you, if you don't have feedback, then you don't know which direction to go. And so you

can, you know, I mean, it's like, if you're, if you're lost in the woods, and you just start

walking, you don't know if you're making progress, you could be getting more lost by walking.

But if you're lost in the woods, and you know that you need to get west somehow, and you have a

compass, then, you know, you might not go in the perfect route, but you at least have a sense of

whether you're going in the right direction. And that's what feedback loops give you, they give

you, it just feels like you're going blind, if you don't have a feedback loop, when you when you

build this habit and get used to working with tight feedback loops, then you feel totally blind

if you don't set them up. So like, the first thing that you want to do is set up a feedback loop,

because you just don't have the patience to like, go in the wrong direction. Like one place that I

see these short feedback loops at play is with when I'm helping people with Elm GraphQL questions.

The first thing I think of if somebody's like, I can't get these types to line up, which happens

often, right? I mean, it's, yeah, it can be overwhelming, like you're dealing with a lot of

different types, you have the, you have some phantom types, and you have to piece all these

things together. And, and people can get really stuck on just like a big compiler error, right?

And whenever I get a question, when somebody's in that situation, I always start with, how can we

break this down into a smaller step so you can get feedback? And actually, sometimes in those

situations, it's better to just revert to the last working state. Oh, yeah, yeah, exactly. Like, if

there's one thing that I've learned from this whole tiny step that you've shown me, like, if I

notice that I'm doing something that is too big, like, well, okay, the problem with doing things

that are too big, is that you have plenty of things in your head. And you need to do plenty of

things like, I need to add a message, I need to handle it in the update, I need to handle it in

the view, to call it in the view. And if you try to do that all at once, while doing a refactor,

yes, exactly, while doing a model change, like, you will get lost. At the end, you, the compiler

will help you out and all. So you will get there. But it will be much longer, and sometimes more,

way more confusing than if you did one thing at a time. If you did, yes, the refactor of the model,

as a one step, yes, you make it a compile, you make the test pass and everything. Then you add

that button, but it doesn't do anything that compiles the test pass, and so on and so on. Then

you do the message, the update, and so on. And every time that I find myself doing too many things

at once, often I will just delete what I just did, like, okay, revert and start one thing at a time.

And that is one reason why I try to commit more and more often now, so that can easily,

can revert back way easier. Exactly. Yeah, because when you get something that you know is working

and something that is almost working mixed together, then suddenly everything is effectively

not working. Yeah, yeah. But if you know something is working and you commit it,

then you have a point to fall back to if things go wrong. I use the Git gutters, the little sidebar

with the colors for the Git diffs in my editor all the time. I very heavily rely on that to

understand, like, okay, what are the things that I am changing? What could be causing a problem?

Because I know I was in a working state before I made a change. So with like Elm GraphQL,

when I'm helping people with these types of problems where they get stuck in too big of a step,

one technique I recommend to break down those problems is to just start with getting the type

annotation right for this thing you're passing in. Like, if you've got a function that takes like a

nested selection set, you know, it's like you've got a person, you're selecting some fields from a

person and you want to grab a couple of fields off of that person, then get the type annotations

correct. And you can even use, you know, selection set dot succeed, which you can annotate with any

type annotation. So once you do that, now you know the problem you need to solve. It's this one small

problem. I need to build up something of this type, which is not such an overwhelming problem.

You know exactly what the goal is. You know if you're making progress towards it or not. You've

put in a type annotation on this smaller piece, and therefore the compiler is going to give you

even more fine grained feedback on that small part that you've labeled with the annotation.

And so suddenly, now it may be that the problem was somewhere else, or there are other problems

you have to fix, which is also good feedback. But you want to find a narrow thing to solve and hone

in on that and just follow that path through until it's fixed instead of like working on 10

different problems at once. This is another thing I see often, you know, just, you know,

like you were saying, having like you're changing the way you model some data, your model changes,

you're wiring in a new message, you're changing the view, you're doing all these different things

at the same time. It's like when you get used to this way of working in tiny steps,

all of that sounds extremely stressful. Yeah, it requires a bit of discipline not to do

too many things at once. But if you get in the habit of doing things in tiny steps, like, okay,

that discipline is just asking you to hold off for like a minute or 30 seconds. Stash everything,

stash everything, rename that model field, commit, then unstash and you're back to where you wanted

to start this whole refactor or something. Exactly. A new feature. And you know, one tiny step that

maybe doesn't get the credit it deserves is writing something down in your to do list.

If something comes up, you're like, I want to refactor this, I want to, you know, like,

change this value in the model, I want to wire in this message, just have a to do list of the things

that you're doing in the next 10 minutes or whatever, that's fine. Like, don't just start

writing the code, just write it in your list, and you'll get to that next. But don't start it until

you finish the thing you're doing right now. Yeah, the good thing with the compilers,

it tells you what you need to fix. So if you do all the changes, if you start all the changes at once,

that the compiler is your to do list. But if you do tiny steps, then you can't use a compiler as a

weird kind of to do list. And yeah, to the list will then be a better to do list than the compiler

to do list. Right, right. So one technique that I think is worth talking about here, starting with

a fake value is a really good starting point. But then how do you take that fake value and turn it

into a real value? And there are a lot of techniques that help with that. So I really like

this technique of separation, Luell and Falco calls it separation, I think, kind of pulling apart

these fake values and splitting them up into multiple fake values, like taking a string and

then separating that string into two strings that are concatenated. That's like a tiny step that

allows you to take this big hard coded thing and turn it into two smaller hard coded things. And

that gives you a sort of insertion point where that you can remove some of that hard coding. So

once you have a fake value, then you want to take tiny steps to make it real values. But you don't

just put in a fake value and then replace that with a working implementation where everything is

there. So if you run through this example, like for instance, you have someone on your page,

you have a text that says, Hello, Dillon. Mm hmm. Mm hmm. So you start by hard coding, Hello, Dillon.

Yes. What you then do is like HTML that text. Yeah. Mm hmm. Hello, Dillon. So what you then do

is you concatenate Hello and Dillon. So one thing that you will need to do then is probably put

parents around it. Otherwise, it will not compile. Mm hmm. Yes. Something that you would have run

into later as a compiler, but that you could fix right now with just this

very tiny step. Mm hmm. Yes. And then what you and I would even do a little step in between there,

which is I would commit that. Yeah, yeah. I know it seems I know it seems really extreme, but I

really do make very small commits. Well, you know, the the best benefit of tiny commits is that very

nice commit contribution graph on GitHub. I know. I know. It's true. Yeah. My repos all.

You made 150 commits today. Wow. He's so active. Exactly. My repos really have like massive

commit counts on them. It's funny. Yeah. Yeah. So you separate those two in Helen. Hello, plus Dillon.

You commit that. I'm not going to say commit every time, but yeah, then you can just run

it. I'm not going to say commit every time, but yeah, then you extract Dillon into a variable.

Yes, exactly. Lead variable or something. And then maybe you want to pull it out from the model.

So what you then do is you remove it, remove that lead variable and use model dot name.

And then we'll tell the compiler, tell you, oh, well, name is not a field in model. OK,

add that field and how you could hardcoded to Dillon. And then you need to get it through a

dynamic value somewhere. So maybe you need to decode it. So you will add that decoder.

Yes. And you can hardcode that with the decoder succeed because that's yep.

Succeed is the key to success. Exactly.

And then once you have that, you can probably just do decode dot string and then get it from a real

value somewhere. Yeah, that's right. At that point, you've pretty much wired it all the way

through. Yeah. So and all in all, we did what we did. One, we avoided one quoted tricky compiler

issue with text having two arguments or something. We added a field to the model. We decoded it.

And every step of the way was very easy. Whereas if we did that to start with, then

yeah, it would have been too much. This is the way I did it previously. Like, oh, I need a name.

OK, so let me add it to the model. Oh, now I need to get it from a value from the HTTP request. OK,

so I need to decode it. And then I do the whole update to do everything. And then I

display it. And yeah, when I'm there, it's done. But I didn't have a small feedback loop. So

I couldn't notice that something was wrong until I was in the middle of it. And as we said,

if you're already doing something like adding a new feature, you don't want to change everything

because your assumptions were proven wrong at some point. Exactly.

Exactly. It's all about validating the assumptions as fast as you can. And with a very straightforward

problem like taking something from a flag, decoding it, showing it in the view, that might sound

forced. And it might be. I mean, we would probably be fine. We would probably be able to do it just

as quickly and with just as little risk if we did it, you know, decoding it right away. But that's

not that's not why it's interesting. It's interesting when you're solving the really

difficult problems and you have that skill set. Now it's really powerful. So, you know, I was just

working this last week on a feature in Elm pages where I'm I'm getting rid of Webpack and doing

a new build process, which I'm very excited about. It's kind of intimidating, you know, it's like

it's a big change. And I mean, I can't even imagine just working in the dark for days and days and

days, like building all these different features like, oh, I'm going to need something that outputs

this HTML and uses this template for the HTML and then, you know, fetches this data and whatever.

It sounds like a nightmare to just be working in the dark. So I want something that works right

away and to just even know that I'm going to be able to wire these pieces through and the

architecture is going to fit like I need to know that right away. Otherwise, it's just terrifying.

So and that's that's what I did. I started with just getting a hard coded thing working end to end

as fast as I could. And I did that by just saying, OK, I'm I'm going to assume that there's one page.

I'm going to assume that I'm I'm, you know, doing a Webpack free build for a site with exactly one

page. And if it doesn't have that, then I'm going to fail. And I'm going to assume that there's not

an error. And I'm going to like make all these assumptions and just cut through this one path.

So instead of doing every case partway through, you want to do one case all the way through end

to end and see it work. Because if you don't if you don't do it end to end, you can't see it

working. So and if you start trying to handle every case, it's only slowing down your ability

to see it working end to end. And what you want to do is you want to see it working end to end as

soon as possible, which means just relentlessly focusing on that one case getting all the way

through. So so that's what I did. I got it all the way through, made as many assumptions as I could.

And and then I started iterating from there. And I had a test harness that I could iterate on and

and do those other cases. So with more difficult problems, it's so valuable to to have that skill

set of taking these tiny steps. Yeah. So I told you before this that this weekend, I was working

on some kind of type inference for Elm review. So yes, there are some rules that check whether

you have type annotations for your top level declarations and your lead variables. And just

told you, hey, you need to type annotation here. Okay, thanks. That's not very helpful.

So I started working on having those type annotations work be auto fixed so that you

don't have to do anything manually. And what I did was I started really small, like because I need to

infer the type of thing. So what I did was I will do the whole thing for if the variable is clearly

a string. Oh, cool. Yeah. So if I see a literal string as a no, okay, just add the type annotation

where it says that it is a string. Because for the built in type, you can't do that for numbers

necessarily, because you don't know if it's an inter float. But for a string literal, you can just

give that fix. Yeah. Well, you for number you could but you just say number. Yeah, although it's less

satisfying. It is less satisfying. But that's what you got to do. So yeah, I made the whole thing

work for strings. So cool. Once I had that I could already run it on some of our projects and it added

strings everywhere. That's amazing. And that's and you've both done no work and a lot of work. Yeah,

exactly. That's a great example of that. And then yeah, I handle numbers, I handle the type

annotation, I handle hex literals, I handle parens, I handle binary operations, I handle lookups to

other variables. And all these things, they how do you say that they use each other? Yes, they build

off of each other. Yeah, exactly. Right. So every step is quite simple. Yes. And then very nice thing

is that since it's easy to test, I write tests for each step. And now I have a huge test with just

for type inference. Right. Yeah. And you've got the wiring, you get to build all of the wiring,

which is not easy. Like building wiring is hard. But you do that for string, like for if it's a

literal string, then the type is string. Yeah. So the first step is to build the type. And then

you build the string. Yeah. So the first part might have been the hardest. It's not, but it might

have been. And what is also nice is that I can already use this. I can already add type

annotations for plenty of things and just don't for all the things that are too complex yet or

not handled yet. So I can already see whether there are errors and I can go fix those. If I did

it the other way where I try to build the whole type inference things first. Well,

I would not be as happy today. I would still not have anything. And I actually wouldn't know

if I'm any closer to the destination. Exactly. And I guess that finding bugs. You'd be lost in the

woods without a compass. Yeah, exactly. And whenever people tell me, oh, you have a bug,

then yeah, I guess somewhere I need to find it, but now I can detect bugs as I go. Yes.

By trying it out. That's an amazing example. I love that. There's also one thing that you get,

even with very tiny steps where you hard create a thing. Like, you know, when people say,

when it compiles, it works, you feel happy when that happens. There's a tiny bit of dope and

new rush or whatever. But if you multiply the number of times that thing succeeds,

you have like, I won, I won, I won, I won, I won, I won. Yes. So many times that it's just like,

I always feel happy. Yes, exactly. It's true. I mean, there is a stress level when you've got

something up in the air and you don't know if it's going to be working like that feeling of like,

oh, come on, please compile, please compile. That goes away. And it becomes like, okay,

it is compiling. And then you do a small step and you're like, you do a tiny step and you're like,

oh, I hope this compiles. Oh, it didn't. Okay. I'll just go back to my starting point or revert

or whatever, you know, try again. Also, every time you save your file,

you get Elm format to format everything. So your code is more readable at every step.

So that's also one nice thing I found. Yeah. I think that working in this style of taking

tiny steps, it becomes harder to take small steps if you're not confident in the quality of your

code. So, you know, for example, if you, if you are working in code that has a lot of bugs,

it doesn't have tests, it has, you know, very large functions that don't have good data types.

And it's just difficult to work with. Then it's going to be hard to take tiny steps. So, and what

you're probably going to end up with in a situation like that is you're probably going to have a

manual testing process where, you know, eventually you end up with, you know, a testing team,

manual testing team, and they take a couple of days or a week to test the code. You have a code

freeze. And so now it's actually, it's the opposite of tiny changes. You make any change and you are

afraid of shipping it. And so you, you take a long time, your feedback cycle gets even longer because

not only can you not make tiny changes, but those tiny changes don't even get into the, into the

finished product until a few weeks later. So there's like a skill set around tiny changes and a set

of habits. And you can really learn those by, I mean, I think that practicing test driven development

doing Kata's is one of the best ways to learn those skills. And you really can learn them. But then

from the other, like the skills are like sort of on one side and on the other side are like sort of

the organizational pressures and processes. And you also need to approach it from that end and

make sure that you don't have things that are lengthening your feedback cycles. And it's all

about building in quality at every step because a tiny step doesn't mean, it doesn't mean getting

it compiling in one small step. That's one part of quality, but if it's compiling, but there's a bug,

the step is not done. It's not a step.

Unless it's a bug that you know and for which you have written a to do or...

Like, like I'm not going to handle the error case. I'm not going to.

Exactly. That's right. So the process is you don't need to handle every case. So you don't need

completeness, but you need correctness for every case that you handle, it needs to be correct.

And that's, it's complete once it's correct. And what happens is the, I think maybe the more

intuitive way to work is just to work on several things at once and try to, try to get to completeness.

And so you're moving in all these areas, getting, getting things towards completeness

and working towards correctness at every step. And the shift is you get things correct very

frequently. It's just very small things.

Yeah. As you said before, like take one path, the path that you really want to work and make it

work from end to end. So don't go for completeness yet. Just go for this path and hard code or mock

or debug to do the other paths.

Right. So now that's, that's another interesting case, the debug.to do. So I do make use of

debug.to do and it's a very helpful tool, but let's talk about that a little bit. When is debug.to do

the right tool and when is it problematic? When does debug.to do get in your way? Do you have any

thoughts on that? I have some.

It's not a tool that I use as often as I think I should. I do find it more and more useful.

The thing with debug.to do is that it allows you to write whatever.

Yeah. Maybe we should define debug.to do.

Yeah. So debug.to do just crashes your application. In Elm 018 was called debug.crash.

You give it an error, a string, and when debug.to do will be encountered, it will just crash.

Right. And the type is any. It's basically Elm's version of the any type, except instead of just

saying that some actual value is any type, it just won't execute it.

Yeah. And that is kind of dangerous, but you can't use the optimized flag with Elm make.

So you will not see this in production, so it's safe.

So the nice thing about it is that it bypasses the compiler. So you can use it instead of any

function or any type, whatever. The downside of that is that you can use it instead of any type.

So when what you want to get is a good type, like you want to make sure that a type is correct and

will be useful and that you have all the information that you will need, then it might not be the

right idea. Because you're not validating one path. Like, oh, I can show an error if I enter this

error case, but maybe you can't because you don't have all the information needed yet.

And debug.to do will not give you that information.

Right. Yeah. One thing that debug.to do is very helpful for is, in that case, I was talking about

earlier where you're trying to figure out the right type for something in Elm GraphQL. Some

function takes some selection set of a particular type. Then you know I need to pass something in

here, but I don't know how to build that thing. And in that case, you can just pass in debug.to do.

And that actually answers an interesting question, which is, is there any type that would fulfill

the type system here? If it's not compiling when you pass in debug.to do error message as the

argument there, then there's nothing that will satisfy the type checker.

I've never had that experience yet.

Yeah. I really like doing that. Maybe I'll have a chain, a pipeline of functions that I'm applying

and I know I start out with this value. I know I need to eventually get it into this function of

a particular value, but then is there some way to transform it into this type of value? So maybe I

say list.map parentheses debug.to do error string. That answers the question for me. Is there any

function that I can pass into list.map in this pipeline here that will satisfy the type checker?

So now if it's compiling, the compiler has just answered that question. Yes, there is. There is

such a function. You could have a function that satisfies the type checker when you call list.map

on it. If it's not compiling, then hmm, what am I doing wrong here? Oh, it's not a list. It's

actually a result string list of something. So now I need to do result.map around that list.map

or something. And now, so now I do result.map parens list.map parens debug.to do string.

So you're basically using debug.to do to figure out, are there any type problems in other places?

You ignore the ones that are local to where you put the debug.to do, but you highlight the ones

that are somewhere else. Yeah. So it's just telling you like, does the connection fit? Do these jigsaw

puzzle pieces fit together here? And so at that point, what I would do is I would take that

function that I was using debug.to do for, I would expect it to be a function that would

using debug.to do for, I would extract that debug.to do into a little let binding. And then

I would try to get a type annotation for it. And now once I've got that type annotation, so it's a,

you know, a function from string to int. Now I know that the compiler is happy and now I'm going

to just return a hard coded int of course, right? Because now I've got a real value. So I've faked

it and I've got it working all the way through. So debug.to do can be really handy for those cases.

I think that it's important to, you know, you want to use debug.to do as a tool to sort of like,

you know, you're sort of bulldozing through a problem. And I don't, you know, you don't want

to keep the debug.to dos in there too long necessarily. I usually use them as a shorter term

tool. There are, you know, there are times when I'll sort of like ignore an error case or something

like that. But if you use debug.to do, for example, to, instead of having a result, because you

ignore the error case and you just say, if it's an error debug.to do, you're actually sort of

deferring dealing with this problem that you're going to have to deal with. And you don't have

working code that whole time. So you can't ship it. So you've just structured your code in a way

where, you know, I was using this distinction of complete versus correct code that your code

doesn't have to be complete, but it does have to be correct. Well, it's not exactly correct. It's

not shippable when it's in that state. So that's not quite in the spirit of tiny shippable steps,

you know, that's sort of the goal is that they're shippable quality steps and you can't ship it. So

you can get yourself stuck in this situation where you're working for a long time with code that's

not shippable. So that's something to be aware of. I think that debug.to do is a very useful tool

for figuring out what step to take, but then follow through that step. And when there's a

debug.to do, maybe this is a good rule of thumb. So you can use debug.to do for sort of exploring

if types line up, if you're like designing an API, that's more in explore mode. You're not like,

your goal is not to build code. Your goal is to like learn and you could even throw that away

when you're done, you know, or you can use debug.to do to identify a step and then you

follow that step through. So just be sure that you're using debug.to do, you know, you figure

out the path and then you go down that path. You don't like ignore it for a long time. That's to

me, that's not really, that doesn't feel right when I use debug.to do that way.

Yeah. I guess when I've done the end to end scenario work, I guess I would go for the debug.to

do afterwards because those are like places where you still don't know whether things will work out

or not. Those are known unknowns and it's best to go and figure those out.

Exactly. That's exactly it. That's exactly the mindset is like you want to,

you want to, anything that's a risk, you want to get out of the way as soon as possible.

And if it's a debug.to do, you're cutting yourself off from understanding whether it's going to work out.

You're deferring that feedback, you're lengthening the feedback loop. So it's really all about feedback loops.

This is a question I asked you after the evening where we met. How often do you need to write to dos?

Because you're writing a lot of dummy code, a lot of hard coded code when you do this.

How do you make sure that you don't forget it?

How do you make sure that you don't forget to handle it?

I write to dos all the time. When I'm coding, I've always got, I use bare notes. It's like a

markdown notes thing. And I just put in like to do items as they come up. And I work in

Pomodoros most of the time, which is like you've set a 25 minute timer and work with no distractions.

And then you take a five minute break after. And when I'm getting close to the end of my Pomodoro,

I'll often make sure that I take all of the context that I had and dump it out into notes.

So I'll write down all the to dos that I can think of, but I'm constantly writing to dos.

And you do that at the end. You don't do it every time you hard code something?

I do both. If something comes up and I'm like, oh, I need to do this, then I'll write it down.

But then sometimes I need to take a moment to sort of collect my thoughts and think about where I am

and say like, okay, what are the next steps here? And I usually try to set myself up for being able

to jump in and have context quickly when I start my next Pomodoro. And so I'll try to capture all

of those to dos and thoughts in notes before I lose that context and then set myself up to get

a good start on the next one. Gotcha. And do you also write what the next end to end

scenario you want to fulfill is? Like I want to have an add button. I want to have a delete button.

So you do the add button, you mark some things and then you do the delete button.

Yes, I do. I do that. I usually try to write the to dos in terms of like

features. Sometimes I'll have like a heading that will be like, have a delete button. And then,

what do I need to do to do that? And then I'll try to break it down into steps that I could do

incrementally in tiny steps. But I do try to choose words that reflect the end to end thing

rather than the implementation also. And then maybe I'll write a few notes on the implementation

if I want to capture a thought. As a developer, I want this button to use stories. Yeah.

Yeah, because you want to keep yourself honest about doing something shippable.

Yeah. And the words that you use can help guide you towards a shippable step and getting a smaller

path to getting something shippable. Yeah. Implement function name is not very useful.

Exactly. Yeah. Yes. And on the topic of debug.todo, I just wanted to share one last thought

there for anybody who's maybe new to debug.todo. It's okay to use debug.todo in your tests.

And it's okay to completely ignore certain cases and tests. That's fine. You don't need to compile

your test code with the optimize flag. You don't need to get rid of debug.todo in your test code.

If you have something in the test code where you expect to, you know, I don't know, you're

decoding some value that you're getting for your test setup and you expect the decoder to succeed.

You can just do debug.todo, you know. Yeah, definitely. To handle it. That's fine.

Yeah, because if you try to do it the Elm way, then you will probably end up with a test that

does nothing otherwise. Right. Or the test fails and says, you know, you have to wire in that test

failure, which would be fine, but you don't need to. You can just crash the test. It's okay. Yeah.

Debug.todo is a test failure in itself. Exactly. Elm review has a rule that says no debug.todo.

And in the documentation, I say it's okay to do it for tests. So just ignore this rule for tests.

Cool. Yeah. Yeah. Nice. Because it's very useful there. So I think there's one thing that we

haven't hit on. I mean, there's so much we could talk about here. I'm sure we could talk about

more, but there's one big thing that we haven't really gotten into too much. And we can touch on

it briefly here. I think it's probably a topic for another episode, and that is refactoring. So

I think that refactoring plays a large role in this. So sometimes you can't take a small step

because of the way the code is structured. So you need to refactor. Yeah. Therefore,

small steps and refactoring are connected. I often refer to this Kent Beck quote,

which I really like, which is, make the change easy, then make the easy change. And he says,

warning, the first part may be hard. I totally thought that this was from you.

I was so disappointed to learn that it wasn't. I used to try to credit Kent Beck pretty explicitly.

I thought it was yours. I was like, wow, that man has some words of wisdom.

And I know it's great. Oh yeah. I will ruthlessly steal any nuggets of wisdom.

I do try to credit them, but yeah, there's, I mean, all of these concepts, fake it till you

make it, short feedback loops. And I mean, we're standing on the shoulders of giants here. Kent

Beck really pioneered a lot of these ideas and it's pretty, I find his thinking on these things

very elegant. But yeah, refactoring is intimately connected to this concept of small steps.

And refactoring can itself be done in small steps. In fact, I think that often what people

use the word refactoring for is not actually refactoring. It's a rewrite, which can be fine

in some cases, but I think it's a difference. A refactoring is an atomic transformation

of the structure of the code without changing the behavior of the code. A rewrite is just

getting rid of some code and saying, okay, I'm going to re implement this.

They're two different things. So if you do a rename refactoring, then it's just like,

and you can think of it as one atomic thing, just boom. Now the name is this. If you extract

some function to a module, ideally it would be great to have, you know, IDE support to do that

in an automated way, but you can do that manually and you can, you can do that as a safe atomic

step. But also, you know, as you mentioned earlier, if you're like extracting a new module

while implementing another thing, just go ahead and extract the module first. It's, it's a habit

and I, I really encourage people to try that habit out to separate your behavior changing steps from

your structure changing steps and try to like, if you can refactoring is so nice in Elm and if you

can make a change with no concern that you're changing behavior at all, that's a huge win.

It's less to think about. You, you think about the refactoring and it's dead simple and then you make

the change and it's more simple than it would have been if you're trying to do both at the same time.

So to me, it's like just a very logical thing, thing to do. It's just hard to build that habit.

So I think maybe we'll leave refactoring as a teaser for a future episode and we can dive into

that more another time. I do feel like when you do tiny steps, you will feel the pain of bad

structures more easily. So you will notice when things need refactoring way more quickly.

Right. And as you, as you pointed out earlier too, it's sometimes you start trying to do a tiny step

and then you kind of get stuck because you're like, Oh, I, now I need this thing. I need this

code to be this way. I need it to take this argument, which I don't have, I, you know,

whatever. Well then that's fine. You get stash your changes, you wire in a new argument. You've now

made the change easy and now you can get stash pop and make the easy change. Now that you've got

the argument that you needed. Well, how should people get started trying out this technique?

Well, my main learning from this is to try and shorten your feedback loop.

And the biggest thing I've took out of it is try to make your code compile be the first thing,

be your priority. So when people say it's nice when you do a huge refactor or rewrites,

it lasts one hour and at the end it works when it compiles. That's great. But if you can make

the fact that it compiles your priority, you will not feel the pain of that one hour of rewriting.

Exactly. So yeah, don't do multiple things at once. Focus on one thing and focus on getting

compilation working and test passing. Yeah. Completely agree. I think that's,

if you learn one thing, that's probably one of those. Commit often. And

as you said before, you could learn a lot from Katas. So go watch Deniz's talk on incremental

steps or what was it again? Tiny? Type driven development.

Type driven development. Yeah. Or I thought he was going to talk about test driven development

because he said it was about TDD. And I basically did except using those principles

without the test part. Yeah. And there's also a very good talk about applying automated refactorings

from Llewellyn Falco. Yeah. He's got a lot of good talks.

Yeah. I really recommend watching those. Are you talking about practical refactoring?

Is that the talk with the two minute timer? Yeah.

I was thinking of the one from the Gilded Rose Kata.

Okay. That's an amazing one too. Actually, I'll put a link to this talk that Llewellyn

Falco and Woody Zewald gave about, it's called practical refactoring. That is an amazing talk.

It's so good. They take a two minute timer and they have two minutes to get the code

to a shippable state for every change they make. Oh, nice. I highly recommend that talk.

And I wanted to point one thing out. I could not agree more with everything you said about the core

idea and following one thing through, not having multiple things that you're working on at the same

time and noticing when you're doing an hour long refactoring. I just wanted to point out

for anyone who's new to this sort of approach, there are times when you're doing refactoring

that sort of take some time because you're wiring in a new argument and that's one small atomic

refactoring, but you have to change 20 places. Yeah. And that's okay. So.

Because you can't get it any smaller. Yeah. There's no way unless it's automated. And again,

these are the types of things that can be automated. Elm has all the ability to be

statically analyzed and automated in those ways. And I think that's a great point.

So you can't get it any smaller than that. And again, these are the types of things that can be

statically analyzed and automated in those ways. And those things will come. But for now, it's okay.

Just pay attention to it could be taking a while, but are you just doing one small refactoring or

are you doing a rewrite of all of the code? And how, and if so, how can you break out one small

piece, do that refactoring? It's kind of like the doing starting at the leaves of the tree

whack, but you want to start up at the leaves and then move towards the root. So yeah. And well,

I wrote an article recently called relentless tiny habits. So you might want to give that a read.

It kind of talks about some of the principles we've been talking about and sort of how you

build those habits into your way of working and how much that relates to taking tiny steps

is not something you just do. It's a habit that you continuously build. Yeah. Anything else to

point people to? I think that's quite a lot of resources already. I think so. I think so.

This takes, this will take a lot of practice. Like even I am doing more and more tiny steps,

but I still don't go end to end. And that is something that I need to practice for instance.

So yeah, a lot of habits. Yeah. And they are habits and they are as with any habit.

If you do that step one time, then you've started a habit and you just need to keep doing that.

Also, as with any other habit, you know, you can, you can get better or worse over time. So

it, it's a continual learning process. It's something that requires constant, constant care

to take care of that habit. But code cadas are a great way to keep that up. I think setting aside

some deliberate time where you say, I'm going to work in this way without the pressure of

production code. I think that can be very helpful. You know, you can apply these ideas to side

projects too. I think you and I would, would both share that experience of learning new techniques

by sort of trying to be our best selves in our, in working on a side project. Yeah, definitely.

So that's another way, but I, I would recommend employers or, you know, developers to set aside

some time and give, give developers some time to do, you know, to practice, to try things out, to,

to do exercises and cadas. I think that's a great way to learn these habits. Yeah. With a focus on

what you want to learn. Yes, exactly. Short feedback loop. That's not just how you write good

code. That's how you learn too. Yep. All right. Well, this one was a lot of fun and don't forget

to review us on Apple podcasts, follow us on Twitter and thanks for listening. Yeah. And if

you have a question, go to elmradio.com. Yes. elm dash radio.com slash question, or just elm

dash radio.com and click the question button. Yep. And Dillon, see you next time. See you next time.