Question for programming teachers only

I am the IT guy at a small private high school. i used to be a CS and math teacher. The present programming teacher is struggling to teach most of his class. I think I know why but am searching for educated opinions. At present we use VB6. If done right i feel it is as good a teaching language as any "commercially used" language. I think the problem is not the language that is being taught but the fact he is teaching a language without the students understanding how to design a structured program. They do not have a clue as to what they are trying to do with the language. I was looking through the Alice programming books I have (4) and I see the same problem. Each has at most two pages on design. Years ago when I started this whole computer programming thing we spent weeks on design; flow charts, pseudo-code, variable lists, etc. When I worked in the programming industry it was the same thing; a large amount of time spent on design while the actual writing of code was the final, minor step to the project that we farmed out to Vietnam (literally). The VB text book he uses does very little design prep. All the texts I have looked at lately preach to the God of Code. I would like a curriculum and text that is 50% design and 50% code, maybe even 70/30. Alice has the intent of reducing the dependence on having to learn to type code but all the print books and ebooks are glorified tutorials on code. Am I off base here? I can see the kids are struggling with basic understanding of the program's objective, they do not seem to understand the fundamentals of programming and the whole program design phase seems to be missing from what they are taught. Comments?

I'm not a "programming teacher" so will only add to the question - for which I really have no answer.

First, I think the basic comment is quite accurate - not only for "programming" texts but for those for such tools as Office and Photoshop. The situation is worse for magazines - a typical Photoshop "tutorial" spends about half the time just giving a list of filters and parameter settings without giving any idea as to the "why" behind the settings.

Second, for OOP, there is an additional problem (though the Alice texts are pretty good here - just rather low level, which is also appropriate considering their overall goal). All too frequently, after repeating the litinay of OOP buzzwords, a "tutorial" will then present a largely proceedural example. One of the good features of Java (vs. C++ or VB) is that this is a bit harder to do than in C++ or VB. There may even still be cases (especially with databases) where a proceedural approach is preferable - but don't call those solutions "object oriented."

Regarding separating design and actual coding - I think that is a problem of a type that is typical for engineering in general. Both the concept word and the implementation are important - and if done right, can easily be done by groups in widely separated geographical locations, which is certainly the current practice. (Hold out for your companion group being located in a nice phyical location.)

Where is the fun if you spend the first half of a semester in design concepts and the last half in doing something? I am retired from the high-tech world and now teach Alice at a middle school. With this age group, you are dealing with some incredibly short attention spans and I guarantee you that they would not be a good audience for an extended design lesson. They need to see results and fast else they are on to something else. IMHO, leave the correctness out until later. Get them excited early on and then they will stick around to learn more.

Originally Posted by josborne

With this age group, you are dealing with some incredibly short attention spans and....

Lol, thats very true. Getting kids excited about what they are about to learn is a key step in a successful class. Kids having fun = more learning.

with a physical activity with Logo - we program people. I'm new to Alice and wish to move from Logo to Alice. I'll be checking in often here.

Right, get them in an occupied - fast - or else lose the lesson.

Just to be the Devil's advocate here; do HS students take math, history, French, etc. because they are fun? Should we as CS/programming teachers be so concerned with making our courses fun or be more concerned with making our courses relevant? Personnally I am a big fan of combining the two without loosing the goal of educating the student. I am a firm believer that it is easier to teach good programming habits in an unexciting (comparitively) method than to try to correct bad habits learned the exciting way. I used to work for a software company that wrote 911 and police software. The programmers in the company would spend about 90% of their time in design, defining variables, program flow, etc, and 10% in code. As I was leaving the company that 10% was starting to get shipped overseas. I personnally like wacking at code, it is like solving a puzzle and I love puzzles. But I also know it is ineffecient. Boring the kids for the first couple of weeks might just be worth the end result. I will have a class of 8th grades for programming this coming semester. I am going to give my plan a try. Bore the heck out of them (not really, it will still be "fun") by teaching how to properly design a program then turn them loose on the computers. I plan to keep notes of how it works.

There was just a rather interesting posting in the forum - http://www.alice.org/community/showt...ted=1#post6357 - that may be relevant to this discussion.

The person posting obviously was using all the neat code tricks that he came across - and getting frustrated (which for me, at least, isn't fun) because his program wouldn't work. While there may be other problems, I think the basic problem is that he (or she) just hadn't worked out the test conditions correctly.

I don't know that you have to split out planning and implementation into clearly defined steps - in fact an itterative approach has always worked better for me. But there are still the basic five P's - Proper Planning Prevents Poor Programming. (There are are also five and six P versions of the motto that are more forceful but that I won't post here. )