Thoughts from Toronto on teaching code to librarians
January 29, 2014 at 1:49 am 26 comments
The blog post linked below felt close to home, though I measure it differently than lines of code. The base point is that we tend to start introductory programming courses assuming way more knowledge than is already there. My experience this semester is that we tend to expect students to gain more knowledge more quickly than they do (and maybe, than they can).
I’m teaching Python Media Computation this semester, on campus (for the first time in 7 years). As readers know, I’ve become fascinated with worked examples as a way of learning programming, so I’m using a lot of those in this class. In Ray Lister terms, I’m teaching program reading more than program writing. In Bloom’s taxonomy terms, I’m teaching comprehension before synthesis.
As is common in our large courses at Georgia Tech (I’m teaching in a lecture of 155 students, and there’s another parallel section of just over 100), the course is run by a group of undergraduate TA’s. Our head TA took the course, and has been TA-ing it for six semesters. The TA’s create all homeworks and quizzes. I get to critique (which I do), and they do respond reasonably. I realize that all the TA’s expect that the first thing to measure in programming is writing code. All the homeworks are programming from a blank sheet of paper. Even the first quiz is “Write a function to…”. The TA’s aren’t trying to be difficult. They’re doing as they were taught.
One of the big focal research areas in the new NSF STEM-C solicitation is “learning progressions.” Where can we reasonably expect students to start in learning computer science? How fast can we reasonably expect them to learn? What is a reasonable order of topics and events? We clearly need to learn a lot more about these to construct effective CS education.
I’m not going to articulate the next few orders of magnitude, both because they are not relevant to beginner or intermediate programmers, and because I’m climbing the 1K → 10K transition myself, so I’m not able to articulate it well. But they have to do with elegance, abstraction, performance, scalability, collaboration, best practices, code as craft.
The 3am realization is that many, many “introduction” to programming materials start at the 1 → 10 transition. But learners start at the 0 → 1 transition — and a 10-line program has the approachability of Everest at that point.
via thoughts from Toronto on teaching code to librarians.
Entry filed under: Uncategorized. Tags: computing education research, CS1, Media Computation, MediaComp, NSF, Python, STEM-C.
26 Comments Add your own
Leave a comment
Trackback this post | Subscribe to the comments via RSS Feed
Computing Ed Research - Guzdial's Take 
1.
Cecily Heiner | January 29, 2014 at 10:10 am
I think I agree that we tend to expect a lot of our intro student; on the other hand our student have pretty outrageous expectations of what they want to learn. On the second day of class I show them a slide of power point with about 10 lines of code and I say “Memorize this”. I see an amazing number of flashcards the first two weeks as students try to understand why I want them to memorize “Scanner input = new Scanner(System.in);” and why I haven’t told them all about the key word new and what it means and how it works(we do objects late). On the other hand, the students expect to learn a lot when they arrive in CS1. We were less than two weeks into class and multiple students have already asked me about final projects, working with pictures, etc— topics that are things we will not officially start thinking about for another month. I think officially the pre-requisite for the class is college algebra, but I have noticed that a lot of students get a huge advantage if they have taken extra math, have good English spelling/typing skills, have prior programming skills, etc.
2.
gasstationwithoutpumps | January 29, 2014 at 10:42 am
I’d hate to take a class where I was being expected to memorize unexplained nonsense—but Cecily is claiming that is precisely what she does in in her CS1 class. No wonder so many people see programming as an inscrutable field, if this is typical of the teaching techniques.
3.
Bonnie | January 29, 2014 at 3:53 pm
When we hit the Scanner input = new Scanner business, I have usually already been talking about variables – and I make a big song and dance about variables being boxes, places with an actual physical location. So when we hit that inscrutable line of code, I do go into a brief explanation, telling them that “input” is a special kind of variable called an object, it occupies memory just like every other variable and that they will learn more about them in a month or so, and this is the special syntax. I am very big on students being able to picture what is happening in memory, at least in an abstracted way, as they learn to program. That being said, there is some memorization because the students have to learn syntax – but probably less than in other fields.
4.
gasstationwithoutpumps | January 29, 2014 at 3:59 pm
One of the attractions of programming for me as a field is how little rote memory work is needed to do well. I never liked the “ritual magic” approach to teaching programming, where students are told to memorize incantations that they don’t understand (that was standard practice when I was learning to program—we were handed JCL decks to put in front of our program decks, and not even the instructors had any idea what the JCL was doing).
One reason for teaching python, rather than c++ or Java as a first programming language is that you have less need for starting people off with ritual magic.
5.
Bonnie | January 30, 2014 at 8:35 am
There are just too many downsides to teaching with an untyped language, IMHO. My students are really helped by compile-time checking.
My personal opinion is that the big problem with teaching in almost any programming language is the kitchen-sink-like nature of textbooks (which encourages instructors to take the same approach). Is there any reason why THREE kinds of loops need to be taught in the first programming class? I don’t see it. I teach them only the while loop, because it is most general. I would like a textbook that supports this slimmed-down approach, which concentrates on the concepts instead of an encyclopedic recital of every syntactic feature of programming language X.
Other examples of unnecessary (for CS1) syntax are constructs like ” num += y” or “x++”, as well as the switch or case statement. Why do all textbooks spend valuable time on every possible output formatting option?
In the end, I think the programming language is not as important as the crazy, detail-oriented way we teach it. Focus on a few constructs, and teach them to the point where the students really get them, and don’t worry whether they can format output 50 million ways.
6.
Mark Guzdial | January 30, 2014 at 8:55 am
Hear here! I strongly agree, Bonnie. (Well, about the myriad of details. I teach FOR instead of WHILE for the first 10 weeks because it’s easier according to studies from the 70’s/80’s, and I love to teach with Python. But that’s in the details 🙂
When we did the last revision of the MediaComp Python book, our publisher asked us if we’d update to Python 3. We couldn’t then (because of the state of Jython and media libraries for CPython), but we did the exercise of asking what we’d have to change. Only print. All the other changes in Python are at the levels of details that we don’t touch, for exactly Bonnie’s reasons. We don’t need to cover EVERYTHING in Python. It’s an introduction to computing and programming, not a tour of language features. If you teach CS1 to cover every feature, aren’t you ceding your curriculum design to the programming language designers? I don’t think it’s the same job at all.
7.
gasstationwithoutpumps | January 30, 2014 at 4:41 pm
I agree with you that teaching every option just leads to student confusion. Personally, I would teach the Python “for” loop rather than the “while” loop, as it gets used much more and produces more readable code.
Compile time type checking is valuable, but the amount of ritual magic needed to make it work for beginners seems to me too high a price to pay. Python is strongly typed, just not statically typed, and the run-time error messages are not too terrible (better than most c++ compiler error messages, anyway).
8.
Mark Guzdial | January 29, 2014 at 3:59 pm
Does it bothers others like it does me that our most popular introductory programming language in computing education requires us to do “a big song and dance”? I do it, too, Bonnie, when I have to teach things like
public static void main. But what a sorry state we’re in when our languages require us to say, “This will be useful and important to you one day. You’re really not ready to understand it all yet, so let me tell you a not-completely-true story…”9.
Peter Donaldson | January 29, 2014 at 8:32 pm
One of the features of python that doesn’t get a lot of attention is the clever way it allows you to use different abstraction mechanisms when you’re ready for them. If you want to get comfortable with basic imperative or functional programming before scaling the mountain to oop nirvana 😉 then python will keep all that syntax completely out of the way.
Pyret appears to be an interpreted functional language that shares some of that philosophy of sensible default behaviours and gradual complexity.
Ray Lister and his colleagues are certainly building up a strong set of emperical data on the relationship between tracing, code explaination and code writing. When you realise how important these Comprehensionskills are before you do a significant amount of writing it completely changes your view on why a lot of students don’t get the code writing process..
10.
Andromeda | January 30, 2014 at 7:24 pm
This *right here* was why Python was the first thing that made me think programming might actually be fun. I did intro CS in C++ in college, and I did quite well, but I found it unappealing — so much boilerplate I had to type for reasons I didn’t understand, so many times I had to interact with levels of abstraction that I simply didn’t have the background yet to understand. I dabbled in teaching myself some perl and PHP after college, and it was always terribly utilitarian and dull. And then I met Python and it was like, wait, I don’t have to type punctuation-filled crap that means nothing to me? I can just *write a thing that talks about what I mean, and the computer does it*?
Oh. Oh, I see. This is why people actually like doing this stuff.
11.
Bonnie | January 30, 2014 at 5:22 pm
Yes, but the while loop is the more general concept. I don’t really care that the for loop is “easier”. The for loop is only a good choice for counted loops. I care that my students completely and fully understand the idea of iteration in all situations. We explore loops that terminate by all kinds of conditions – the while loop is better for that. I also think the for loop has jumbled up syntax, and since my students need to walk through the logic of the loop line by line, the for loop becomes a bit confusing for them.
Towards the end of the semester, I show them the for loop and explain that it is a convenience, syntactic sugar for expressing counted loops.
12.
gasstationwithoutpumps | January 30, 2014 at 8:06 pm
The Python for loop is for iterating over any iterable (sets, lists, keys of dictionaries, ranges of integers, …) so is conceptually simpler than the low-level while loop, which requires a termination test and which has to completed with initialization and operations for advancing.
The while loop is a more general mechanism, but it is syntactic sugar for a goto and a conditional branch, which are more general still. I can see starting at the low level in a bottom-up computer engineering class, which teaches assembly language, then C, then higher levels of abstraction, but I don’t see the “while” loop as a sweet spot for initial instruction. (I may be prejudiced by having had a student in a grad course who still used while loops for all his loops—his code was damn near unreadable.)
13.
Cecily Heiner | January 29, 2014 at 9:22 pm
To be clear, I usually have less than 3 power point slides all semester that must be memorized, and I typically try to keep it down to 1 per course. My methods may sound crazy, but our retention is way up since I started teaching the class- our CS2 class enrollment has increased by about 40% since my students started taking it. In spite of being a small rural school, we also have an increasingly diverse program and we are doing an increasingly good job of closing the gap.
14.
Peter Donaldson | January 31, 2014 at 5:55 pm
I have to say that a finer grained approach based around basic elementary patterns helps to avoid the let’s teach you every kind of arithmetic expression, conditional and loop all in one go.
Although they only discuss some of the patterns they use, the papers by Orna Muller, Bruria Haberman and David Ginat have some interesting results on Pattern Orientated Instruction vs a traditional sequence. On a new code writing problem with no additional support 50% of the group either didn’t attempt to solve it or had no clear idea vs 16% in the POI group. 96% of POI students attempted to solve it vs 74% in the traditional group.
Gradually exposing novices to different patterns that they need to solve simple and then more complex problems really helps. If you then give them a name it also gives novices another a way to engage with comprehending larger complete example programs above the level of individual keywords and lines.
15.
Kathi Fisler | February 1, 2014 at 6:44 am
Thanks, Peter for pointing to the pattern-oriented programming work. I hadn’t seen that before (and still have to read through the papers closely).
The “How to Design Programs” work that we’ve done over the last 20 years was in this spirit of teaching few constructs and a systematic method for getting from problem statements to programs (through functional programming). Our typical CS1 gets to trees because the method and constructs we teach (recursion based) scale to these data structures naturally (in a way that loops do not). “No magic” wrt linguistic constructs or elements is one of our core principles.
You mentioned Pyret in an earlier comment. One of Pyret’s design goals is to create a language that addresses some of the bumps we’ve experienced teaching HtDP through Scheme/Racket, but that still supports the “no magic” philosophy and core pedagogy of HtDP’s data-driven program design. We’re starting to study various learning issues around HtDP with Pyret, including some long-overdue studies of the effectiveness of HtDP.
Kathi
16.
Peter Donaldson | February 1, 2014 at 4:33 pm
Hi Kathi,
HtDP and its spiritual offspring, bootstrap and picturing programs have been one of the clusters of alternative approaches where you really get the impression that a lot of deep thinking has gone into the design and underlying philosophy. I’ll be really interested to see what you and the team do with it curriculum wise. I’ve only had a brief look at it but it definitely appeared to a more approachable introduction to functional programming.
It’s interesting that you mention” no magic” in relation to HtDP because one of the key ideas we’re exploring in PLAN C is the importance of making sure students have a viable model of the mechanism that the code initiates. Juha Sorvas dissertation and papers on the notional machine really touch on why and how visualisation helps novices.
I can imagine some people reading this might think this is a very imperative orientated view but when you look at research examining the effect of techniques to make the execution of declarative programs visible they also improve novices comprehension and writing skills.
It genuinely feels like we have a lot more pieces of the puzzle about conceptual understanding in cs. What it might be and how we can develop it more effectively. It’s an exciting time.
17.
Mark Guzdial | February 1, 2014 at 4:42 pm
Peter, thanks for the lead on the pattern-orientated instruction. I hadn’t seen it yet, and I agree, that it looks really promising. They’re developing ways of thinking about composition that we never really got to with the goal-plan-code work with Elliot Soloway in the late 1980’s and early 1990’s.
I read Juha’s dissertation, too, and I came away with a sense that visualization helps sometimes, not everyone, not all the time. John Stasko’s work on algorithm visualization came to a similar kind of place — people liked it, but it was an additional symbol system that was sometimes hard to interpret. I do agree with the importance of conveying a notional machine. I wonder if (especially for younger children) you could convey a notional machine with some CS Unplugged kinds of activities. I’m wonder if the physicality of working through a notional machine might be more effective than watching a visualization — we know more about decoding physical actions than symbol systems.
18.
Kathi Fisler | February 2, 2014 at 4:41 pm
Hi Peter,
I wasn’t able to find an email address to write you directly. We have a lot of curricular material, and even more expertise doing teacher professional development (nearly 18 years worth!). If you want to chat about either the programs we have or just stuff we’ve learned, drop me a note (kfisler@cs.wpi.edu).
Kathi
19.
Peter Donaldson | February 1, 2014 at 5:55 pm
We’re introducing a very low tech system of tracing to our computing teacher’s that combines tracing the flow of control through a program with the data flow. The template has a very simple notional machine model so you can’t visualise more complex abstraction mechanisms with it yet but it does help with understanding various control structures and statements. I tend to think if you can get novice students to make the mechanism visible for themselves it really helps. The students annotate the code example themselves so everything is visible. From feedback we’ve had from teacher’s who have used it in their classrooms it also makes a great diagnostic tool as you can literally see students faulty mental models.
20.
Kathi Fisler | February 2, 2014 at 4:31 pm
I wonder whether students find such notational machines abstract or concrete (I’ve argued it to myself each way). The difference could affect whether the machine helps or adds undue cognitive burden.
This exchange has me thinking about the notational machine (if I’m using the term correctly) that underlies Bootstrap, but that we don’t usually expose to students: it’s basic model-view-controller, but each element in a students’ game has a position, and the functions that students write update the position of each element from one frame to the next.
That feels fairly concrete to me, in that students can see a connection between the current position of something in a frame/drawing window and the underlying “machine” that they are controlling. The machine only works for programs written in our infrastructure (which does go beyond games to mobile apps and other interactive programs).
We talk about teaching students to program in domain-specific languages, but rarely about teaching them domain-specific notational machines. I wonder what becomes easier/harder were we to do so.
Kathi
21.
Mark Guzdial | February 2, 2014 at 4:44 pm
Kathi, isn’t the notional machine underlying Bootstrap Scheme? Scheme’s notional machine is pretty easy for students to pick up — much clearer than Java’s. MVC, on the other hand, has a long history of being really hard for students to understand. Jack Carroll and Mary Beth Rosson did studies with IBM Smalltalk back in the 1980’s showing that even seasoned programmers didn’t understand MVC.
22.
Kathi Fisler | February 2, 2014 at 8:15 pm
Scheme is the notational machine for the functions that students write. However, the functions only yield a videogame by being applied repeatedly to the last positions in the model portion. It isn’t yet clear how much we need to explain to students about this process (the teachers often ask about it, so we do cover it in our PD workshops).
I haven’t seen the Carroll/Rosson studies on MVC, though Bootstrap’s versions are much simplified from the general case. Worth checking these studies out — thanks for the pointer.
23.
Mark Guzdial | February 3, 2014 at 8:04 pm
A couple of the other studies of student understandings (and misunderstandings) of MVC:
24.
Mark Guzdial | February 2, 2014 at 4:45 pm
“I tend to think if you can get novice students to make the mechanism visible for themselves it really helps. ” Sounds like a great experiment to run! I look forward to seeing the results!
25.
Peter Donaldson | February 3, 2014 at 4:53 am
It does, although we’ll need to think carefully about exactly what and how we want to measure the impact of pupil tracing in introductory programming on a larger scale.
By the beginning of May we’ll have around 45 lead teachers with a set of research evidence based techniques and new perspectives on teaching Computing. Through local groups these leads have the potential to reach another 300-500 computing teachers which is the vast majority of subject specialist teachers in Scotland.
If everything goes according to plan we’ll have a strongly connected network of 300-500 teachers that we can easily distribute new perspectives and techniques to through local hubs. We might also be able to conduct large scale experiments as long as they relate to our new cs qualifications.
The big question for us is what would you do if you had access to this kind of network?
26.
Raymond Lister | February 4, 2014 at 11:29 pm
Thank you, Mark, for the plug for my type of work in the original blog entry. Thanks also to Peter Donaldson, for mentioning my work with others on tracing, code explaination and code writing. I’ve been nagging people for years about that stuff, and sometimes it feels like nobody is listening, so it cheers me up to see you guys mention it.
In my recent work, I’ve developed a three stage model for how novices programmers progress:
In stage 1 (which I call sensorimotor) the novice programmer cannot reliably manually execute a piece of code and determine the final values in the variables (i.e., “trace” code). This inability has two causes. One cause is that novices may have misconceptions about how the notional machine works. Those sorts of misunderstandings were well documented in the 1980s. The second cause is that these novices may write down a trace in a poorly organized fashion, and just make a lot of errors. In my view, there isn’t much point in asking stage 1 students to write much code.
In stage 2 (which I call pre-operational) novices can trace code reliably, but they struggle to “see the forest for the trees”. That is, the novice struggles to understand how several lines of code work together to perform some computational process. When trying to understand a piece of code, such novices tend to use an inductive approach. That is, they may perform one or more traces with differing initial values, and make an educated guess based on the input/output behaviour. These novices also struggle to see the relationship between diagrams and code. When writing code, these novices tend to patch and repatch their code, on the basis of their results from tracing specific values
through their code. They cannot truly design a solution. In my view, stage 2 novices need to BOTH read and write code, but I don’t know what the ratio of reading to writing should be.
However, I suspect that the current pedagogic emphasis on writing code is too much writing for these students.
In stage 3 (which I call concrete operational) the novice is capable of deductive reasoning. That is, the novice can understand short pieces of code by simply reading the code, rather than tracing with specific values. When reading code, they can abstract from the code itself to reason in terms of a set of possible values that each variable may have. These novices can design code, at least for algorithms that can be easily visualized as diagrams. In my view, stage 3 novices (and only stage 3 novices) cope reasonably well with the current pedagogic emphasis on writing code .
If this stage model is of interest to anybody, then my most recent paper about it is:
Teague, D. and Lister, R. (2014). Longitudinal Think Aloud Study of a Novice Programmer. Sixteenth Australasian Computing Education Conference (ACE2014).
Click to access CRPITV148Teague.pdf
That whole 10 page longitudinal study may not be of interest, but the first 3 pages describe the overall ideas.
Mark wrote that he’d read Juha Sorva’s dissertation, and “came away with a sense that visualization helps sometimes, not everyone, not all the time. John Stasko’s work on algorithm visualization came to a similar kind of place — people liked it, but it was an additional symbol system that was sometimes hard to interpret”. I agree with all of that. Stage 1 students cannot use visualizations at all. Stage 3 students cope reasonably well with visualizations. Stage 2 students need to see visualizations if they are going to advance to stage 3, but stage 2 students struggle with visualizations.