3 ms·

When implementing something: Figure out enough to get started. Then start. Don't think you can get a perfect view of something before wading into it, you'll ju

by tsujp 4y ago

When implementing something: Figure out enough to get started. Then start. Don't think you can get a perfect view of something before wading into it, you'll just be wasting time. Likely your first attempt will suck so with your new found experience from starting and trying you can improve for your next attempt.

mobilio 4y ago
KISS = Keep It Simply Stupid
- CRConrad 4y ago
  Uh... If that was intentional, then great joke! If not, "keep it simplE, Stupid!". The original is an exhortation to keep things simple, calling the recipient "Stupid" as a somewhat derogatory nickname (implying they would be, if they don't follow this advice). With the -y turning the adjective "simple" into an adverb, this becomes an attribute of the only available adjective (well, only available word left in the sentence), "stupid", specifying in which manner said adjective is to be applied: simply stupid. (Like, plainly moronic.) No, please don't keep things simply stupid. Keep them simple, Stupid!
jeffreportmill1 4y ago
Great advice! I call that the "Mad Dash" - just try to get something working in a quick and dirty fashion. I often don't understand the problem until I work on the solution.
badluckbuddha 4y ago
Interesting how seemingly-at-odds this is from another highly upvoted trick: the one that begins "Understand the problem and solution before coding." Hard to find that balance sometimes between "just dive right in" and perfectionism.
- jones1618 4y ago
  I think you balance the two tricks by defining "Figure out enough to get started" as "Understanding the problem (without overthinking it)." For me this means walking through use-cases of an idea "on paper" while resisting the temptation to actually design the solution. Once you've defined the verbs/nouns of the system you're much better prepared to "dive in" and build something. That, in turn, will uncover things your paper system forgot or burst your illusions about certain use-cases causing you to rethink them. Rinse, repeat.
  - tsujp 4y ago
    This is a better explanation of what I meant. I've been the "overthink it" person, the person to spend way too much time on preparation only to start the implementation and realise one or many of the reasonable assumptions I've made are wrong and then have those affect everything else. I could have done a new on-paper solution for every single fork like that in the preparation phase (greatly extending it); or, I could have learned enough to _get started_ and come back to the drawing board to re-learn each time these (before: assumptions) are met. It's a careful balance of preparedness and real-world discovery. Neither gives a complete picture without the other. Neither is even possible without the other. Spending too long preparing is as bad as spending too little time. Too long and you account for possibilities that may not even exist, things you cannot know until you enter the system. Too little time and you're a bull in a china shop.

by tsujp 4y ago

mobilio 4y ago

KISS = Keep It Simply Stupid

CRConrad 4y ago
Uh... If that was intentional, then great joke! If not, "keep it simplE, Stupid!". The original is an exhortation to keep things simple, calling the recipient "Stupid" as a somewhat derogatory nickname (implying they would be, if they don't follow this advice). With the -y turning the adjective "simple" into an adverb, this becomes an attribute of the only available adjective (well, only available word left in the sentence), "stupid", specifying in which manner said adjective is to be applied: simply stupid. (Like, plainly moronic.) No, please don't keep things simply stupid. Keep them simple, Stupid!

jeffreportmill1 4y ago

Great advice! I call that the "Mad Dash" - just try to get something working in a quick and dirty fashion. I often don't understand the problem until I work on the solution.

badluckbuddha 4y ago

Interesting how seemingly-at-odds this is from another highly upvoted trick: the one that begins "Understand the problem and solution before coding." Hard to find that balance sometimes between "just dive right in" and perfectionism.

jones1618 4y ago
I think you balance the two tricks by defining "Figure out enough to get started" as "Understanding the problem (without overthinking it)." For me this means walking through use-cases of an idea "on paper" while resisting the temptation to actually design the solution. Once you've defined the verbs/nouns of the system you're much better prepared to "dive in" and build something. That, in turn, will uncover things your paper system forgot or burst your illusions about certain use-cases causing you to rethink them. Rinse, repeat.
- tsujp 4y ago
  This is a better explanation of what I meant. I've been the "overthink it" person, the person to spend way too much time on preparation only to start the implementation and realise one or many of the reasonable assumptions I've made are wrong and then have those affect everything else. I could have done a new on-paper solution for every single fork like that in the preparation phase (greatly extending it); or, I could have learned enough to _get started_ and come back to the drawing board to re-learn each time these (before: assumptions) are met. It's a careful balance of preparedness and real-world discovery. Neither gives a complete picture without the other. Neither is even possible without the other. Spending too long preparing is as bad as spending too little time. Too long and you account for possibilities that may not even exist, things you cannot know until you enter the system. Too little time and you're a bull in a china shop.