3 ms·

Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing st

by fleitz 15y ago

Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. The first software that I wrote professionally was atrocious, hacky as hell, but it worked. I didn't let the fact that I didn't know how to program stand in the way of creating a solution. I probably could have spent a year reading books and writing practice software and the solution I came up with would have been much more elegant, but it wouldn't have mattered, they needed a solution today, not next year when I might have understood writing software at a much better level. I'm suggesting that knowing that something does work is far more important than knowing how it works, or why it works. Whilst I'm sure LCD manufactures have their scientists on understanding that part of the manufacturing process in the meantime they'll do their voodoo wool rub because it works. Maybe the wool rub with the plastic in the LCD disrupts the higgs field, who knows. Rubbing wool on an LCD because it works is an example of spit and bailer twine 'engineering'. Similarly, the first transistor was a massive hack, but a huge step forward for technology. I'm not advocating ignorance, I'm just saying that those who are ignorant can make huge steps forward, eg. the first guy who rubbed wool on an LCD. I'm sure the original facebook code had SQL statement embedded next to HTML; everyone knows it's a bad idea, but despite that you can put the foundations in place to make a huge business. The important thing is solving problems, not the elegance of the solution. Be a wright brother, make an airplane despite the fact that no one knows how. Solve a problem first, make it elegant second.

Jach 15y ago
> Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. My own objection would be: does it really work? If we can determine that yes, in fact, it does, then I want to know why, but I'd continue doing it until we know why. When you know why, you can make it better. Until then, you're still just shotgun testing. Not that shotgun testing can't work, but if you can do better, and you can afford the resources to learn how to do better, you probably should. I would agree the best is the enemy of the good enough, but also of the better--if all you know are so-called "best practices" and never deviate you'll never improve. You have to answer the question for your particular case though of whether deviations are likely to result in an improvement any time soon. I don't really understand why, in this particular case, some people would stop the method without a replacement, just on principle of not understanding it. This isn't the first case I've heard of such things though--I've heard of some developers on a team deleting large swathes of code they didn't understand, replacing it with something they wrote that doesn't even work nearly as well. (One of my roommates says for a robot project one of his teammates took apart a working breadboarded controller but still hasn't replaced it with anything.) > Solve a problem first, make it elegant second. "If you nail simple and fast, elegant is usually forced to come along for the ride.." ( http://twitter.com/#!/1/statuses/122368755962621952 http://twitter.com/#!/1/statuses/122368755962621952 ) I don't think elegance is at odds with solving a problem, but in general I agree that getting something working that's good enough now beats something that would have been better later. But not always, and possibly not even most of the time, as the time spent in the programming world rewriting and reinventing things shows.

by fleitz 15y ago

Jach 15y ago

> Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. My own objection would be: does it really work? If we can determine that yes, in fact, it does, then I want to know why, but I'd continue doing it until we know why. When you know why, you can make it better. Until then, you're still just shotgun testing. Not that shotgun testing can't work, but if you can do better, and you can afford the resources to learn how to do better, you probably should. I would agree the best is the enemy of the good enough, but also of the better--if all you know are so-called "best practices" and never deviate you'll never improve. You have to answer the question for your particular case though of whether deviations are likely to result in an improvement any time soon. I don't really understand why, in this particular case, some people would stop the method without a replacement, just on principle of not understanding it. This isn't the first case I've heard of such things though--I've heard of some developers on a team deleting large swathes of code they didn't understand, replacing it with something they wrote that doesn't even work nearly as well. (One of my roommates says for a robot project one of his teammates took apart a working breadboarded controller but still hasn't replaced it with anything.) > Solve a problem first, make it elegant second. "If you nail simple and fast, elegant is usually forced to come along for the ride.." ( http://twitter.com/#!/1/statuses/122368755962621952 http://twitter.com/#!/1/statuses/122368755962621952 ) I don't think elegance is at odds with solving a problem, but in general I agree that getting something working that's good enough now beats something that would have been better later. But not always, and possibly not even most of the time, as the time spent in the programming world rewriting and reinventing things shows.