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: <a href="http://5by5.tv/s/14y" rel="nofollow">http://5by5.tv/s/14y</a>
There is so much truth packed into that 36 mins -- so many juxtapositions -- it would take several hours to reference them all.<p>For starters, see Rich Hickey's talk on "Hammock-Driven Development" for more on the "background mind" (<a href="http://blip.tv/clojure/hammock-driven-development-4475586" rel="nofollow">http://blip.tv/clojure/hammock-driven-development-4475586</a>), and then see how what Dan Pink is saying about motivation (<a href="http://www.ted.com/talks/dan_pink_on_motivation.html" rel="nofollow">http://www.ted.com/talks/dan_pink_on_motivation.html</a>) and what Sebastian Deterding is saying about gamification (<a href="http://www.youtube.com/watch?v=7ZGCPap7GkY" rel="nofollow">http://www.youtube.com/watch?v=7ZGCPap7GkY</a>) 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.
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.<p>I watched this last week, and this was my big takeaway. Programmers too often want to argue about what is right.