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 (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.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: