If you have lived through and seen the changes, and can speak to why / when they occurred, I'd appreciate it.
"Ask yourself, why do you think the best ideas come when you're in the toilet?"
It sounds trivial and you won't suspect a magic or pattern behind it. You'll think it's just coincidence, but in reality you secretly remember the toilet is an awkward place where you magically solve the problems that you were stuck with all day. It's way of thinking, releasing yourself from stress to focus on the path you want to go with your planning and code, not so much theory here. It's not enforcable.
The only room, where you're alone with yourself and where you relax your inner muscles. As you know, every contraction happens in your cerebrum first, this relaxation acts as stimulus for something I can't explain.
Planning, Development, Strategy and Success aren't entirely seperate, they live in symbiotic co-existence and strengthen each other. That's why many people say "You first start coding and the rest will follow". In reality this is an illusion, you can't code without planning or strategy, it's fueled by hard trained routine and effective problem->solution matching. You know it: The more you code the better you become and success boosts you into new directions.
We've all experienced it, sometimes you're better than usual and you want that effectivity back, when you're stuck and don't know a solution. Call it flow if you want, but I think it's peeing problems away :)
My routine is to do more learning than planning. Because the more relations from very different topics I can come up with, the more effectively I can solve a problem on a special field.
Have a nice weekend!
I'm usually a bit wary about planning without thinking of the code level because it can quickly result in architecture-astronaut plans which take a lot of decisions prematurely.
There's two kinds of projects -- the ones who know what their solutions should look like, and why, and the ones who don't.
Most problems really end up being hammer and nails once we understand them and can make a clear blueprint.
Part of planning can often mean Proof of Concept coding / trying out some things, but not always production code.
Just because we can build a doghouse without a blueprint doesn't mean we should build a house or a factory without one.
I've noticed that when I write programs, the more time I spend planning features and algorithms before I start writing code the less time it takes to actually create. I don't always spend a lot of time planning, though.
Plan -> Code -> Refactor -> Replan -> Code -> Refactor
10% -> 15% -> 30% -> 20% -> 10% -> 15%
For me, the first refactor and replan phases take the longest time.
Just kidding, sort of.
He said they never have a web project lasting more than 2 weeks. ie. from planning to completion.
It's not because they're using agile methodology or iterations or whatever.... they just do things differently (and yes, sometimes that means zero planning, zero testing and generally 'worse').
But that is because I spend a lot of time when not coding, thinking about these things, so the path forward is clear. And that higher-level planning usually happens informally, all the time, away from work.
http://i.crowdfunded.it is an example of this.
Also I think that using the right tool to plan is very important. The right tool must be something that fits into your routine and thinking more cognitively and intuitively than conceptually.