6 ms·

This is genius. Anecdotally I’ve seen a high correlation between procrastination and perfectionism. Once you have a vomit draft I can see how the perfectionist

This is genius. Anecdotally I’ve seen a high correlation between procrastination and perfectionism. Once you have a vomit draft I can see how the perfectionist bent suddenly works in your favour.

distantwarning7 4y ago
I agree 100%.
theshrike79 4y ago
When coding I have a rule: "first make it work, then make it pretty". The MVP can be a complete spaghetti piece of crap, just make it work. When it works, you can iterate on making it elegant. Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask. Otherwise the spaghetti crap will end up in production.
- llm_sent_me 4y ago
  My variation on this. Make it work then make it slightly less horrible.
  - bdavis__ 4y ago
    Then repeat until you are proud of the work.
- augustk 4y ago
  1. Make it work 2. Make it right 3. Make it performant (if too slow).
  - Fell 4y ago
    I disagree. 1. Make it work 2. Make it performant (always, but within reason) 3. Clean up your mess to prevent future mistakes I claim that "if too slow" can't be judged because you almost never have the slowest possible target device.
    - DSingularity 4y ago
      I disagree with all of you. Make it work. Then make it maintainable. Then polish it to make it more ideal. When it works it can be spaghetti and lack testing and filled with hacks. After you make it maintainable it can still be less than ideal — some hacks here and there in leaf functions but things are localized and understandable and non-brittle (ie good testing coverage, design which has appropriate abstraction, refactors to promote test ability, no more spaghetti etc etc). Then in the final step you polish the stuff to gold (ie use better solutions or improve performance). It is the only way.
  - qwerty1793 4y ago
    1. Make it work 2. Make it understandable 3. Make it performant (if too slow).
- xvinci 4y ago
  Except I've seen too many spaghetti code craps in production to actually recommend this. There is a plethora of reasons why colleagues (or even you) will end up not waiting until code is production ready (e.g.: A new nice task comes in which you'd rather work on, you get reassigned, you get sick and someone else has to finish, you get a great opportunity to show off and say "hey I'm already done no problem", a tester sees and tests the features and misinforms the customer, etc. etc.) I am not saying your code needs to be perfect and then you only notice the one great flaw which requires re-engineering after weeks of hard work. I am saying find a good (backed by TDD) middle ground of fast work and fitting into existing / designing a decent architecture. My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.
  - dahauns 4y ago
    As someone who otherwise works somewhat similar to OPs workflow, I have to agree. One golden rule for me: The "vomit draft" version cannot be your MVP. It is never Viable for production. That said, TDD (with emphasis on driven) is no silver bullet either, especially when working that way - the tests are equally affected and I've seen enouph code bases where the initial test surface was so off compared to what was needed/sensible that it ended up being solely a hindrance and stifling to actual rework/refactor - with people ending up throwing it away and rewriting the tests from scratch, or worst case, simply setting them to be ignored on build.
- MathMonkeyMan 4y ago
  My teammate says he does this. Writes everything three times, and is careful not to let _anyone_ see the first two, lest somebody tell him it's "good enough."
- red-iron-pine 4y ago
  > Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask. I would if I could, but schedules are schedules and stuff has to ship...
agumonkey 4y ago
I'd go a bit further, it's more like we lack an evaluation compass therefore we can't even try because we don't know if we will be able to see a difference. You can't anticipate benefits of any path and most of the time it's anticipation that drives your effort (you "foresee" things). Dealing with that situation requires changing this habit and go wander, try to find anything that revives curiosity, gives you a clue, a perspective you didn't have.

This is genius. Anecdotally I’ve seen a high correlation between procrastination and perfectionism. Once you have a vomit draft I can see how the perfectionist bent suddenly works in your favour.

distantwarning7 4y ago

I agree 100%.

theshrike79 4y ago

When coding I have a rule: "first make it work, then make it pretty". The MVP can be a complete spaghetti piece of crap, just make it work. When it works, you can iterate on making it elegant. Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask. Otherwise the spaghetti crap will end up in production.

llm_sent_me 4y ago
My variation on this. Make it work then make it slightly less horrible.
- bdavis__ 4y ago
  Then repeat until you are proud of the work.
augustk 4y ago
1. Make it work 2. Make it right 3. Make it performant (if too slow).
- Fell 4y ago
  I disagree. 1. Make it work 2. Make it performant (always, but within reason) 3. Clean up your mess to prevent future mistakes I claim that "if too slow" can't be judged because you almost never have the slowest possible target device.
  - DSingularity 4y ago
    I disagree with all of you. Make it work. Then make it maintainable. Then polish it to make it more ideal. When it works it can be spaghetti and lack testing and filled with hacks. After you make it maintainable it can still be less than ideal — some hacks here and there in leaf functions but things are localized and understandable and non-brittle (ie good testing coverage, design which has appropriate abstraction, refactors to promote test ability, no more spaghetti etc etc). Then in the final step you polish the stuff to gold (ie use better solutions or improve performance). It is the only way.
- qwerty1793 4y ago
  1. Make it work 2. Make it understandable 3. Make it performant (if too slow).
xvinci 4y ago
Except I've seen too many spaghetti code craps in production to actually recommend this. There is a plethora of reasons why colleagues (or even you) will end up not waiting until code is production ready (e.g.: A new nice task comes in which you'd rather work on, you get reassigned, you get sick and someone else has to finish, you get a great opportunity to show off and say "hey I'm already done no problem", a tester sees and tests the features and misinforms the customer, etc. etc.) I am not saying your code needs to be perfect and then you only notice the one great flaw which requires re-engineering after weeks of hard work. I am saying find a good (backed by TDD) middle ground of fast work and fitting into existing / designing a decent architecture. My 2 cents only, and if you can make it work that's great. But I will never go ahead and recommend this to juniors or even younger seniors.
- dahauns 4y ago
  As someone who otherwise works somewhat similar to OPs workflow, I have to agree. One golden rule for me: The "vomit draft" version cannot be your MVP. It is never Viable for production. That said, TDD (with emphasis on driven) is no silver bullet either, especially when working that way - the tests are equally affected and I've seen enouph code bases where the initial test surface was so off compared to what was needed/sensible that it ended up being solely a hindrance and stifling to actual rework/refactor - with people ending up throwing it away and rewriting the tests from scratch, or worst case, simply setting them to be ignored on build.
MathMonkeyMan 4y ago
My teammate says he does this. Writes everything three times, and is careful not to let _anyone_ see the first two, lest somebody tell him it's "good enough."
red-iron-pine 4y ago
> Oh, and if you work for a Corporation, don't tell them it's done when the crappy MVP finally works. You're still "working on it" if they ask. I would if I could, but schedules are schedules and stuff has to ship...

agumonkey 4y ago

I'd go a bit further, it's more like we lack an evaluation compass therefore we can't even try because we don't know if we will be able to see a difference. You can't anticipate benefits of any path and most of the time it's anticipation that drives your effort (you "foresee" things). Dealing with that situation requires changing this habit and go wander, try to find anything that revives curiosity, gives you a clue, a perspective you didn't have.