Let me see, when was the last time I used a flowchart. Believe it or not it was about 2 months ago when using multiple DS1820s and so I needed to implement the search rom algorithm. This algorithm is rather complex but Maxim provide a flowchart (See page 5 of AN162) and this enabled me to implement the algorithm in assembler without too many headaches. I think what I am saying is I find it much easier to write code when I have a correct flowchart.
FWIW, when I took Comp Sci courses I learned, among other things, that you're supposed to avoid flowcharts by using extremely well-commented code, written so that six months from now you'll completely understand those comments.
Even better: Comments so well-written that, if you get hit by a truck tomorrow, someone else, six months from now, can completely understand what you've done, and how.
When I was a college undergraduate, there were no Comp Sci courses. There were exactly two one-semester courses in programming: One in FORTRAN, one in COBOL; and neither were required. If you were majoring in the sciences or engineering, you took FORTRAN--if you wanted to.
In fact, when I arrived as a freshman at the University of Wyoming, it had just received as a gift and installed a brand-new Philco 2000 (yep, the Philco division of Ford ) for its computer center, which was in the basement of the College of Commerce and Industry building.
For me, the three important skills for good programming are:
1. Flowcharting
2. Detailed comments
3. Liberal use of subroutines
The comp room was a madhouse, punched cards flying through the air, three deep at the counter waiting for their output, and one look was enough for me.
I never learned Fortran or Cobol, but I might still be able to do something in Pascal or BASIC.