Sign up to save your podcasts
Or
Share Write the code first, then make the abstraction
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Write the code first, then make the abstraction
CORRECTION: I came up with the concept of AHA Programming but I did not come up with the acronym. AHA (pronounced Aha! like you just made a discovery) is an acronym I got from Cher Scarlett which stands for Avoid Hasty Abstractions.
Hey friends, just something that I've been thinking about recently is this
acronym that I came up with a few years ago. It's AHA and it's pronounced
aha and so that's aha programming and it stands for avoid hasty
abstractions and this is actually a blog post that I wrote with some time
ago and it talks a lot about how like dry do not repeat yourself as to
dugmatic and wet programming which is a variant of that is right everything
twice is also.
Two dogmatic and more we should be more mindful of the types of
abstractions that we create and and I talk a lot about in the blog post,
which I suggest you go take a look at but one part of this and is at kind
of the micro level and that's what I have been thinking about recently just
today.
As you're working on a new feature or something is really really often in
my programming at least I'm working through something and I start I'm
thinking about how I'm going to implement something and I instantly decide
okay, I'm going to need.A function that does this And so often that ends up
being the wrong decision I end up making and especially with TypeScript
actually.
This is a big pain because then you have to there's just a lot of
boilerplate with making a function. But even even not without TypeScript,
you have to think about okay, what are the parameters what order are they
going to be in or is it going to be an object that AD structure?
And it just adds a lot of stuff that for code that you don't even really
know what it's going to look like yet and and on top of that if you decide
oh actually this function needs to change like weWe just add a lot of extra
work and thought before we've actually written the code just by making a
function for this thing that we think we might want to function for where
in actuality.
I find I'm so much more productive if I just start by writing the code and
inlining as much as I possibly can even if that means I'm copy pasting from
one part of the code base to another and just in line everything as much as
you can make a big long function.
And then before you commit at that point, you look atThe code that you've
written and you think okay, so now what are the abstractions that I see now
that the code has been written? And so, I find a lot of my problem comes
with when I try to abstract the code that's not there yet.
And I find a much more productive if I abstract the code that exists after
I've written it. So anyway, hopefully that's helpful to you next time you
feel the urge to write a function for code that doesn't exist yet. Maybe
take a step back and write the code first then make the function.
Have a wonderful day.
View all episodes
By Kent C. Dodds
5
44 ratings
CORRECTION: I came up with the concept of AHA Programming but I did not come up with the acronym. AHA (pronounced Aha! like you just made a discovery) is an acronym I got from Cher Scarlett which stands for Avoid Hasty Abstractions.
Hey friends, just something that I've been thinking about recently is this
acronym that I came up with a few years ago. It's AHA and it's pronounced
aha and so that's aha programming and it stands for avoid hasty
abstractions and this is actually a blog post that I wrote with some time
ago and it talks a lot about how like dry do not repeat yourself as to
dugmatic and wet programming which is a variant of that is right everything
twice is also.
Two dogmatic and more we should be more mindful of the types of
abstractions that we create and and I talk a lot about in the blog post,
which I suggest you go take a look at but one part of this and is at kind
of the micro level and that's what I have been thinking about recently just
today.
As you're working on a new feature or something is really really often in
my programming at least I'm working through something and I start I'm
thinking about how I'm going to implement something and I instantly decide
okay, I'm going to need.A function that does this And so often that ends up
being the wrong decision I end up making and especially with TypeScript
actually.
This is a big pain because then you have to there's just a lot of
boilerplate with making a function. But even even not without TypeScript,
you have to think about okay, what are the parameters what order are they
going to be in or is it going to be an object that AD structure?
And it just adds a lot of stuff that for code that you don't even really
know what it's going to look like yet and and on top of that if you decide
oh actually this function needs to change like weWe just add a lot of extra
work and thought before we've actually written the code just by making a
function for this thing that we think we might want to function for where
in actuality.
I find I'm so much more productive if I just start by writing the code and
inlining as much as I possibly can even if that means I'm copy pasting from
one part of the code base to another and just in line everything as much as
you can make a big long function.
And then before you commit at that point, you look atThe code that you've
written and you think okay, so now what are the abstractions that I see now
that the code has been written? And so, I find a lot of my problem comes
with when I try to abstract the code that's not there yet.
And I find a much more productive if I abstract the code that exists after
I've written it. So anyway, hopefully that's helpful to you next time you
feel the urge to write a function for code that doesn't exist yet. Maybe
take a step back and write the code first then make the function.
Have a wonderful day.