Flowcharts are, as Jargon file tells, a form of displaying the activity in program by using graph.
As with all forms of diagrams, they're a good servant but a bad master. Like all diagrams, they're only useful in design phase of programming project, and for communication between developers. And for these things, we already have better things like UML these days that are actually fun to use...
So, what does the flowchart look like?
Typically, the program flow is displayed as a vertical line, on which there are input, output and processing sections (represented as rectangles) and branching conditions (represented as diamonds). Sometimes other symbols are used - for example, tilted rectangles for processing, specially-shaped boxes for subroutine calls, and commonly there are small symbols for continuation over pages and markers for start and end of subroutines.
Above, I'm speaking of stuff that I learned in late 80s and early 90s; the modern flowchart stuff is sometimes even more watered down (it seems that people only use boxes and diamonds now...) I'm under the impression that in earlier times (60s and later), the flowcharts had a lot more symbols; for example, the book I have in front of me has special symbols for paper, magtape, punched cards, paper tape, and other horrors of the ancients.
So, what use are the flowcharts these days? Not much - if you want to make a graphical description of a multi-threaded program, you're getting nowhere because the above stuff doesn't tell how to do synchronous program flows. And don't even get me started on asynchronous stuff like GUI programming and signal-driven programs in general.
These days, it's better to use UML diagrams, some more laid-back diagrams, or pseudocode if you need to give a less detailed overview of the structure of the program to someone.
BTW, here's a good symbolic gesture for hackers: Buy a flowchart drawing disk/ruler/whatever, and never get it from the package. Then download Argo/UML and use it instead. =)