Trust me! I’m a Computer Science Teacher!

July 23, 2009 at 1:21 pm 16 comments

U. Washington has a terrific Computer Science & Engineering Colloquium series available on iTunes.  I just finished a talk by Alan Borning on his UrbanSim project, which is (as he describes it) “Professional SimCity” which supports people making urban planning decisions.  He talks about the challenge of trust in that setting.  These are high-stakes decisions with complicated issues, trading off pollution with equitable land use with water needs with land values, and so on.  The project has moved from Java to Python, so that the models can be more easily inspectable and changed — he said modelers just didn’t like Java and hated declaring types in their models.  He said that their tools used to have a button to re-run the unit tests on the software, so that users could be assured that the basic software underlying the models was working as expected.  Nobody ever used it, so they removed the button.  People trusted the software, even though changes/mistakes there could have had much bigger impact on the end result than the models themselves.

Mike Hewner’s comment on my last blog post and Alan Borning’s talk have had me thinking about when students trust us, and when they don’t.  It’s not obvious to me when students trust us and when they don’t. I’ve two stories to share about trusting (or not) the computer science teacher.

Story 1: We trust you. Bill Leahy teaches CS2261 Media Device Architectures here at Georgia Tech.  This is our class on computer organization for students in our Computational Media degree program, which students find much more motivating than our traditional computer organization class.  Instead of working on a simulator of a pretend processor, CS2261 has students program a Nintendo Gameboy.  Same low-level focus, and even more complicated (since it’s a real computer), but more motivating, so it’s a real win.  Students tell us that they like programming for the Gameboy. Yet, they never do.

Bill shows them on the first day of class how he can write code for the Gameboy, compile it, download it to flash memory, and then boot it on the Gameboy.  Lo-and-behold, his game runs on the Gameboy.  To the best of Bill’s knowledge, no student has ever repeated that process!  None of them ask him how to get the flash card set-up, and nobody ever shows him their program running on their own Gameboy.  Amazing as it seems, it seems to be enough for the students to know that their code could run on the Gameboy.  During the course, they only use an emulator.  So, in a real sense, it’s exactly the same as the other course!  The authenticity of the course (that it really is about programming a Gameboy) is entirely based on trust and that one example on the first day.

Story 2: We don’t trust you. Soon after we started teaching Media Computation here, we started having requests for a second Media Computation course.  No, students didn’t want to take the next CS class — they explicitly wanted to do more in “Media Computation.”  So we built one, which focuses on how the wildebeests were animated stampeding in Disney’s The Lion King.  That was Disney’s first experience with computer-modeled characters in a crowd (herd) simulation. Explaining that scene requires us to cover all the basic data structures as well as continuous and discrete simulations.  The course has been well received with a 90% success rate — pretty good for a data structures course mostly serving non-CS majors.

Faculty in Industrial and Systems Engineering (ISyE) asked us if their students could take this course.  They wanted their ISyE students to learn some Java, and a focus on simulations is right in-line with how ISyE professionals use computing.  However, nobody told their students that.

At Georgia Tech, ISyE typically has the smallest Freshman class and the largest Senior class of the Engineering programs.  Students don’t know what it is coming in, and then they discover ISyE while here.  When they first discover it, they don’t necessarily know what it’s all about.  In particular, they don’t understand the relationship between ISyE and Computing is.

I have gobs of surveys with student comments like, “Boy, will I be glad when this class is over with, because then I’ll never use a computer again!” and “Why do I have to take this stuff?  Industrial engineers don’t ever program and hardly ever even use computers!”  Now, we do tell them otherwise.  They simply don’t believe us. Gregory Abowd, when he taught this course, got an ISyE faculty member to come in and tell the students, “Honest! I do use simulations! My research group does program!  You will, too!”  Do we have to do that every semester?  Maybe — the students certainly don’t trust us on this point.


Entry filed under: Uncategorized. Tags: , .

The Economics of Computing Education Media Computation update

16 Comments Add your own

  • 1. Peter Boothe  |  July 23, 2009 at 2:37 pm

    In the first example, the students are shown that something is true, and in the second they are told that something is true. In neither case do they necessarily trust the professor or anything other than their own eyes.

    Reply
  • 2. Mark Guzdial  |  July 23, 2009 at 3:04 pm

    Fair comment, Peter. Could Bill have faked the Gameboy example? How would you demonstrate to ISyE students that computing is relevant, if they only accept their own eyes? Why would they accept the word of a Professor (any professor, any domain) as knowing what their future jobs will be like? At some point, trust enters into it. How do we gain that trust for items like future careers where no evidence for their eyes can be gathered?

    Reply
    • 3. Peter Boothe  |  July 26, 2009 at 2:32 pm

      I think I would try and demonstrate relevance to the ISyE students by showing rather than telling. So, instead of having the professor shill for how relevant it is, have the professor present some accessible part of their research in which they clearly had to do computer science or computer programming to get the job done.

      Reply
      • 4. Mark Guzdial  |  July 26, 2009 at 2:35 pm

        Which is exactly what the ISyE professor did, Peter. Many of the students were convinced, just as you suggest. Others pushed back, saying things like, “That’s what the researchers do, that’s not daily practice.” (Not unlike CS students when they say, “That’s just the theory, and I’d rather have what professional programmers do.”) I think you do point out best practice, Peter. It just isn’t enough to convince those students who seek out a reason not to believe us.

        Reply
      • 5. Peter Boothe  |  July 26, 2009 at 2:42 pm

        All of which is to say that students, particularly straight-out-of-high-school freshman at a good school, have a lot of experience being lied to (small white lies and otherwise) by teachers. To overcome this barrier, we must show, rather than tell, because it is much harder to fake showing. Also, we encourage experimentation when we do this — and that’s perhaps the most important thing. By demonstrating that our assertions can be put to the test of actually being run on actual real-life situations, we encourage them to be computer *scientists* and to engage with the computer systems around them.

        Reply
        • 6. Mark Guzdial  |  July 26, 2009 at 3:21 pm

          Agreed, Peter! Developing warrants for claims is a really important thing for students to learn.

          Reply
  • 7. Alfred Thompson  |  July 23, 2009 at 4:15 pm

    One of the things I do when ever I get the chance to do is talk to students about computer science professions. It is a special treat to be able to look at their projects, especially their code, and comment on it. Invariably, without prompting, I tell them the same things they hear from their CS teacher. They know I work for Microsoft and that I spent years as a professional developer. The students look at me and then at the teacher in amazement. Perhaps the teacher knows what they are talking about after all!

    I see my role as a “swears by it.” The teacher has been telling the students but all too often they don’t really trust tt the teacher knows what they are talking about until some stranger from industry swears by it.

    Reply
  • 8. Alan Fekete  |  July 23, 2009 at 5:45 pm

    One of the most important things for us to remember when we teach or design a curriculum: students know that teachers lie to them (every teacher says “this course is important/relevant” “you can do this in the time available”, “this is exciting” etc)

    Reply
  • 9. Mike Lutz  |  July 23, 2009 at 6:19 pm

    I can’t resist my most memorable case of student lack of trust.

    We require students write a fair amount in our software engineering program. I grade not just for technical content but for organization, style, and even grammar and spelling.

    One student, who received a low grade on an assignment, argued that such a critique was unfair and irrelevant. When I told him he’d have to write plenty of documents when he went into industry, and that poor grammar and spelling would hurt him, he responded:

    When I’m in industry I’ll have a secretary to do all that for me.

    Reply
  • 10. Mark Miller  |  July 24, 2009 at 2:57 am

    Interesting about the Gameboy example. I had a hardware course in my freshman year of CS where we wired up chips on breadboards. This was in 1988. One of the things we were taught to do was to test our chips before we used them. Some students found out the hard way the reason why they needed to do this: chips would burn out, and their entire circuit wouldn’t work. I think this happened to me once. It was quite a lesson, because we’d get a zero for the lab even if it was totally wired up correctly. It had to work. Never mind if it was supposed to work.

    The next year the same course was being taught but they got rid of the breadboards and replaced them with simulator software students could run on PCs. I remember at the time thinking this was watering down the course, because it was setting up an expectation that didn’t square with reality: all chips will always work. I think the assumption was that in the near future breadboards would no longer be used for circuit design. Hardware engineers would design circuits on simulators, and once they were finalized the design from the simulator would be shipped to manufacturing. They would fabricate the design onto PC boards, handling quality control with their own testing process. So the assumption was that people like us didn’t need to touch the chips. I went into the software business so I never saw how this went with hardware design.

    @Mike Lutz:

    I agree with you that the student was dead wrong about getting a secretary to write the documentation. There are software architects whose sole job is to write up technical specs. They’re not secretaries. They meet with managers or customers and talk about requirements and design. Depending on the job role they’re in they may do no programming at all. In the IT work I’ve done as a software developer I’ve written specs myself precisely because there was no one else to do it. The thing is in most IT operations documentation is something that’s usually done by senior engineers, and even then it’s just to get things started. The documentation quickly gets out of date because no one has the time to update it. It’s something that would have to be budgeted into the project and as far as I’ve seen it’s hardly ever budgeted in, so the documentation doesn’t get updated, unless the customer explicitly requests it.

    I once gave this some thought years ago and I *wished* that there was a secretary who I could just do a “brain dump” with, and they could update the documentation for me. No place I’ve worked has had such an arrangement. I would be surprised if an IT operation had secretaries to update docs.

    Reply
  • 11. Ian Bogost  |  July 26, 2009 at 11:21 am

    On the Gameboy example, the “realness” of the platform is not just the ability to download a game that makes it real, but all the rest of the platform: its hardware architecture, the way one programs for that architecture, and the similarities of the resulting experience to a real game.

    Reply
  • 12. Mark Guzdial  |  July 26, 2009 at 12:45 pm

    I agree, Ian. What I find challenging to understand about Bill’s example is that that ‘realness’ had nothing to do with the physical hardware. The students never ran on the Gameboy platform. The simulation of that platform was “real enough.”

    Reply
  • 13. Ian Bogost  |  July 26, 2009 at 3:11 pm

    In some ways, this is a miraculous “free” lesson to get. A platform is, at its heart, an abstraction, not a physical thing.

    Reply
  • 14. Mark J. Nelson  |  July 30, 2009 at 3:33 am

    Separately from pure lack of trust, or suspicion that they’re being misled, I think a good number of students simply need to be convinced that any particular subject should be a priority. The amount of stuff “everyone” should know is frighteningly large! An informed member of society really needs to know the basics of macroeconomics, and good portions of microeconomics, not to mention political theory and history and ethics; a scientist whose work might impact humans should be particularly conversant in specialized areas of ethics; any scientist should be familiar with the philosophy of science and epistemology; probably everyone should have some idea of the roles communication and media play in societies and professions; many people are going to need to know how to write persuasive arguments, whether short-form memos or long-form essays; and so on.

    Even if a student really does believe programming is one of those “need to know” areas, they might not necessarily believe that it’s so far up the priority list to merit N hours/week of their attention, ahead of all those other need-to-know areas that get neglected in the meantime. Of course, the dirty secret is that, for any particular criticism of priorities in any curriculum, a student can probably find a dozen professors who agree with them!

    I personally sidestepped all that by being interested in computing via a “pull” rather than “push” sort of mechanism: I needed to do some things that were tedious to do manually, so I availed myself of the internet to figure out how to automate them (the killer-app of programming, for the highschool version of myself, was scripting in mIRC). A problem with formal education generally is that knowledge is usually pushed to possibly-skeptical students, rather than pulled by the students when they feel they need it, adding this strange meta problem of convincing them that they really ought to acquire information that they don’t actually want.

    Reply
  • 15. cheap computers  |  August 11, 2009 at 5:26 am

    I think they don’t necessarily know what it’s all about. In particular, they don’t understand the relationship between ISyE and Computing is.

    Reply
  • […] in Computer Science.  We have to figure out how to get these tools into use so that students see use of such tools as authentic and not a […]

    Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,003 other followers

Feeds

Recent Posts

Blog Stats

  • 1,875,123 hits
July 2009
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728293031  

CS Teaching Tips


%d bloggers like this: