John Cleese on how to be creative(youtube.com)
youtube.com
John Cleese on how to be creative
https://www.youtube.com/watch?v=VShmtsLhkQg
5 comments
If we're going to share this across the entire web, let's give credit where credit is due: Merlin Mann, Back to Work 62: http://5by5.tv/s/14y
There is so much truth packed into that 36 mins -- so many juxtapositions -- it would take several hours to reference them all.
For starters, see Rich Hickey's talk on "Hammock-Driven Development" for more on the "background mind" (http://blip.tv/clojure/hammock-driven-development-4475586), and then see how what Dan Pink is saying about motivation (http://www.ted.com/talks/dan_pink_on_motivation.html) and what Sebastian Deterding is saying about gamification (http://www.youtube.com/watch?v=7ZGCPap7GkY) all connect into what Cleese is saying about creativity.
For starters, see Rich Hickey's talk on "Hammock-Driven Development" for more on the "background mind" (http://blip.tv/clojure/hammock-driven-development-4475586), and then see how what Dan Pink is saying about motivation (http://www.ted.com/talks/dan_pink_on_motivation.html) and what Sebastian Deterding is saying about gamification (http://www.youtube.com/watch?v=7ZGCPap7GkY) all connect into what Cleese is saying about creativity.
In the context of software development, I think his idea that we should switch from open mode to closed mode when it's time to implement something is dead wrong. I today I gave a demo of something epic at work that I had developed exclusively on my own time. The way I managed to get myself to spend 30+ hours of my free time producing something for work was by remaining in open mode: i.e. I was playing.
You might be missing something here. In the Open mode you came up with your epic idea. You saw connections that were not immediately obvious and formed the kernel of the idea.
It takes the closed mode to focus on 'divide and conquer' and implementation of the idea as envisioned. This doesn't stop you going back in to Open mode to frequently consider where you are. Judge your work against it's initial goal etc.
If you are perpetually in Open mode you would continually add new features and extend the brief and never implement anything. I've worked with those kinds of people, they are a PITA.... although very creative.
Some people seamlessly switch between open and closed and others are stuck in one or the other.
I personally struggle to get in to the Open mode. After 30 years of disciplined coding, leading teams and divide and conquer my mind is highly specialised. It doesn't mean I'm not creative but it takes me longer to get in to that mode of thinking.
It takes the closed mode to focus on 'divide and conquer' and implementation of the idea as envisioned. This doesn't stop you going back in to Open mode to frequently consider where you are. Judge your work against it's initial goal etc.
If you are perpetually in Open mode you would continually add new features and extend the brief and never implement anything. I've worked with those kinds of people, they are a PITA.... although very creative.
Some people seamlessly switch between open and closed and others are stuck in one or the other.
I personally struggle to get in to the Open mode. After 30 years of disciplined coding, leading teams and divide and conquer my mind is highly specialised. It doesn't mean I'm not creative but it takes me longer to get in to that mode of thinking.
No, I'm fairly certain I was in open mode the entire time I was implementing the system. It wasn't a single epiphany followed by many hours of implementing the ideas generated in that epiphany; it was a continuous stream of idea after idea, with little "what if" explorations. I was experiencing flow: http://en.wikipedia.org/wiki/Flow_%28psychology%29
I wasn't stressed, thinking about deadlines, or worrying about whether my system would work or not. I was simply playing, with no goals in mind other than improve the "beauty" of the system. It was very similar to what I experience when I'm painting or composing music.
There was another system I developed a few months back - again, exclusively on my own time. I would only work on it while in open mode. Only once I felt my "art" was complete did I present it to my manager and a few execs. They loved it! My system has now replaced the old system and is now part of a real product. Had I instead tried to develop the system at work, because my boss said I had to, I highly doubt it would have turned out as good as it did.
I wasn't stressed, thinking about deadlines, or worrying about whether my system would work or not. I was simply playing, with no goals in mind other than improve the "beauty" of the system. It was very similar to what I experience when I'm painting or composing music.
There was another system I developed a few months back - again, exclusively on my own time. I would only work on it while in open mode. Only once I felt my "art" was complete did I present it to my manager and a few execs. They loved it! My system has now replaced the old system and is now part of a real product. Had I instead tried to develop the system at work, because my boss said I had to, I highly doubt it would have turned out as good as it did.
A very important nugget of wisdom is at 27:18. In short: it's very useful to be creative w/ other people, but you have to be supportive even if you disagree. Don't tell people "no" or that they are wrong. Provide constructive redirection.
I watched this last week, and this was my big takeaway. Programmers too often want to argue about what is right.
I watched this last week, and this was my big takeaway. Programmers too often want to argue about what is right.