On flowcharts and pseudocode

The other week I had to write a small overview about flowcharts and pseudocode and their uses for my Introduction to Python class I am taking this semester. Many of my classmates did not seem to understand the roles flowcharts and pseudocode played in the program development cycle, and my little explanation seemingly helped some of the other students understand their differences and usage. The following is a revised and expanded version of the writing, and truthfully I wish they would have read this one instead, as they might have understood it more. It is geared more towards beginner programmers, but that is fine, as most of my writings are for beginner to intermediate-level programmers. Enjoy. 🙂


While both pseudocode and flowcharts have their place in application design and development, they are used for different reasons, and are usually not interchangeable with each other. Flowcharts are usually drawn out before any code, even pseudocode, is written. The various types of flowcharts map out a program’s actions, either on an abstract, high-level or detailed, low-level overview (usually the former case). Flowcharts quickly visualize how the program will work (either conceptually or in actuality), the program’s architecture (which means exactly what you might think it would: the core workflow and layout of the program), and when more detailed, the program’s control structure the job each one of its functions performs. Flowcharts are also good for team development, as everyone knows the end goal, a broad overview of how the program will be structured, and what all needs to be done to accomplish the goal.

Pseudocode usually comes in once the application’s objectives are in place but before actual code is written. It is also used during programming. Pseudocode maps out the program’s implementation as it would look in code while not actually being valid code that could be compiled or interpreted. In this regard, it could be considered a higher level programming language than the actual code you will write. I like to think there are two broad forms of pseudocode, much like there are two forms of an outline: sentence pseudocode and topic pseudocode. Sentence pseudocode consists of only English (read: not actual code) words, phrases, and punctuation, much like you use full sentences for each point in your outline, while topic pseudocode uses a mix of programming keywords, symbols, functions, and English, much like a topic outline. If you are confused, the following examples may help.

Sentence Pseudocode

Ask the user for their favorite number and assign it to the variable `favNum`.
Convert `favNum` to an integer.
Check if `favNum` is an even number.

If `favNum` is even, tell them it is an even number.
Otherwise, tell them `favNum` is an odd number.

Topic Pseudocode

`favNum` = user input() of their favorite integer

if `favNum` % 2 == 0:
print on screen “Even number!”
“`favNum` is an odd number.”

Pseudocode is great for understanding how you plan on writing the code (thus implementing the program), as each line of pseudocode you write (no matter which form you choose) more or less directly relates to a “real” line of code. Furthermore, while you are debugging some of your code but not doing so in front of your computer or script (such as when you are going to sleep), you are usually writing pseudocode. While in your mind you are mapping it out directly according to the Python (or any other programming language) syntax, you can be certain there will be minor details your brain will leave out, much like how that research paper you proofread looked fine to you but contained many errors to your friend whom you asked to proofread as well. Consequently, you have actually written what is essentially pseudocode (or if you want to look at it in a different light, legitimate code with many syntax errors).

Flowcharts and pseudocode are not interchangeable techniques in the programming world. Flowcharts would not perform as well as pseudocode when it comes to implementing the program, and pseudocode makes for a lousy general overview and architectural design concept. Each one plays their own special role in development, and upon ripping them out of that environment, their shining qualities begin to diminish. If you are not good at drawing, that’s fine. Even if your drawing is not as good as Bill Watterson’s, if you need to make a flowchart for your program, as long as you can read what you wrote and drew later on, everything will be fine. In the same token, if you are not the most technical thinker around and details confuse you a lot, do not abandon pseudocode. When you need to draft some code but it does not need to be able to be compiled or interpreted, pseudocode will save your bacon, no matter what form you choose. It will be a valuable resource later on, trust me. Yes, either one of these techniques may be hard for you, but you will not die if your rectangles look like oblong polygons or your pseudocode is more pseudo than code. Just “keep on trucking”, and things will be fine in the end, even if you are not cut out for a life of code. 🙂