Write the code first, then make the abstraction - a podcast by Kent C. Dodds

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 (https://twitter.com/cherthedev/status/1112819136147742720) Cher Scarlett (https://twitter.com/cherthedev) 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 timeago 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 everythingtwice is also.
Two dogmatic and more we should be more mindful of the types ofabstractions 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 kindof 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 TypeScriptactually.
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 extrawork 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 wherein 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 asyou 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 nowthat 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.

Further episodes of 3 Minutes with Kent

Further podcasts by Kent C. Dodds

Website of Kent C. Dodds