How to get good at building functional prototypes fast

Read Leslie Lamport's Specifying Systems (2003),¹ study the example modules, study others' modules online, and write your own. It's a really good way to bug test your program's logic before you choose the language to code it in. It's not easy to learn, but you can build functional prototypes fast once you learn it. A gentle introduction is Scott Wlaschin's 2020 YouTube video "Building confidence in concurrent code using a model checker".²

¹ https://lamport.azurewebsites.net/tla/book-02-08-08.pdf

² https://www.youtube.com/watch?v=tqwcz-Yt9gQ

Problem decomposition. You need to remove everything from idea and build single feature at a time. Sometimes you will end up implementing something in different way than originally imagined.

I did it for last 3 months in my paid job. I started with writing code to initiate business flow which I needed, added input params and prepared dummy result storage. Then provided new settings required by flow. Then implemented flow with very simple logic to handle data processing. Then improve processing. Then upgrade solution to Shipp able imementatipn - refactoring and making it a generic solution for future. The last part is optional and generalization is on business level, not pure functional/solid code for the sake of it itself.

The more you do the better you'll become at it. Also, do set yourself deadlines, even if they are artificial, otherwise it wil take forever

- Build small things. Get really familiar with asking: “Is this necessary? Is it essential? Can I use something that was already built for this?”

- Get feedback when you’re not done yet.

Doing it a lot will give you two things that might not be obvious (in addition to general skill).

1. You’ll get better at knowing what to leave out from future projects, or finding simple alternatives.

For example, for one recent project I built a semi complex payment scheme that used stripe. For my current project I’m using Gumroad, which costs more but should save a bunch of time.

2. You’ll develop a massive set of pre-written code you can reuse. I went through the steps of figuring out how to configure Redis/Django/Heroku for asynchronous tasks on a project 2 years ago, and it’s simple for me to drop in my pre-existing code for anything I build now.

The more you plan the less code you'll need to rewrite. And keep things small because rewrite #3 will probably be a lot simpler and better than rewrite #2.

Find set of tools that you like and start with very simple project then keep adding features to it.

I still build out prototypes using www.meteor.com

Firebase is good for that too

You're practically answering your own question.

Build more prototypes.

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.

Experience and practice.