4 ms·

I think it might have to do with the fact that the older you get the more knowledge and experience you have; thus you see problems you didn't see before althoug

by dimman 10y ago

I think it might have to do with the fact that the older you get the more knowledge and experience you have; thus you see problems you didn't see before although they did exist all along. I like KISS. Usually there's three ways to solve a problem: 1) The quick workaround/fix. Almost always costs more in the long run but is fast. 2) The good enough fix. Costs a little bit more time and might not be the absolute best solution, but it's good enough. 3) The "real proper" fix. Costs a lot more time than the above with little value added over #2. These days I'm almost always opting for #2 by default because it's good enough. It's hard at times to let things go that you know could be solved in a better way. There's seldom a real need to go down road #3 for other purposes than your own satisfaction though, and that sucks at times.

monodeldiablo 10y ago
Amen. I've found that changing my conception of software from a concrete deliverable to a process has led to a more healthy relationship with my work. It's never done, and since I've made peace with that, I've rediscovered a different kind of delight in working. These days, I regard change requests as fascinating plot twists, not blemishes on my completed work. And I find myself asking, "Did that fix your problem?" much more and "Am I done?" much less. Since I consciously stopped trying to mind-read and anticipate needs, I've had much more success. Keep it simple and assume nothing. After all, expectation is the root of disappointment. My clients like it and I enjoy it more, too.
stinos 10y ago
These days I'm almost always opting for #2 by default because it's good enough. Me too, but I think it only works (and also doesn't introduce problems in the long run i.e. still keeps the software maintainable) because the software to which the fix gets applied is already properly designed to begin with. So in the end #2 only seems to work because the one applying it is good enough, and the software it's applied to is also good enough. At least, that is my impression from a bunch of experiences: applying #2 to what is aleady a trainwreck will usually cause problems in the long run anyway, standard avalanche effect. For proper, elegant pieces of software though basically the difference bweteen #2 and #3 fixes seems to fade away: everything is so loosely coupled and has such well-defined responsabilities that most fixes which are #2 simply cannot become any better no matter how much time spent because they are so focused there is only one way to fix it. Or there might be an alternative way, but the outcome is exactly the same so it's also not really 'better'.

by dimman 10y ago

monodeldiablo 10y ago

Amen. I've found that changing my conception of software from a concrete deliverable to a process has led to a more healthy relationship with my work. It's never done, and since I've made peace with that, I've rediscovered a different kind of delight in working. These days, I regard change requests as fascinating plot twists, not blemishes on my completed work. And I find myself asking, "Did that fix your problem?" much more and "Am I done?" much less. Since I consciously stopped trying to mind-read and anticipate needs, I've had much more success. Keep it simple and assume nothing. After all, expectation is the root of disappointment. My clients like it and I enjoy it more, too.

stinos 10y ago

These days I'm almost always opting for #2 by default because it's good enough. Me too, but I think it only works (and also doesn't introduce problems in the long run i.e. still keeps the software maintainable) because the software to which the fix gets applied is already properly designed to begin with. So in the end #2 only seems to work because the one applying it is good enough, and the software it's applied to is also good enough. At least, that is my impression from a bunch of experiences: applying #2 to what is aleady a trainwreck will usually cause problems in the long run anyway, standard avalanche effect. For proper, elegant pieces of software though basically the difference bweteen #2 and #3 fixes seems to fade away: everything is so loosely coupled and has such well-defined responsabilities that most fixes which are #2 simply cannot become any better no matter how much time spent because they are so focused there is only one way to fix it. Or there might be an alternative way, but the outcome is exactly the same so it's also not really 'better'.