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.