Month: June 2019

Planning Ahead is Hard

I find that planning for much farther out than a week is not a good use of time. Not that I don’t have a general idea of what we’ll be doing. I mean planning in detail. More often than not, I throw out my “well planned” lesson the day or two before we’re going to do it because I think of something better. This results in some on the fly teaching, which, as Mike Zamansky pointed out in this blog post has some value for students. I generally agree with Mike’s assessment of the situation, and I’ll add this: planning is not the same as scripting. Generally I have a topic in mind for the day and I go about teaching it as I see fit (at that moment). Sometimes the examples I use will differ from class to class. This more often than not occurs because the students have different interests and, once I get to know them, I try to cater my examples to them. That only applies to direct (group) teaching though, not necessarily to assignments.

As soon as possible, I like to get students making stuff. Whether it be a program to help them with their Algebra class, a study tool for history or science vocabulary, a hangman game, a choose your own adventure game, etc. I find they are much more engaged when they’re making something they value. Since there tend to be multiple ways of creating working solutions for a project, working out a single solution ahead of time is often not as helpful. I do, at first, give them small chunks of starter code. Sometimes this code comes from me working out a program, then deleting the main chunks. Other times, it’s just to get their brains going and I haven’t necessarily figured out all of the inner workings yet.

I agree that working out problems before assigning them allows the teacher to know ahead of time what difficulties students may have and how to address those difficulties. Another advantage to working problems ahead of time is it gives me a chance to make sure the problems aren’t too hard, or go too far off-track from the objective. It also gives me a little bit of time to figure out how to extend the problems for my more advanced students who enjoy the extra challenge.

The downside to this of course is students think that I know everything and this stuff should be easy. I also have a really hard time resisting the temptation to help them by just telling them what to do (especially later in the day).

Also, by having prepared solutions, they don’t see me pounding my head on the table trying to figure out what is wrong with my code. They don’t see my missing colon, missed indentation, misspelled variable names, missing return statements, etc. They see a finished product that took problem solving and hard work, but they don’t actually see me working hard. I don’t think they believe me either when I tell them how much effort I put into my solutions. 🙂

While knowing potential pitfalls students are going to run into, I find that proactively pointing these out is generally a waste of time. The students have to encounter the problem before they are listening for a solution. I don’t know how many times I have warned the class up front about a particularly tricky problem (and how they might go about handling it) to just have them ask me 5 minutes later anyway, “What did you say?” In fact, when they run into a problem, I really want them using their resources (Python/Java documentation, Google, Stack Exchange, a classmate, etc.) before they ask me anyway.

I started this blog post with a very different idea of topic in mind. I am currently working on rewriting my CS 1 curriculum (if you could call it that, more like a collection of small projects and problem sets with some Google Slides and Youtube videos). I’ve been inspired by the 100 Days of Web in Python tutorials that I’ve been working through (just wrapped up day 21). I would love to create something similar for my classroom. Where each day is carefully planned out and chunked in a logical way. In my experience, most students have a different work ethic than professional programmers, hobbyists, etc. that would be taking this course along with me. As a result, my course would need to be structured differently and would need to include things besides just programming in Python.

That being said, I have a ton of ideas, but given my difficulty planning more than a week out, it’s hard for me to really flush them out. I now have two full years of teaching Python under my belt, and while I think I’m getting the hang of things for the most part, I’m still struggling with a few things:

  • Sequencing: what should I start with? how far should we go? Last year, I started with Turtle graphics and the kids did really well. This year, I’m considering going back to ASCII art and printing/inputting text before introducing the Turtle. By the end of the 2nd semester, students have used OOP to build a basic “Tron” style 2 player game using the Turtle module.
  • Homework submission: While not really directly related to the curriculum, I need to have some idea of how students will be turning in the assignments. I still don’t have a good system in place for students to submit their assignments. I have used Google classroom the past two years. The downside is, I have to have all of the assignments created in Google Classroom. Once I create them, they’re difficult to change if I need to (you have to edit each class individually after creation). I like the ability to give feedback within the system (not that the students read my feedback, but it’s nice to have it there nonetheless). I’m trying to create the curriculum on Github, and, while I guess I can link to the individual assignments, I would prefer a more integrated approach. I use Github Classroom with my 2nd year and AP classes, but I don’t want that kind of cognitive overhead in my intro course.
  • Getting everything in there and documenting it. I teach in Texas where we have K-12 standards for CS. The CS1 standards (called TEKS in Texas) are kind of all over the place. I need to figure out better ways of incorporating the non-programming parts of the standards into my class. We have talked about computing ethics, open source software, and the like just a little each of the past two years. I would really like to hit that a little more if we can. We used Linux in my classroom this year after the first semester, so we talked a little bit about operating systems, viruses, and security, but again not in much detail or depth. We did a brief foray into MakeCode/Javascript but did not discuss other programming languages beyond the (false)dichotomy of compiled/interpreted. I’m sure there are another handful of standards that we either barely touched on or left out all together.
  • Information delivery: what is the best medium to pass on information to students? Students tend to avoid reading carefully, like the plague. I really dislike full class teaching, especially when it comes to coding. I find that very few students can actually keep up when I live code. If I provide my code, then they just tune out, thinking they will be able to figure it out when I finally stop talking. I generally make short tutorial videos and put them on Youtube, but that is a problem when the school wifi decides to have a bad day. There are of course advantages and disadvantages to these ways of delivering content. Some combination is probably best.
  • Not getting bogged down: This is more about creating the curriculum than teaching it. I tend to overthink assignments, materials, videos, etc. at first. Do I start here, or there, or what about if we did that? It results in a paralysis of choice. I think I just need to start writing, and then worry about organizing later.

Of course all of this begs the question, why make my own stuff? I’m familiar with CodeHS (who are FINALLY switching to Python 3 this summer), Code.org, CodeCombat, etc. But for the past 13 years of teaching, I’ve always had more success making my own teaching materials than using someone else’s. I like the freedom it provides. While it is definitely time consuming, I find that I’m not able to deliver someone else’s lessons with the same gusto as my own. Maybe it’s just my imagination.

Honestly, I would be interested if anyone is familiar with an open-source project to build a high school computer science curriculum (lessons, activities, etc. not just a book) with Python as the language. I didn’t find anything after a few Google searches. I’m aware of the EDU-SIG resources at python.org, but many of the free resources on that page are either dead links or go to projects that are/have ended.

For now, I only have the first few days’ activities loosely planned (with solutions of course). Once I get a bit further, I plan on sharing with the world to anyone who wants to use it or contribute to it. But like I said, planning ahead is hard, so we’ll see how far I can get before the new school year is upon us.

How do you Google?

It used to be that if the teacher didn’t know something, and we couldn’t find it in the adopted textbook, there wasn’t much else to be done. I mean, you could go to the library, or try to find an article someplace, but it was difficult and time consuming and unless the question was extremely compelling, it just wasn’t worth the effort to us (the students). But times have changed…

In this day and age, teachers are no longer “Founts of Wisdom” as they once were; textbooks are not the only place for information on a subject (in fact, many classrooms don’t even use the adopted textbook anymore). Today’s students have more tools at their disposal for getting information. That being said, most students really only use one tool: Google.

Most of the time when students ask me a question, I answer with a question. One of my goals as a teacher is to foster independent learning. My usual go to is, “How could you find that out for yourself?” I want students to know how to find information on their own, and not rely on me to provide it. That’s not to say I don’t answer some of their questions. In particular, if there is a feature of the language that we are not fully taking advantage of to keep things simple, I will often just answer their question. When asked, students inevitably respond, “I can Google it.” With some topics, Google is pretty straight forward. But with technical things (like programming) students often aren’t sure what they should use as their search terms. They also have difficulty narrowing down or eliminating irrelevant information from the Google results.

Using Google (or any search engine for that matter) is a learned skill. I think most teachers are pretty good at it because we are used to searching for information by key word or concept, and then iterating on that search to hone down the results to what we think might be useful. However, we tend to take for granted that students will be able to effectively use Google to find what they’re looking for.

No one taught me how to use search engines. I was around in the bad old days of search engines like Lycos, Webcrawler, and Alta Vista. Using these search engines required using logical operators in order to get useful results. While Google has made searching much easier (generally Google is pretty good at guessing what you’re looking for), finding useful results for programming often requires multiple searches, with slight modifications in the searched words or phrase based on the returned results. This iterative process of searching requires some patience and the ability to determine relevancy of the search results quickly. When you’re new to a topic, that second point can be difficult. The best way to improve that is with practice and experience. These things take time but we often don’t give ample time to develop them.

I think this year, I’m going to spend a little bit of time (maybe a week before we get into programming) having students develop their “Googling” skills. I’m not 100% sure what that’s going to look like right now, but I came across this page with lesson plans from Google on improving search engine use. I haven’t had a chance to look closely at the lessons, but at a glance they seem promising.

What is your approach to teaching students to use search engines?

Block-Based vs Text-Based for my Intro CS Course (High School)

The past two years I have used Adafruit’s Circuit Playground Express in my CS1 classes. The students really enjoy working with them, and while there were a few hiccups this year (more about that in another post), I felt like it was time well spent and the students learn quite a bit.

The CPX is this really nifty all-in-one device that runs Circuitpython. It has built in touch sensors, buttons, a switch, speaker, temperature sensor, accelerometer, infrared sender/receiver, and LED lights called Neopixels. Check out the link above for more information, but needless to say it does a LOT of cool stuff. In addition to Circuitpython, it can also run Microsoft’s MakeCode. I really like the interface for MakeCode, and actually had the students play around on the website for a bit. I used it as an opportunity to talk about “block-based” languages. Keep in mind, this came at the end of the year, so the students had about 6 months of experience with Python.

I asked them to give list some advantages to the block-based language. All of the expected ones were there:

  • No concern for syntax errors
  • No need to remember commands or keywords
  • It was easy to see what was or wasn’t allowed because of the shape of the blocks
  • No need to go looking through documentation to find an available list of functions, just search through the pretty colored categories.

I then asked for any disadvantages:

  • Once you were familiar with the keywords or functions, it became tedious to use the drag-and-drop interface
  • They didn’t think they could add their own custom functions (which I showed them afterwards could be done pretty easily in the “advanced” section)
  • In line with the previous, they felt like the block-based coding was more restricted than text-based, but they could not articulate why they thought that
  • Removing or changing blocks is tedious; if there is a very small change necessary you often have to drag apart multiple groupings of blocks in order to make the change.

These issues were very similar to the complaints that my OnRamps classes had about Scratch, so no real surprises here.

I then asked which style of language they preferred. They unanimously agreed that while MakeCode might be easier for a beginner, they still preferred Python. This is understandable: they just spent 6 months learning a text-based language, of course they’re going to prefer what they are familiar with!

(I did show them how MakeCode would convert very nicely to Javascript. BUT since they aren’t familiar with Javascript, they did not see the advantage that brings. So our discussion focused on the block-based nature of MakeCode. I’m not comparing Python to MakeCode, but instead block-based to text-based.)

Finally, I asked them to put on their beginner hats for a moment and rewind time. I told them to go back to their August 2018 self, who doesn’t know any programming. Would that self have preferred the block-based language, even if just for a month to learn? Every one of them said “no”. They gave some interesting reasons for this (I am elaborating on their responses a bit, none of these are word for word what they said):

  • Starting with something more “difficult” when you don’t know any better is easier than starting easy and working your way to difficult.
    • My analogy for this one: Pretend you have two dumbells (weights), one is 5 lbs and one is 30 lbs. Which will seem more difficult:
      • Pick up the 30 lb weight, or
      • First pick up the 5 lb, THEN pick up the 30 lb
    • They all said the 2nd one would be more difficult since you will have a lighter weight to compare to the heavy one, whereas in the first instance, you won’t know any better and just kind of go with it.
    • By starting with Python (or text-based programming) they were just under the impression that this is programming. Without an “easier” thing to compare to, they just accepted it and struggled but weren’t complaining about wanting to do things the easier way.
  • They felt a greater sense of accomplishment using Python (text-based) than using MakeCode (block-based)
    • This one is interesting, but not terribly unexpected. Block-based languages seem like anyone can do them. While this is great from a recruitment perspective, it may have an unexpected downside. Think about it, if EVERYONE can do it, then when you have difficulty you must just not be good enough!
    • I would argue that programming, whether it be block-based or text-based, is difficult and requires a lot of hard work and thinking.
    • However, when the student struggles with Python (or another text-based language), they are fine with that, because it is “hard” (and looks hard). When they finally get the program working, they feel real pride for having overcome the challenge.
    • When that same student struggles with a block-based language (Scratch/MakeCode) they feel like they can’t do something that everyone else can do. When they finally get the program working, they don’t feel the same pride because they expected for it to work the first time!
  • “Real” programmers use text-based languages.
    • Not much to say here. I challenge you to find anyone in industry (not academia) using block-based languages for their daily jobs. In fact, if you find them I would be curious to know what they’re using and why. I’m always open to new ideas!

I took a vote from my classes asking if I should start CS1 next year with a block-based language instead of Python. Not a single student said they thought I should start with block-based programming. Now there is some selection bias here, I know. The students who might benefit most from starting with block-based dropped the class at the semester. This wasn’t a large number, but there were a few. However, I’m not convinced that those students would have stuck it out if I had used something like Scratch or MakeCode either. The students who dropped didn’t drop because of low grades (very few were failing). They dropped because they weren’t enjoying the class. I could probably argue that they weren’t enjoying it because it is “hard” and they didn’t want to exert the mental effort necessary to understand what we were doing, and if I were to use Scratch/MakeCode, it would be “easier” and would require less up front effort. I think they would eventually hit a wall though and not want to continue. Maybe it’s better they find out sooner rather than later that they don’t enjoy the subject?

While their feedback validated my thinking and some of my reasons for choosing Python for my CS1 classes, I can’t help but wonder what differences starting with Scratch would have on the class dynamic. Students would be able to get up and running with neat graphical applications much faster. They would be able to more easily share their products with family and friends. They can make cool (though probably very basic) games and applications very quickly. I wonder if that is the goal though. I mean, is computer science about instant gratification? In order to make any programs of substance, you have to have a lot of perseverance and persistence. Debugging code is a pretty useful skill that is mostly eschewed by block-based languages, if nothing else because you can’t really get syntax errors. Finally, Scratch and MakeCode often fail to reinforce the sequence of program execution; everything (seemingly) happens simultaneously. Async, threading, and multiprocessing are getting more and more common, but I can’t imagine starting off my programming journey without understanding flow of execution!

I do see how separating logic from syntax might be nice, but I think you lose something. I wonder how effective an English class would be if they used “block-based” languages. Where students could essentially drag and drop sentence stems together and just fill in a few blanks. While this strategy might be terrific for a younger audience, at some point (high school at the latest, I think) the student needs to be able to form their own thoughts into their own sentences into their own paragraphs. They need to remember how to spell some words. They need to remember some grammar rules (yes, I know they can always Google them when in doubt, but you have to remember some basics for sure!)

I think the same holds true for programming.