A Good Reminder

I have enjoyed the responses I got to my "Teaching CS IS Hard" post, thanks to links by some great CS ed colleagues out there. Can I say colleague as a noob? :)

The frustrations I have been feeling at trying to figure out how to do all my things better to help my students learn and improve have been rampant lately. I know I can still do some things differently here in the last six weeks of the school year, but I also know a lot of this will have to be put to thought, consideration, and much planning this summer. This school year isn't "lost" but it will feel like I'm just slugging it out and limping to the finish line.

So it was very refreshing to read Gina McCarley's blog post on AbstractingCS today, "Keep Your JOY, Know Your WHY, and DON'T BREAK THEM". It was a timely and needed reminder that the reason we do all of this is greater than all the little minutiae of the content. Here is the tail of her post, which sums it up quite well:

At this sometimes stressful time of year, my advice to you:

• Know from where your joy comes. No one can take it you have to give it away.
• During your battles, remember your WHY. I have shared my WHY, you need to know your WHY.  What keeps you going?
• And a big one, DON’T BREAK THEM (students) and MAKE THEM HATE COMPUTER SCIENCE! What we are teaching is foundational skills.  Big Ideas, algorithms, abstractions, syntax, protocol, and a lot of other stuff.  I bet there is a selection (IF/Else) statement in UT Austin’s cancer detection pen.  If you are from UT Austin, let me know. Our classes are stepping stones to bigger and better things.  Don’t let your students feel your stress trying to get everything in before the finish line.  Don’t make them hate Computer Science.  Do what you can as the clock clicks down to the exams. What you teach is important!

Remember your why, reflect, keep what’s good, fix what didn’t work and do even better next year.  The struggle is real but the rewards are worth it.  Running, walking, and sometimes crawling.

Quick Thought For The Ides Of March

So we start spring break next week, and today and tomorrow (we are on a block schedule) I'm having my CS Essentials classes look at the function/procedure event that handles the placing the wavefront numbers into the 2D array. They are looking at it ON PAPER. I am asking them to comment lines and mark it up in whatever way their brains are seeing this, so I can try and get a bead on how they might be thinking about code. This is something I think I need to work into my classes more - reading code and trying to make sense of it away from the computer. I think too many of my students just go through trial and error instead of going into deep thought about the algorithms in the code itself.

Teaching CS IS Hard

Well we have hit the wavefront algorithm assignment in my curriculum, which ultimately will be used to navigate our little VEX self driving vehicles. And for probably 90% of my students in CS Essentials, welcome to what my PLTW CS colleagues on the PLTW forums have termed "code shock" with students.

I think one of the hardest things to manage in designing a curriculum is how to dial the difficulty up at a proper pace for the "center mass" of the class skill level. And in this new curriculum from PLTW this particular unit starts out manageable, but suddenly shoots up rapidly, thus the "code shock" mentioned above. I also have the challenge of having a lot of kids in class who simply don't want to interact in class when, for instance, I'm working through pseudocode on the board.

The good thing for me is it has really illustrated how much more I need to emphasize getting the students off the computers, and crunching out the problem in flow charts or pseudocode. Many of them just want to do everything while in the code editor, and I keep telling them (and trying to show them as well) to solve the problem first, THEN translate your solution into code, and then get into the debugging process.

For my audience of few to several out there, I welcome any insight or input you might have!

Good Grief Have I Been This Busy?

Wow, it has been four months since my last post! I guess things got busier than I thought. In addition to the normal grind of teaching here is what has been filling my time:

• Finishing up the leading of a PLTW online training in their new CS Essentials curriculum
• The holidays (fa la la la la)
• The flu over break (blarf)
• Starting up a new semester at school
• Trying to get the CSTA Kansas chapter reboot up and running

I have been dutifully reading my favorite bloggers in CS education, and it is good to know that to one degree or another, it seems we contend with many of the same issues. For me, I have been wrestling with whether or not the PLTW CSP curriculum is the right fit for my students. We are a NMSI (National Math and Science Initiative) school, and with the grant that comes with that is a lot of training and support, which is great! In addition to me getting to go and work with colleagues three times a year, they send a person to my school on three Saturdays to help my AP students prepare for the AP exams and performance tasks. All great for their learning as well as mine.

What is becoming more clear to me, though, is the fact that the PLTW CSP curriculum, while quite good in and of itself, isn't really tailored towards the AP stuff as much as others. Yes, I know there are strong negative sentiments out there about the AP, but the reality for me is the fact that my school is highly committed to AP classes that fall under the NMSI flag, and considering the grant is well into six figures I understand why.

The guy who comes in here for the Saturday Study Sessions uses the code.org curriculum, and has used some of their materials for these sessions. I do use certain elements from the code.org CSP curriculum to fill the gaps I perceive in the PLTW CSP materials, and I do pull a few activities from other sources as well. What I am trying to figure out is whether or not using the code.org CSP as my primary curriculum would better prepare my students for our school's intended target, success on the AP. I would probably supplement the code.org version with programming in things outside of their JavaScript in Code Editor, most likely in Python and App Inventor, since those are the two things with which I have the most familiarity.

And of course, in addition to trying to build my programming skills in general, there is the never ending quest for best ways to teach CS. I'm looking forward to hopefully building up a stronger network of the CS teachers here in Kansas so that we can share and chat and work towards common goals in Kansas, and of course look very forward to going to CSTA in Omaha this summer.

Feels good to be back blogging again!

The Beginner's Garden Of Concepts

So I'm going to throw this out there to my colleagues with more miles down this road than I have. I'm wanting to craft up a "language agnostic" list of core concepts and key terms for computer science, mainly because I want to develop some kind of "mastery" checklist or scale scoring, reminiscent of what the typical kindergarten progress report looks like. You know, the ones that have a list of things like "can tie own shoes", "counts 1 to 10", and so on. I know this kind of list would look different and be more lengthy as a student progresses beyond beginner level, but I'm aiming for what the foundation should be, regardless of programming language or platform.

The items that pop to mind for me, in no particular order, are:

• inputs/outputs
• loops (for, while, chained, nested)
• conditionals
• Boolean logic
• variables
• abstraction
• algorithms
• decomposition
• procedures
• functions
• arguments
• lists

I'm sure I'm leaving something out of these concepts, and this list doesn't have the key terms that would be much longer I'm sure, but hopefully this is a start of a good "core". The one thing I think is tough for my Intro kids (mostly freshmen) is getting them to understand this isn't something that you just observe and memorize to regurgitate back - putting these concepts into use requires actual understanding and higher level thinking! Oh, those freshmen...

Interesting Notion About Starting With Block Based Programming

I was having a conversation with a CS teacher in a nearby district, one who has more years teaching CS than I, and someone I respect greatly. We were discussing the pros and cons of starting with block based programming, in this case, App Inventor in particular.

He mentioned how he at first was kind of dismissive of block based programming, because he didn't view it as "real" if you were having to tangle with the syntax and all the other hurdles of a text based language. But as he has actually used a block based platform for the first time this fall he said he was having some interesting thoughts, ones that will take a few years to find out the results, he said.

What he mentioned was he noticed that because his students WEREN'T getting mired in syntax, they were focusing on the structure of concepts themselves, such as how a conditional or loop is built. He also said that he always thinks of any new language in reference to the first one he learned, in his case C++ I believe.

Anyways, they were interesting thoughts that got me thinking too! I know the main purpose of the block based languages is to make a "lower floor" for entry, but this is a cognitive/pedagogical notion. I will be curious to see what he and I think in a few years!

Prepping For A Programming Contest

So on November 1st my AP students and I will be venturing to Kansas State University for their HSPC, which of course is High School Programming Contest. They have been putting this on since 1999, and my 12 AP kiddos are really looking forward to it, even though sometimes the practice on problems from the archives spooks some of them, especially the more novice kids. We are working up a problem solving workflow collectively so the ones who get more nervous have a guide to follow on steps. Oh, and they will be in four person teams, but only one computer per team. Still have to find out what the guidelines are on allowing resource materials and such.

Anyways, here is a recent practice problem. All three teams were able to pseudocode or flowchart the general algorithm OK, but only one was able to put it to code within the time limit. I work alone to try and solve the problems myself while they work, and I find the challenge of it quite fun.

2 Beginning — Probability
Below are the probabilities for desired outcomes for each six different football games:

Game number 0 1 2 3 4 5
Probability 0.5 0.4 0.6 0.75 0.3 0.83

Some combination of these outcomes must occur in order for a certain team to make the playoffs. Write a program that takes as input a nonnegative integer n giving the number of relevant games, then n different game numbers. It then outputs the probability that all n of these games have the desired outcome, assuming the above probabilities and that the games are independent. In order to compute this probability, you will need to multiply together all of the probabilities for the selected games (if no games are selected, the probability is 1). You may assume that 0 _ n _ 6 and that the n game numbers are all valid and distinct.

My team that solved it within the time limit created this. Aside from naming things a bit more descriptively, I thought they developed a pretty effective solution.

prob = [.5,.4,.6,.75,.3,.83]

def probcalc():
  gamenum = int(input("How many games?"))
  probag = 1
 
  if gamenum <= 0:
    print(1)
  else: 
    for i in range(gamenum):
      probag *= prob[int(input("Game Number:"))]
    print(probag)

probcalc()