Comment by csours | Hacker News Reader

Comment by csours | Hacker News Reader

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.

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

https://en.wikipedia.org/wiki/Six_Thinking_Hats

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!

same, I thought everyone learnt this in school when growing up...

I learned about the hats in primary school back in the 90s

I’ve never heard of it before. Sounds like it’s well known in Australia though!

Not everyone. I finished my formal schooling before the book was published.

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.

I read it and liked it. It's also on Alan Kay's recommended readling list, who i greatly admire: http://www.squeakland.org/resources/books/readingList.jsp

It's here for anyone who wants a video of the book: https://www.youtube.com/watch?v=3Mtc_CBTIeI&list=PLeAgmjjzpw...

I think you’ve nailed the heart of six hats thinking, and I really like this iteration of it geared towards code.

Does that make you a black hat?

Where does Team acceptance fells into? (Process/Project Manager?)

I honestly have no idea. I think you might want to turn it around and say what do I have to do for team acceptance.

Reply on news.ycombinator.com