>> Kyle Simpson: Now, I've shared with you this highly scientific graph, okay.
This plots out very specific scientific data of my journey of learning how
to incorporate declarative techniques into my programming.
And my ascertation of what impact that had on the readability of my code, okay?
You notice that at the beginning,
there's kind of an initial wind that you start using something.
Like somebody teaches you something like math, for filter or reduce, or
everybody's favorite 4H, which by the way is not functional programming, sorry.
But somebody teaches stuff like that and you throw it in the code, and
now you feel like, my codes, way better now.
So you started to get these early wins, this is exactly how it went for
me as I started to understand these things.
And for me, the journey was I'm writing a book so
I just mapped out a whole book of all these to do comments.
Giant sections with nothing but to do in them, I gotta go learn this,
I gotta go learn this.
And I would learn it and then try it and
some countdown like, it's a little easier to understand now, I get it.
So you get some early wins and
you start to feel like you're building some momentum.
I'm only sharing this journey because some of you may go on a similar journey.
Most everybody that I've talked to you has been on this journey.
Okay, that you get these early wins, but
then stuff starts to get a little more complex, you get a little bit more
sophisticated about the stuff that you're bringing together.
And eventually,
you get to a point where the winds are starting to taper off a little bit.
You're still using functional techniques.
It's not like you've given up on them, but you're not seeing,
when you incorporate a new technique, as big of a difference in the readability.
Things are slowing down, you're reaching the top of that first curve.
Then you throw a few more things in to the mix, and
uh-oh, one time you look at some code and you're like, what does that do?
And you look at what it used to be, and you have this thought, and
it was better before, it was more readable before.
And some of you I can see your smiling because you've been on this curve,
you've already know exactly what i'm talking about.
Maybe it wasn't functional programming,
it maybe something else but you see this curve it happens, okay?
And it's gonna happen in your journey on functional programming,
I'm almost certain.
And I'm sharing it with you because I'm trying to not solve that problem for
you, but make you aware of this effect.
And encourage you and challenge you not to give up,
because you keep plunging along and you keep trying new things like I did,
and eventually you get to some point like that dotted line that's there.
That's about the point where you wanna give up because, now the code is worse
than it was before you ever started trying to incorporate this new thing.
Whether it's a new framework, or
whether it's this whole new paradigm functional programming,
same thing happens, you reach this point of questioning, why did I even start this?
This existential crisis, why am I even, am I even a programmer?
What is this?
Well all go through that, and that's where many developers give up.
And it's where I almost gave up.
It was about chapter two and a half of my book.
And I was like, wow, this is really much worse than I thought.
It's much more complicated than I thought.
It's gonna take a lot more time for me to learn and get comfortable with this stuff.
This isn't gonna be like, I'm done in a few months and then I,
I get my membership card in the mail, now I can say I'm functional programmer.
That's not how this is gonna be, there's gonna be like decades.
Years and decades of me trying to change the way that I think,
to think and solve problems differently.
But at the same time, I still got a ship code.
I would imagine most of you, if not all of you are in the business of being paid to
ship code, I gotta ship code.
Even though I'm a teacher, I got to ship code because I gotta write libraries and
help support all this stuff I teach.
I have to still ship code, every once in a while I work on a side project
where I have to ship code, so it's not good enough.
For me to sit in an ivory tower and think big thoughts about what
programming could be, if I can't put that into practice.
It's useless, it's a waste of time.
And I would imagine many of you are in the same boat.
So you're gonna get to that point where you're headed towards the pit of despair,
as they call it, I love that, the pit of despair.
You're gonna be headed towards the pit of despair and
you're gonna be saying, nope back up.
Go back to what I was doing before, and I was there.
And what I'm gonna encourage you to do is keep pushing through,
because I kept pushing through.
I kept saying, maybe it was from some naivete on my part,
but I kept saying, one of these days I'm gonna get it.
Maybe I'm just a little thick headed on this stuff, but
I'm gonna get it, it's gonna start to click and I kept pushing.
And I kept trying to add new things onto it, and create new knowledge and
new experiences and try it on a different piece of code.
And at some point, the bottom of the curve arrived.
And one day, I looked at a piece of code that was using a curried
composition or whatever.
And it clicked for me, that just that one line, not everything.
It's not like you wake up one day and it all works, but
just that one line actually made more sense to me.
And a week later, another line of code made more sense to me.
And a week later, and a month later, and six months later.
I'm three years into this journey of, I wanna learn about functional programming.
Book's been out a year and a half, I spent a year and a half writing the book, so
I've been at this three years.
I'm not the end of the curve, but it's on a good trend, that's what I'd say.
So it's worth it to keep pushing,
it's worth it to encourage your co-workers to keep pushing at it.
The ultimate pragmatist as well,
it doesn't really matter what the code looks like.
Just as long as it ships because that's what I get my paycheck, and
I am sensitive to the idea of this pragmatism, this whole courses based
on the idea, that we still have to ship working executable Java Script.
It's not good enough that it just looks nice, but it doesn't actually work.
It has to actually work, it has to do something useful for me,
and it has to be maintainable.
I gotta be able to go back and
understand what the hack I was doing, otherwise what was the point?
So this look at functional programming that we're diving into,
is born out of this idea of, let's not take the theoretical top down.
Let's take the practical and pragmatic bottom up approach.
Let's start with what we know how to do, and
try to make it a little bit more functional, one piece at a time.
Let's look at this pile of equipment on the ground, and
let's just figure out what a carabiner does.
And then let's just figure out how to tie a knot, and how to put some rope in, and
how to take our first step onto the cliff face.
That's it, just one thing at a time, and if you do and if you keep pushing through
and you keep trying that stuff in it, I can not make that not a difficult climb.
I don't have the magic to fix that,
I can't make it not a difficult climb, what I can make it for you.
And this is my hope with the book and the course, what I can make it for
you is, that it's a manageable climb.
Somebody can tell you how the equipment works, so that you can start climbing.
That's what we're trying to do here, okay?
Now, there's a tension that I wanna call out in this.
There's a tension here because I and you may have missed it.
And that's why I wanna call it out.
Because I said at one time, no, no, you gotta keep pushing on it.
You gotta keep trying it, and even though it's more confusing.
And then at the same time, almost in the same sentence, I said, but
you still got a ship code that can be maintained.
There's a tension here because, if you only work with code that is familiar,
and readable, and understandable.
And anything you do that's not readable and
understandable, you just take the shortcut out of, well I'm a pragmatist,
I got to go back to what works.
Then you're never gonna advance along that curve.
And at the same time, if you advance along the curve and
you never connect it back to anything practical and pragmatic.
You're going to lose the motivation and
you're gonna bail out at some point anyway.
So there is a tension here, and I can't fix the tension.
I can simply call it out for you and make you aware of and
be prepared for, at every moment that you take one of these concepts, like what
we're gonna talk about in this course, and you try to apply it to your code.
It is going to happen, that it's more confusing at that moment than it was
before, because it's not yet familiar.
So you're going to have to be comfortable in that gray area where it's uncomfortable
and feels less readable.
And you're gonna have to try it not once, not twice, ten times, a hundred times,
a thousand times before that thing becomes familiar.
And at the same time, you're gonna have to have an eye towards.
If I wanna continue, if I wanna sustain the journey,
if I wanna make it up the mountain.
It's simple when I got the chip code and
I got to make a practical choice that at this in my code and at this point in my
journey of understanding I don't need that thing, a four loop will do, you with me?
That tension, it exists, you should be aware of it, you should meet it face on.