The order of subjects in beginner's curriculum

Question

This year I'll be an unofficial teacher assistant in the CS class of 9th graders.

Background

This question is about a curriculum for introducing students to programming in java.

The students are in 9th grade (14-15 years old) and are not expected to have any background whatsoever in computer science (usually some do have, but that's not relevant to the curriculum. Differentiating it is something relatively easy at this stage).

This curriculum spans 2 terms (1 year - Sept. to June), and is meant to build a firm foundation for students. The subject is compulsory in 9th grade. I have some doubts regarding the ordering of the subjects in the curriculum.

How it stands

Students are initially introduced to computers in general.

The first lesson is always brainstorming: "What is computer science?". It's established from there that programming ("computer science is writing code" is usually a response of a few students) is writing something, and then converting it into binary (it's expected that they know that the binary numbering system exists). The students use the remaining time ($\pm$10 minutes) to write the famous:

public static void main(String[] args){ //we don't explain this line
    System.out.println("Hello, World!"); //sometimes we use a Hebrew alternative:
    System.out.println("!שלום, עולם");//which is literally the translation
}

That's the first lesson. From here, I'll list the subjects (each one is a subject, and not a separate lesson; lessons are ignored, I only address the subjects of the curriculum) taught (the language used to teach is Java)

   0. (First Lesson) introduction and simple printing of text

1. Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just int,double,char and String).

2. Mathematical operators: +,-,*,/ as well as %. The curriculum has an option to teach increment as well as +=, -= and the rest.

3. Conditionals: if, if\else and nested ifs. Also boolean is introduced.

4. switch-case. Not much to say about this at this level.

5. Math library. This is one of the things that caused me to doubt the order of things in the curriculum.

6. for loops and various uses. Arrays are not taught in the curriculum at all

7. while loops.

8. Nested loops.

9. functions. yes, functions:

   static returnType functionName ( parameters)
   {
       //operations
       return returnValue;
   }
   

That's it.

Doubts

I spotted a few issues in the curriculum. First and foremost: Where are all the arrays? I want to include arrays, but I'm not sure where\instead of what.

Teaching for after arrays seems better than before, because then I can show the foreach in the same lesson. They are essentially the same (but not 100% equivalent. Concurrent modifications is something beginners aren't ready for). So I am uncertain about the order of the subjects.

Secondly: Functions. Again, why? I want to remove them from the curriculum (students learn about them in the following years anyway, as part of OOP), but this might do more damage than good. Students might want to know, after an entire year, what exactly is the meaning of the public static void main from lesson 1.

Functions can explain that, but other than that, it's pointless at this stage (because they'll learn it anyway, should they major in CS).

So, does the order of subjects in the curriculum, as it stands, make sense (keeping in mind that arrays are not covered at all)?

Note: this question is not a duplicate of this one, simply because I already have a curriculum, and I am asking for a review of it. I'm also asking about specific aspects of my curriculum, and not general "hand wave-ish" things.

Answer 1

I once wrote a course to introduce Java. My order of topics was as follows: (Note: Those are not lessons, just the order I've written the topics down).

1. Obligatory Hello World, console output

2. Comments

   This is something missing in the curriculum you provided. I don't know how important it really is, but I like the idea to introduce comments because I usually use them in the following examples.

3. Variables, data types (the primitives and String)

   This already includes boolean

4. Arrays

   Here they are. I've just explained them as some kind of list where you could store multiple variables of the same type (half a page in my script).

5. Operators (mathematical, but also logical)

6. Reading user input

   When writing the course, I put it here; but looking over it again, I'm not particulary happy with it. I think it's a good idea to keep reading user input where it is in your curriculum.

7. Conditionals (if, else if, else)

   I don't explain switch/case here.

8. Loops (while and for)

9. Basic exception handling

   Here I only explain try/catch as a way to do something (like printing a message) when "there are errors with a part of the program".

10. Writing and reading text files

The course continues with a second part about OOP.

---

When comparing it to your curriculum, I think there are many good elements in it. However, here are a few things I noticed:

1. The Math library

   If there's no special need for it (e.g. class has just discussed trigonometry in Maths and now wants to implement something using a trigonometric function) I wouldn't include it in a starters' curriculum.

2. switch/case statements

   I'm not sure whether you really need to introduce them that early. However, if there's enough time, I also don't see a problem with it. I think I'd just drop it if there are issues with time.

3. Arrays

   As said, they are missing in this curriculum. If you drop the Math library and/or switch/case statements (for the reasons given above), I think you could integrate this instead. Students should already feel comfortable dealing with variables now, so the "lists of variables" can be introduced on a safe basis.

   I think it's a good idea to introduce them before loops, so you can show looping over arrays in the lesson you also introduce loops.

4. Functions

   When designing my course, I haven't really thought of them. However, the idea teaching "functions" is probably not that bad: Students now know a way how to structure a program's flow and write reusable code without having to dig into object-oriented-programming.

   On the other hand, this could also be interpreted as downside: As Java is a strictly object oriented language, it might be bad introducing functions before introducing the concepts of OOP.

---

To sum up, the curriculum given by you sounds quite good to me. Except for the adjustments proposed above, I don't see much that needs to be changed.

Answer 2

We teach AP CS assuming that our students come to us with no prior computing background. Being that the language for AP CS A is Java, we plan our sequencing accordingly. We don't follow the approach of starting with Hello, world. and user input because I think it (main, System.out.println, and Scanner) produces too much of a cognitive load at once . I always try to minimize hand waving as much as possible in the early parts of a CS course to help students build their confidence in navigating code.

While Eclipse is commonly used in industry and higher academia, an introductory course isn't industry or higher academia. So we use an IDE that is more appropriate for the new learner. We utilize BlueJ to begin demystifying Java from the very first day of class. Thanks to BlueJ, we don't have to discuss main or making tester/runner classes to run our code. In our post-AP CS course we can introduce IntelliJ or Eclipse, once the students can comfortably grasp the idea of multiple classes and project directories.

Our decision to introduce objects early was inspired by Dr. Kolling's book's sequencing and the fact that Java is the language taught in AP CS. Others may chime in by saying they think objects should be introduced late. I disagree for the reasons previously mentioned. Should we leave AP and teach Python or Javascript, I would wait until later in the course to introduce OOP. That being said, here is our general outline:

1. Introduction to OOP
   • What is a class and what is an object?
2. Writing Java Classes
   • What makes up a Java class?
   • Fields
   • Constructors
   • Methods
     • Conditionals
     • Logical Operators
     • Java Math and the Math Class

At this point it's September and my students can navigate an entire Java class and the hand waving of public static void main(String[] args) is gone. That's hugely important and beneficial.

3. Classes as Data Types for Other Classes

   • Encapsulation

4. Strings

5. 1D Arrays

   • Looping

6. 2D Arrays

7. The ArrayList Class

8. Inheritance, Abstract Classes, and Interfaces

9. Algorithms

   • Recursion
   • Searching
   • Sorting

Keep the students in mind. Remember where they are coming from and that your goal isn't to turn them into CS researchers or software engineers in a single year. Expose them to the content in an order that appropriately challenges them, while avoiding the statement "You can ignore that for now" as much as possible.

Answer 3

If the set of "allowable" topics is set by a ministry, then you have no power to do anything better, but it is misguided. Tinkering around the edges of an inadequate set will have some effect, but not a lot, I'm afraid.

The problem is this. Students taught this way will solve math-y problems for quite a while before they see more interesting problems. They will build up strong reinforcement patterns that "this is the way we program". Then later, when given a difficult problem they will default to those patterns again and their solutions will look like C code even in more modern languages.

One reason that this dominates is that the student has two problems, one is to decompose the problem somehow and the other is to put a solution together. If both problems are hard then they get lost. But if they have already built up strong reinforcement patterns on the second part they can use their mental energy on the first part. But since they "know how to program" (i.e. C) then they will just code it that way to minimize their overall effort.

My preference is to turn it around (though recognizing that you may not have that opportunity), so that students think first about problems and how to decompose them (into objects in my case - OOP). Then they build up the reinforcement patterns on that, so it becomes "obvious" to them and they spend their effort on the coding part.

The overall result is better programs, since they are more likely to have better problem decomposition into small parts that are more easily coded anyway.

Note that I've seen the effect of this kind of learning in industrial practice. While consulting to IBM is was approached by a team member (an employee - and a good and smart one) who wanted me to look at his code. My practice was not to do that since my charter was to talk about higher level process, but he was a good kid so I consented. He showed me a bit of code (less than 2 pages) and started out by saying he could no longer understand it (his own code). It was written (Java) using the tools you describe above. The code was one method that consisted of some deeply nested structure that would be difficult to untangle. Factoring out helper methods (a la Procedural Programming) would be difficult.

My first response was that I wouldn't have started out trying to write anything that looked in any way like that, and that by the time we got to the point of solving the particular problem the method attacked, we would already have a decomposition into parts that made the required (set of) methods quite trivial too write and to understand.

The overall effect of what you propose is that you are, in the long run, reinforcing poor habits of thought. Or at least, poorer than the alternatives allow. That sounds like just opinion, I know, until you consider the effect of reinforcement and the tendency to fall back on what you know "best" which is often what you learned "first", since you've practiced it the longest time.

tl;dr You are starting with the machine and with machine level solutions. Instead, start with problems and their decomposition. Assuming you can.

Answer 4

I would be concerned that there isn't any material on planning. In a course that has the goal of building a strong foundation for students, teaching the process of specifying and planning a solution before implementing it will pay huge dividends.

Personally, I am a fan of the course order in Rick Mercer's CS1 Textbook. Chapter 1 is Program Development. It could be summed up as "plan before you code". Of course, Mercer has more specific steps which really show the value.

Phases of Program Development and related Activities

1. Analysis: Understand the problem.

2. Design: Develop a solution

3. Implementation: Make the solution run on a computer

Analysis

This can be summarized in a few steps:

1. Read and re-read the problem statement
2. Determine what the inputs are
3. Determine what the outputs are
4. Write down information on the inputs and outputs, including names and sample values

For example:

Problem             Data Name       Input or Output   Sample Data
-------             ----------      ---------------   ------------
Count how often     aBardsWork      Input             Much Ado About Nothing
Shakespeare wrote   theWord         Input             the
a particular word   howOften        Output            220
in a particular 
play

Design

This is where the algorithm is figured out, and psuedocode is written. It's also a great place to introduce common patterns in solutions, like the Input, Process, Output pattern so common in beginner programs.

For example:

Three-Step Pattern     Pattern Applied to a Specific Algorithm
------------------     ---------------------------------------
1. Input               1. Obtain test1, test2, and finalExam
2. Process             2. Compute courseGrade
3. Output              3. Display courseGrade

This step could further elaborate on the details of the Process step, of course.

Implementation

This is where you finally code! But note that the previous steps require no knowledge of syntax at all. Those steps could be learned in the first few days of class before a single static void main(String[] args) is ever seen.

Here's the full outline of Rick Mercer's CS1 text (aimed at college freshmen):

1. Program Development
2. Java Fundamentals
3. Objects and JUnit
4. Methods
5. Selection
6. Repetition
7. Arrays
8. Search and Sort
9. Classes with Instance Variables
10. An Array Instance Variable
11. Two Dimensional Arrays

Answer 5

I will share two starting points I use for teaching CS topics:

1) CS is about solving problems and developing this skill in students. To that end all of our students take a mandatory class in Computer Science - Intro To Java Programming where the focus is on solving problems using a simple visual robot simulator. In this class students spend much more time discussing and writing down ideas (in english) than "coding". Our focus is on designing advanced robot behaviors and interactions to solve increasingly difficult scenarios.

The important thing to note here is that we focus on developing a foundation of thinking skills and introduce computational thinking and problem solving methods. The first exposure to "programming" is base on an objects-first approach where much of the details of "coding" is hidden. (for an example see the LightBot app in the app store).

2) In the AP CS A class (not Principles which is usually taken first and has a strong focus on algorithms and abstraction, which build naturally upon the previous courses), I usually teach the topics in the historical order of their use, from the Abacus to Artificial Intelligence (or self learning machines like Alpha Go). I use examples that are appropriate to the current stage of CS evolution, and many of these solutions evolve as we learn and use more techniques and tools.

For example:

Early in the course we look at developing a console based guess the number game. Our first focus is on developing an algorithm for this and evaluating solutions. Along the way we look at how to make our own random number generator, then later we look at using one from the program library, etc. We iterate over various solutions improving its utility: We don't let the computer make duplicate guesses.

Solving the problem of avoiding generated duplicates can be be quite challenging, especially early on. It's worth trying on your own. You will find many interesting approaches.

1st iteration: use n-1 variables to store previous guesses - This brings up the idea of a collection of similar items - arrays.

2nd iteration: use an array of size n to store all guesses - This brings up the question of how to manage the items in the array

3rd iteration: use collections - removing the guess as it occurs from this list of unused numbers and randomly selecting from a new, and smaller subset.

By the time we get to collections we also discuss having a collection of heterogeneous items. Then we talk about the problems with that, leading to strongly typed collections and Generics etc. Then we move backwards to homogeneous collections but now within the framework of polymorphism which bring us back to behaviors and interactions.

I find that the historic approach combined with the why did we invent this / what problems does it solve, works quite well because it gives the students a sense of why something exists, and how it might be used. It allows them to see a variety of possible solutions and be selective in their choices.
(Why did we invent screws? What's wrong with nails?)

I use the same approach for

• global / local variables and passing parameters
• Abstract Data Types to Classes / Objects
• Manipulation of data to Interaction of objects
• And finally, developing behaviors (having objects doTheRightThing()).

and for the evolution of using

• Sentinels
• nulls (missing values)
• Null Objects

I can also challenge the students if I think they are seeing everything as a nail (overusing their hammers), or suggest if they are designing / coding caveman like solutions (do more efficient or elegant solutions exist).

Along the way their thinking moves from functional to behavioral.

Answer 6

Pure ordering should be dictated by how you intend to interconnect the ideas. For instance, I use arrays as a motivating example for for loops, so it makes sense to introduce arrays to my students before for statements. Think about segues, motivating examples, and lab assignments, and a sensible order should emerge on its own.

Questions of what to include, however, are not so simple. Your major curricular goals now become central considerations.

The curriculum you've shown us looks like a pretty reasonable objects-last approach to beginning Java. I do agree with you that arrays are pretty fundamental, though, particularly when utilizing an objects-last approach, as they are the only tool prior to objects that allow you to deal with variable amounts of data.

There is one additional red flag (for me) that you may want to mention to the instructor. Nowhere in your write-up is a discussion of mutability, with all of the cognitive traps that it brings. Mutability is often the secret trap that kids fall into, because x = x + 1 is not a sensible algebraic statement.

If it is not specifically discussed, beginning programmers will take what they know about equality and apply it in an ad-hoc manner to code. Sometimes they get it right, sometimes they get it wrong, and there may be little consistency, even with the same student from one moment to another.

This is because, if mutability is not explicitly taught, folks just kind of drift between all of the contradictory ideas about = that start to float around in their minds, fuzzing from one idea to another, without any fully concrete sense of what it really is.

This notion has been discussed already fairly extensively on this site (such as my write-up here, or this question here.) If you don't call attention to the idea of = as an operation, very different from the declaritive $=$ that kids know from math, they may never dig back out if that hole.

Answer 7

I learned to program by looking at simple program that did things, working out a bit about how they work, and changing them. So I learned a little bit about each topic in some random order as my overall understanding increased.

Therefore maybe start with LOGO and the class having some fun with a Turtle moving about the floor, then loops etc can be introduced along with "if" assuming the Turtle has some sensors on it. Once the students start having fun you can move onto the formal topics.

Otherwise you risk having everyone that has not already learned that programming is fun from their come computers not seeing the point of learning programming.

Answer 8

Consider that the best way to teach Java might not be to teach Java (at first).

For several programming languages (those that were not designed for pedagogy/teaching), starting with a teaching language or environment, and segueing later to the more arcane/abstract coding syntax, might be the easier path, and leave less students out in the cold (or typing magic incantations with near zero understanding).

Answer 9

If you're an unofficial TA, why are you the one coming up with the curriculum? Anyway, my review is inline:

introduction and simple printing of text

I wouldn't limit this to printing text. I would frame it as a lesson on calling functions. Printing text is one example. Showing a simple dialog box is another example. Come up with a list of basic functions, and get them into the habit of looking stuff up in that list. Basically you're training them to look stuff up in the Java API.

Simple Eclipse console Input\Output and user input (print what the user inputs etc.) as well as variables (just primitives, and just int,double,char and String).

I would absolutely not start them out in Eclipse. Start them out with a basic text editor and the command line. They need to understand what the compiler is doing, and how their code is being run. Eclipse is great for advanced coding, but it hides way too much of the fundamentals to start out in.

Mathematical operators: +,-,*,/ as well as %. The curriculum has an option to teach increment as well as +=, -= and the rest.

Make sure you teach these in an engaging way. Have them write programs that play simple math games like higher-lower or the subtraction game.

Conditionals: if, if\else and nested ifs. Also boolean is introduced. switch-case. Not much to say about this at this level.

Boolean needs to come before if statements.

Math library. This is one of the things that caused me to doubt the order of things in the curriculum.

I don't know why you need to treat this as a separate thing. Include it in the "mini-reference" that you give them on the first day.

for loops and various uses. Arrays are not taught in the curriculum at all

The use cases for for loops in a command-line environment are not very engaging, but if you're stuck with "pure Java" then I guess that's a problem you're going to have throughout the course.

while loops.

Nested loops.

You should teach nesting as soon as possible, as it's always a point of confusion. Start with nested if statements above.

functions. yes, functions

Not sure why you're saying "yes, functions" here, but this is a reasonable thing to include. I would maybe go a step further and try to get to creating classes.

Here is the order I suggested in my answer to the related Order to Teach Topics in an Intro Programming Class question:

Instead of using "pure Java", I would use a language called Processing, which is built on top of Java (and can be used as a Java library) and allows you to create visual, animated programs without any boilerplate code.

Even if you can't use Processing, here's the order I would talk about topics:

• Calling Functions
• Using Variables
• Creating Variables
• Creating Functions
• Debugging
• If Statements
• Animation
• For Loops
• Arrays
• User Input
• Using Objects
• Creating Classes
• ArrayLists
• Images
• Libraries
• Deploying your code

These topics can be covered in Java, albeit with a ton more boilerplate code than if you used Processing.