4 ms·

I like the buildup here with "Antifragile". Sounded very cool and I was eager to see how it would apply to "Idea Generation". But Carmack's 5 steps seem to boi

by pbw 11y ago

I like the buildup here with "Antifragile". Sounded very cool and I was eager to see how it would apply to "Idea Generation". But Carmack's 5 steps seem to boil down to "Try to tear down ideas before you implement them" don't they? Just needlessly expressed as 5 separate steps?

amasad 11y ago
It's just me paraphrasing. You have to take my word that the talk is much more interesting. Although it does boils down to that, he spoke for an hour recounting ideas from game development and rocket science that he applied this on.
- ramkarthikk 11y ago
  This is one of the reasons I don't always support TLDRs or the apps that try to read an article and give you the important points. Yes, most of the articles can be explained in a sentence or two. But then there are articles or talks from which you take away new points every time you read it/re-read it. Your article is important for people who didn't have the privilege to listen to the talk (like me). So thank you for writing. It would also be interesting to read the takeaways of other people in the room even though the talk could be boiled down to "Tearing down ideas".
  - amasad 11y ago
    Totally. Take Antifragile for example, the "boiled down" version is a paragraph length, but it took a book for me to really internalize it. There is a big difference between getting the tl;dr of something and actually internalizing it. The latter takes a many examples, and takes looking at the subject in multiple ways and through different lenses. Which reminds me of a famous quote by the late Marvin Minsky: "You don't understand anything until you learn it more than one way."
firebones 11y ago
The book will clue you into a lot of other design principles beyond that simplification. For instance, one basic idea is to "accelerate stressors". Systems (and ideas) that are fragile won't survive exposure to stress, and the more stress we hide them from in an attempt to make them more robust, the worse the expected value (since we gain false confidence and invest more on a fragile foundation). Protecting from stress could be anything: automatically restarting crashing services, throwing money at hardware to scale out rather than addressing underlying performance issues at the edges, etc. When we accelerate stressors, we more quickly find out what works, and we commit to the graveyard our bad ideas and systems before they can take root. (If we test after building them, sunk costs leave us patching and iterating, and unable to change fundamental design flaws.) Another proxy for this is the Lindy Effect, which is a statement of how past longevity relates to future expected longevity. What has been around a long time (X years) can reasonably be expected to be still relevant (or as relevant) X years from now. If you're building throwaway code you can write in two months that you expect to only be relevant for 12 months, then by all means, use the flavor-of-the-month JS framework. If you expect the code to be relevant for 5-10 years, and you're going to take a year to write it...maybe look for as much code committed to infrastructure/languages/frameworks that have a chance of still being relevant 5-10 years from now. And certainly don't pick a tech with an expected future lifespan shorter than your poorly-estimated expected development time! There are MANY design principles to be learned from Taleb's book. Many are generalizations of ideas and mantras we've already internalized in the code domain. Via negativa is one--we colloquially see one manifestation of it as YAGNI and DRY. Maintaining long options is another--retain optionality in designs to potential upside (e.g., make it easy for others to extend your work and contribute to capture the value they provide.)

by pbw 11y ago

amasad 11y ago

It's just me paraphrasing. You have to take my word that the talk is much more interesting. Although it does boils down to that, he spoke for an hour recounting ideas from game development and rocket science that he applied this on.

ramkarthikk 11y ago
This is one of the reasons I don't always support TLDRs or the apps that try to read an article and give you the important points. Yes, most of the articles can be explained in a sentence or two. But then there are articles or talks from which you take away new points every time you read it/re-read it. Your article is important for people who didn't have the privilege to listen to the talk (like me). So thank you for writing. It would also be interesting to read the takeaways of other people in the room even though the talk could be boiled down to "Tearing down ideas".
- amasad 11y ago
  Totally. Take Antifragile for example, the "boiled down" version is a paragraph length, but it took a book for me to really internalize it. There is a big difference between getting the tl;dr of something and actually internalizing it. The latter takes a many examples, and takes looking at the subject in multiple ways and through different lenses. Which reminds me of a famous quote by the late Marvin Minsky: "You don't understand anything until you learn it more than one way."

firebones 11y ago

The book will clue you into a lot of other design principles beyond that simplification. For instance, one basic idea is to "accelerate stressors". Systems (and ideas) that are fragile won't survive exposure to stress, and the more stress we hide them from in an attempt to make them more robust, the worse the expected value (since we gain false confidence and invest more on a fragile foundation). Protecting from stress could be anything: automatically restarting crashing services, throwing money at hardware to scale out rather than addressing underlying performance issues at the edges, etc. When we accelerate stressors, we more quickly find out what works, and we commit to the graveyard our bad ideas and systems before they can take root. (If we test after building them, sunk costs leave us patching and iterating, and unable to change fundamental design flaws.) Another proxy for this is the Lindy Effect, which is a statement of how past longevity relates to future expected longevity. What has been around a long time (X years) can reasonably be expected to be still relevant (or as relevant) X years from now. If you're building throwaway code you can write in two months that you expect to only be relevant for 12 months, then by all means, use the flavor-of-the-month JS framework. If you expect the code to be relevant for 5-10 years, and you're going to take a year to write it...maybe look for as much code committed to infrastructure/languages/frameworks that have a chance of still being relevant 5-10 years from now. And certainly don't pick a tech with an expected future lifespan shorter than your poorly-estimated expected development time! There are MANY design principles to be learned from Taleb's book. Many are generalizations of ideas and mantras we've already internalized in the code domain. Via negativa is one--we colloquially see one manifestation of it as YAGNI and DRY. Maintaining long options is another--retain optionality in designs to potential upside (e.g., make it easy for others to extend your work and contribute to capture the value they provide.)