4 ms·

But many people do let perfect be the enemy of the good. Sometimes they're even right. If you think we shouldn't push a quick & dirty fix for this issue that'

by danaris 10mo ago

But many people do let perfect be the enemy of the good. Sometimes they're even right. If you think we shouldn't push a quick & dirty fix for this issue that's affecting 20% of your users, because a good fix will take much more time, but also take care of an entire class of bugs that are otherwise likely to crop up... That's letting perfect be the enemy of the good. And there's no way to know, just from that scenario, which side is really correct. Maybe the bug will cost your company $1 million/hour until it's fixed. Maybe letting the quick & dirty fix go in means that you'll annoy users enough that you'll lose 10% of them permanently.

godelski 10mo ago
I think we're in agreement. Though I want to expand on something a bit subtle. Perfect doesn't exist. There's no perfectly written code. If there were it wouldn't be perfect for long because the environment is constantly changing. After all, code rots. I want to make that clear because it is why I said only a real novice gets roadblocked by perfection. They might have an idea of a perfect solution but anyone with any meaningful experience knows the real world is full of unknown unknowns. (Even with perfect information it's usually not traceable) What's the old joke? Theres two types of software: those with bugs and those nobody uses. So given that, everything else is actually an argument of "what is good enough." Take perfection off the table, it isn't useful here [0] In other words, we're looking for locally optimal solutions, not global. Because global likely doesn't exist[1]. My interpretation of what you said here is the same. We could write down all the (known) conditions of that problem and still not get a perfect solution that works every time. There are good practices, but those aren't bulletproof algorithms to success. They still require interpretation[2]. So the job of the engineer isn't to be a robot that follows instructions to the letter. It is the job you interpret, explore, and discover. It's to implement suboptimal solutions and iterate on them to find better suboptimal solutions. You have to balance short term and long term benefits, such as your hot patch scenario. There's always some trade being made. And that's why the thought terminating cliché is so detrimental, because it at best sidesteps the trade-off conversation and at worst creates willful ignorance of them. [0] perfection is a good target to help align but it is also fundamentally unobtainable. We could say that same thing about utopias. But similarly the inverse (e.g. shit code/dystopia) is easily obtainable. This, I think, is a subtle difference in how we're using the term "perfection". I think you're using it as a guide rather than a literal objective that can be achieved in finite time. Do I have that right? [1] real world problems are very high dimensional and we usually project them into lower dimensions to make solving more tractable. [2] no rule can be so well written that there are no exceptions. (Including this rule)

by danaris 10mo ago

godelski 10mo ago

I think we're in agreement. Though I want to expand on something a bit subtle. Perfect doesn't exist. There's no perfectly written code. If there were it wouldn't be perfect for long because the environment is constantly changing. After all, code rots. I want to make that clear because it is why I said only a real novice gets roadblocked by perfection. They might have an idea of a perfect solution but anyone with any meaningful experience knows the real world is full of unknown unknowns. (Even with perfect information it's usually not traceable) What's the old joke? Theres two types of software: those with bugs and those nobody uses. So given that, everything else is actually an argument of "what is good enough." Take perfection off the table, it isn't useful here [0] In other words, we're looking for locally optimal solutions, not global. Because global likely doesn't exist[1]. My interpretation of what you said here is the same. We could write down all the (known) conditions of that problem and still not get a perfect solution that works every time. There are good practices, but those aren't bulletproof algorithms to success. They still require interpretation[2]. So the job of the engineer isn't to be a robot that follows instructions to the letter. It is the job you interpret, explore, and discover. It's to implement suboptimal solutions and iterate on them to find better suboptimal solutions. You have to balance short term and long term benefits, such as your hot patch scenario. There's always some trade being made. And that's why the thought terminating cliché is so detrimental, because it at best sidesteps the trade-off conversation and at worst creates willful ignorance of them. [0] perfection is a good target to help align but it is also fundamentally unobtainable. We could say that same thing about utopias. But similarly the inverse (e.g. shit code/dystopia) is easily obtainable. This, I think, is a subtle difference in how we're using the term "perfection". I think you're using it as a guide rather than a literal objective that can be achieved in finite time. Do I have that right? [1] real world problems are very high dimensional and we usually project them into lower dimensions to make solving more tractable. [2] no rule can be so well written that there are no exceptions. (Including this rule)