Is this a legit tool or is it a crutch that I will eventually grow out of needing?
Update: By order of operations, I mean:
Right now, I draw diagrams at the method level as well as the app level when I'm having trouble visualizing the program flow.
There are many things I draw, it depends on the my capacity to comprehend an abstraction. Don't think of it as a crutch rather as tool you need and thus use. Your abilities are different to others sometimes better sometimes worse. Don't knock yourself for using a tools that helps you be an engineer, even if no one else uses them.
But importantly you should always be on the look out for better ways.
I try to generate documentation from the code, not the other way round, so I would say no.
I typically code it and fix it until it meets requirements and have any documentation either in the code or generated.
In my current system (almost entirely SQL-based), the processes in the system are in tables and metadata is extracted either from the system metadata or auxiliary tables we maintain. Flow diagrams are generated from these dependencies using MSAGL. The diagrams also act as our interactive dashboard.
Off the top of my head, I've mainly seen flowcharts when business analysts are involved and mainly when the specs are being worked out.
Wnen working with non-technical folks, it's a convenient way of modeling data/information flow.
Oh yes: They're almost always very simple (at least the good ones). Any single flow-chart with more than a handful of polygons and lines and you start losing people.
My opinion is that when working at the method or expression level flow charts are usually overkill. However they can be useful for learning, or for understanding broad control flow in an application.
If you find them useful there is no reason not to use them.
It depends on how complex the process flow is. It's a tool for visually displaying the flow of information or the workflow. If it's simple then by all means do it in your head. I usually find (even after 14 years of doing this) that have it to glance at during my code design is useful to keep me focussed on the process in the correct order.
I use flowcharts all the time to map out orders of operations.
If you mean "order of operations" in the sense of "overall data flow of a program", then flowcharts are an absolute must. There come to be certain diagrams that everybody has a copy of, and that are seen on whiteboards all around the office because they are so important/common. eg, a diagram to describe that "Data from the application, is encapsulated using a UDP header, and then travels to the IP layer, where a header is then added..."
If you mean "order of operations" in the "how does this code work" sense, then yes - flowcharts absolutely help there as well. "The first thing we do in this routine is compute the checksum. Then we pass the pointer to the next routine and set a timer. The callback function for the timer is..."
If you mean "order of operations" as the mathematical evaluation of expressions, then this can be important as well when trying to understand someone's code, or when trying to write your own algorithm. "First we increment the pointer, and then we dereference it so that we can read the value..." or "We need to right-shift the integer 32 times, check for the presence of a 1, and then..." These are sometimes algorithm flowcharts, or sometimes operator flowcharts. In either case, they are useful to understanding what is going on without having to mentally parse code.
That is to say, they are not a crutch at all.
Some things to note: with the mathematical evaluation... often, if an expression is not easily readable (many nested operations or parentheses, may operators of many different precedence - like dereferencing, incrementing, and arithmetic), it might be better to break the code into multiple smaller steps. That way you can easily show the logic of the calculation, as well as the implementation. You might still need a flowchart, but the code itself reads easier.
Finally, more advanced/experienced programmers sometimes don't need as many flowcharts. They already have the relevant diagrams memorized, or they can parse logic better because they recognize certain idioms. You will certainly develop that, if you haven't already. But in the meantime, there is no reason not to use flowcharts if you need to understand something. Not a crutch at all!
Flow charts, as in the old school kind http://en.wikipedia.org/wiki/Flowchart were a bad idea when they were invented and are still a bad idea.
I don't know any programmers, good or bad, who use them. They don't help, in that the problems in which they can make things clearer are trivial, and any problem which isn't trivial is made less comprehensible, rather than more by a flowchart. I would go so far as to say any formalized drawing system for programming is a waste of time. Sure, you can make some sketches on a whiteboard or with pencil and paper that can be helpful, but taking it beyond this (e.g. visio, I'm looking at your idiocy) is a waste of time.
no, experienced programmers don't use flowcharts, they use data-flow diagrams, action diagrams, sequence diagrams, use cases, et al; flowcharts fell out of favor in the 1970s when empirical studies* pretty much demonstrated that they were useless as a design tool
...Empirical studies of GRA's have focused primarily on the flowchart and the results of these studies indicate its effectiveness as an aid to comprehension is questionable.
yes, of course. Visual metaphors are useful tools.