This approach is turning out to be helpful for several reasons. For one, I wanted to organize the content into 8 or so example programs that will hopefully be of interest to the target students. Each program will be demonstrated first before I walk them through how it's made via live coding. As certain concepts are needed, the coding will pause and we will discuss the concept in general and in the specific context of the program. I also intend to have at least one peer instruction question per lecture period. Having a detailed list of objectives is helping me ensure I hit all the main points in the planning process.
Beyond this, as I have found when teaching as a contract instructor in the summer, you can give your learning objectives up front all you want, but it doesn't mean students will remember them or see how the course material connects to them. This year, I plan to colour code the objectives and explicitly link to them during every lecture and in every tutorial and assignment. I am hoping that this will make the course more clearly interconnected and help students organize the content in their minds as we go.
Finally, always linking back to the objectives will help me prove to students (and know for myself) that everything we do is relevant to the desired outcomes. Nothing should feel like busy work!
If you're interested, the current version of my objectives for this course are below.
By the end of the course, you should be able to...
- Understand what computer science is, and how it can help you solve problems in your field.
- Learn how to use Processing to create visual programs of varying types.
- Explain these basic concepts of programming to somebody who has never programmed before:
- data types (numbers, Strings, etc)
- variables
- functions
- Booleans and if statements
- loops
- arrays
- objects
- Solve basic programming problems by working with:
- searching and sorting algorithms
- using simple data structures
- dynamic memory
- recursion
- Develop good programming practices in the areas of:
- breaking a problem down into smaller pieces
- testing
- debugging
- code reuse
- Learn to approach programming problems with the following values:
- a desire to experiment
- the confidence to make mistakes and try again
- the instinct to consult documentation and seek solutions yourself before asking for help
5 comments:
You sound like a seasoned elementary/high school teacher! Exactly the same principles are used when we plan our programs. Good luck! I like the "values" section - we all learn by our mistakes and some students find this hard to accept.
It is VERY hard to break students out of the mindset that wrong = failure that should be avoided at all costs. It's really part of the process, and in the future, I want to work this idea into the whole assessment scheme more somehow.
I stumbled over one of your objectives: "dynamic memory". As a computer engineer, to me that term means RAM that stores information on capacitors that need to be refreshed every few milliseconds. But that concept has no usefulness in an intro course for non-majors.
I see from Wikipedia that some people are now using the term to mean "memory allocation" (which seems like it already had a perfectly good technical name), which is an important concept in C or C++, but probably not reached in a first course course using Processing.
So what do you mean by "dynamic memory"?
I actually just changed this back to "shared memory," which refers to understanding references pointing to the same object in memory and that sort of thing. (This is what it's been called in past version of the course.) The term dynamic memory came from Think Like a Programmer, which I am using at least a bit as inspiration - there, it means working with pointers and dynamically allocated objects/structs in C++.
That wrong=failure thing I think is ingrained very early on. People don't like to be wrong, and they don't like having to own up to it. My guess is that this reinforces the brain's response to have an aversion to anything difficult. In that view it might be easier to get kids to adopt the mindset of debugging if they're given a pre-built hunk of code that doesn't work, and they're asked to fix it and make it work. This might be a good way to get them into the tweak/test loop without the stigma of dealing with their own prior failures. Once the mindset on how to tackle broken things is there, it might be easier to direct that mindset to handling failures they make themselves.
Post a Comment
Comments are moderated - please be patient while I approve yours.
Note: Only a member of this blog may post a comment.