Ask HN: What's your ratio of time coding to planning?
25 comments
"Pee your problems away and think ahead!"
"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!
"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!
That really depends on how you define planning. Sometimes, I write code, realize I'm going in the wrong direction and need to re-plan things. Planning isn't always something you do before you put your thoughts to code.
This. After years of writing detailed specifications I realized I'm always stupid and always wrong. Now I plunge as fast as I can into code to find exactly where are my mistakes.
All time is planning. While I'm writing code is some of my most productive planning time.
Same for me. Not that I never sit back to think of the bigger picture, but I've learned to think at multiple levels at once, so I can think of the higher level design while writing code / comments.
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.
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.
Sage advice I heard somewhere: "Weeks of coding saves hours of planning."
Usually 60-65% planning 35-40% coding.
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.
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.
Putting aside BA work, I seem to do most planning in code - ie, fleshing out an example implementation in code, mocking up some models, etc. That eventually morphs into the end result. So, don't think it's as cut-and-dry as coding OR planning.
My guess is that it would depend on the project. Some projects are simple to conceive of (it will be like facebook, but for cat-lovers!), easy to rough out, but more difficult to implement correctly. Other projects may require a lot of up front planning and thinking (which data structure to use? what should it look like?) but then end up being quick to code.
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.
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.
In my experience, it's more or less 2 parallel processes which are very alike. If I really had to guess as to time, it's be something like:
Plan -> Code -> Refactor -> Replan -> Code -> Refactor
10% -> 15% -> 30% -> 20% -> 10% -> 15%
For me, the first refactor and replan phases take the longest time.
Plan -> Code -> Refactor -> Replan -> Code -> Refactor
10% -> 15% -> 30% -> 20% -> 10% -> 15%
For me, the first refactor and replan phases take the longest time.
What does writing tests count as? Especially if you're doing TDD or BDD.
Though code is used for test cases I would consider it planning. Especially in a TDD/BDD development process because you're taking the time to define what/how/where/when and why the implementation you'll write after works. Just my $0.02.
I agree TDD/BDD is the result of good planning and the byproduct is a coverage of cases into a application skeleton or bounding box.
Right in spot. I spend a lot of time in test files. It is not actual development, but not planning too. It is something in between.
Planning is a wasteful byproduct of being a poor developer. A good developer will write code once, get it right the first time, without any planning, and have it do exactly what it needs to do. Everything else slapped on top of that to get from A to B is a waste of time. That includes planning. Writing tests. Coordinating meetings. Documentation. Commuting. Sleeping. Unfortunately, people have come up with things like "planning" and "QA" because they hire incompetent developers - and instead of properly getting rid of them, they hire people to fill in the gaps and flaws.
Just kidding, sort of.
Just kidding, sort of.
slightly off topic, but i spoke to a Technical Department director in a Chinese computer games company yesterday about planning and length of projects etc.
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').
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').
20% coding, 70% re-writing the code. Planning 10% somewhere in the middle.
It's a very tough question because 'planning' can include time when I'm in the shower, falling asleep, or driving to work. I work at a megacorp though, not a startup.
I'm the co-founder/CTO of a startup and I agree: when I'm not in front of the computer coding, I'm always planning.
Yes, it's a rare day (but happens once a month) where I will step away from the computer and say, I'm digging myself into a hole and I should not code any more without a plan for how this will fit with the rest of the system, a plan for better abstractions, or a plan for testing, or whatever.
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.
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.
I know this is really stupid and the initial quality of some of the code i write is really low but when I am just making things for fun its kind of like freestyle rap to me so 0% planning 100% coding.
http://i.crowdfunded.it is an example of this.
http://i.crowdfunded.it is an example of this.
To put a name to it, your using the http://programming-motherfucker.com style/method.
I thought the "motherfucker method" was cursing at the program until it works. This aptly describes my style of programming.
hahaha :) fun, I believe I can share the same frustrations with non-programmers, except that I used to learn to make non-programmers viable tools that round-up the programming experience. It means that they can help in more ways than you can imagine as a programmer.
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.
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.
LMAO, do you think this is bad in all situations? If I am working for a client I use whatever their preferred methodology is. I really only do this when I am doing things for fun on my own.
If you have lived through and seen the changes, and can speak to why / when they occurred, I'd appreciate it.