16
$\begingroup$

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);
  }
}
$\endgroup$
  • 2
    $\begingroup$ @TravisJ This is all they are expected to know for this lesson. They have built an HTML page with a Jeopardy! type game using tables and the button calls this function with an onclick="" This level of class is being introduced to functions, variables, alerts, prompts, and if/else (the score formula and += and -= are only added because what good is a game without points). $\endgroup$ – Bill Pratt Dec 19 '19 at 18:41
  • 1
    $\begingroup$ Thanks, the background makes a lot of difference for how to approach the subject. $\endgroup$ – Travis J Dec 19 '19 at 18:44
  • 2
    $\begingroup$ @Buffy - The correct way would be to create a producer of these questions, and then instantiate the set of question instances for use. That is way too over the top for this situation. $\endgroup$ – Travis J Dec 19 '19 at 21:08
  • 5
    $\begingroup$ I'll try again: Please don't use Javascript to teach programming. The syntax is confusing for beginners. The language itself is a constantly-moving target. I don't even know whether terminating lines with semi-colons is even good practice these days. ES6 has added a whole load of extra confusion. It's just quite annoying in general, and gets in the way of the actual learning, which is the important part. I really don't know why you don't use an interactive Python interpreter. Once they know how to structure a program, the syntax is superfluous, so they can move on to JS at that point. $\endgroup$ – Aaron F Dec 21 '19 at 13:45
  • 2
    $\begingroup$ @Bergi: JS is simply too weird compared to Python/Java/Ruby or even C/C++. It's unlike any other programming language, and it's so weakly typed that it's easy to miss/hide/ignore bugs. There are millions of people writing Javascript even though they don't really understand it, and there are Javascript teachers who don't really understand it either. It's possible to write great pieces of software with Javascript but it requires a lot of knowledge and discipline. $\endgroup$ – Eric Duminil Dec 22 '19 at 19:10
29
$\begingroup$

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.

$\endgroup$
  • 2
    $\begingroup$ Advice is always good as I am not a pro so criticism welcomed. There is a lot of background not in my original post with what the students have already studied. They have learned block-based coding (Scratch) and this "function" relates to previous blocks and concepts learned in Scratch. It isn't perfect but is intended to extend the previous learning while learning a small bit of JavaScript. They have also spent a semester learning some basic HTML/CSS. We use a platform called Trinket.io as our sandbox. It has limitations but is decent. By the way, I like idea of making code "poetry." $\endgroup$ – Bill Pratt Dec 20 '19 at 14:22
  • 1
    $\begingroup$ If you are purely looking at introducing JavaScript the language on its own, I think this is great advice, and in general outlines standardized approaches to single language instruction. However, in this instance, I think it is important to consider that Bill is introducing JavaScript as another step in building a minimal web application. The introduction of JavaScript should be considered with a holistic view of the current project. Converting to the classical approach of using method best practice would possibly be confusing at that point to these students who are 12-14 years old. $\endgroup$ – Travis J Dec 20 '19 at 19:17
  • $\begingroup$ @Buffy Can you expand on the "intention revealing names"? I thought that askQuestion, answer, and score would be good names since that is what they are doing. "askQuestion1()" deals with the first question and asks it. The "answer" is the answer that the user enters and the "score" is their points after answering the question. I want to understand better myself as I am self-taught and want to learn best practices. $\endgroup$ – Bill Pratt Dec 20 '19 at 22:24
  • $\begingroup$ The function names are my main issue. The others are fine. The function names here have no semantic meaning. What is the semantic difference between the two question names? AskCirculatoryQuestion has semantic meaning. $\endgroup$ – Buffy Dec 20 '19 at 22:40
  • $\begingroup$ @Buffy I see what you are saying now. Thanks. $\endgroup$ – Bill Pratt Dec 20 '19 at 23:05
5
$\begingroup$

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 :)

$\endgroup$
2
$\begingroup$

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.)

$\endgroup$
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks. Actually, that is the path we have followed. We started with Scratch and have moved on to HTML and CSS. Now we are adding just a couple of JS tools to introduce them to JS (we have actually changed our curriculum to start JS in Minecraft Education Edition but these students have missed that). Since they have those basic concepts in place (sequences, loops, conditionals/logic, variables, etc.), we started with alerts and prompts in JavaScript. I wanted to make it a little more fun with the quiz game so I added this "function." $\endgroup$ – Bill Pratt Dec 22 '19 at 2:50
1
$\begingroup$

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!

$\endgroup$

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.