What is the best way to teach JavaScript functions to middle schoolers?

Question

I am teaching middle school kids (aged 11-13) some basic JavaScript and want to get some "professional" opinions.

I am introducing JavaScript with a simple function with a variable, a prompt, if/else, and a couple of alerts. This function (14 lines total) then repeats a series of times (say 10 times) changing the prompt and the conditional in the if/else for a total of say 140 lines. Otherwise the function remains the same. In the lesson, we will be using trinket.io to run the code in browser, and I am able to give them a partially complete piece of code to work from.

I know best programming is to not repeat when you can use additional variables and arguments passed through functions. I am doing that programming with a more advanced class.

My question is this: If just introducing JavaScript and wanting to teach syntax of these basic features, is it better to have students do the repeating (that works but is not programmatically the best way to program) or is it better to teach them the "correct" way where the program is simplified but includes more code understanding than we are ready to introduce?

Here is the code (I repeated it once to show the differences).

function askQuestion1()
{
  var answer = prompt ("What body system contains the heart, blood, arteries, and veins?") .toLowerCase();
   if (answer==="circulatory") {
    alert ("Correct!");
     score += 100;
     alert ("Your total score is now " +score);
  }
  else {
    alert ("Sorry, incorrect.");
     score -= 100;
     alert ("Your total score is now " +score);
  }
}
function askQuestion2()
{
  var answer = prompt ("What body system contains the brain, spinal cord, and nerves?") .toLowerCase();
 if (answer==="nervous") {
   alert ("Correct!");
    score += 200;
    alert ("Your total score is now " +score);
  }
  else {
    alert ("Sorry, incorrect.");
    score -= 200;
    alert ("Your total score is now " +score);
  }
}

Answer 1

I apologize in advance, but I'm going to be a bit hard on you.

First, your goal of keeping it simple is a good one that I applaud. You are right, IMO, not to bring in advanced features too early.

However, this is not the sort of code I would show to a beginner. Ever. It is the kind of code that, if submitted by an early teen would be fine, but not the sort of code that a teacher should show, lest it be emulated. If this were submitted by a college first year student, as part of some project, it would be severely downgraded.

I think students should only ever be shown code, from instructors, that they would be proud to emulate. But I think the lessons taught in this code need to be unlearned before the student can gain a proper understanding of how to program. I would use some completely different example, even if I was only interested in syntax, which I don't think you should be. You can also teach deeper lessons, just by example, by choosing what code you present to students.

Let me list a bunch of criticisms of the code, that are easily corrected, but using a different framework possibly.

First, the function names aren't descriptive in any way of what the function does. Also, they aren't functions in the classic sense since they return nothing, but that is just an issue with how javascript is built. They are procedures (actually commands since they don't have arguments either). But "intention revealing names" are a really good idea so everyone should use them, and novices should see them. So, askCirculatoryQuestion is preferable to askQuestion1.

Next, the formatting is a bit sloppy. A minor issue, but, if you are only a bit sloppy it won't be easy to teach them not to be.

Next, your var should probably be a const. There is no intention to change it. (Note: I'm not a javascript wizard, so I hope this is possible in this context.)

Next, you use an identity comparison, so, in the first function neither "the circulatory" nor "circulatory system" would be accepted. This is a human factors issue and may be the main objection to the example overall. An example without such an issue could probably be easily devised. But code that frustrates uses is not what you should show beginning students. But parsing user input is a genuinely difficult problem, of course.

Next, you make assignment here to a global variable, which is a tool that shouldn't be in the beginner's toolbox. It is an advanced incantation suitable only for trained wizards. Such practice makes larger programs much harder to understand and debug. Even wizards use this "spell" sparingly.

Finally, blasting alerts from a function is likely to mislead them when you try to teach real functions (that return values). Too many students have a very hard time with the notion of "return", and think that blasting out the answer is the correct way to write a function. You are laying a trap here that can cause issues later. (Confession: I once had that misconception. It made it difficult to understand program flow.)

Overall, my suggestion is to show students only the sort of code you'd like to see from them, not just now, but in the future. Yes, keep it simple and yes, keep it motivating, but make it poetry.

The code you will get from them is probably going to be worse than the code you give to them. So, always show them something they can emulate and that any teacher would be proud to see from a student. Make it easy for them to build good habits from the start.

But note that your concerns are not the same as mine. I agree that it is too early at the start to stress things like the "say it once" principle and such. And an exercise in which you have them write the analog of your second function after giving them the first wouldn't be a bad idea. It reinforces some skills, which is a good thing.

Again, sorry to be so hard on you.

But lest I be entirely negative, let me also give an idea for something similar that works on more levels than syntax. I'll stick with functions and if-else as the primary lesson.

Show the students a function maxOfTwo, that returns the maximum of two arguments. The function doesn't "alert" but, instead returns the value. Then write a driver to test it and have the students execute that a few times. Note that the function needs no local values.

After that, work out with the students a maxOfThree, that has three arguments. Do this one two ways. First with nested if statements and again by employing maxOfTwo instead. Don't give this as an assignment, but work out the logic with them and then write the (poetic) code. You may want to introduce a local value, so it is a bit more sophisticated on two levels (locals and nesting). But using maxOfTwo twice is a truly beautiful solution that shows the power of abstraction and reduces complexity.

Then, you can assign medianOfThree to them to work on. I suggest that it might be worthwhile to have them work out the logic of it in small groups and then come up with the code. They can either write out the code individually (probably a good thing) or in their group. Then critique the code as I have done here.

---

And don't lose track of the point that writing functions is more about abstraction than anything else. It makes programs easier to understand. The only code hidden by the maxOfTwo function is a single if-else statement. But calling the function (assuming it has a good name) makes the intent of the program immediately clear at that point, where the expanded if statement does not. This, I think, is much more important than the ability to call the function from more than one place and know that the effect is the same. Note that obfuscated code still runs correctly, but it is the understanding that separates the programmer from the machine. So, always use intention revealing names.

Answer 2

Middle school is a great place to start teaching kids programming, and especially JavaScript. I have guest taught something similar for third graders, and it went so much better than I had expected.

Code structure is not important for introductions. Engagement is the most important aspect for kids, and building a game is a great way to do that.

At the beginner level, having them just take something, and place it in is gold. I tend to prefer having students transcribe at that level, where they are given a printout and then are walked through adding the code themselves (maybe this is what you had planned, or similar).

I don't really see the need for repetition at all here though, because it doesn't really benefit them much as written. What I would suggest would be to allow them to come up with their own question2, their own accepted answer, and their own score bonus. This will allow them to not only better understand which inputs correlate with which outputs or behaviors, but will also introduce a good amount of fun to the activity.

Introducing fun, especially at the end of an activity once the main goal was accomplished, is a great way to build engagement. Never underestimate the value of joy :)

Answer 3

I think if you're teaching anyone something like programming, you should show them the elements in isolation first, and then combine them once they seem to have a grasp of what you taught them. (software's great for this, since a "statement" is a pretty generic concept)

I'm assuming you mean "function" in the sense of a callable function which runs a block of code and returns.

I think you should focus on re-usability when showing what functions are/how they work. When I was learning, the thing that got them planted in my head firmly is that you can just write some huge block of code once and get it to run at any point later with a single line.

I think a better example of a function would take an argument, and perform some action based on that argument. e.g. a greet(name) function which prints out Hello $name! Your name is $num letters long. when called.

You could then show the function being called multiple times, with the results depending on what's passed into the function. (e.g. hard-code the string in one invocation, and pass the response from prompt() in another.)

Answer 4

I wouldn't.

Based on my experiences as a student teacher in the Australian education system, typically actual coding doesn't get taught until grades 9-10, at which point the language is typically Python because of its relatively simple syntax.

At the age range you're discussing, students are typically taught a visual block programming language like Scratch in one unit (year or semester, depending on how the school's structured their IT course), to teach them about the programming thinking (loops, Boolean logic, etc) without worrying about correct syntax, and then taught HTML and CSS in the following unit to teach them about the importance of syntax and to get them used to typing code into a computer.

Answer 5

To answer your question directly, I think it would make sense to teach the students the more complicated looping structure first, so that they maintain a good sense of what clean code looks like. Unless, of course, you're going to teach them looping later on in the same lesson and want to use this as an example of bad code, but if you're just introducing them to programming, giving bad examples right of the bad likely isn't the best way to do it.

---

In the larger sense, I think you're approaching this lesson wrong.

First of all, I tend to recommend not including syntactic sugar when introducing programming for the first time, because that requires the student to understand more then they really need to. I mention this because I see you using features such as foo -= bar instead of foo = foo - bar and foo === bar (because the difference between === and == should be taught later on).

Second, you're introducing a whole lot at once. To understand the code snippets you've given, the students will need to first understand if / else statements, blocks, mutable variables, general language syntax, typing, string concatenation, and variables at the least. And most importantly, functions! Functions are very nontrivial for someone who hasn't seen programming before. You really ought to break down this lesson into the smaller pieces first, and then, once your students are able to grasp those pieces, then they can put it together into a larger project like the one you've described. But, at that point, they should already know what loops and how they work, so you won't even have this question :)

TL;DR Re-evaluate your approach to teaching this lesson. Break down the topic into smaller building blocks and teach those smaller building blocks first.

Good luck with the lesson!