Do you draw flowcharts while you do the programming , design new network or simmilar ?
No, I do it after, its easier then.
In my experience there was a definite trend over the last 5-10 years of doing the documentation and similar chores after the design and development. In these days of "agile programming" developers are more encouraged to sign up for small bits of work that should be relatively easy to do with minimal documentation and "red tape", to try and keep their "velocity" high. Often developers produce prototypes for the work, which is usually more useful, correct, and as quick to implement as some of the more antiquated design techniques. However, once the work is done, documentation should be provided. The type of documentation usually depends upon the product that is being developed, however in my career I can honestly say I have never come across flowcharts being used in earnest. I hope this helps...
Though I was taught from "day one" to use detailed Program Flowcharts and Decision Tables, in hindsight this was really just a teaching aid.
Btw. The only time I ever used Decision Tables in earnest was when programming in RPG.
I have use Program Flowcharts in earnest.
Once you can visualise a whole program module-by-module in your head you are a programmer and are unlikely to need detailed Program Flowcharts to produce working code. However a simple "main route" Flowchart should be documented as part of the program specification and maintained with the filed program documentation. This should include an introductary overview of the function of the program and the function of each main module without going into fine detail. This documentation should be verified by the System Analyst and a Senior Programmer before the program is allowed to "go live".
I you ever work on a site long-term this sort of documentation could save your life. Everybody expects you to remember every line of code you wrote in every program. For a while this is easy but once you reach the 100,000 lines mark you won't even remember the name of the System.
I have made much use of overview Flow Diagrams at a System and Network design level to show visually how the individual components fit together. I cannot stress how important Flow Diagrams are in a large scale commercial environment where is is quite possible to get a cold call to a fault where there is nobody to ask.
Footnote: Yes, I have spent two months retro-documenting a dubiously designed and sparsely documented System ready for the next (inevitable) obscure failure. Try to avoid this sort of situation folks!
We call them architecture diagrams, which most of the time have some process flow enmeshed in them. Mostly created in google docs for easy sharing. Flowcharts as in precise process steps with branching and conditions and user roles, we never make those because they are too maintenance prone.
I do not design with typical flowcharts, however I do use whiteboards to draw the flow of data in very general terms, and also the rules.
My entire life would be flowchart drawing and revising if I were a 'strict' user. Yes, I use the general theory of flowcharting, just not to the detail that many think of from the 70's and 80's.
in my mind, yes!
on paper, next to never 
Good to draw after as it help to make clear options and simple the task.
Occasionally. Depends on what I am doing.