3 ms·

Actually, I think 'half-assing' it is never good. But some people have a problem with perfectionism. I think in general one should have standards and the standa

by cjfd 2y ago

Actually, I think 'half-assing' it is never good. But some people have a problem with perfectionism. I think in general one should have standards and the standards should be good enough to keep a code base in a permanent state of maintainability. And even to bring back maintainability to a bad code base in small increments. This does not mean attempting to do everything perfectly, though, because that just invites too much stress and what is 'perfect' anyway? I think the 'boy scout rule' of leaving a piece of code in a better state than you find it is good. Don't make things perfect, just make them a little better and next time they can become yet another bit better. Also, try to automate more and more manual steps, especially increase automated testing. Automating testing is necessary to ensure improvements are not actually regressions in disguise.

mewpmewp2 2y ago
> Actually, I think 'half-assing' it is never good. All of these conversations are so bizarre to me. I have to imagine these basic labels like "half-assing", "perfectionism", everyone has their own little definition of those things, the circumstances are different, and really all of those things are more like spectrums. And in different scenarios very different configuration of how much "half-assing" is being done will have very different yields. You can make those absolute statements, and sure they could be the optimal truth in certain scenario, but there's thousands of permutations of different scenarios. From the article itself "self-identified overachievers" - to me that doesn't even mean perfectionism. It could be that someone is just doing a lot, but half assing all of it. They could also be identified as an overachiever. E.g. they are always working, and delivering half assed projects, which despite being half assed are successful because there are so many of them, and few of them succeed because they were delivered quickly. In addition if you are constantly working and "overachieving" you might start to half ass for just that reason, that you are mentally done. If there's one truth that is somewhat accurate is that in most projects the 80% / 20% rule does apply, that with 20% effort you can get the 80%, and rest of the 20% will become increasingly difficult towards the perfection, where perfection is actually impossible to reach. Is spending 20% effort to get the 80% and leaving it there half assing? Or is it 80% assing? Or 20% assing?
- cjfd 2y ago
  You are correct that it depends on circumstances. My comment assumes working on a software project for a longer duration and also that the project is non-trivial. Regarding your 80/20 comment I would say that this is true regarding features. I.e., quality attributes that the external world sees. My comment is about internal quality. So, let us say we have the 80/20 mindset and determine that features A, B, C, D, and, E belong to the 20% that we want to deliver and features F through Z end up on the backlog, perhaps to never be seen again. With insufficient internal quality it happens that the first and second version of feature C actually do not work, but fortunately feature C works the third time. Then feature D breaks feature A, but this can be fixed. After that feature E breaks C again, distressing the customer to no end because this is the third time that they have to report that feature C is not working and they already were a bit irritated that feature A broke.

by cjfd 2y ago

mewpmewp2 2y ago

> Actually, I think 'half-assing' it is never good. All of these conversations are so bizarre to me. I have to imagine these basic labels like "half-assing", "perfectionism", everyone has their own little definition of those things, the circumstances are different, and really all of those things are more like spectrums. And in different scenarios very different configuration of how much "half-assing" is being done will have very different yields. You can make those absolute statements, and sure they could be the optimal truth in certain scenario, but there's thousands of permutations of different scenarios. From the article itself "self-identified overachievers" - to me that doesn't even mean perfectionism. It could be that someone is just doing a lot, but half assing all of it. They could also be identified as an overachiever. E.g. they are always working, and delivering half assed projects, which despite being half assed are successful because there are so many of them, and few of them succeed because they were delivered quickly. In addition if you are constantly working and "overachieving" you might start to half ass for just that reason, that you are mentally done. If there's one truth that is somewhat accurate is that in most projects the 80% / 20% rule does apply, that with 20% effort you can get the 80%, and rest of the 20% will become increasingly difficult towards the perfection, where perfection is actually impossible to reach. Is spending 20% effort to get the 80% and leaving it there half assing? Or is it 80% assing? Or 20% assing?

cjfd 2y ago
You are correct that it depends on circumstances. My comment assumes working on a software project for a longer duration and also that the project is non-trivial. Regarding your 80/20 comment I would say that this is true regarding features. I.e., quality attributes that the external world sees. My comment is about internal quality. So, let us say we have the 80/20 mindset and determine that features A, B, C, D, and, E belong to the 20% that we want to deliver and features F through Z end up on the backlog, perhaps to never be seen again. With insufficient internal quality it happens that the first and second version of feature C actually do not work, but fortunately feature C works the third time. Then feature D breaks feature A, but this can be fixed. After that feature E breaks C again, distressing the customer to no end because this is the third time that they have to report that feature C is not working and they already were a bit irritated that feature A broke.