Iffy Understanding

Beginner CS students are quick to accept the concept of conditional statements — if <conditional> then do <something>. A lot of instruction about coding conditionals starts with real life examples of if-statements. That’s where I think the weak understanding begin…

1.  if isLessonOnConditionals {
2.    useBadExamples()
3.  }

The root concept of conditionals is program flow or “identifying which lines of code happen and which don’t.” It would not surprised me to learn that many students don’t think line 1 is executed — but that’s a deeper discussion that doesn’t need to be had now — which means, in the above example there’s no clear contrast. Maybe we should be surrounding example if-statements in contextual code to have clear examples of some code that always happens and some code that conditionally happens.

0.  writeAgendaOnBoard()
1.  if isLessonOnConditionals {
2.    useBadExamples()
3.  }
4.  assignHomework()

When the else block is introduced, I think it becomes even more helpful to have preceding and subsequent statements to highlight ‘always vs. condition 1 vs. condition 2.’

While introducing ‘if’s in Python to my 9th-grade Intro CS students, the above issue tripped me up, and I had to backtrack for a day. Then, as I started writing about this and thinking further about teaching if-statements, I realized that this two-letter command is very jarring. An if-statement is likely to be the first time:

  • text does not start on the left edge of the page,
  • the squiggly bracket key is used,
  • something is being written that is supposed to be skipped, and
  • not every line of code happens every time.

Add to that, conditionals are a significant advance in algorithm sophistication. A generalized algorithm that uses a conditional requires the creator to have thought through and simultaneously described all options. (The various execution paths do not need to be written in parallel, but the final algorithm holds within it a description of all possibilities.) This can be mentally trying.

Maybe I have been breazing over this very critical step and hoping students would see and write enough of them they would eventually catch on. It will be helpful to spend more time considering how I mentally process a branching point in code and how I can provide better scaffolding for students.

2 thoughts on “Iffy Understanding

  1. If’s and any new construct is tricky for beginners and usually harder to teach and learn than we think.

    A couple of things going through my mind now:

    It’s easy to set up a real world exercise – bring in a bag of candy. Here’s the program:

    if age > 18:
    take a piece of candy
    # optionally add eat it

    With the idea that you get to keep all the leftover candy.

    Then repeat with:
    if age < 18

    and they'll see that the first time the program is run by the class, the supply of candy isn't depleted and in the second time it is.

    Or something like that.

    Also, we're surrounded by things like fire alarms which say "in case of emergency…." <– that's an if statement that's rarely run.

    The if is one of the reasons I like Scheme for beginners (which also brings a downside which I won't get into here). In scheme you have:

    (if BOOLEAN TRUE_PART FALSEPART) so you always evaluate and return something – it's also a function so can be embedded as such. I think this is actually easier for kids since it always does something.

    Like

    1. Thanks Mike for your thoughts. I do like tangible (and unplugged) examples.

      I did a few similar examples, but ones that required every student to individually process the conditionals: https://docs.google.com/presentation/d/1RQ8IK54vBtkpbmwQiAz2hduXUO29beq66rxdX5hbxsY/

      To the point I was trying to make, in each of my examples there was code that preceded and code that followed the conditional block so that we could discuss which instructions do happen and which instructions (conditionally) do not.

      Like

Leave a comment