Maximum PC

This is a topic that has been running through my head as of late, and a topic I would often discuss with a previous CS teacher of mine. How do you introduce, and effectively teach teenage students programming? If you walked into a classroom full of high school juniors and seniors, given the task to introduce them to programming, where would you start?

The way I see it, there are 3 basic approaches.

1. Start with something visual. Alice or Game Maker for example.
2. Start with a very high level forgiving language. Something a little more complex than option one, but still holds their hand all the way through. Python, VB, or some other derivative of BASIC.
3. Leave them for dead with something like C or Java.

The latter got me hooked, but I have an unusual interest for programming. I've seen students completely discouraged by the daunting disposition of that approach.

Queue Edsger Dijkstra. In a pretty interesting write up he states:

If that holds true, than the first two approaches I outlined are completely invalidated.

Any opinions?

The problem I have with almost all CS curriculums, including the one that you offer, is that they put the tools before the concepts.

I don't think that CS students should write a single line of code in their first year. Teach them to problem solve. Teach them to break a problem down into its most basic components. Teach them algorithms and sorting and the basics of all of the tools of a software designer.

Once they've got a grasp on that, teach them to implement their ideas.

When data structures are taught, teachers will usually explain the structure, demonstrate it and then the students are asked to implement it. This is how CS should be taught. Learn the concepts, THEN apply them.

For some reason that I can't fathom, every CS curriculum I've ever seen is completely ass backwards.

I agree. I've seen too many of my fellow students learn syntax and specific languages, but not be able to design a simple algorithm to save their life.

Start with problem solving skills, and then maybe move to pseudo-code. When they have that down move to real code.

TBH language doesn't matter so much as how you teach it.

I learned QBASIC and look at where I am. Oh wait...

Teach the hard courses first. Get the boring sections done and then go for the fun stuff at the end. If they can't take the math and the thinking then programming isn't for them. Those who can do the thinking for the math will get those who can't.

Arrays, print, math, etc should all be taught first. Displaying images, graphs, etc should be taught last.

Mostly because when people think of programmers they think of game design (at least students who frequently game do). It's a common misconception that really needs to be remedied.

Personally, I would start with the basic print functions. then variables, then the math, and keep building.

Edit @ Jip: I say teach them to program and problem solve. the CS courses can't waste time fixing problems that math classes should have taught in the first place.

^^agrees with Jip. Best CS curriculum:
-Algorithms and problem solving (no prerequisites)
-Any high level language (probably Java) (prerequisite above)
-C or C++ (as vehicle for memory access, pointer arithmetic, etc.)
-ASSEMBLY!

however i can't really offer a good opinion on this, being one of those students dumped into a Java class who did quite well, and had lots of fun, although I understand that a few of my peers were struggling.

EDIT: I agree that the OP's #3 produces the best habits and style in those that aren't killed by it.

Best.Quote.Ever.

Would have never thought that, but then again, I'm not a teacher.

You're right though, teaching problem solving is far more important than putting tools in front of students. There's a reason why they're called tools: it assumes apriori knowledge of problem solving and tools supplement by aiding the programmer in being more efficient (can't be efficient in problem solving if you can't problem solve).

I remember I had a professor who would explain the structure and ask us to implement it. Out of everyone in the class, only four were able to implement it (thankfully, yours truly was one of them but even my solution wasn't that good). While it took me some time to solve the problem, the fact is, I used more problem solving than tools to get the job done.

I think the way mine worked out was good.

Then again, I was programming in basic when I was like 11?

We learned C++ (they start with java now, bad idea imo) the first semester. really simple, just to get the syntax down. Then we had a discrete math and an algorithms class in the 3rd semester. We had to learn how it worked / why and then we had to write it.

We had a couple labs comparing sorting routines.

Red black trees anyone? Come on? Who uses them, don't be shy!

I totally agree with you there. However, I think that the reason that most curriculums do not do this these days is because they're going for the demand vs the need. People say "I want to be a Programmer". They don't say "I want to learn how to be a good Programmer".

The colleges, being the capitalistic institutions they are, see that they can sell "Learn C++ to be a programmer" vs. "Learn Algorithms, Set Theory, Boolean Logic, Object Oriented Design, and then C++ and become a good programmer"...

AMEN! and AMEN!! and AMEN!!!

Problem solving is the very essence of any programming good bad or indifferent.

The issue I have with teaching a programming language first is that invariably the language and its syntaxes and its procedures become a hammer to the budding programmer. After that every problem that comes along becomes a nail to be solved by that particular languages syntactical hammer.

Let us not teach "Programming" first in CS. Let us instead teach the SCIENCE of computing which includes of course teaching the history of the science, the methods used to problem solve, the steps of defining a problem, the steps to detailing a plan to solve or partialy solve a problem, the steps to lead up to implementation of a solution, the software development life cycle, history of systems, and THEN teach a specific language after the student has firm grasp on all of the above.

I write curriculum for a CS program for a private university. We have attempted to front-load OOA/D, logic and problem solving (pseudo-code, algorithms). I am now convinced, after having taught the curriculum for 1 year in this format that while the problem-solving techniques are effective early on, object oriented programming fails to sink in until the students have grasped sequence, selection and iteration.
Teaching programming in the first exposure is similar to teaching a new language. It can be fruitful to provide sentence structure theory, but only in conjunction with teaching the words and syntax rules that make up the sentences. Higher level instruction can be taught theory first because students at that point possess a fundamental vocabulary.

I dislike your analogy. Teaching a new language necessarily implies knowledge of an existing language ... this isn't the case with a first-time programmer.

However, I agree that front-loading a curriculum with nothing but theory can be detrimental .. particularly with students who learn by doing rather than learning by understanding. Some 'hands-on' programming based on structured paradigms can be helpful.

I'd caution against making any observations after a single year of your new curriculum, though. A single class is far from a statistically significant sample. Far more importantly, though, you need to matriculate a class through the entire programme before you know whether it works (though you can spot a BAD curriculum much more quickly ... ie., when your second-year class has a high failure rate ).

Keep us informed on your students' progress, please ... the more practical information we have, the better we can help the next generation of code monkeys.

TI-Basic. 'Nuff said.

No. It isn't.

Well, it is 'nuff said' in the sense that we don't need to discuss it or ever bring it up again.

Right, nmanguy?

Back when I was tutoring, I noticed a few different problems.

Students didn't really pick up on how to go about solving a problem. Students memorized full algorithms/code (or attempted to) rather than understand what the algorithm was doing. Simple things - like introducing a dummy variable escape them. When you think of an algorithm say - quicksort - you shouldn't be seeing [pseudo]code, but understand - ok here's what we do - get pivot, stuff there is greater, that side is less recursively call right, left and concatenate with pivot... That's just not what I saw them doing though.

I agree with what Jason said - simple things we take for granted - iteration, case statements/conditionals, proper logic escape students. For most students I worked with, this had to be overcome to start getting to real problem solving.

If an algorithm can be shown visually it helps - don't just say this is spoon feeding - most people I met in college doing CS never picked up a computer for any form of scripting/programming.

The other thing is, many students are lazy. Meeting someone as a tutor should not start with being offered money to complete someone's project.
That's the truth of it. The only way students will learn is if after your class they go home and tinker for themselves. Maybe they need more interesting projects? Perhaps a project they start rather small and continually build on through the course?

Having gotten what I feel was a good handle on both VB and Java at a basic level, in the course of a single school year, I do have a couple things to say about teaching a language.

First, start off with written lessons, lectures even. It's boring, yes, but it often gets the concept across. You can also try to teach while typing up code on the screen from your PC. Explaining the significance of each line, as well as asking the students exactly what should came next. Explaining how certain things, for my Intro to Java class it was sorting using nested for loops, work exactly are very helpful to later problem solving, because then the students can figure out a work around for other problems.

That being said, I don't think students that can think outside of the box on most levels, or who can problem solve very well should be taking CS classes. I found that complex logic and problem solving are the two biggest things to remember when learning to program. And End Ifs and semicolons. Always forgot those.

Thats what they do at my high school (i'm in intro to programming level 1). First semester (level 1) we learn syntax and figure out the algorithms etc. on our own. Second semester (level 2) we continue with c++ but now doing much more complicated things. I'm not there yet, so i'm not sure exactly. Then in AP, we learn Java.

Interesting posts; and I thoroughly agree with teaching the concepts first then providing the tools to get the job done.

I have recently been persuaded to go back to school to finish off a degree. I started in EE, but have a fond desire for programming. So, I enrolled (at age 36 mind you) in the local college for a CIS degree. First class: Java. Don't know the first thing about Java, but I have been blessed to have exposure to many "good" programmers in the past who taught me that problem solving skills are more valuable than speaking the coding language. Time to put my old brain to work and see how the Lord blesses.

36 is not old.. you're not even middle-aged yet.

Just think .. you'll be surrounded by women half your age in all of your classes.

Ok, not in your actual CLASSES, since you're studying CS, but on campus.

Think of all the things you've learned over the last 18 years and how easy it'll be to have those girls eating out of your .. errr .. hand.

Going back to school with some years under your belt is one of the best things you can do to improve your quality of ... life.