I don't believe in the 6 thinking hats methodology (I don't think it has anything to do with psychology, but I do think it has something to say about work), but I think I learned something from reading about it.
I have a certain mentality where I will plan a feature, and then I will spend literally forever poking holes in that feature and thinking about all the ways it will fail. This demotivates me greatly.
I think it is better to plan the happy path, then take a finite, planned amount of time to mentally test it and note corners and edges, then take a stab at iteration, then go back and re-evaluate. I think this is probably how normal people do this, but I also think it's easy to get stuck on one of those modes. One of my architects is stuck on happy-path mode, and it's really hard to get them to actually think about implementations.
---
Notes on the 6 hats: I think the important thing is not to get stuck on one hat. You may pick some of these as your focus, but I think it's important to have some balance as well.
This was introduced to us during year 5 and 6 (ages 10-11) schooling in the Australian public education system's gifted and talented stream. Great free education!
It's really hard to be critical of your idea and to be super enthusiastic and passionate about that idea as well. In theory, this works but in practice it's super hard. I have tried it. Either I'll be super exuberant and tend towards over optimism or be super critical and get demotivated like you've mentioned.
I think allocating a specific time to poke holes in an idea might really work.
Another option that I have found helpful is external validation. You talk or demonstrate your ideas to outsiders and they are generally critical of your demonstration. This can be an eye opener some times. You as the idea originator, can then take a real hard look at the critical feedback and test out if that feedback really breaks the idea. There will be a ton of armchair criticism that you can ignore, but you get specific pointed criticism that is super helpful.
Even better is to have a co-founder or someone internal who can take a critical stab at your ideas. Of all the reasons that are out there for having a co-founder this might be the most useful one, especially for experienced folks. It is a bit tricky to make this kind of co-founding relationship blossom though.
Carmack described the wantrepreneur. Beware the "idea guy," find the head-down guy or gal who is smart and a workaholic; people who tend to work more than socialize, fall in love with ideas and talk about work that they're not doing.
There's no free lunch and schlepping where others give up or aren't willing to invest energy, time and money are also key. If something is relatively easy for you but more difficult for most others, that's a good signal. And if that something becomes very difficult for you, think of how hard it would be for someone else... that has the potential to be a defensible business.
Antifragile: "Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. According to Taleb, the opposite of fragile is antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better"
Do those things become stronger or do they just remain while everything else collapses? How much is this about being the real deal? In crisis, bullshit doesn't work anymore.
from reading his book on the topic, my understanding is that they become strionger. he would classify "just remaining" as robust as opposed to antifragile
Developing that skill is really hard. It isn't the methodology. It's that you need the pervasive paranoiac scientific desire to poke holes in the idea. And that's very hard for most people. Carmack applies evidence to develop his posteriors very well.
i.e. when evidence comes along for an idea you have, most people will say to themselves "Even though that's true it's not enough" or "but that doesn't disprove it". In fact, I'd hypothesize (with poor evidence) that people who do not alter their posteriors when presented with evidence cannot do this at all. And that's very common - because lots of evidence won't disprove anything, it'll only make it less likely. If you never alter your posteriors you will dismiss it.
I know I sometimes fall in love with an idea and this happens.
The best way to get over a brilliant idea is to start working on it. Hopefully, that work inspires another idea and so on and so forth until you end up with something real.
The "big idea" folks typically go further by treating their ideas like their offspring and insulate critiques of those ideas from the big, scary world of reality. Also, making an analogy to "cattle" sends the wrong message to the demographics of developers these days; I would replace that with something inanimate.
I suppose whether that's true depends on whether you are looking for a metaphor that is technically accurate and descriptive or one that is perceived as such by your audience.
I'm aware that there is value in both of those, and as such am willing to strive for both, but moreso to the extent that I trust that those with whom I am communicating are doing the same. In this case, I'm not sure that good faith is there.
Good novel ideas that identify a consumer/user demand are always high value whether implemented or not.
Zero to One by Peter Thiel basically implies this with his "Competition is for suckers, monopoly is where it is at". Yet how many businesses and tech companies get founded doing the same think everyone else is doing (or at least half a dozen competitors)?
Truly novel ideas, truly thinking outside the box, truly seeing possibilities that aren't in existence is HARD. Extremely hard. I can understand why the idea that ideas without implementation is meaningless became so prominent, but that is mainly because most of the ideas people have have been had by 1000 other people so if you arne't implementing they aren't of any use.
Whereas ideas that are truly novel are still extremely valuable because it gives all the hard workers something worthwhile to shoot for (as opposed to yet another social media app).
As an example think of blockchain. Fairly basic from a techincal or implementation sense, it is the idea that was really novel. Even if Bitcoin hadn't been made, the idea itself is enormously valuable. There are 1000s of ideas out there like this waiting for a novel thinker to draw them out of the fog and make them clearly visible.
> There are 1000s of ideas out there like this waiting for a novel thinker to draw them out of the fog and make them clearly visible
I think this is the exact reason people say ideas (on their own) aren't worth very much. "Drawing them out of the fog to make them clearly visible" is the implementation portion as far as I can tell. That's the part that makes the idea valuable.
I, along with thousands of others, had the idea for Doordash/UberEats long before either of them existed. Years before. However, if I had tried to implement the idea back then it still would have likely failed. Even though I had the idea, I had no idea how to implement it (and still probably don't, as it is much more than just a technical problem). I realize that Doordash isn't that novel of an idea. But I think even the incredibly novel ideas are thought of by dozens of people before the "right" person comes along to implement it.
That's why I don't think people are memeing when they say "ideas are worthless", as ggp implied. It's more of a response to the "I have an idea and I'll give you 5% if you build it for me" propositions that developers tend to get.
I don't think people even know what they mean when they talk about startup ideas generally.
If the Bitcoin paper is an implementation, then what is the idea? You could argue that the "idea" would be something like "a distributed trustless transaction protocol" or something.
But then you could as easily argue that that's not an idea. That's a goal.
Inversely, you could argue that the Bitcoin paper is not an implementation, that the implementation is the actual software that... implements the content of the paper.
The problem with "idea" and "implementation" is that they're relative concepts that can be used to separate arbitrary parts of complex systems into two buckets, but where that separation doesn't always provide any insight.
Is general relativity an idea or an implementation (of the idea "a better theory of gravitation than Newtonian mechanics")? Is a winning trading strategy an idea or an implementation (of the idea "something that makes money on the stock market")? Etc.
The whole concept of a "startup idea" itself is fraught with imprecisions. Not to mention the assumption that startups are to be based on one singular idea, which is highly debatable.
I think this conflicts a little with my view of antifragile.
Or maybe it compliments it. Can't say clearly.
My view is that having multiple ways to do things often leads to an antifragile system. Reason being that busting one way only busts that one way. This plays out in the likes of timsort. The point is to pivot not just the same strategy on the data, but to pick your strategy on the data.
As he said in this tweet, even with 8 hours of sleep, there's a lot of time left per week and people like Carmack makes the most out of those remaining hours.
I know a lot of people outside the normal 9-5 job who overwork themselves and takes less than 8 hours of sleep though. I think it has a lot to do with the fact that people just react to stuff and it's easy to come up with short term thought process of "less sleep = more work", instead of working fewer hours one day in order to keep long focussed hours in the long term. Also, some people can't afford 8 hours of sleep, as far as I have seen, unfortunately.
I have a certain mentality where I will plan a feature, and then I will spend literally forever poking holes in that feature and thinking about all the ways it will fail. This demotivates me greatly.
I think it is better to plan the happy path, then take a finite, planned amount of time to mentally test it and note corners and edges, then take a stab at iteration, then go back and re-evaluate. I think this is probably how normal people do this, but I also think it's easy to get stuck on one of those modes. One of my architects is stuck on happy-path mode, and it's really hard to get them to actually think about implementations.
---
Notes on the 6 hats: I think the important thing is not to get stuck on one hat. You may pick some of these as your focus, but I think it's important to have some balance as well.
Hat Color - Original Theme/My theme
White - Data/Data Analysis
Yellow - Optimism/Happy Path Plan, Architectural View
Blue - Process/ Project Manager, Task management, Scrum
Black - Pessimism/Testing view, how will it go wrong
Green - Creative/Implementation Phase (just write some code)
Red - Emotion/Iteration Review, Hot wash