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 pronouncedaha and so that's aha programming and it stands for avoid hastyabstractions 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 todugmatic 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 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 kindof the micro level and that's what I have been thinking about recently justtoday.

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'mthinking about how I'm going to implement something and I instantly decideokay, I'm going to need.A function that does this And so often that ends upbeing 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 theygoing 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 decideoh 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 afunction 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 fromone 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 comeswith 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 youfeel the urge to write a function for code that doesn't exist yet. Maybetake a step back and write the code first then make the function.

Have a wonderful day.