I am a young professor teaching a data structures course for the first time. I'm teaching at an engineering college that provides an academic degree, but the focus is preparing future computer programmers, not academics.

Before the start of the semester I decided to present the algorithms as java code, instead of pseudocode. I felt that this would make the presentation more precise, and show the students how to put these algorithms to practical use.

My experience has been mixed. It seems like the problem is that now the students think that the various algorithms are the java code. They are complaining that, for example, I can't possibly expect them to know the counting sort algorithm, because how can they be expected to learn code by heart? So I am starting to understand the wisdom of using pseudocode.

My question, intended for other teachers, is: What has been your experience when using pseudocode vs using code?

  • 9
    $\begingroup$ This is a symptom of a failure in earlier education... an university student ought to know how to abstract ideas. Whatever choice you take you are probably still going to have troubles with these students. I don't think simply using both as @Art says would help them... you probably need to show them both and also the translation between the two... basically teach them the concretization of an algorithm from pseudo code to implementation code and abstraction of an algorithm from implementation code to pseudo code. $\endgroup$ – Giacomo Alzetta May 16 '19 at 11:04
  • 2
    $\begingroup$ "What has been your experience when using pseudocode vs using code?" -- this is going to get you a list of singular opinions. I recommend you ask for solid evidence instead, e.g. in the form of scientific studies. $\endgroup$ – Raphael May 16 '19 at 21:19
  • 2
    $\begingroup$ You don't say what your teaching goals are beyond the topic of the course. Those will heavily influence any didactic choice, and may just make the difference here. The background and focus of your students is also relevant, as is the form of exam you're going to hold. Say, some students know Java, others Python, and some C++. How fair is an exam requiring Java skills? How do Java skills reflect on their data structure expertise? $\endgroup$ – Raphael May 16 '19 at 21:22
  • 1
    $\begingroup$ I think the problem is deeper than Java code vs. pseudocode. It seems likely to me that if you taught with pseudocode instead then the same students who complained that they could not memorize Java code would be prone to complaining that they could not memorize pseudocode. How about this radical idea: use words (and then code). Prose will be more inherently meaningful to inexperienced programmers. Also, put more emphasis on the definition of the term "algorithm". Quiz your students on it, even. And quiz them early and often on prose descriptions of algorithms. $\endgroup$ – John Bollinger May 17 '19 at 20:16
  • $\begingroup$ The question doesn't provide information about the students taking this course. Would this be the first or a very early course for this curriculum at the college? If part of the course is for students to develop their own algorithms, or to modify algorithms, pseudo code doesn't prove a means to verify the algorithms will work. $\endgroup$ – rcgldr May 25 '19 at 6:00

12 Answers 12


Similar to @Vince, I think it's a good practice to do both. I don't really agree with the cooking recipe analogy, though. Pseudocode describes that the algorithm does, without going into detail how you do it.

I think perhaps a better analogy:

  • Pseudocode: you need to put an egg into the flour mixture
  • Actual code: pick up an egg, crack it open on the side of the bowl, and drop the egg into the container. Don't forget you need to dispose the egg shell as well.

There are so many ways to accomplish the task, and the actual code just gives the student an example of how to do it.

Presenting only the pseudocode might make some of your students loss. Presenting only the actual code would keep them in the box and get them focused too much on the details. A mixture of both would be my choice.

  • 39
    $\begingroup$ Don't crack the egg on the side of the bowl: that risks getting shell in your batter, which is a pain to get out again. And this is exactly why actual code is bad for teaching -- arguments about irrelevant details take over. $\endgroup$ – David Richerby May 16 '19 at 8:57
  • 13
    $\begingroup$ @DavidRicherby: Isn't your example proving the exact opposite, that actual code is useful for teaching actual skills? In pseudo-code, it's easy to ignore edge cases like the empty collection and the collection with one element. $\endgroup$ – MSalters May 16 '19 at 12:49
  • 7
    $\begingroup$ Depends on which "skill" you wanna have the students practice I guess. I'd imagine that these students preparing to become a programmer would have other project courses to practice on coding already. $\endgroup$ – Art May 16 '19 at 13:00
  • 7
    $\begingroup$ @MSalters There are multiple skills, and it's usually not a good idea to try to cover too many of them at once. In an algorithms course, the focus is on algorithms, not coding; in a creative writing course, the focus is on expression, not handwriting; etc. $\endgroup$ – David Richerby May 16 '19 at 15:59
  • 4
    $\begingroup$ @DavidRicherby Most people in an algorithms course intend to actually write code for a living. There is no reason to deprive them of experience converting problem descriptions to actual code. The skill of making that translation is fundamental to being able to do much of anything useful in computing. $\endgroup$ – jpmc26 May 17 '19 at 1:06

Actually I am of the opinion that you should not present your own code, but rather get the students to implement the algorithms you teach them, which you give in pseudocode, and give them the freedom to choose any one of a fixed set of languages that you are familiar with, such as C++/Java/Python. Really, the only way students can truly understand an algorithm is when they face the real task of implementing it, but the key ideas behind an algorithm can be sufficiently conveyed via pseudocode.

  • 6
    $\begingroup$ And perhaps even more importantly, don't go about the entire course shoving one arbitrarily-chosen programming language down students' throats; specially not Java. That's very off-putting. I've seen complaints about this all too often. $\endgroup$ – Marc.2377 May 16 '19 at 23:54
  • 1
    $\begingroup$ The algorithms course I'm taking right now is exactly what you are talking about. The prof explains algorithms in class and we can choose the Python, Java and C++ to implement them as homework :) I can confirm that this is a great idea :) $\endgroup$ – Rakete1111 May 17 '19 at 22:03
  • 3
    $\begingroup$ Implementation from pseudo-code is one of the more long term useful skills. Outside an academic algorithm design course, I have rarely needed to create an algorithm from scratch. I have often needed to look one up in various references, and implement it in whatever language I'm currently using. $\endgroup$ – Patricia Shanahan May 19 '19 at 3:46

I understand your dilemma, but from a general pov it's better to present content through pseudocode. This actually gives students the freedom to explore multiple languages. When you present your code in a particular language you are making them comfortable with that language alone and they might find it hard to shift to other languages later on. The main purpose of learning algorithms is to know how they work rather than implementing them in a particular language. Regarding resources, I would suggest looking up books like Introduction to Algorithms. You can also refer to CodeMonk which is an online portal which has a collection of all known problems and algorithms to look into.

  • $\begingroup$ “When you present your code in a particular language you are making them comfortable with that language alone” This can be an advantage if the students are currently learning the same language. Just don’t confuse them with features they haven’t used yet. $\endgroup$ – Michael May 16 '19 at 11:39
  1. Pseudocode helps a lot by removing anything unnecessary, and focusing entirely on the algorithm, which can already be hard to understand as is. It's also faster to express ideas : if a student wants to write a different algorithm than the one you taught them, it can be really cumbersome if they have to deal with every details of Java.

  2. As others said, it's good for students to come up with their own implementation in code of the pseudo-code algorithm. They need to really understand it, while if they just paste code or learn it by heart they won't necessarily understand every subtlety.

I think most universities do this already (mine did), but I think the best is pseudocode for the course, and real code for practical exercises.


When I took algorithms, my first professor used a pseudo-code of his choosing. It may have been clear in his mind, but in was pretty opaque in they eyes of his students. It was a much dreaded class, and hard to get useful knowledge from. Then he had a heart attack.

New professor (let's call him "Finkle"), discarded the previous class notes and textbook. Finkle wrote new notes (replacing the book) and explained algorithms using Pascal (it was the 1980's). Pascal was much more clear than the pseudo-code AND IF YOU DID NOT UNDERSTAND HOW SOMETHING WORKED, YOU COULD RUN THE CODE AND LEARN.

That class ended up being the most valuable class in my whole undergraduate education.

  • 1
    $\begingroup$ "He used pseudo code of his choosing, [...] then he had a heart attack". Correlation vs. causality ? $\endgroup$ – Michel Billaud Jul 24 '19 at 11:38
  • $\begingroup$ Even pseudocode can carry viruses, apparently. $\endgroup$ – Scott Rowe Aug 7 '19 at 23:35
  • $\begingroup$ Was the pseudocode syntax more convoluted than Pascal? $\endgroup$ – tazboy Aug 21 '19 at 2:07

One of the key points here is that you are teaching to future engineers, even if at academic level. The very nature of engineering is solving problems by implementing a solution.

Therefore I think that presenting the pseudocode is useful to give your student the correct theoretical POV to frame the problem, BUT showing them an actual, working implementation is key to make them develop their engineering skills.

Much better would be to show them the pseudocode and make them try to come up with an implementation first, then show them yours. But this requires honing their skills first, probably.

As their skills improve, you may also dare show them more than one implementation, possibly in two or more languages. Of course this depends on their actual knowledge of the languages you are going to use. If they know only, say, Java, showing them an additional implementation in another language could backfire and confuse them more.

Of course, I'm assuming that it's not your duty to teach them another computer language, otherwise, it could be a useful approach: start with pseudocode, show a reference implementation in a known language (e.g. Java) and finally show them how to reimplement the algorithm in the new language they must learn.


Writing from a students point of view:

I had a course regarding algorithms and data structures two years ago.

The first exercise consisted of implementing a program with a certain behavior (Search in a sorted array, etc.). In the next lecture we would discuss an algorithm in pseudocode which fulfills the requirement of the previous exercise, only in a more efficient manner. The next exercise consisted of another goal to achieve (sort an array, ...) and a implementation of the pseudocode we discussed earlier in the lecture. We could freely choose the language for implementation.

These assignments made every student give their best since we compared the runtimes of our algorithms among ourselves.

The course was well received among all of the ~30 students. For myself I think I learnt a lot since you can also focus on optimization instead of only making something work.


I think the best is to do a comparison. The algorithm may be a cooking recipe that may be written in many languages but produce always the same cake.

Pseudo-code is like describing the recipe with pictures. There is not a unique grammar or way to "talk" in pseudo-code but anyone should be able to interpret it. By reading the pseudo-code written by someone, one may often guess what is his favorite language. The main rule is to forbid the language specific keywords.

Teaching an algorithm in a specific language is not a problem in my opinion as long as anyone understand it. But if you want someone to master this algorithm, you have to make him try it by hand. Make him do the different steps of the algorithm on a small example. In fact it is again like cooking the cake... You can remember a recipe much easier if you actually have cooked it.

  • $\begingroup$ Not just pictures, but more like ideograms. $\endgroup$ – user28434 May 17 '19 at 15:10

Neither alone is enough for a good dish.

I'd go with pseudo code in the lecture, and use homework to give students practice in turning pseudo code into real code.

Using pseudo code in the lecture has the pragmatic reason that pseudo code is, by nature, somehow vague. You want to use it as a tool to be able to concisely state ideas that still contain all important details, but abstract as many of the unimportant ones away.

Because of this, it takes some time to gauge, as a student, how pseudo your pseudo code actually is allowed to be:
As an example, at the start of the course, pseudo code shouldn't involve a (merge-)sort, but once you're done with that chapter, there's no harm in adding the line "sort the array A" without further explanation.

Therefore I'd say that the easiest way for a student to learn what is, and what is not, allowed in pseudo code, is by getting a feel for it, simply by osmosis over time.

And if some students have problems understanding your pseudo code, then they still have enough resources (books, or even interactive coding sessions of the algorithm) showing them how the algorithms would look like in an actual programming language.

On the other hand, to understand the design and working of an algorithm, it helps immensely to have coded it yourself, at least partially, once.
Therefore, by letting your students program the algorithm (or letting them finish a partially programmed algorithm) and then tasking them to "play with it", they'll get a good look on the other side of the medal as well.


I see two very different reasons to use pseudo-code.

First, being precise. You want to describe an algorithm in details, without being dependent of the particularities of some programming language. That's the way algorithms are presented in the CS literature. Maybe you avoid a language war, but then, you are dependent of the particularities of your notations anyway, so it sort of defeats its own purpose.

Second, being vague. You want to explain ideas on how to do things, with more or less details. Maybe what you want to show, is a succession of intermediary steps that lead to an algorithm, and later a program. Because you want to teach, not the version of algorithm X published by Y in 19xx, but how to build algorithms, and this generally requires several steps of refinement with, in the middle, some yet-no-so-well-defined actions.

Pseudo-code allows discussion of approaches to a problem, without solving it entirely. For example the (in)famous "find the largest difference between 2 elements from an array".

One approach is

largest = 0
for each pair (i,j) of indices
   if the difference between t[i] and t[j] is > largest
       change largest

and another

find the min and the max of the array
largest is the difference

such pseudo-code is precise enough to discuss the 2 solutions.

Same kind of discussion about "should we use incomplete/incorrect UML diagrams when teaching" ?

  • $\begingroup$ Your two pieces of pseudocode for solving a particular problem are an excellent example of how easy and instructive it is to compare algorithms. One requires half of n squared comparisons, the other 2 n comparisons in a linear scan of the array. Very nice. $\endgroup$ – Scott Rowe Aug 7 '19 at 23:34
  • $\begingroup$ The first algorithm is a classical illustration of the "design by keyword" trap. "2 elements" => loop over all pairs. $\endgroup$ – Michel Billaud Aug 9 '19 at 15:09
  • $\begingroup$ If I understand you - it is still early in the day - Anyone who sees "loop over all pairs" and does not immediately see a nested For loop (or equivalent) has never written a program. I didn't even think for one second about it as I read the pseudocode, and I saw that we only have to do the "upper triangle" because there is no point in both comparing x to y and also comparing y to x. But seeing that we only need to capture the max and min as we scan once was pleasant. This is why I find SQL so fascinating. Data is really amazing stuff. I despair of teaching these nuances. $\endgroup$ – Scott Rowe Aug 10 '19 at 13:11
  • $\begingroup$ Blame the hour of the day. The "triangle" enumeration is sort of a micro-optimization of the "square" (multiplicative factor 0.5 in a quadratic algorithm). The other solution is linear. Anyway the point was about the presentations of solutions, without showing all details. $\endgroup$ – Michel Billaud Aug 11 '19 at 16:06

To answer your question: my experience of using pseudocode is that it works perfectly well in combination with actual code. It would be like a photography teacher explaining the basis of composition by drawing instead of pointing at actual photos. As long as photos that use the rules are shown also, this is great.

Your experience raised a more important concern, one which I think that the other 1010 answers did not address. You said:

My experience has been mixed. It seems like the problem is that now the students think that the various algorithms are the java code.

Indeed. My experience of people has been that there are two kinds:

  1. Those who can generalize about a subject
  2. Those who can not (yet)

I had a student who thought he would be great at programming because he had done a lot of RPG2. His approach was to memorize everything - the book, my lectures, stuff he found on his own... Alas, his brain could not memorize everything. No one's can. We cannot function on the level of detail and master complex things, it is simply impossible.

So, your students who are trying to dig to China with a spoon need to learn to use larger concepts and tools. They need to do this by starting with small concepts and tools, and master them all as they go along. I don't know a single programmer who started out at a high level and never mastered the basics. It is impossible.

A program is nothing more than the coordinated operation of billions of transistors, possibly spread across machines linked by many technologies connected across large geographic areas. A mind is nothing more than the coordinated firing of trillions of nerve cells. But for us to understand, we need to be familiar with all of the levels. I think that this is beyond anyone, but what else do we have to occupy ourselves?


"Pseudocode as first language" is a terrible idea. Some of the hurdles a newbie programmer faces is to understand that you have to spell everything out, precisely; that the computer does as told, not as it should; the need for variables (and names, and types/structures) to store data; to organize operations into the right order. Most of that can be glossed over in pseudocode, and there is no compiler/test run that shows mistakes.

Sure, as a help, as a way of sketching solutions for newbies a sort-of-our-language pśeudocode is useful; later, when they have overcome the first round of obstacles, it is an useful tool for design and communication, and the language can take second row seat.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.