Teaching Kids to Code: Day 2

This week, I am teaching a youth summer enrichment course for coding in Java.  You can read about my first day here.

Day 2 went much more smoothly than Day 1.

When I teach, at least towards the beginning of a course, I take roll in GTYK sort of way.  It's great to learn a bit about the students, but it's also great to gauge how comfortable the students are with me as a teacher.  Am I creating the right atmosphere for learning? Do they trust me? etc.

Anyway, so today I told them that when I called their name they should say "Here" and share their scariest memory.  The first kid wouldn't share something, and I thought, "hmm".  Then, with the second kid there was a dramatic pause during which I was wondering if I had picked the wrong thing to ask them.  Just as I was about to back off and ask the students a different question, he said that his first time jumping from 20 feet down to the ground while practicing parkour was his scariest memory.  You do parkour? Cool! For how long?

Most of the kids opened up after that, and I was able to share some scary stories of my own, like getting pushed off the diving board when I was 4 or accidentally hitting my son with a small tree causing him to tumble down a mountain side when he was 3.

After this, we did a Code n' Tell.  I guess every kid likes showing off, but there is something rewarding about showing off what you were able to make a computer do.  We talked about the changes that students had made to the number guessing program outside of the project objective.  One student added the concept of a maximum number of tries before the player lost the game.  I asked the class how they might implement such a feature, and another student described it to the class and I wrote down the appropriate code on the board, asking the students for feedback on syntax, etc.  I asked the original coder if the class got it right, and he added a couple of improvements.  It was great to see the gears turning.

Next was a Bug Hunt.  To review the concepts from the previous day, I wrote a few lines of code on the board that had some typos that had to do with what we learned yesterday.  For example, I wrote:


int guess = takeGuess();
if ( guess > 10 )
  System.out.println("Woah! That's a big number!")


The students correctly pointed out the missing curly braces.  (I told them that they were always necessary; for now, I want clean, legible code!)  They also noticed the missing semi-colon on the end of the System.out.  We reviewed for a few minutes why some lines in Java have semi-colons and others don't.  This was tricky for the students to grasp at first.  For the time being, most of the students just know that semi-colons don't come after curly braces.  A few of the students comprehended the idea that if, for, and while are like "multi-statements" or statements that have children.  I'll need to re-enforce that later on.

The next set of bugs looked like this:


number = 10;
if ( number > 10 ) {
  system.out.println("The number is: " number);
}


The kids right off the bat noticed the missing type reference; line 1 needs an "int" in the front.  They also quickly noticed that something was wrong with the string literal, but it took a little bit of coaching to realize that it was a missing + sign.  Last, they noticed (though this one doesn't translate as well on the board) that the "system" needed to be "System".  Not bad.  The kids asked questions like "Are there any other places in Java where you use the plus sign like that?" And "What does the 'int' mean?" Perfect.

With those out of the way, we pulled open Greenfoot.  No matter how many times I say something, there is a kid or two that doesn't listen or that runs into problems, so opening Greenfoot and getting the first scenario open took a few minutes.  "Where is Greenfoot?", "I don't have that scenario", "My scenario doesn't work", etc., etc.  One student had accidentally removed all the code from the inside of one of the Actors, and that had to be restored.  Getting everyone onto the same scenario took about 5 minutes.

After that, though, it was a bit of managed chaos for the next two hours.  In case you are familiar with Greenfoot, we started with the Wombat scenario.  I showed them how to run the scenario, how to invoke methods on the Actors arbitrarily, how to change the underlying Java code.  In the process, we talked about what was good or bad about the scenario and what we could do to improve it.  As the students gave suggestions, I wrote them down on the board:
  • Have the wombats be smarter about turning so they can get the leaves on the inside
  • Have the wombats die if they don't eat leaves soon enough
  • Have the wombats be controlled by the user through the keyboard instead of the Wombat making its own decisions
  • Make an enemy to the wombat that chases after it
All great ideas.  In fact, the last two are in my lesson plan for Thursday, so that's great.  And, in fact, the first and the second (at least in spirit) were in my lesson plan for today.  Awesome.

We started off with the second one.  I mentioned that we should have it go both ways; the wombat should somehow get healthier the more leaves he eats.  How should we represent that? I mentioned The Very Hungry Caterpillar, and one kid latched onto the idea that we should make the wombat bigger every five leaves that he eats until a certain point when he explodes and makes three new baby wombats.  (I do have a class almost entirely of teenage boys.)  Great idea, let's do it!

The experience was really electric.  We talked about the math of "every 5th leaf" using the modulo operator.  We talked about method invocation and why we need parentheses even when there are no parameters.  We talked about newing up an object (the new babies).  From a Greenfoot standpoint, we used several elements of the API:  We scaled up the image as the wombat ate more leaves, we "exploded" him (removeObjects) and added new babies (addObject).

The biggest problems that the kids were having was with curly braces and semi-colons.  These are just hard, period.  We talked for a bit about keeping the code clean and keeping curly braces lined up.  The other subtle problem was that some of the kids didn't quite comprehend the idea that if the condition in an "if" statement isn't met that the program won't run the code on the inside.  Several kids had at some point or another something like this:


if ( leavesEaten == 5 ) {
    ... get bigger ...
    if ( leavesEaten == 25 ) {
       ... explode and make babies ...
    }
}


"Mine isn't exploding", each would say.  I'm sure you see the problem that after the fifth leaf is eaten, it never gets into the outer if block, let alone the inner if block.  Of those kids a few quickly realized what was going on.  One or two of the kids just changed it how I told them to and it felt like a bit of magic to them.

We got side tracked on the "death" objective because many students were complaining about how long it took to add leaves to the game.  So we shifted gears and talked about how to do random numbers and how to use those to generate random leaves.  This was cool because we started to get into population modeling, at least in concept.

The last objective we didn't have much time for, but we tried anyway.  A couple of the kids got the Wombats eating all the leaves by the end, though, by not always hugging the wall like it does.

Some kids added niftiness, so we ended the class with a Code n' Tell.  One student added Spiders onto the board.  If a Wombat ran into a Spider, the Wombat died.  Awesome! We talked briefly about what he had to do to get that to work.  Another student found an Explosion actor from another scenario and added that to his scenario so when he placed an explosion randomly in his World, it would destroy all the Actors in its wake.  Great!  Another student hadn't quite figured out the smart turning, thing, but he'd make the Wombats do a little dance.  :)

Overall, I think the students had fun with it and left with a higher level of confidence in their coding abilities.

I can't wait for Thursday!

1 comments:

Teaching Kids to Code: Day 1

I taught my first youth programming class this Monday.  I don't have a degree in education nor my teaching certificate, so I probably didn't follow researched and proven teaching methodologies, but we still got to accomplish some cool stuff that few in the classroom had ever done before.

We started out by showing a video that attempts to motivate kids to learn to code.  This is a great video that has the likes of Chris Bosh and Will.i.am advocating that kids learn to code as well as Mark Zuckerberg, Bill Gates, and other software engineering giants.  I highly recommend showing it to your school principal, your science and math teachers, and your students in school.  We need more coders in America!

Afterwards we talked about what we wanted to create this week.  The kids are pretty excited to create a Minecraft Mod using CraftBukkit on Thursday.  I got a pretty positive response from the kids when I told them that we would be programming games all week.  :)

Our first game was a simple guessing game.  The computer was "thinking" of a number between 1 and 100, and the user had to guess it.  I gave them a working, but stripped down version of the game and had them use the command-line JVM.

What I gave them always reported back "Nope!" whenever the guess was wrong.  Not very helpful.  There first task was to be more helpful with the answer by changing it to "Higher!" and "Lower!".  To buffer against the slowest and the fastest kids in the class, I had two "bonus" tasks--a) constrain the range printed out to the user based on his guesses, b) track the number of guesses that it took the user to finish and c) an enhancement of your own.  I had one student out of 11 finish all three bonus tasks, so I think it was a pretty good amount of buffer.

Because of some First-Day Problems, we spent a fair amount of time getting the lab environment working; a few of the computers weren't ready with command-line Java.  Greenfoot wasn't compatible with the JVM installed on some of the computers.  MinecraftEdu.com hadn't gotten back to us yet regarding our request to purchase licenses.  Grrr.  This is the first time that U of U Continuing Education has offered this class, so I guess that is to be expected.

Anyway, we all had a blast.  Today, we will be using Greenfoot to program interactive games.  Can't wait!

1 comments:

Why Coding Isn't Taught Well In US High Schools

9:09 AM 0 Comments

Okay, so there are a lot of reasons, including the fact that most school systems in the US remarkably don't consider computer programming a core competency, but this graphic in a recent article about teaching coding in school:


I thought was pretty telling.  The node on the far left says "Shortage of teachers with sufficient subject knowledge."  Why is there a shortage?

The graphic proposes that not enough students are going into post-graduate Computer Science, and I would agree with that in part; however, I assert another problem which is not the size of the pool of eligible candidates, but instead of interested candidates.

The painstakingly obvious reason I am referring to is Money.  The median salary for a software engineer is about twice that of a teacher.  Compare the current Software Engineer Salary Trend on indeed with the current High School Teacher Salary Trend.  An article in the Deseret News on July 5, 2013 hits the nail on the head when they say (emphasis mine):

"In its analysis of the numbers it provides, ACT does acknowledge the existence of qualified potential math and science teachers is no guarantee that schools will be able to successfully recruit them. A student with STEM interests can earn $67,500 right out of school working as an electrical engineer, according to data from Payscale. However, that same student would only make about $37,500 as a math teacher."

In an ideal world, we would have individuals who were good teachers as well as subject matter experts teaching our youth.  I once worked for a company that, in the distant past, paid engineers sub-market value.  As far as I know, the motivation was to save money, and the company relied largely on their non-profit, good-cause nature to entice engineers away from the beefy salaries that other companies in the region were offering.

To be totally blunt, they got what they paid for.

In time, they changed several policies, adjusted pay scales to match market value, and voila! they started producing some really great results.

Of course, when it comes to our public educators, it isn't that simple.  How can we get qualified software engineering teachers without breaking the bank? My wife and I chatted about this one evening and in our amateurish, arm-chair-superintendent fashion, we came up with a few ideas:

First, we can rely on teachers who see it as a calling to teach.  This is how schools systems have operated for years, at least in the state of Utah (I often hear the argument, "we shouldn't pay our teachers more; they knew what they were signing up for when they got the job," which always leaves me a bit discouraged).  The result is that we have a few angelic, heaven-sent teachers, the ones that you can hardly stop from shedding a tear when you talk about them, and several sub-par-those-who-can't-do-teach teachers.  (See my you-get-what-you-pay-for anecdote above.)

Second, we can pay our teachers more.  For most governments, this just isn't realistic.  Some back-of-the-napkin math shows that between the 870,000 households in Utah, an average of $30 comes from each household for every $1000 paid in raw salary to each of the roughly 25,000 teachers we employ.  Now, there are benefits, administrative costs, training costs, etc., etc., and I'm not really trying to come up with a rigorous figure here.  The point is that in raw salary alone it would take roughly a 65% property tax hike to raise the median salary from $47000 to $77000 and 97% to get teachers in the realm of high-skilled labor.  Raw salary isn't the only thing in play, of course, so I'm sure the real numbers are higher than this.

(If you are curious about what my napkin looks like, it is this:  25,615 teachers/871,358 households*($1000/1 teacher) = $29.39/1 household.  (30*$29.39)/$1351 median property tax = 65%.  (45*$29.39)/$1351 median property tax = 97%)

Third, we could introduce the idea of tech businesses donating teachers to high schools.  They would stay on the payroll of their company and there are millions of kinks to work out like what happens if the individual leaves the company during the school year, but this is just an idea.  I mention high schools specifically because only one in ten US high schools offer a computer science program and it would be great to start bumping up that number.  There are roughly 200 public high schools in Utah.  These high schools house an average of 800 students.  To introduce a one-year computer programming graduation requirement to these schools would require 1 full-time teacher to teach 8 classes a day to keep the class size down to 25 students.  Now, a business can't donate one of their employees full-time, of course, but they may be able to donate them quarter-time.  Can we find enough tech businesses that would donate their employees for 2 hours during the work day to regularly teach two periods of computer science?

Fourth, tech companies may be willing to allow their employees some flex on when they take off during the day to be an adjunct teacher.  In this case, the school system would pay the cumulative of one full-time teacher sans benefits per high school and businesses would still require their employees to contribute their normal full-time hours otherwise.

Fifth, have the local universities and colleges supply teachers.  This isn't concurrent enrollment.  In fact, it is essentially the same idea as the previous two except that the universities are providing the personnel instead of local tech companies.  Ostensibly, most engineering faculty in most colleges and universities would be qualified to teach entry-level coding, regardless of whether they are teaching undergraduate computer science courses; it would seem that the same roughly 800 individuals could be identified and recruited.

Of course, the above three ideas have significant problems.  Where is the Computer Science teacher for Delta High School going to be sourced from if she needs to be donated from a university, college, or tech company? Perhaps the growing number of telecommuters may be a solution.  What incentive do business have to enter into this kind of agreement?  How would the school system get all these volunteers or adjuncts trained?

Sigh.  It's a conundrum.  How can we fix it?

0 comments: