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:

Teaching Computing in Middle School

8:23 AM 0 Comments

My oldest is in the 3rd grade right now, so it seems like a good time to start pounding the pavement with the fact that kids should be taught serious computing as early as the 6th grade.

My kids use Scratch and love playing around with it.  They take the game examples from a Scratch book I bought for them and tweak them to do different things.  I want to start taking it to a more formal level, but right now I'm happy to let them tinker.

Born to Code


That's what I did when I was a kid.  Tinker.  When I was 12, my dad showed me how to change the color of the DOS prompt, and I was immediately intrigued by the idea that I could tell the computer how to do something, and it would do it.

I wrote my first program in QBasic when I was 13, and took a Pascal programming class from Robert Czapla at West High School when I was 14. I remember the textbook being one that I couldn't put down.  (How many textbooks can you say that about?)  I would read it at home, at school, and in the car.  I couldn't wait to get my hands on a computer and try something new.

By the time I had graduated high school, I had added C++ to my tool belt.  I was programming games, using algorithmic thinking, and am a better problem solver today in general because of it.

By 18, the year 1999, I also had learned Java.  I applied for a Java programming job at the Park City Group.  I was hired and spent the next year coding there for $13/hr (compare this to my counterparts who were making $7/hr at Wendy's), saving up money to serve an LDS mission.

Raising Students to the Engineering Expectation


I was very lucky to go to a school that offered me computer programming at a young age.  In my opinion, it could have been a couple of years younger, and I would have been just as avid.  In fact, with new programming languages like Scratch and Alice, introducing computing and programming concepts has never been easier and the minimum age requirements have never been younger.

The most forward-thinking schools are starting to teach computing with Lego Mindstorm robots, Scratch, HTML, and Alice when the students are a mere 11 years old.  Other schools are stuck with the idea of teaching the students typing, word processing, excel, etc. at that age.  These are skills that I am teaching my kids now at the young ages of 6 and 8.  While they are absolutely vital skills, schools that aren't offering more advanced computing in middle school are leaving today's tech-minded families in the desert.

These forward-thinking schools are responding to the writing on the wall.  Computing needs to be a core competency like Math, Science, and English.  Computers are in virtually everything, and the United States is not producing enough Engineers to fill the need.  In my current workplace, I am a 1 in 10 minority with about half my co-workers being from India, another quarter from Asia, and another roughly sixth from other countries.  While I appreciate and enjoy the diverse culture, what does the demographic say about how many engineers the United States is producing?

In 2011, NCWIT reported that 1.4 million computing related jobs would be added to the U.S. by 2018.  The years leading up to that are the years that our middle schoolers are formulating into adults that can fill those jobs.  If schools don't produce enough engineering-minded students over the next 5 years, the market will fill it with more engineers from other countries as it is doing today.

Raising Social and Cultural Beings


One concern that I heard recently was that in middle school, students should be learning how to be social and cultural beings, not productive workers.

I am a big fan of Ken Robinson.  He is the presenter of a somewhat famous TED talk as well as the author of a very excellent book that I'm just about to finish called The Element.  In these works, Robinson propounds the idea that our schools today are killing creativity by focusing too much on the right answer and not allowing for subject matter that requires greater mental flexibility on the part of the teacher and learner.

Computing is one discipline that is an answer to Robinson's call, if done correctly.  The adage that there are one hundred ways to skin a cat is true with computing:  There are a hundred (or even a million) ways to write a Microsoft Windows USB Driver, a Honda Civic Fuel Injection routine, the next Facebook, or the next World of Warcraft.

Certainly, computing has its standards, and I myself have been known to cause my co-workers grief by holding them strongly to good craftsmanship.  However, the necessary aptitude for problem solving and taste for variety are found in levels in computing that I have not been able to find elsewhere.

I am a big proponent of teaching Math in school as well.  Unfortunately, the math curriculum has turned into one less of discovery and finding unique ways to make advances and more of finding the one right way to do things.  Again, understanding the fundamentals is important, but one only needs to watch the creative videos by Vi Hart to see how far astray our math curricula are from what is possible.

Such could happen with Computing in a school system of right and wrong.  If that does come to pass, then the above concern is valid.  However, if done correctly, computing is an excellent vessel for sparking creativity in our youth.

Computing also teaches algorithmic thinking, which is another important social and cultural trait.  The ability to create efficient, scalable, extensible, robust systems are useful skills well beyond the realm of computing and engineering.  Climate change, diminishing natural resources, and disease, just to name a few, require kids that not only know how to think analytically but how to think in algorithms.

The adults that solve the worlds problems of tomorrow are the kids that are learning computing today.

Other Points of View


Clearly, I'm not the first nor the last that means to talk about the need to bring computing into our middle schools.  There has been a lot written over the last few years about the need to introduce computing more rigorously to younger students.

A simple Google search will reveal several fantastic articles that explain in greater detail the need our country has for teaching computing at younger ages:

Why Girls Should Be Encouraged to Tinker

New Programs Aim to Lure Young Into Digital Jobs

Getting Computer Science Into Middle School

Homegrown Computer Science for Middle Schoolers

Middle School Computer Science:  An Interview with Laura Blankenship


Existing Curricula and Other Solutions


Again, a brief search on Google evidences a wealth of proven resources that teachers have at their disposal to bring computing into the classroom at young ages:

Happy Nerds - A site of resources for teaching computer science to younger students

Bootstrap World - A curriculum for teaching computing alongside algebra and other math subjects

Scratch - A programming language for introducing programming to younger students

Alice - A programming langauge for introducing programming to younger students

Lego Mindstrom Program Setup Guide - A guide for setting up a LEGO Mindstorm program

"Exploring Computer Science" curriculum - An entire curriculum for teaching computer science (note: this is targeted at high schoolers)

Conclusion


Educators, begin today.  The kids need it, our future needs it.

0 comments: