3 ms·

Perfectionism is usually a cause for procrastination. In my experience the long and rich history of procrastination, half-assing and missing deadlines is usuall

Perfectionism is usually a cause for procrastination. In my experience the long and rich history of procrastination, half-assing and missing deadlines is usually caused by over-thinking, pre-mature optimization, wrong abstractions and analysis paralysis combined with deadlines. I would suggest to try to finish tasks with the bare minimum. Not half-assed but without bells and whistles. Important bells and whistles will come back anyway as their own tasks. Drive by sight and don't prepare too much for the final destination. The latter will change anyway and you will waste your time worrying about ifs.

fphhotchips 2y ago
I've been taking this approach more recently. Something shipped is 100% better than nothing at all, even if it's 25% worse than if I whole-assed it. It's been working, in that the 'leave room for others to step in' has worked well, and those others have filled the gaps with new and interesting ideas that I likely would not have done even had I whole-assed it. At the same time, those people weren't equipped to whole-ass something from nothing.
huygens6363 2y ago
I emphasize, because I share your tendencies. This is all personal btw, nothing to you personally. I have to admit that failing to produce a required result in time using the right abstractions and without “overthinking” is actually just that: failing. That’s why I mentioned all parameters, including time, social reality, etc. Using too much time is failing. Producing results is a skill. Like mastering programming languages and system internals is a skill. We should approach it with honesty and reflection: we suck at that for now and it’s OK. We can improve. Personally I found whitewashing failure with “I think too deeply”-type of arguments tends to maintain status quo instead of improvement. Because we deeply belief that it’s not actually failure, but it is. I actually agree with “just finish”. It’s a good first step. Don’t furnish, but also don’t half ass.
robofanatic 2y ago
Agreed, but you have to be lucky to be not on a toxic team for that otherwise you are going to get a ton of comments by your peers in your Pull Request for trivial things that you left out even though you had clearly stated the scope before, just so that the peers can show that they are doing their job of peer reviewing. And later the ignorant manager questions you in 1:1 about the number of comments on your PR without actually reading them. This is based on my recent experience.
- diarrhea 2y ago
  From their perspective, what are you going to do? Say you implemented a new function and missed some clear edge cases in the new tests. Or perhaps there's no tests written at all, because it was half-assed. You will have to speak up in a peer review. I'd speak up just to have it written down. Perhaps you just forgot to `git add` that part, I don't know. It'd be professional negligence not to at least bring it up! If your reply is then, 'I'm aware, and didn't do this for reason X', that's perfectly fine, if reason X is at least slightly better than couldn't be arsed.
  - mewpmewp2 2y ago
    I would say to sync on this out of PR before to make sure you are aligned on it with reviewers so they don't have to waste time focusing on the wrong things and writing those comments in the first place.

fphhotchips 2y ago

I've been taking this approach more recently. Something shipped is 100% better than nothing at all, even if it's 25% worse than if I whole-assed it. It's been working, in that the 'leave room for others to step in' has worked well, and those others have filled the gaps with new and interesting ideas that I likely would not have done even had I whole-assed it. At the same time, those people weren't equipped to whole-ass something from nothing.

huygens6363 2y ago

I emphasize, because I share your tendencies. This is all personal btw, nothing to you personally. I have to admit that failing to produce a required result in time using the right abstractions and without “overthinking” is actually just that: failing. That’s why I mentioned all parameters, including time, social reality, etc. Using too much time is failing. Producing results is a skill. Like mastering programming languages and system internals is a skill. We should approach it with honesty and reflection: we suck at that for now and it’s OK. We can improve. Personally I found whitewashing failure with “I think too deeply”-type of arguments tends to maintain status quo instead of improvement. Because we deeply belief that it’s not actually failure, but it is. I actually agree with “just finish”. It’s a good first step. Don’t furnish, but also don’t half ass.

robofanatic 2y ago

Agreed, but you have to be lucky to be not on a toxic team for that otherwise you are going to get a ton of comments by your peers in your Pull Request for trivial things that you left out even though you had clearly stated the scope before, just so that the peers can show that they are doing their job of peer reviewing. And later the ignorant manager questions you in 1:1 about the number of comments on your PR without actually reading them. This is based on my recent experience.

diarrhea 2y ago
From their perspective, what are you going to do? Say you implemented a new function and missed some clear edge cases in the new tests. Or perhaps there's no tests written at all, because it was half-assed. You will have to speak up in a peer review. I'd speak up just to have it written down. Perhaps you just forgot to `git add` that part, I don't know. It'd be professional negligence not to at least bring it up! If your reply is then, 'I'm aware, and didn't do this for reason X', that's perfectly fine, if reason X is at least slightly better than couldn't be arsed.
- mewpmewp2 2y ago
  I would say to sync on this out of PR before to make sure you are aligned on it with reviewers so they don't have to waste time focusing on the wrong things and writing those comments in the first place.