Hacker News new | ask | show | jobs
by getpost 1215 days ago
Tangentially, Taleb tweeted a nice quote yesterday, "You don't do well by trying to be right; it is impossible for humans. You do well by figuring out when you're wrong faster than others do."

https://twitter.com/nntaleb/status/1627765781168619520

3 comments

This is wack advice.

There's value in shipping an MVP (or multiple MVPs) fast, sure. Cull the failures and iterate the successes. Better than trying to achieve perfection with a forever-delayed product that never ships.

But even the sloppiest, most minimal MVP has to get something extremely right. You need to solve some problem for the user in ways that others haven't.

If you don't get things right enough, you've just trashed your entire brand. Game over.

And sometimes, getting things "right" is literally your entire unique selling point. Look at Apple nailing the iPod's features in ways that its predecessors didn't. Look at Tesla nailing their vehicles' features in ways that its predecessors didn't. Etc.

>Look at Apple

both Apple and Tesla have had plenty of failures to learn from -- and they recovered remarkably.

There isn't much reason to believe that the parents' quote is at-odds with the operation of either of those two companies.

No, sorry. That's not Apple's corporate culture. Apple is not and never has been a "fail fast and learn from your failures" company.

Tesla, on the other hand, is a great example -- they're willing, even enthusiastic, about killing their customers as learning experience.

It is not impossible for humans to be right. This is an idiotic position.
I have no idea what Taleb actually means, but to the extent it isn't dramatic rhetoric, I imagine his claim is based on the idea that humans can never be completely right, due to the limits of our perception and memory. The best we can hope for is to be right enough to survive until the next iteration of our learning process.
Taleb loves an idiotic aphorism.
Strongly agree. We need to put out a constant stream of low-quality products, and iterate quickly to achieve our goals.

I used to do the opposite: write high-quality well-tested code, but very often the results weren't useful to the business by the time I was done. It would have been much better to produce a couple "sketches" of the feature first, then the business could kill or refine it as they want. Everyone wins!

(disclaimer: writing a book, featuring feedback loops)

Isn’t most of our business code just glue, forms and api? I appreciate the quick way, but also believe that our tools at hand have a plenty of room to improve. Sometimes I drop a project because it induces “ah, here we go again” mood. Quick mudballs that could be bricks that could be panels, but there’s nowhere to order them. The worst part is when the idea actually works so that mudball becomes your home.
That is quite nuanced. It is good to be clear when you are building a POC or a production ready feature. Often the POC becomes the POS. But https://www.explainxkcd.com/wiki/index.php/2730:_Code_Lifesp...