4 ms·
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).
by quadcore 5y ago
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.
- throwawaynay 5y ago"I usually put all my code in one file " Stopped reading after that, are you insane?
- suprjami 5y agoI think this poster was talking about a rapid example to see if a concept works. 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-and-games.html#the-good-in-bad-code https://gameprogrammingpatterns.com/architecture-performance...
- suprjami 5y ago> 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. 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.