John Carmack on Idea Generation | Hacker News Reader

John Carmack on Idea Generation

amasad.me

123 pointsamasad20 comments

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?

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.)

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.

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".

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."

"Failure events must end up making our system stronger. Meaning when an idea fails it needs to make the overall system better."

"As soon as you get an idea you try to defeat it. You’ll be able to generate more ideas because you freed up mental space."

These are good ideas, both from coding as well as entrepreneurial perspectives. Every failure you encounter, if taken as a learning lesson, will make you or your ideas stronger.

I tend to write my ideas down in a Google doc as a way of throwing them away. Then I keep going on my current one focus. If the idea is good enough, I always manage to come back to it and finish. If I don't, it probably sucked.

I wrote a more comprehensive essay on ideas here: http://brianknapp.me/books/creative-pursuit/chapter-7/

It seems that doesn't account for this effect of not immediately attacking your ideas, since I assume you don't forget them completely:

> Everyone has their pet ideas that they go around discussing. The more time this idea spends in your head the less critically you think of it. Now, when the time comes to actually try implementing it, if it fails you’re left discouraged, embarrassed and might even quit the project you’re working on.

This was, for me, the crucial insight of the talk this post is written about.

I like to tweet them. Something satisfying about shouting into the void knowing even if no one listens the echo will carry forever.

My ideas are too good and the main problem is getting enough time to complete them all.

We need an army of code servants that are cloned from our brains so they can create all our ideas for us (and make it properly) while we sit back, relax, and come up with the next idea.

No way, I want to have my cake and eat it too. Being an implementor is arguably just as much fun as being an "ideas" person.

The 100:10:1 method seems particularly relevant. http://blog.fogus.me/2015/11/04/the-100101-method-my-approac...

This is just one instance of it, but many people have written about it by this point.

I use trello cards so I can easily organise them into new, investigating, viable and not viable columns. Then I can easily put more detail into the card for each idea as well.

It's great because I can add ideas quickly from a widget on my phone's desktop.

any chance of watching this carmack facebook video?

Looks to me like scientific ideas, first thing you do (or should do) is try to shut it down.

Also as a counter-example, I've had ideas that I dismissed because I found apparent flaws in them and then I've seen those ideas being built into successful companies because users don't think like me and didn't care about my issues.

> Proprietary software is usually used in controlled environments all the while building up fragility for a major catastrophic event waiting to happen

Not necessarily true. OSX, Oracle, MS etc.. are used by many and are under constant stress test.

I don't think OSX is a good example here. As far as I know Apple builds both hardware and software, so even in hands of customers OSX still runs in quite controlled environment.

How much of this hinges on having enough tooling to be able to efficiently explore/prototype/abuse your ideas?

In my experience: a lot. Many of my projects have a `repl.sh` in the root dir that sets up the environment and autoloads the library for quick hacking and prototyping.

Reply on news.ycombinator.com