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.

CS End of Year Summary

April 21, 2017

There are about six weeks of school left.  Four weeks for the seniors.  It is time to look back on the year and consider how things worked out.  This year I only taught one CS course, two sections of “Introduction to Game Programming”.  The course looked at Gamemaker and Unity.

I had three advanced students also look at Blender and Amazon Lumberyard.  The Lumberyard was just for them to make a quick comparison with Unity.  The three advanced students knew nothing more than the rest of the students in the classes about the various software, they were just into it a lot more so I separated them from the crowd and turned them loose.  This was a great decision.  Two (senior boys) of the three worked in tandem.  Incredible team.  The third was a quiet sophomore girl who is an uber-geek.  She worked by herself in the same small room (my office) as the two boys.  Although she did not work with the seniors she was not treated separately by them and did contribute to conversations.    Not a bad dynamic at all.  If I am able I will try to separate the dedicated from the not so dedicated in future classes.  I do realize it has to be done in such a way that it does not cause any tension.  In this case it worked out perfectly.

Prior to deciding to offer this course I knew nothing about Unity, Blender or Lumberyard.  I had dabbled in Gamemaker enough to understand the scheme but not enough to really be proficient.  Since my expertise was nonexistent, I knew this was going to be a course taught by on-line tutorials, YouTube and anything else I could round up.  It was not going to be a lecture course.  My programming course involve very little lecture anyway so no great change there.  The biggest issue for me was finding and previewing the tutorials and YouTube videos.  I have learned from previous errors to always work through the videos before presenting them to the class to use.  There is some bad stuff out there.

Initially I thought of this as being a programming course.  The more I and the kids got into it the more I realized it is less programming and more like a building course.  Using tutorials you do more typing code than learning code.  It is a lot of “type this and see what happens”.  It is possible to learn some coding this way but it is not to efficient.  It is easy to just cut and paste, with no attention paid to what you just cut and pasted.  I had to shift my “teach coding” mind set to “teach problem solving” mind set.  Of the seventeen kids in the course I would say about half got to the point where they could build what they wanted for a game from just looking on-line for solutions.  They could recognize coding errors and understand what the code was doing.  The other half can cut and paste.  Four cannot read directions or follow a simple video tutorial.  Experience with other classes tells me that overall that is really not bad.  The scary thing for me is that the seven freshmen in the course were only surpassed by my three advanced students.  I have to dream up cool and exciting programming and CS stuff for them for another three years.  eeek.

I do plan to continue offering this “Introduction to Game Programming” course.  It is a great way to get kids started with some fun building using cookbook coding.  It is my idea of a great introductory drug.  It is possible for those that want to work in the game writing field to take something like Unity and run with it.

I do not think the course can really be turned into a true programming course at this level.  The background required in C#, in particular the Unity specific code required from C#, is just more than we have time for.  There are also aspects of coding that just do not come into play with the Unity environment.  The idea of code for loops and iteration come to mind.  For a true coding class I will stick with Small Basic and Python.  I am not says a good coding class could not be made using Unity and C# but the time involved would likely be more than a high school student could commit.  Or a high school teacher.  To really teach programming with Unity the focus would have to change.  Right now everything is “Unity using C#”.  It would have to switch to “C# using Unity”.  Not quite as tempting or as catchy.

There is one huge drawback to teaching Unity.  It sucks time like a black hole.  You get this cool idea for a game and four hours later you come up for air.  I am really glad I did not set up a comfortable place to work on my computer at home.  I would never get out of the house.

Technology in the classroom: A warm and fuzzy worm

April 12, 2017

Larry Cuban has one of the best blogs for creating head scratching questions.  His posts on school reform and classroom practice always make me sit back and think.  His latest post on “Have Silicon Valley Teachers Using Technology Daily Altered Their Classroom Practice?” really has me sitting and thinking.  Larry posted some of his “Yes” and “No” replies to his study and they are interesting.  It seems a consistent thread that the changes the teachers made are in how the material is presented (electronic textbooks, electronic handouts, better access to resources) and not a change how the topic is structured.  (By “structured” I mean teaching the same math (or whatever) the same way, just with an electronic textbook and on-line resources.)

I also follow Dan Meyer’s blog on Math Education.  I do not always agree with Dan’s views on use of technology in the classroom, some of his ideas are a bit too tech intensive for my mind, sometimes the math would be lost in the many issues that can happen when trying to teach with tech,  but they are always food for thought.  What I like about Dan’s approach is that his ideas are not just a fancier way of presenting the same math.  He suggests completely different approaches of teaching a broad concept.  For example using a phone camera to record the flight of a basketball, then derive the formula for parabola as opposed to memorize the general forms of the parabolic function then find ways to use it.  His approach is often looking at a problem then developing the math.  An approach I am a big fan of.

From what I can see in my small little world of western Montana, and from my broader reading, education has not changed with the introduction of technology in the classroom.  Things like interactive boards, electronic textbooks, clickers, and so on do not seem to have changed how the teacher waves their hands at the front of the room.  Are these “presentation” technologies really improving on how much a student understands and retains when they walk out of the classroom at the end of the period or two years down the road?  Does a digital book really make a difference other than the weight if the student’s backpack?

There have been changes in classroom practice, which fits under the umbrella of teaching, with the use of paperless classrooms, video presentations (Khan Academy like or home grown), clickers, interactive boards, iPads, 1-1 laptops and so on.  It still seems to me that a teacher from fifty years ago could step into the modern classroom and still operate comfortably.  No, they could not operate all the tech presentation devices but with a whiteboard they could easily teach the curriculum.  I am not sure if this is a good thing or a bad thing.  It does seem strange to me that given the advances in tech we really have not changed the fundamental process of teaching most subjects.  The “sage on the stage” still seems to be the norm.  Is there nothing better?  I am not saying there is but with the years of education research with and without technology it just seems strange this is the preferred method for teaching. I know there are exceptions to the rule out there but those teachers that are exceptions seem to have developed their teaching methods independently through their own blood, sweat and tears.  Our student teachers are still coming in with the same fundamental teaching techniques I started with.

I remember the old saying “We teach how we are taught”.  Most of the present generation of teachers were not taught with technology and therefore use it as an add-on.  Presentation methods and maybe an easier way to hand out and collect homework are our concessions to technology.  Is this all tech in the classroom has to offer?

To really use the power of technology we would have to change how we measure learning success.  The present standardized tests would be worthless.  Using and teaching with technology assumes the student has access to said technology.  What would happen if a kid showed up at the ACT with a Chromebook in hand?  What a can of worms.  Now imagine the discussions out of the “let’s use technology to the fullest” approach.  Teachers would be up in arms immediately.  Math teachers would be making statements (and most make complete sense) such as: “Students should know how to do such and such by hand”, “Math is not a black box”, etc.  English teachers would have the plagiarism and file sharing issues to give them bad dreams.  Foreign language teachers would be out of a job.  Now let us bring in the economic issues.  Not every kid can afford a computer.  Not every school can afford to give out computers.  Staff training would be a nightmare.  All those standardized test companies would have to start from scratch.  Politicians would get involved and then things would turn into a real mess.

Somewhere in there is a dividing line as to how far we should go with tech in the schools.  In my math classes I assume a graphing calculator.  If they need the square root 3459 I assume they are going to use the calculator, i.e. the black box.  (When is the last time anyone found a square root using the long division looking algorithm? When is the last time you saw someone whip out a slide rule to compute a square root?  OK.  I admit it.  I have a slide rule in my brief case for these occasions but then I am old and weird.)  So the calculator is an approved technology.  How about WolframAlpha?  Not so much.  “It is the devils tool and will corrupt the minds of our youth.”  Or something to that effect.  I show my students WolframAlpha on day two of class.  If I want them to know the factors of some ugly polynomial, WolframAlpha it is.  I do not want my students wasting their time.  I am more into the “here is why we want the factors” and even that is getting a bit dated.

“Technology in the classroom” is such a warm and fuzzy at the moment.  Technology for enhancing teacher presentation and communication is expanding and is an accepted use of technology.  Since the graphing calculator was accepted, (we are still having issues with the algebraic computation calculators) students using technology to actually solve problems has sort of hit a brick wall.  Deploying the total power of technology to the classroom is right back to that can of worms.

I do have a solution to tech in the classroom.  Introduce whatever you are comfortable with and then hope for the best.  Hey, I did not claim it was a good solution.  I rarely get any of those.