I don't find working on whiteboards useful for figuring things
out. What many programming books don't mention is that diagrams
are generally useless for explaining things to oneself, but very
good for explaining things to others.
So, instead of writing diagrams on whiteboard, I pull out
a notepad and scribble out in pseudocode what I think a given
process is supposed to do. Then I can type it in as comments as I
write my code. It gives me a quick way of seeing the big picture
of the code without creating flowcharts.
When you're dealing with nonprogrammers (Muggles? Trivial persons? :) )
it's best to be armed with charts. Nonprogrammers will occasionally panic
at screenfuls of text, but they often feel at home with pictures.
Dive-coding (just immersing yourself into the code without prep work)
feels practical, but sometimes can get you into serious trouble if what
you thought the client wanted and what the client thought they wanted
are different things. But there are other, sometimes far better, charts in this world than
flowcharts. Transition diagrams are good; so are use-case diagrams.
If you are the client, though, by all means dive right in...
And yeah, it's frustrating when a professor makes you diagram,
but it's important to know how to do... since there are more people
out there that think like that professor.
Not so, not so... True, you get a lot more done coding, but my boss doesn't like to say what he wants... that, or he finds it even harder to put words to his ideas than i do... so i practically have to wrench it out of him with a pencil and paper... then he changes his mind before i get the 0.0.0a version out... or he trashes the project minutes before i complete it...
also, i'm working on a project with my brother... he knows NOTHING about computers (oh, sorry, forgot... he knows how to move the mouse), so we're gonna have a HUGE planning session next week or so...