-=> Quoting Bob Lotspeich to Rick Pedley <=-
 BL> Like you, I find it much easier to
 BL> sit down and think the program out, then start typing it in. If I hit
 BL> a snag, I will briefly pseudo-code it out on paper sometimes, then go
 BL> back to working on the code itself.
  
Flow charts were in vogue when programs had a beginning and an end:
the program was run, it did something, it finished, more or less
unattended. I don't know of too many programs like that anymore except
for small utilities; instead they tend to be enormous closed loops with
dozens of branches on the way around, each branch possibly a loop in
itself. The sheer size of such a flow chart would minimize its usefulness
as a simplified overview. And how do you represent event-driven Windows
apps with flow charts? But whatever works for the individual, there's
no hard and fast rule. Several studies have been done however, that showed
flow charting made little or no difference in the quality of programs
written by high school and college students. I can't quote you any
sources unfortunately, it's been ten years or more since I left teaching.
--- Blue Wave/DOS v2.20
---------------