feedback on last night's class, and ideas for future classes

[RonConescu]

Folks,

Some observations from last night, some thoughts about some changes we could make, and some ideas for the programming principles we might want to consider teaching.

(If this is too long an issue for this forum, my humble apologies. Where's the best place to discuss it?)

---

I. Observations

Overall impression from the people I worked with:

• they didn't seem to know what a "module" was, what it was for, what exercise they were supposed to accomplish, or what they were going to gain from it.
• they didn't recognize that other code was being yanked in from a file they could see, control, and modify themselves.
• they mostly didn't understand objects ("tables") and methods. If they saw a construct like "x = thingy.doSomething()", they didn't have any idea how to find what "thingy" meant, where "doSomething" was defined, or why they might want to find either of those. They were working around those lines of code, carefully ignoring them, instead of diving into them as stuff to play with.
• they didn't all recognize "if" and "for" statements, or understand how they work.
• (every week) they didn't seem to know where to go next, or what to do with their skills, after performing the introductory exercise in the reading.

Which leads me to think:

• maybe there's too much reading, for them, or for them-in-1.5-hours
• maybe it's hard for them to relate to what's in the reading
• they having trouble absorbing some of the basics
• maybe it'd help to have a concrete sense of how much they've absorbed, each week

---

II. Ideas

So here are some ideas which I hypothesize might help. I don't know that this will help. I'm just saying that maybe, if we tried these things, we'd learn something about what would help.

I'm going to phrase all these ideas as a single class structure -- a plan for our 2-hour-ish session. If we actually did this structure, I'd imagine structuring every class the same way, so the kids and parents know where we are, and what the goals are, at each moment.

The goal: make sure they achieve specific skills, and acquire matching principles of programming, in Corona (or whatever environment we're using).

Summary:

1. 5 minutes: Tell 'em what we're gonna tell 'em
2. 30 minutes: Hand-hold them through examples of principles, with code to embody those principles
   3-4. 45 minutes: Give them challenges using those principles
3. 10 minutes: Have them get inspired by each other
4. 15 minutes: Give them time to free-associate on these ideas
5. 5 minutes: Get feedback for the next class
6. Pack up

Details:

1. 5 minutes: describe this plan. Give them a 1-page printout listing today's plan.
2. 30 minutes: 1 to 5 brief, fun examples that embody the principles they're going to learn today. In each example, show them the files, the code, and the resulting UI. Have them change or add some code that causes a distinct effect.
3. 30 minutes: give them a concrete goal that uses those examples or principles. Have them build it. Have the mentors check each person's actual understanding of the principles, and/or find some other way of concretely measuring their progress, so we know how the process is working.
4. 15 minutes: ditto. More complex goal.
5. 10 minutes: demos. ask for volunteers to show what they've done. In case they don't volunteer, the mentors will have chosen 3 people who accomplished something valuable. All students and mentors will then troop around the room to look at each person's laptop (or we'll project from that laptop to the screen, or from a camera to the screen). Have a mentor or instructor illustrate the principles (from above) which the student accomplished, focusing on the accomplishments, not the person. 3 minutes each.
6. 15 minutes: free exploration, play, students helping each other. Possibly with another concrete goal.
7. 5 minutes: get feedback about our performance. Ask the parents and kids what improvements or changes they'd like to see in future classes. Implicitly: what mistakes did we make? But keep the discussion focused on the activities, not the people, and focus on what to do better next time, not what went wrong this time. One or two of us takes notes on the whiteboard or projector, so the parents and students get the instant sense their perspectives are being listened to, and can error-check our understanding. If they start putting gear away, ask them to stop, and explain why: this feedback session is part of the class, not something incidental and unimportant. If they're touching their computers at all, it should be to find examples that caused problems, not to put cables away.
8. Then and only then have them put away their gear, and thank them for their ideas, skill, creativity, participation, and enthusiasm.

---

III. Principles?

Here are some ideas for the principles I imagine teaching above, based on what Steven has done so far. I'm imagining stuff that can be embodied in a 10-minute example (when the instructor is driving, but everyone's participating) and 30-minute exercises (on their own). What do you think?

Programming:

• for
• while
• if
• variables
  • ...with meaningful names
  • ...as state
  • ...as adjectives
• statements
• operators: assignment, comparison, other (specific questions I heard: . .. , = == "")
• literals (7, "hello")
• functions
  • ...with parameters
  • ...with meaningful names
  • ...as verbs
• objects ("tables")
  • ...as collections
  • ...as nouns
• methods
  • ...with parameters
  • ...with meaningful names
  • ...as verbs
• modules
  • using multiple files in your project
  • using other peoples' files in your project
• recognizing where objects and methods are declared, finding them, modifying them
• array accessors: objects as collections of stuff
• (maybe) arrays
  • linear collections of stuff
  • arrays of arrays (such as the game grid)
• the keyword meaning "the object owning this method"
• the difference between keywords and program variables
• computer languages as tools:
  • Lua's power/limitations
  • Lua itself as just another computer program that "somebody just like you" built
  • sample matching/missing features in other languages
• libraries as tools: ditto, but for Corona, not Lua

Mobile interactivity:

• touch
• multitouch
• complex touch: swipe, pinch, rotate
• tilt

GUI:

• getting events from the screen: tap, swipe, multi-finger tap/swipe, tilt
• putting graphics on the screen: colors, shapes, backgrounds, image files
• putting text on the screen

Style:

• when variables and functions are named well, your can read your code like a story, in English
• if that story doesn't make sense in English, that's probably a source of bugs
• indentation as debugging technique
• writing code for other people, 6 months from now, not you

Debugging:

• what the error messages mean: the file, line, and character having the problem
• the fact that the problem is often reported at the wrong location
• writing a 3-line standalone test program to debug one line of code

Practical:

• creating a project folder
• editing code
• running a sample program on the physical device and the simulator
• running a custom program on the physical device and the simulator

Working with other people:

• posting their code on a server
• getting each other's code from a server, using it in their own programs
• multi-person games?

Personal drive:

• Actively creating their own ideas based on what the language can do and other games, tools, and situations they've seen

Relating programming to real life:

• Brackets is written in Lua
• comparison to games they've seen
• the Finder and operating system as programs
• the timer running the overhead lights as a program
• the programs in their cars, watches, ATMs, telephones
• air traffic control, GPS, every spaceship yet built
• graphics in movies as programs, and generated by other programs

Ron