A week of in-service: Another Python course

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

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 (255³?) 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

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.