Elysian Shadows

Now this year, I am 99% certain that I will be the programming leader of my highschool robotics team, so that means I would have to raise up these fledgling programmers. That means I have to teach them wisely and practically. At first when I was learning, I never seen the practicality of classes until Falco bashed me for not using them How would I keep them interested and learn the practical applications of stuff? I don't want to hand them a book and tell them to read it... Actually they would have basic Java training but too basic IMHO. I was thinking of teaching C++, but how ever I would not call myself very "advanced" just intermediate. I have tons to learn myself too.


So how would I go about teaching programming?

Teach by example and be someone who they can ask questions of. Let them come to you. If they want to learn, then you're there to help them. If they don't want to learn, they won't learn anyway. If they're human, they'll dislike someone telling them what to do if it's pushed on them (and they'll be more like the latter than the former).

Just ask them to show you more when they have something to show, and if they seem like they're looking for your thoughts, then give your opinions and advice (but you don't need to give it every time you look at what they do - sometimes people need to figure things out themselves or be open to receiving input first).

How can I explain certain concepts like classes and inheritance? Inheritance is easier but IDK any layman's word for classes... Can I call it "containers". It doesn't quite describe it so any suggestions? Maybe objects, but thats kinda different.

I would start by showing some pre-existing classes and show how they are used.

I would do what all the online tutorials do. Relate the classes to objects, any object. Like an apple. Then show them how it can have variables like Red, Green, Yellow... etc. Next explains functions as actions the object can do, ie apple.grow() or apple.wrot() or something. And as for public vs. private, I'm not entirely sure how you'll want to explain that... maybe relate it to a person, with private thoughts, and public thoughts... That's how I would go about it.

Yeah, I definitely like the real world object approach. In a lot of ways, that's what the model is based off of (although you can extend it into whatever logical space you want).

For public/private, explain it via how you want other object's to access that class. If you're practicing tight encapsulation, make all variables private and do get/set methods for variables you want public access to. It's a good model for teaching future network communication: one object sends something to another object, and that object does something with it. In some cases, the communication is one way and you don't receive anything back, and in other cases, you get a return message back (and in some cases you have pointers/references that point to the same data value/object as if you punched a hole through those barriers to make things easier/more efficient). Draw pretty pictures, lol. Support stuff visually, it helps.

You know, not to long ago I would have said, teach by example, but I dont know if I feel that way anymore.

I think foremost a distinction should be made between "programming" and knowing a programming language. They are not the same thing what so ever.

Defining what the basic premise of programming is, goes a long way in keeping people motivated. Your goal should not be to learn a language, but rather concepts that you can use to solve practical problems.

Teaching someone how to successfully extract and define a problem is key. With out knowing what your problem is, one can not really make a solution.

It's no easy feat, but I would suggest posing them with a problem, and asking them to, in pictures, or a state diagram, make a solution. It should give you a good idea on what kinda level they are thinking. Then ask them to extract a bigger concept out of the solution, assuming they get it right, and talking about the bigger concept and how that may relate to a more general problem, not just the one at hand.

A lot of the times people will know how to solve X but not Y, Z .. etc, even though Y, Z.. etc are the exact same problem, but just posed differently, If you can make them see the bigger picture ,they will benefit infinitely more than having you show them how to make sort a array of size X.

Avansc is largely correct. Don't make it out to be "learning C++," but rather, "Learning to Program."

I actually have had a considerable amount of "teaching" experience. In Jr. High, I taught two extracurricular classes, and in High school/College I've done a vast amount of tutoring and competition training. I am not, however, a good teacher, so I really cannot give you any great hints. :P

If you'd like advice or hints on particular topics, let me know and I'll see if I can't relay some of my experience. Also, it is very true: not everyone will learn, simply because not everyone wants to. You should be able to figure out quite quickly who is there because they want to learn, and who is for resume padding. Seriously, make it easy on yourself and focus your attention on the ones who actually want to learn.

How can I explain certain concepts like classes and inheritance? Inheritance is easier but IDK any layman's word for classes... Can I call it "containers". It doesn't quite describe it so any suggestions? Maybe objects, but thats kinda different.

Aww, now there's a question I can answer. Believe it or not...This topic can be disastrous if not approached correctly. Even though I hate to say it, it is to my experience that "jumping to classes" is the complete wrong way to go. Even if your class of students already have some experience, they will be left scatter brained when considering when and why of objects. For this reason, I would propose an iterative problem solving approach. Though I confess most of your "students" will not favor this, it is to my experience that they will actually learn to code better in this manner.

The simple truth is...Most of us on these forums are programmers because we fucking love it. Much of what we know is from billions of scattered remnants across the internet, forums, books, etc that we have pieced correctly (and sometimes incorrectly?) through countless hours of leisure coding. While this worked fine for us...You must consider that the kids approaching you in need of "teaching" obviously don't work the same was as you do, or else they wouldn't need a teacher in the first place.

Also, consider every experience you've ever had in a math or physics class. If you simply sit and watch somebody work problems or have it explained very very concisely to you, you will understand everything. You can muse at the easy to follow logic and realize, "Wow, this is easy." Then, in a week, when you sit down to work an "easy" problem, you will likely fumble at where to begin. This is simply because of inactive learning--if you didn't actually work the problems yourself, you will not retain the process without a photographic memory. And with one, you will still have a hard time applying the same logic to slighly altered problems. So, even though programming is very enjoyable to us, it is still a subject bred entirely from logic like math or physics, and must be handled similarly.

For the guys actually willing to learn, in order to teach classes, I would do a 3 part lesson:

1) Assign a very easy to complete program forcing upon them a procedural approach. Don't even mention the existence of stucts or classes for these first few programs. They are going to quite obviously be "grunt work," but the students actually willing to learn will complete it, so no worries. For the ones that already know of structs or have been coding before, simply explain to them that this is "just practice" and "approaching problems from a different angle," and tell them that they must still do the program as your later programs will expand upon them.

I the subject of this initial program should be Arrays for data containers, and procedural problem solving.

Here's an example of an assignment:

Problem: You are writing a program for a company that is to compute Social Security taxes for a group of employees. The company has requested that you track employee ID, employee Salary, and then compute Social Security taxes based upon the fixed rate of 6.2%, being applied only to employees with salaries less than or equal to $106,800.

Data Requirements: Each employee must be able to contain a 5 character identifier (example: "AD76E"), a yearly salary (ex 107321.32), and the calculated Social Security tax (ex 807.32). These will all be stored in arrays of the appropriate data type.

Program Structure: All processing will be done within your main(), and no variables except constants will be allowed in the global scope.

For the complete noobs: Before assigning this program, they will need to be introduced to the following:

1) Data types
2) Main
3) Const
4) For loops
5) arrays
6) basic operators (assignments, addition, multiplication, etc)

And, in addition to the assignment, be sure to introduce them to tons of PROPER vocabulary, such as "algorithm," "procedural," etc. And, finally, do what avansc has suggeseted: have them draw logic and flow diagrams (make an algorithm) before they try to complete it.

2) For the 1st program, they saw how they can use arrays and (badly formed) procedural programming to solve problems. This next one will introduce them to basic aggregation (don't even bother explaining this to the newer folk, just let 'em work). This will also be helping to work them up to the logical structure of classes, and emphasize the work they do. And finally, they will be modifying the same code, so they will already be gaining experience with 'refactoring.'

Problem: The same company has offered you a 2nd contract to modify and improve your first program. The small changes are as followed: They now want a way to compute average salary, count the number of salaries above and below this average, find the largest and smallest salary, and still maintain the same functionality the first program had. Also, they are having a hard time tracking people by their ghetto 5 digit employee number, so they want a "name" identifier as well.


Data Requirements: At a code review, your boss said that your 1st program was structured horribly. Keeping up with 3 static arrays of employee data? What were you thinking? He wants you to "do it right" in what he calls his "old fashioned" method. Use a "struct" for each employee, and use some goddamned "functions" instead of doing it all in main. A matter of fact, he says that you need to figure out how to do it with your main being less than 10 lines or else you're off the job. Oh, and use a String for the name like a normal person--no more character arrays.

Program Structure: Make atleast one function return thing by reference. Main must be very short--most processing must be done in function. Also, one array of "employee" structs instead of multiple arrays. Make them pass "employees" to every function--they are not allowed to make the array global. (Note: This is VERY important in leading up to classes--when they see how fucking painful it is having to pass employee structs to every function, they'll welcome classes with open arms.)

For the Newbs: be sure to introduce functions correctly, and get it straight in their heads form the start the difference between function signature, definition, declaration. Also, be sure to emphasize things like "in" and "out" parameters (in case they ever end up moving to C# or another language with those reserved words). Be sure to give em good vocab!

3) For this one, do the same king of thing. make them modify it, except use classes and make all of the functions in the employee class. Also, EXPLAIN TO THEM THAT C++ GIVES EACH MEMBER FUNCTION AN EXPLICIT "this" PARAMETER. This will "click" for students, as they just got done painfully having to pass around "employee" objects and arrays.

Finally, to move into inheritance and more advanced topics...Just add to the same damned program. Make the company want distinctions for different types of employees (inheritance), introduce "encapsulation," make it complex...Make "managers" that are "employees" actually contain "linked lists" of other employees they manage, so that they can give out raises...:P Be creative, and introduce topics through problems.

Marcel, that was the contribution of the century.

The only way that post could've been better is if you had excluded this:

Arce wrote: I am not, however, a good teacher, so I really cannot give you any great hints.

That's complete bullshit and nullifies your entire point more so than saying "That's it." at the end of a presentation. Don't do it.

And ... "The longest post of the year" award goes to.... Arce!! .
*reads long post*

eatcomics wrote:I would do what all the online tutorials do. Relate the classes to objects, any object. Like an apple. Then show them how it can have variables like Red, Green, Yellow... etc. Next explains functions as actions the object can do, ie apple.grow() or apple.wrot() or something. And as for public vs. private, I'm not entirely sure how you'll want to explain that... maybe relate it to a person, with private thoughts, and public thoughts... That's how I would go about it.

The realms of fruit salad programming are dangerous, tread carefully...

It's a fantastic way of teaching the basics of objects and classes, but once people have learned to attribute a class to an object such as an apple, it's difficult to teach them to apply that to an actual programming scenario. You face the dreaded, yet inevitable question of 'but how does having an apple in your code solve this?'.

JGorard159 wrote: The realms of fruit salad programming are dangerous, tread carefully...

It's a fantastic way of teaching the basics of objects and classes, but once people have learned to attribute a class to an object such as an apple, it's difficult to teach them to apply that to an actual programming scenario. You face the dreaded, yet inevitable question of 'but how does having an apple in your code solve this?'.

I agree. I find that most classes are way more abstract than that and often the job of a class is to alter the state of other objects, not itself, which is something this approach don't teach.

ismetteren wrote:I agree. I find that most classes are way more abstract than that and often the job of a class is to alter the state of other objects, not itself, which is something this approach don't teach.

Ismetteren worded it better than I did: listen to him instead!

*runs off and pretends he was never here*

adikid89 wrote:And ... "The longest post of the year" award goes to.... Arce!! .
*reads long post*

+1