Flow charts and programming

[LucyB]

Do you do the flow chart first or go straight to the code? I find it easier to do the code first for some reason, maybe this is bad?

[Salem]

Depends on the scale of the problem.
If you can "see" the whole problem at once, then just doing the code is probably fine.

But if it's going to take you more than a day (or you plan on maintaining it in any way), then some kind of design is essential.

You wouldn't approach building a flat pack garden shed in the same way you would a house or a skyscraper.

Flow charts are just one of many ways of looking at the design problem.

[Narue]

>Do you do the flow chart first or go straight to the code?
This question assumes that the only alternative to diving into code is drawing a flow chart. I'm anal about careful design before writing code, but I rarely draw flowcharts unless some management type asks for it.

>I find it easier to do the code first for some reason, maybe this is bad?
You'll discover that past a certain level of complexity, this hacker mentality begins to break down quickly. This is the biggest problem I have with hiring rookies. They don't have sufficient experience to appreciate the critical role design has in a successful project.

[Rashakil Fol]

Flow charts are basically an awful way to design a program and an awful way to represent the design of a program. If you asked me to name any "good" ways to _represent_ the design, I couldn't. But I think type systems are pretty good.

The very idea of just jumping in and coding is completely nonsensical. It's not like you just jump in and write code that (somehow) will lead you to the solution. You surely need think about what information you will be manipulating and how you will communicate information first. The phrase "what information you will be manipulating and how you will communicate information" is also called "the design".