I'm currently in high school and want to learn how to be able to build prototypes fast to validate ideas.I'm proficient in javascript,particularly in react, and some python as well. However Im nowhere near close to be able to building out projects fast .How do I get better and faster at building usable prototypes that can work as MVP's?
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.
- Get feedback when you’re not done yet.
Though I might expand “fun” to a more general sense of reward. Eg “if I build this thing in a week, will I want to try using it?” or “if the idea is valid, will I be glad to be able to use it?”
I’m bringing this up because I’ve found that kind of reward very motivating to work on personal projects which are otherwise dull and full of drudgery. For instance, for my current spare time project I’m building yet another test runner. Before I started it, that sounded so unappealing that past me would laugh out loud if future me came back in time and told me about it. But there’s nothing that fits my vision for a test runner in the stack I usually work on (TS/JS/Node/browsers). And the benefits I hope to enjoy when I actually get to use it are much more motivating than the project itself.
In fact the project itself is just a yak shave I couldn’t let go of—trying to start another personal project, then finding “blazing fast” solutions too slow, or too limited, and generally both. And I find testing in these environments painful in my every day work, so if it even has a chance at success it could make even that more rewarding and motivating.
Yikes, what a long ramble. But I think it’s worth posting in case it gives OP or anyone else another perspective that gets them excited to start or stick with an idea.
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.
This pays off in spades.
--
Picasso was at a Paris market when an admirer approached and asked if he could do a quick sketch on a paper napkin for her.
Picasso politely agreed, promptly created a drawing, and handed back the napkin — but not before asking for a million Francs.
The lady was shocked: “How can you ask for so much? It took you five minutes to draw this!”
“No”, Picasso replied, “It took me 40 years to draw this in five minutes.”
EDIT: Additionally, learn to use a command line tool called `ripgrep`.
I still build out prototypes using www.meteor.com
Firebase is good for that too
Build more prototypes.
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.
Stopped reading after that, are you insane?
In that stuation, reducing complexity is the correct thing to do. You can achieve this by stuffing all your code in one fine, not checking if malloc failed, etc.
When you decide the concept works, THEN you go back and do it properly.
This sort of "prototyping for speed" is discussed much better here: https://gameprogrammingpatterns.com/architecture-performance...
This is such good advice. This sort of procedural thinking really helped me to separate the capabilities of OO from the actual intent of design patterns.
Like you said, Carmack's code is well written in plain C - a procedural language which doesn't have OO constructs like constructors and methods.