Monthly Archives: November 2016

Keep it civil

Technology & Culture

Keep It Civil
=============

2016-11-22

by Richard White

Anyone who uses any kind of modern, social-media-related technology is aware of the kind of derision and scorn that can occur on the Internet. The awful GamerGate debacle is perhaps one of the worst and most serious examples, although trolling and flamewars can easily erupt from the most innocuous of situations.

As a professional, a teacher, and someone who likes to think of the Internet as being used mostly for good, and less for evil, I try to behave well, and part of that includes having a thick skin and/or erring on the side of forgiveness when it comes to things like comments on my YouTube channel.

Case in point: I recorded a brief video introduction to Free and Open-Source Software (FOSS) that I put up on YouTube a few months ago. In that video I discuss the FOSS operating system Linux, and mentioned in particular one particular distribution of Linux called “Ubuntu.”

Amidst the other nice comments people made on the video, there was this one:

Actually Ubuntu is not entirely a “free software”

“Is this guy kidding?” was my immediate response. “I spent a lot of time putting this video together, and he’s got the nerve to nit-pick about this? Ubuntu does bundle some proprietary software together with their distribution, so technically, he’s right. But, geez! That’s the thanks I get for all my work? Snarky comments picking it apart for minor points that practically nobody cares about anyway? Why, I ought to…”

I admit, that thought passed through my mind for a moment. But when I had the chance to think about it for two seconds, I realized that it might be me that was over-reacting. Certainly a more level-headed response was called for, and this is what I ended up replying to him in a follow-up:

That’s true! Although it’s a bit beyond the scope of this introductory video, none of the common Linux distributions comply with the Free Software Foundation’s strict interpretation of FOSS. (If you’re interested in those details, you can read about them at https://www.gnu.org/distros/common-distros.html). For the majority of Linux users, however, we’re happy to support and use those GNU/Linux distributions anyway. :)

I wasn’t expecting a reply back. If this poster’s comments had been intended as trolling, I hadn’t taken the bait, and for a troll, where’s the fun in that? So imagine my surprise when a reply did come back:

Yep. Thanks for making this video :)

An acknowledgment of my point, a “thank you,” and a smiley face? That’s quite a turnaround from the original comment, consisting solely of a criticism.

I’ll never know what the original intention of the commenter was when he left that note for me. I do know that a non-reactionary reply from me—fair, factual, and cordial—evoked a response in kind.

And that’s the Internet world that I like to live in!

keep_it_civil

Teaching CS: Am I doing it right?

AP Computer Science, Computer Science, Teaching

Teaching CS: Am I doing it right?
=================================

by Richard White

2016-11-10

I’ve been teaching Computer Science in one way or another for a decent part of my teaching career, from courses using BASIC and Pascal on standalone PCs (pre-Internet!) back in the 80s to courses using Python and Java currently. I’d like to think I mostly know what I’m doing by this point.

It’s interesting to note, however, that there is a wide variation on how teachers work with students in a computer science classroom. From the AP Computer Science teaching community, I’ve heard of teachers who:

* have their students use Linux workstations exclusively
* have their students learn Java exclusively through graphics programming (Processing language)
* have their student use web-based Java compilers/interpreters
* have their students learn how to interact with a server
* have their students turn in all assignments on paper only
* have their students retrieve lessons and submit assignments using GitHub
* teach Java by having their student write mobile apps

It’s a stunning variety of strategies given that we’re all teaching the exact same course with the exact same curriculum.

And maybe that’s a strength of computer science, that there are lots of ways to make it happen. Whether you use Linux or OS X or Windows, whether you program using a terminal or an IDE, whether your programs interfaces are text-based or graphical… we’re all teaching computer science.

If there’s a downside to this variety, it’s that we may be tempted to feel that some of the other strategies–old ones that we haven’t had time to consider, or new ones that have just been recommended to us–might be better (more interesting? more effective? more appealing to students?) than what we’re currently doing. And so we feel compelled to give these new strategies some consideration.

In the last few years there has been an explosion of interest in Coding (which is not quite the same thing as Computer Science, but we’ll take what we can get, eh?). Hadi Partovi’s Hour of Code, MIT’s block-based Scratch language, the Raspberry Pi, the Arduino, the College Board’s new AP Computer Science Principles curriculum… and these are just the most popular of the recent technology and CS-based innovations that might merit some consideration by me, with an eye toward possibly incorporating some of them into my teaching toolbox.

How much should I stay the course and stick with what I think works best? How much of my limited professional time should I invest in consider these other possibilities?

More than teachers in any other subject area, we teachers of Computer Science need to wrestle with these questions. It’s a de facto part of our job description.

What is your specialty in teaching CS/technology? What topics do you add to your courses, because those topics work, or they’re part of your pre-existing skill set? Do you feel pressure to always be looking at The Next Big Thing?

For related reading: http://blog.acthompson.net/2016/11/too-many-cs-teaching-resources.html

The Poor Person’s Guide to Differentiated Instruction

Computer Science, Education reform, Staff Development, Teaching, Workflow

The Poor Person’s Guide to Differentiated Instruction
=====================================================

by Richard White

2016-10-28

I’m a classroom teacher, and I’m a busy man.

I prep lessons, I develop and coordinate assignments for my students, and post homework assignments on the school website. I collect work, set up labs, write, administer, and grade tests. I develop caring relationships with my students.

It’s the best job in the world… and I come home *exhausted* most days.

One of the many challenges we teachers face is providing learning opportunities that are appropriate for the level of our students. In classes with an especially wide range of abilities, these can become problematic, logistically speaking.

In my Computer Science classes I typically have at least three ability levels in the same class:

1. students who have already had some experience with programming, possibly in a different language, and who are able to accomplish most assignments very quickly.
2. students who may be new to programming, but who are making reasonable progress. They quickly learn that programming requires attention to detail, and they typically pick up patterns—syntactical, logistical, procedural—after one or two exposures.
3. students who struggle to recognize the patterns, or who find themselves more easily frustrated by the puzzles posed by programming assignments.

I’ve experimented with a few different strategies over the years. Here are three that I’ve tried that have met with some success.

1. Below the Fold Progression
In this type of differentiation, students are provided with a text file (usually online) that contains a statement of the problem at the very top of the file. The file itself is actually a working copy of the problem, with the initial problem statement written as a multi-line comment near the beginning of the file. Much farther down on the page, where students can’t easily see it without scrolling, is another multi-line comment containing a pseudocode analysis of the problem. And finally, much farther down again, is the solution code itself. Students who want to work out the program without any hints are free to do so, while students who need a bit of help from the pseudocode can look at that as needed. Students who need much more support may find themselves looking at the actual program for assistance, and that’s okay if that’s where they are in their own learning process.

Example: ch06ex03.py (Right-click or Ctrl-click to download)

2. Page 2 Solution
In this strategy, something similar to the “Below the Fold” method is used, but now, the problem statement and its solution are printed on paper to be distributed to the students. The front side of the paper has the problem statement, and a complete working version of the code is on the back side (page 2) of the same piece of paper. This has the advantage of giving the students a concrete document to scribble on, and giving the teacher some ability to see which side of the paper students are looking at as they work on the program.

Example: four_functions.py (PDF format, Right-click or Ctrl-click to download)

3. Progressive Lecture
The final strategy is much more interactive. Students are assigned a problem in class and instructed to begin developing a solution. At the front of the room, after some reasonable amount of time has passed, the teacher begins writing out a rough outline of the program, perhaps with comments highlighting significant sections of code. Students who have developed their own solutions to the program will continue working on their own, while those who may be struggling to organize a solution will get some hints from what is written on the board.After a few more minutes have passed, the instructor may continue fleshing out the solution to the problem using the framework already developed. Students who still aren’t sure about some aspects of the program are free to ask questions as actual code is presented on the board.

Example: Differentiated Instruction (YouTube video)

Strategy 3 requires the most from me in the classroom. I’m moving around the room, actively monitoring students’ progress, and trying to determine the *decisive moment* (thank you, Henri Cartier-Bresson) when I should begin reaching out to assist students who need some additional guidance. Strategies 1 and 2 have the benefit of being delivered by computer or paper, with assistance immediately available to students when they decided they want to take advantage of it. The downside of those two strategies, of course, is that students do have access to solutions, and may be tempted to avail themselves of those materials before they’ve had a chance to wrestle with the material… and it’s in that wrestling that they really get to learn things.

As I say, I’ve used all three of these strategies on one occasion or another, and they work pretty well in Computer Science courses. I’ve adapted similar strategies to some of the science courses I teach.

As a teacher, do you use any of these strategies, or something similar? How do you reach out to the students of varying ability levels in your classroom?