It is not about coding

July 13, 2017

I was chatting with a teacher friend of mine about the difficulties he was having teaching programming in his technology class. He teaches a section on robotics in his practical technology classes using RobotC and Lego Mindstorms.  He is not a programming teacher; he is a machine shop teacher who has graduated to some very advanced computer controlled manufacturing machines.  He offers an engineering class with the robotics section and his thought was he should be able to teach the kids the syntax of RobotC and they should be able to figure out their robot projects from there.  It is not working out.  The kids simply cannot figure out what to do.  My friend suffers from what I see a lot in inexperienced programming teachers, the idea the programming is all about knowing how to type code.

Many beginning programming teachers have a fixation on coding.  (I differentiate programming and coding.  Coding to me is writing and typing code.  Programming is the complete package: algorithm design, building a user interface, and a whole lot of things that are done before sitting down in front of a keyboard.  I do this just so I can separate the two behaviors.)  I have attended two week long summer camps for teachers, one from Microsoft about Touch Develop, and the other just this summer about a curriculum written at Montana State University on how to teach Python.  Although both camps were for teachers neither dealt with any pedagogy on how to teach coding or programming.  Both stressed syntax and how to read the curriculum they had designed.  It was implied in both camps that although pedagogy was important it was something that would somehow be easier that coding and syntax.

This is where I start waving my hands above my head and using phrases like “Are you out of your frigging mind!?”  To teach programming, or even coding, it would help to actually know how to teach programming and coding.  It is necessary to know to step away from the computer and teach kids how to plan and think.  Things like how to disassemble a problem into manageable parts.  These are not skills the kids are adept at.  These are skills many teachers are not adept at and therefore need to be taught to teachers.  Previously I talked about how surprised I was at the lack of knowledge the new teachers had towards how to teach programming.  Little things like having the kids write the procedure for building a peanut butter and jelly sandwich then having a second kid follow those directions, or when programming with turtle graphics having the kids either walk or use something like a toy car to follow the desired path. To those of us that have been teaching programming since FORTRAN was popular these are common teaching strategies.  To new teachers they seem to be a revelation.

My friend feels he should be able to point the kids at syntax, and from there they should be able to figure it out.  After all, he figured it out that way.  The trouble with that strategy is he is not a 16 year old male whos brain is still not completely wired.  Those thinking skills that require logical steps, organized thinking, and all sorts of brain skills required to program have to be taught.  Considering the students my friend has (he does not get high-level thinkers or computer geeks) what he wants to do in a couple of weeks might be difficult in a couple of months.

My friend’s goal is to teach problem solving.  Teaching coding does not teach all the preliminary work needed to teach or learn problem solving.  Without that preliminary structure, he is just going to frustrate himself and his students.


Going Old School, not quite clay tablets but close

July 5, 2017

I am going to be teaching Math II again next year.  The course is some Algebra, some Geometry and some of whatever comes to mind as I go along.  The students are a good group, just not mathematically oriented.   I do have a major problem when I teach this course, I get bored.  And if I am bored then the kids have to be beyond bored.  If I start progressing through the book page by page and chapter by chapter then we all go into a vegetative state.  High school math textbooks are not designed to teach math, they are designed to force math down the throats of unwilling students and to give the teacher a lazy way of doing it.  OK, a bit of an exaggeration but textbooks put me to sleep so they have to kill the kids.  I need to start digging up some interesting stuff that will still get some real math taught.  I think I am going to approach this two ways, no-tech and high-tech (sort of).

No-tech.  Most of my math students have zip for estimating skills, no ability to do simple math in their head, think Satan brought fractions to Man and that using the WAG method to start solving a math problem is a cardinal sin.  (Catholic school, we can think things like that.)  (What is the WAG method you may ask?  I was taught this method in one of my calculus courses many years ago.  It has held up to the advancement of technology well.  It is still one of my favorite problem solving strategies.  So what is it?  Well you start with a wild assed guess (WAG) and go from there.  Clever huh?  What do you want?  I have spent the last two days troubleshooting laptops and reimaging computers so I am just a bit giddy and more than a bit brain fried.)  So in an effort to address some of these student handicaps (I think they are handicaps) I am going old school.  No calculators.  There will be tears and protests.  I expect picketing.  But that is OK, we are not going completely “device” free.  I collect slide rules.  Yup, we are going really old school.  I am going to reintroduce the slide rule to a math class in 2017.  Those of you that have used a slide rule remember the lesson when using a slide rule (other than knowing how to work the thing), you have to have an idea what the answer should look like.  If multiplying 23 X 562 you have to know the answer is somewhere in the 10,000 to 12,000 range.  It is all about place value and being able to do some simple math in your head.  Slide rules also lead into addition as multiplication.  (Adding exponents.)  It should be interesting.

High-tech (sort of).  I want to do a lot more with Excel.  Build some number crunching spreadsheets.   I was considering doing some turtle geometry but that may be a bit to tech intensive.  Teaching them a language and some geometry might be more than this group can handle.  I will have to think about this more.  Using tech with student often brings in a level of complication that these kids have problems with.  The problem is more often than not a focus issue.  Cruising the internet is a lot more interesting than doing a geometry problem on the computer.  These are not the kids that get interested in what math can do for them and why it is interesting.  These are the kids that find school an inconvenience to their social life.  One thing I am going to de-tech is phones.  Last time I taught this course I allowed the use of phones as a calculator.  Not a good idea.  At this age the kids are simply not mature enough to not get distracted by cat videos.

I have to be somewhat careful what I do with these kids.  The course is pretty algebra intensive in order to get them ready for a pre-calculus course.  The teacher they will get for Math 3 and pre-calc is big into old school hand algebra methods.  Me, I am more into WolframAlpha and just solving problems.  If I point out to the kids that factoring polynomials by hand can be done on only on a special set of polynomials so do not bother learning how to factor polynomials their Math 3 teacher would not be happy with me.  So I cannot abandon this ancient math.  Standardized tests seem to like this stuff.  I rather like to do this stuff too but then I think Project Euler is a fun website.  And I collect slide rules.

A week of in-service: Another Python course

June 20, 2017

I just spent a week in an in-service/seminar with twenty teachers on a high school Python curriculum written at Montana State University.  The curriculum is “The Joy and Beauty of Computing” (JBC) and I believe is adapted from a curriculum developed at Berkeley.  It is used at MSU as their introductory programming course.  I had perused the curriculum several years ago and was not impressed enough to change my present curriculum.  It was fairly standard and did not offer me enough to deviate from my core of “How to Think Like a Computer Scientist: Learning with Python 3 Documentation; 3rd Edition” by Wentworth, et al.  The University of Montana wrote a grant to train teachers how to use the JBC curriculum so I jumped in.  Attending these events is very revealing, both about the curriculum and the state of teaching programming in Montana.  I really went to the in-service to meet the other teachers and to get a network started.

I had the opportunity to meet programming and prospective programming teachers from all over Montana.  A couple had come from as far as Wolf Point, an eight-hour drive.  What a broad spectrum.  Everything from a former professional programmer who is now a teacher to an English teacher who had been directed to offer a programming course next year and has never programmed in her life.  There were several business teachers with about the same experience and directive.  (The English teacher sat right next to me.  Poor lady.  Not a clue what she was getting into.  Not a computational thinker.)  Only a couple of us had actually done any CS/programming teaching.     It was a bit interesting talking to the teachers that had been give the directive to offer a programming course at their school.  It was a “come up with something” type of directive.  Not a lot of research or experience guidance behind the directive. As could be expected for a weeklong summer event like this it was an enthusiastic and involve bunch.

Now to the JBC curriculum.  It still does not excite me.  It is missing about 90% of what the programming curriculum needs for beginning programming teachers.  It is almost exclusively a syntax course.  There is very little on how to program prior to hitting keys on the keyboard.  We were doing a semester in a week so admittedly the preliminary work the teacher would do was being greatly compressed but most of the teachers attending did not even understand there was preliminary work to do.  All the pre-planning required to write a program has been ignored in an attempt to get the kids coding.  In the exercises we did I found myself doing exactly what I teach my students not to do, planning at the keyboard and filling those gaps with trial and error.  Most of the teachers there assumed that was the normal programming procedure.  The teacher with professional experience and I had to do a lot of demonstrating.  Little things like have kids walk through the turtle moves were “great ideas”, where she and I considered them required techniques.

As a core the JBC curriculum has what is needed, some syntax and some exercises, but it would involve a lot of work to get it ready for use by teachers who want to really teach programming and computational thinking.

I have said it before and I will say it again, teaching syntax is the easy part of teaching programming.  Teaching the computational thinking skills needed to make that syntax easy is the really hard part.


Flint’s perfect strategy on how to teach programming

June 6, 2017

Alfred Thompson had this link to a set of nice simple Python projects.  The projects are great ideas.  It is the implementation that I think is extremely poor.  “Instruct the students to input the following code:”.   Is there a worse line to use when teaching anything?  This is the universal approach to programming tutorials.  I admit I use a lot of online tutorials.  And I admit I am sometimes very lazy and tell the kids to just type in the code.  I also admit that this approach is almost worthless for any long-term retention of code or of understanding how to program.  (Hopefully there is a mountain of research to back that up but I am happy with my seat of the pants feel that 30 years of teaching programming has given me.)  Following tutorials is a great way to learn how to follow tutorials, and maybe get a little programming syntax on the way.  But for actually learning how to program, how to understand a programming language and how to learn to build a project or do a task from scratch I claim they are basically worthless.  Proving that might take a dissertation, or maybe just common sense.

This leads me to my present project.  I am working on Flint’s Perfect Strategy For Teaching Programming.  I figure if I stretch this out long enough I might get an EdD dissertation started just in case I develop a severe mental instability and decide to start an EdD.

Flint’s perfect strategy for teaching programming breaks down into some fundamental concepts.  Here are a few.  The rest are still in the warm and fuzzy stage.

  1. Programming is designing and defining before any code is typed.
  2. Programming is algorithm development, not trial and error, hit or miss or just luck.
  3. Programming class is a thinking class, not a typing class.
  4. Programming is knowing what you are going to do before you try to do it.
  5. Programming is not learning syntax, but you do have to learn syntax to program.
  6. Programming is 90% planning, 10% coding. But that coding seems to take 90% of your time.
  7. Programming is not language specific or even CS specific. (Big discussion here of transferable skills.)
  8. I figure there are fifty or sixty more. I will work on those.

Here is a rough example of Flint’s perfect strategy for teaching programming.

Have the kids close their laptops or put them in their backpacks.  If you are in a lab turn off the monitors or the computer.  If you do not do this they will not listen or think.  They want to hammer keys and not pay attention to your wisdom.  This is a simple program I just did with my freshmen to give them a very brief intro to Python.  This group of freshman had all programmed in some language before so a large amount of intro stuff was not needed.  The program assignment was: given the number of sides as an input, draw a regular polygon using turtle graphics.  We started with the concept of a biological turtle that draws on a piece of paper.  What skills do we need to teach this turtle?  We then looked at polygons, angles and side lengths.  Once they had the idea of a polygon completely understood, we looked at what it takes to draw something with a turtle.  Things like a turtle, a piece of paper, a pen, a distance and an angle.  We then sketch out the instructions that this biological turtle would need to know to draw the polygon.  Right turn, left turn, forward and so on.  Once all the design stuff is done we start discussing what Python might need to do this.  What a library is all about.  That a graphics window is different from a text window or a Windows window.  We did a rough flow chart, some pseudo-code and how do you think a programming language might say these things. We still have not touched a keyboard.  We probably spent an hour before touching the keyboard even on this simple program.

Once they have done a couple of turtle projects the pre-keyboard work will shift more to the task definition and less on the needs of Python.

For this first program I actually built the program on the board for them, correct syntax and all.  I wanted to discuss variables types and dot notation.

We also discussed different types of loops.  It you want to loop through something 5 times, a loop that can count is the way to go.  Do not know how many times you are looping then we need a different type of loop.  We discuss these things non-syntactically.  This group of students was already familiar with For loops so we only had to look at the Python syntax for a For loop.

So they get the polygon program typed in.  They are happy.  They got to type.  I then up the ante.  Here is an addition to the task.   All the sides have to be random colors.  At this stage a tutorial would say “type this”.  We sit down without the computer again and talk about what we will need.  Random numbers, pen colors, how many colors do we want to deal with (2553?) or do we want just some favorites.  We talk about rgb colors and why 255.  We are now into decimal to binary conversions.  Some will know why 255 and how to do this but most will have forgotten.  Once we have talked about what we want to do I let them open their computers and have at it.  This time I give them no code.  They have the internet and they have Google.  Let me see what you can find.  I have given up worrying that they will copy some snippet from stackoverflow or the like and be done without understanding what the snippet does.  It is extremely rare that anything from stackoverflow is direct copy, paste and work.  It takes a while but they do eventually get the concept that the stackoverflow type websites give ideas on how to solve a coding problem.  They rarely give a solution.  Having small classes where I can actually see what they are doing and how they are getting there makes it fairly easy to monitor the cut-and-paste issue.

This example is very basic.  The focus is on design before code.  Programming projects like those mentioned are excellent for this teaching strategy.  I do the Shakespeare Insults project.  There are so many decisions to make before a computer is even looked at in this project that it makes an excellent project to build.    My data file is different from the one in the example.  My file consists of about 30 lines, each with three words separated by commas.  The program randomly selects two words and plugs them into a sentence involving someone’s mother and sister.  One early decision the kids have to make is are the words from two different random lines or just two random words from one random three word line.  How will the decision affect the program flow?  Excellent time for a flow chart.  The amount of pre-keyboard work with this program can be extensive.  I have seen this program coded in three very different ways so it can be a lot of fun.

There is a drawback to Flint’s perfect strategy for teaching programming.  It takes time.  Lots of time.  This polygon program can be described and typed in minutes.  We took over an hour.  Some of that extra time was because this is their first encounter with Python but all of these freshmen had done some programming so they understood most of the programming concepts.  Another drawback to Flint’s perfect strategy for teaching programming is the kids are very resistant to the approach.  They do not want to plan, they what to do trial and error at the keyboard.  They have not learned an important axiom of programming: “three hours of trial and error coding will save fifteen minutes of planning”.  (I wish I knew who came up with that.  They deserve an award.)  The kids want to hammer keys for an hour then complain how it does not work.  Run-time errors forever.

Another issue with Flint’s perfect strategy for teaching programming is that it is a lot of work for the teacher.  It does not lend itself to large coding projects so it is necessary to have a bunch of small projects that will target the lesson of the day.  The large projects often take more planning than the average kid will tolerate.  If the project can be broken down into smaller modules then the planning stage is manageable.  For an intro course I prefer the small targeted projects.  There is also the grading.  Instead of just grading a program as the end product, it is now necessary to grade programming plans, pseudo-code, flow charts, maybe all written in hand.  Ugh.  The kids’ handwriting is worse than mine.

Flint’s perfect strategy for teaching programming is not original.  I imagine many programming teachers use the same principle.  (A good example is Mike Zamansky’s blog on A* is Born.  Notice the focus on “we talk about” and “leads to a discussion” and the like.  Understanding is the principle.)   The problem is that many programming teachers do not understand what a good programming course should consist of.  Too many programming teachers think the purpose of a programming class is to have the students memorize syntax.  Memorizing syntax should never be the focus of a programming course.  I need to clarify to myself exactly (or at least as exactly as I ever get) what should be the focus of a programming course, write it all down and make a small fortune by publishing it.  By writing down random ideas I might actually come up with something that will make sense, at least to me.  The rest of you are on your own for that perfect strategy for teaching programming, at least until I get that EdD and publish.

Of course this whole conversation can lead back to a discussion of the lack of pre-service and in-service pedagogical training for CS and programming teachers.  Kind of a weird real life recursive loop.



Microsoft: A love/hate relationship

June 1, 2017

We are a Microsoft Windows 10 school.  We have a math lab of Macs because of the calculus software the teacher uses, and the elementary school has a scad of Chromebooks for the little kids, but we are primarily Windows 10.  This means I have developed a strong love/hate relationship with Windows.  Here is my latest hate.  We bought 30 Lenovo Windows 10 Pro laptops.  Nice little things perfect for the classroom.  We also bought 30 Lenovo Chromebooks for the little kids.  It takes me about 5 minutes to get a Chromebook from me to the teacher ready to use (not counting the time to carry it to the classroom).  Four and a half minutes to get it out of the box and thirty seconds to make sure it turns on.  The Windows 10 laptops are more like 30 minutes per device.  The problem is all the bloatware and crapware that Microsoft puts on their machines.  Here is an example.  The school owns Office 2016 so I want to install it on the laptops.  No big deal.  I am installing wanted software so I do not count this as wasted time.  The issue is that the Office 365 that is pre-installed will not delete completely.  The splash page wanting you to buy still pops up after the uninstall.  The solution?  Edit the registry in two places.  On 30 laptops.  OMG.  Then there is all the other “crap” I do not want on the laptop; games, Xbox, Minecraft and so on.  I tried building an image of a “clean” laptop but my free imaging software will not work on these.  Too much is locked down.

The kids are starting to use Google Docs more and more.  Other schools in Montana are starting to bail on Microsoft for pretty much the same reason, just a pain to setup and manage.  Chromebooks have large limitations, especially for programming, so they can never take over completely in a school but I am looking harder and harder at Chromebooks.

Python editors: Simple wins

May 25, 2017

I am working on next year’s courses already.  Programming is an elective so I have to sell the course to the students.  I want something ready now to convince them to sign up.  I have six freshmen and one sophomore coming up but I want some upper classmen to jump in.  I need to find some Juniors and some more Sophomores that are looking at STEM for college and would therefore be good candidates for a Python course.  I teach a dual-credit Python course and the college credit is only available to Juniors and Seniors.  I do not offer Python to Freshmen and Sophomores for that reason.  Many of these Juniors and Seniors will be first time programmers so I need things to initially go smoothly.  Things like having the installation instructions for Python and the IDE of choice laid out.  The Python IDE or editor of choice also has to be simple enough to be easy to use for a beginner but not so limited that it restricts what we want to do.  My programming courses are BYOD so whatever editor I use has to work on whatever is carried through the door.  Even a Mac.  So the digging begins.

Previously I used PyScripter with Python 3.4.  Python is now 3.6 (or 2.7 depending on the version you want to go with) and PyScripter has not been updated to work with newer versions, and it looks like it is not going to be updated.  (This is a major issue with free stuff.  Updates can be few and far between.)  So I was off to Googleland looking for something new. It has to be simple to use, simple to install and/or set up and free.  Right now I am just Googling and trying editors.  How many are there?  Lots and lots (just Google “Python editor”) but that simple to setup criterion can be a killer.  It killed Eclipse right off the bat.  Sublime Text 3 went down in flames. Visual Studio was not bad if you found the right website that gave the correct instructions.  I did and it worked but it sort of misses the simple to use thing.  File management with VS is a bit of a pain.  Visual Studio Code (a simplified version of VS) does not seem to do anything when I run my simple little draw a polygon test program.  It fails the simple to use test.  I tinkered with IDLE for a while.  It is nice that it is the native Python editor but I am lazy and like the auto complete feature other editors have built in.  Supposedly IDLE has autocomplete (I have the feature turned on) but it seems to have a minor issue, it does not work.  Things that do not work are bad.  I try not to use bad things in my classes.  It seems to frustrate the students.  PyCharm.  Easy to install, has a little green arrow to run the code, console is there by default, not a large number of never to be looked at options, autocomplete works, simple as a brick.  Folks, I think we have a winner.  Of course PyCharm sort of cheats.  It was written to be an editor for Python exclusively.  The other editors I looked at (other than IDLE) are multi-language so of course there are going to be setup issues.  I want something that is initially brick simple.  A professional programmer is maybe going to want more features than PyCharm offers but we are not professional programmers.  Brick simple wins.

When teaching beginners the more distractions, frustrations or simple confusion the uglier it can get.  Frustrate new programmers early and they are pretty much done for the semester.  If their first experience is a messy setup with an editor then there is going to be trouble.

The same can be said about beginning programming teachers.  I help teachers that have no programming background.  They have been asked to get a CS/programming curriculum started in their school.  That first language/IDE/editor has to be brick simple.  Eventually that beginning teacher has to leave Scratch and Small Basic to step up to a college level language.  Python with a good simple editor is an obvious step.

Daughter Graduates: Good and Bad

May 15, 2017

My daughter graduated from the University of Montana Saturday with a BA in Psychology.  Yesterday she was only five years old.  What happened?  She is not really sure where she is going from here but it really does not bother me.  She has a couple of retail jobs and wants to take some time to think.  She knows to go anywhere in psychology she has to get the doctorate.  She is looking at forensic psychology which means leaving Missoula.  Now that does bother me.  She was only five yesterday.

Teaching Programming with BYOD

May 10, 2017

Bring Your Own Device.  It is a solution and it is a problem.  All my programming classes are BYOD.  I have loaner laptops for those that cannot afford a laptop but that really is not much different from BYOD.

Why BYOD?  Many reasons.  The school has two computer labs.  One is in a classroom so it is out.  The main school lab is pretty sterile, computers in rows elbow to elbow.  Just not what I would consider an atmosphere for thought and exploration.  It is also used regularly so putting a programming class in there is going to be a pain for other teachers.  I used to have computers lining the walls of the room in which I teach.  I would install all the software and have things pretty cookbook.  But then I had problems with privileges when the kids wanted a sprite, needed to save locally, saving on Google Drive and half a dozen other issues because the kids were not administrators.  I wanted the kids to learn how to download and install the software they were using.  Getting Python up and running with an editor is not always a trivial exercise.  The kids should know how to troubleshoot an install.  BYOD allows those that want to work at home to do so.  Admittedly I do not get a large number of those students but there are enough to justify the BYOD hassle.  Perhaps the biggest reason for BYOD is I want the kids to know about their device.  The kids can run apps, download from Steam and get Netflix to work but changing resolution, hooking up a second monitor in extended display and installing a Google Drive folder are not tasks the techno generation seem familiar with.  So BYOD it is.

A big advantage of BYOD is the kids that own their own laptop (most of them) have a better device than anything the school owns.  There is just something about working on an i7 with 16 GB of RAM and a dedicated video processor that make a Python or Unity assignment run better than on one of the ten year old school loaner laptops or lab towers.  The only way I get to see really cool hardware is when a kids brings it in.  BYOD eliminates any administrator install issues (unless the computer has something like Network Nanny on it.  I had a long discussion with a parent over that one.)

The big disadvantage of BYOD is you are now dealing with five different brands, weird malware, fourteen viruses and a partridge in a pear tree.  I actually like dealing with all these issues.  At the beginning of the semester the kids learn all sorts of software and hardware issues.  Cool.  Another somewhat interesting disadvantage is the kids that are working on 11-inch computers.  My eyes do not see that small any more.  A Unity project on an 11-inch screen is just silly.  Then there is the kid with the Mac.  Kid, you are on your own.  If you want to borrow a PC I have some.  Even worse is the kid with the Chromebook.  It is always an interesting conversation with the parents about how that new, cheap Chromebook is not going to do the trick for anything we are going to do in my programming classes.  A sad, sad moment.

Some lessons learned:

  1. Teach file management. The kids keep forgetting where they save things or they scatter files everywhere.
  2. Stress saving to Google Drive or the like. Backpacks are rough on computers and I have had a couple kids kill their computers by not being careful.  Bad, very bad.
  3. They need a mouse. Trying to do something like Unity without a mouse is not practical.
  4. Bring the power cord every day.
  5. All sorts of things are on that BYOD laptop so watch them like a hawk.
  6. Expect weird issues so be flexible.
  7. Have some kind of central file storage area for assignments, YouTube videos and what not the kids can have access to. Something like Google Classroom or a Google shared folder.
  8. Have enough power outlets in the room. My school was built in 1922.  Electricity was a fad at the time.  The classrooms have two outlets.  I had to have maintenance run conduit and outlets around the room.  Laptops do not pull a lot of amperage so there is no problem with the breaker.
  9. The internet content filter is going to cause a problem. Be on a first name basis with the person that controls it.  In my case it is me.
  10. Read #6 again. Several times.

After several years of BYOD programming I would never do it any other way.  Yes, it can be a pain at times but the advantages for the student far outweigh that pain.

First programming language hoopla

May 8, 2017

The first language discussion is warming up again.  Universities seem to be abandoning Java for something else and the conversations start (see here and here).  Even the University of Montana is switching their intro CS major language from Java to Python.  The news folks and non-educators (professional programmers are always the best) start coming up with all these “great” suggestions as to what should be the first university level language.  If you read comments by the people that actually teach (two of which are the here and here above) they will pretty much agree that IT DOES NOT MATTER!!!  A good teacher who understands who he or she is teaching to can make almost any language do the trick.  Yes, there are better languages for teaching and some may be a bit too limited to really be a good first college level language but the number that would actually do the trick is pretty high.  I think I understand why UM is switching.  Montana suffers a major shortage of high school programming courses.  Most Montana schools offer nothing in the area of programming.  Incoming college kids looking at CS are coming in with little to no background in programming.  Stepping into a full blown Java course with that background is guaranteed to reduce the number of students looking at CS as a major.  I can still remember (admittedly vaguely) my first CS programming course in the early 90s (the FORTRAN in the early 70s does not count).  I sat down with about 100 college freshman.  By the end of the quarter there were maybe 25 of us left.  The instructor was one of the worst I have ever had in my long college experience.  He knew Java in and out but could not understand we did not know Java in and out.  The first programming language should not be intended to reduce the number of possible CS students.  It should be something tempting, interesting and an introduction to a possible future.  It should be taught by an instructor that understands how to teach, not a very smart CS adjunct that has no idea of how students learn.  Years ago I saw some statistics on the percentage of freshmen that change majors from CS after the first semester.  If that first programming course is intended to keep the shortage of CS majors steady, it is working well.

That first language really does not matter.  What does matter is the objective of the course, (rite of passage or introduction to CS) and the quality of the instructor.  If we want more students looking at CS we have to have a gentler introduction to CS than the usual “death by Java” type intro class.  I was a math adjunct at the University of Montana for ten years.  The math program had courses stating at the very bottom, about middle school math, so an incoming student had about four levels to step into depending on their math background.  Those bottom level courses would not give college credit but they prepared students with poor backgrounds for entrance to college math.  They were taught by middle school or high school teachers working on masters degrees or retired teachers.  CS needs a scheme like this to attract students and keep students (although the extreme shortage of CS teachers might be a bit of an issue).

As Mike Zamansky said in his post “There’s no single best universal answer. Each choice giveth and each choice taketh away.”  Remember, no matter what that intro language is, it will not be the language some employer the student interviews with is using.

Why teach game programming? Why not?

May 3, 2017

Next October I will be doing a presentation on my year of teaching game programming with Unity at the Montana Educators Association convention here in Missoula.  Being well aware that procrastination kills I started an outline of what I want to do.  After reading Dan Meyer’s post “How I Present” I figured I would not build the PowerPoint first.  I am sitting here doodling along making notes for my witty yet enlightening presentation when it hits me, why am I teaching game programming with Unity in the first place?  Not the Unity part, but the game programming part.  (I do this “why am I teaching blank” regularly.  I keeps life from getting boring and simple.)  The first line in my out line is “Why Game Programming”.  I really want to get a good answer to myself for that question and not just a “because it is fun”.  (Although that may be enough.)

I have been teaching game programming with some language for a long time now.  No great innovation there.  If there is a programming teacher in the world that has not used game programming as a fun incentive I would be very surprised.  Back in the mid 80’s I used Pascal and Apple BASIC.  The games were just the text based Dungeon & Dragons things (“Go North”) or simple Pong like things.  When Scratch came along all sorts of new games were possible and the sprites were of much higher quality.  Then smart phones started turning up in class and the kids were captivated by the games.  Some of them looked very easy in design so I looked for a programming app.  I found Corona.  I gave teaching Corona a try.  The course worked, sort of.  The programming required by Corona was a bit more than many of the students in the class were capable of.  The step from Scratch to Corona was simply too big, there was a level of complication in the IDE management, files, importing, event management and so on that I was not comfortable teaching.  (The drag-and-drop progression to line code discussion comes along here.)  I was simply too used to teaching with languages that were complete packages designed for teaching, like Scratch, Small Basic and Alice.  But, and this is a big “but”, the kids wanted to learn Corona programming.  They saw a goal that was cool, having an app on their phone that they wrote.  At the time I was still in the traditional mindset of teaching coding with the game as an incidental.  It was a programming course that ended up with a game as the final product.  Due to work load (school techie, two or three math courses and a couple of programming courses) I backed off on the gaming programming direction for a while.  My programming classes still wrote games in whatever flavor language we were using but they were not very fancy.  I dabbled in GameMaker but it just did not tickle my fancy.

About this time my programming class sizes started to drop.  What used to be 10-15 was looking like 4-5.  There is no two ways about it, programming is not easy and it can be as exciting as watching grass grow, especially if you are not a programming/computer geek.  I was low on geeks.  I wanted something that would attract the non-geeks of the school into taking programming and would possibly get them hooked into going farther in CS and programming.

Some kid showed me Microsoft’s Project Spark.  Oh my.  Oh my again.  I am thinking I may have to limit class sizes.  It was not really programming in the traditional coding sense but boy does it look like fun and I was trying increase the fun factor in my programming classes.  I was getting all set to roll on a semester of Project Spark when Microsoft killed it.  (I am still really, really sad about that.)  I had a scheme to get kids into my programming classes and with the demise of Project Spark I had a bit of a problem with my scheme.  Now what?  I had tinkered with Unity a year or two previously and found the tutorials wanting.  Desperate, I looked again.  I found better tutorials.  I found tutorials that did cool things in Unity.  I was back with the scheme.

That is the history.  Now for the “why teach game programming”.  It is very simple and can be stated in one word, “numbers”.  Numbers in seats.  As bad as it sounds numbers rule education.  If only two kids sign up for class the class disappears.  A program can disappear this way.  I needed numbers.  For an elective like programming to have numbers it has to be fun.  To be fun it has to be something the kids relate as fun, not what geeks who like to program relate as fun.  So game programming it is.  The trick was to not throw out the baby with the bath water.

Teaching game programming with Unity at the introductory coding level is really not teaching “programming”.  It is definitely teaching application use with a little code cutting and pasting.  My intent with Unity was to not teach programming but to teach the application and to have the kids see coding as an incidental.  I want to teach the kids how to learn.  They get to see the power of knowing how to code.  This is the applications side, kind of like in a math course.  The big math student question is always “How am I going to use this in real life.”  For programming here it is.  Yes, it is “black box” coding, just like “black box” math but it is also “here is a super cool thing you can do with code”.

Is teaching Unity a college prep course?  Not even close.  Is it an introduction to something cool that is going to temp kids to take the college prep courses?  I sure hope so but even if it does not bring them into my traditional Python programming classes it does get them seeing and thinking about code and the power of coding.

Skills.  By far the biggest skill the kids learn is following directions.  They watch YouTube tutorials, read text tutorials, listen to me give brief lectures, all involve following directions.  Does not sound to impressive does it?  The thing is if you can follow directions you can learn almost anything.  Of course I mess things up by making them build their own game by using the techniques they learned from the tutorials so the class is not just following directions.

Most of my programming students are not going into a programming or a CS career.  Teaching Unity, even if it is mostly cut and pasting code snippets, gives the students a look at big time programming.  Will they understand the code they were cut and pasting?  Not really but I think there is enough seepage that even the oblivious will come away with something.

Teaching an elective is a balancing game.  The elective has to be interesting enough to attract students but not so watered down that it does not justify its existence in the curriculum.  I really believe gaming programming with Unity is a viable option.  Kids that take it as an only CS course will get something worthwhile out of it.

Would it be possible to teach C# using Unity?  Maybe but learning Unity itself just takes so much time that to really get the full programming experience with C# would take a couple of years at least.  Would a C# course then a Unity course help with learning Unity?  The answer is of course but so much of the Unity C# code is Unity specific that the C# pre-course might not be a big enough advantage to justify the time.

I plan to hang with the Unity game programming (or some high level 3D game IDE) because it is fun, has a good amount of problem solving, has some coding, and requires the kids to follow directions closely.  My CS college bound kids will get a solid dose of Python their Junior or Senior year.  I will also keep the Java course alive.