This is a programming style that I know very well I beleive (I've been payed at multiple occasions to make prototypes for big and small companies, some famous). My first advice would be to learn to use functions very well. Try using only functions for a time. You have to understand what you can do with functions alone before using more advanced stuff like OO. If you start with OO, you take the risk not to understand how simple things can be. And this is the graal youre after: simplicity. Good example of that is Carmack's code: wolf, doom, quake engines. Notice how quickly you can produce code like that. Data, functions, data, functions, in a file. Master this.

Get good with a great text editor like vim, emacs or sublime. I usually put all my code in one file (why would I waste my time doing otherwise?). Paul Graham seems to do the same if that matter to you. So essentially: win time, here and there and over here.

Dont forget the programming basics: always start with a test in mind. Im not saying you should write unit tests, this is essentially useless even if many will disagree, however it is critical you understand test->code->test->code. Test comes first. This way you will build bottom-up. If you start with code, you are waterfalling essentially. Start with "if this is printed or processed or whatever, Im done", then repeat. Get that done as fast as possible.

Then there is the collection of little magic ingredients I personnally use: asserts in the code to get the quality boost immediately, I dont use jumps at all that way I write code in an idiomatic way that's so systematic I can parse what the code do 10 metters from the screen (identation is your friend, not your enemy), one file, repeat yourself over doubtful abstractions, etc. Those work for me but everyone has his own variant.

Do tons of prototypes. It is critical it to be easy to start you understand. Notepad and gcc. Sublime and nodejs in command line. No git, no plugins, no nothing (you get the idea, do things that work for you). The more you add to the initial setup, the less projects you will do. It's like working out, if you go badass for an afternoon you will be beaten and stop for the week, you wont do as much as if you just went super easy the first day.

Be insanely lazy. Now being dumb is not being lazy, it's being courageous. Be laser-smart lazy.

Maybe one day you will ship in 1 year what an other team took 4 to do with double staff at a FAANG. I'm saying knowing to kickstart a project with a smooth and efficient bottom-up style is a good way to become a terrific programmer.

I wouldnt focus on the clean or sustainable part of coding at first. This is an opposite force which you will learn to master naturally with volume. Dont start with clean code, free yourself entirely and focus on the goal of making prototype fast. Works better in this order, you dont want to clean something thats badly engineered and a disfunctionning project anyway. Once you have a rough diamond that cost nothing, you can trust it will be made into a beautiful ring with all that fat remaining budget of yours.