|Perl: the Markov chain saw|
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.