Friday, December 20, 2013

A demoralizing semester for instructors

DISCLAIMER: I believe most students don't cheat, most students don't try to make life miserable for their instructors, and most students really do want to learn and take responsibility for their own education.

That said, the fraction of students to whom this doesn't apply—those who do cheat, or have a sense of entitlement about the grade they "deserve", and when something goes wrong (including getting caught cheating or not getting the grade they "deserve"), it's everyone's fault but their own—seems to have hit a high point this semester.

I've been teaching as a faculty member for 13 years and as a GSI or assistant instructor for several years before that during my MS and PhD. I've never felt as down on teaching as I do at the end of this semester.

Colleague Dave Patterson and I co-taught our this semester.  Modulo a few bumps, it generally went smoothly, although there is the inevitable flurry of grade complaints at the end—some based on a simple misunderstanding of grading policy, but distressingly, some displaying a truly stunning sense of entitlement and lack of self-accountability.  One student was upset that their grade was affected because other students in their project team complained that s/he was a slacker.  This student was convinced that in other teams, "buddies" colluded to give each other high grades, whereas in her/his team things were different, resulting in an unfair disadvantage.  (The data didn't show this by any means, but the student hadn't seen the data, so apparently s/he was free to make assumptions about it.)  Another was wondering why we didn't move them up to a higher grade given that they were near a borderline (e.g. A-/B+).  I asked on what grounds they thought we should do that, and the answer was essentially that they were near the borderline.  If we assume that fairness means applying the same policies and considerations to all students, which I believe we have scrupulously done, the transitive closure of a policy that accommodates this student's request would result in most people getting an A.  And while that may be the case at Harvard, Berkeley is at least trying to hold the line on grade inflation.

But on balance, we got off light: our colleagues Randy Katz and Anthony Joseph discovered possibly-widespread cheating in their courses, and a Reddit thread allegedly containing (pseudonymous) remarks from students in his class about the incident is disturbing in that students justify cheating by blaming it on someone else:

  • It's the GSIs' (teaching assistants') fault for not policing us when they know cheating is happening.

  • It's the instructor's fault for not changing the projects enough since last semester.

  • It's the instructor's fault for making this course so much more difficult and time-consuming than its prerequisites.

  • It's the instructor's fault for not making the boundary between "collaboration" and "cheating" crystal-clear.

  • It's the Department's fault for enforcing a high GPA threshold to stay in the major.

  • (Variation:) It's the Department's fault for creating circumstances that cause people to cheat.

Are we running out of other people to blame yet?  Hell no:

  • It's the Internet's fault because why do the project if you can search for the answers online in just a few minutes?  (To the student who made this comment: your parents will be delighted to know that their tuition money and your four years at college are being so well spent.)

  • (Variation:) It's the fault of students who took the class last semester for making their code publicly available online.

No one has yet blamed Obama, Fox News, or global warming, but I suspect it won't be long before those are all implicated.

(And for those who are truly unable to determine if they themselves are merely collaborating or cheating, here is a good method: Does it feel like you're cheating?  If yes, then you are.)

Of course, everyone makes bad judgments at some point in their lives, so in the interest of making it a "teachable moment", Randy opened a voluntary amnesty period during which those who came forward voluntarily and admitted to cheating would less severely penalized than those who did not.  Amazingly, even this was considered controversial, with one student even reporting that a TA from another course had advised him, in a prisoner's-dilemma sort of way, to stay quiet and deny everything if confronted.  That sounds like the advice a lawyer might have given to Al Capone, and I'd be distressed if it was really true that one of our own TA's said this.

Never mind the fact that cheating is known to eventually screw the cheaters; the simple truth is that cheating is a choice that shows a lapse of personal integrity and a lack of self-accountability. Lack of integrity brought us Michael Milken, Enron, Bernie Madoff, and the malfeasance related to securities analyst fraud and mortgage-backed securities fraud that brought down Lehman Brothers, laid low JP Morgan, and plunged the country into its worst economic recession since the 1930s.  So, to the students who cheat and then try to justify it, when you carry your lack of integrity into the business world and end up on the witness stand, please don't reveal that you graduated from Berkeley—just plead the Fifth and spare us the shame.

On the other hand, I applaud the anonymous student who made this comment on the Reddit thread, and who appears to get it:

My grades in those classes could've been raised by getting other people's code, but I knew that cheating would only hurt my understanding of the concepts the projects were trying to teach.  All these people who are cheating are the type of people I absolutely hate working with at my job. They always do the bare minimum and then hope that someone else covers their asses. Cheating in college only sets you up for a slippery slope that's hard to avoid when you get into the real world.

Incidentally, I've known Randy since I was a graduate student in 1994—he was on my dissertation committee and we even co-taught a freshman seminar together—and I know firsthand that his skill and dedication as an instructor are as laudable as his numerous teaching awards would suggest.  Among other things, he's received the highest teaching honor the University can bestow and the highest distinction as an educator that the Institute of Electrical and Electronic Engineers can bestow.  When one of the Department's best instructors feels burned out and unenthusiastic about teaching because some students are unable to commit to a code of ethics that basically boils down to "don't lie", something's really wrong.

As always, my opinions are my own and don't necessarily represent those of UC Berkeley or the EECS Department or anyone else.

Monday, December 2, 2013

Rethinking the format of a software engineering textbook

Why did Dave Patterson and I decide in April 2011 to write a textbook for our “SaaS-flavored” CS169?  Aren’t there a ton of software engineering textbooks out there already?  And aren’t there a ton of practitioner-targeted books for teaching Rails, Agile, Cucumber, etc.?

Among the textbooks, precious few focus on Agile, mostly treating it as a side topic, but we think Agile is a great fit for the classroom—1 or 2 week iterations doing complete “mini-lifecycles” of a part of a software system.  The ones that teach Agile use Java (presumably because so many universities are ), whose viscosity outweighs the “lightweight process” advantage Agile is supposed to confer.  Our view is that learning a new language and tools is worthwhile  if it furthers the educational goal of teaching how to build long-lasting maintainable software with maximum productivity.   (I’m one of the contrarians who is still conflicted about the elimination of the Scheme version of the Abelson & Sussman SICP course, since Scheme is arguably the best language for doing what SICP tries to do.)

Also, despite the fact that the #1 request from our industrial colleagues was “teach students how to work with  legacy code,” most software engineering textbooks we looked at barely mention this topic, with a couple of notable exceptions that focus on using existing open-source software as a teaching vehicle.  (For the record, I think that’s a great idea, but not for our course: while OSS affords opportunities for teaching about legacy and refactoring, it often lives in ecosystems whose testing environments are less than delightful to use, e.g. C or C++ code.)

There’s hundreds of practitioner books on Agile, Rails, RSpec, Cucumber, Git, refactoring in Ruby, design patterns in Ruby & Rails, ad nauseam—and that’s the problem.  We probably perused over 10,000 pages of text in those books in preparing the material for our book.  There is no single narrative that weaves the topics together in a way that makes sense to engineers new to SaaS+Agile+Rails, puts them in the context of software engineering history and best practices, and does it in an amount of text that is realistic for undergrads to consume during a 10-15 week course.

Once we decided to write the book, the next easy decision was to focus on ebooks.  Ebooks aren’t the future of textbooks, they’re the present.  So we knew from day one that we needed an authoring environment that would allow us to derive multiple ebook formats plus a dead-tree version from the same source files.  (I’ll probably release this environment as open source once it’s cleaned up; it’s LaTeX, tex4ht, and a bunch of Ruby scripts.)

But since today’s ebooks are generally inferior versions of their printed counterparts, we came up with a whole list of enhancements for what we thought an ebook could be, inspired in part by Al Gore’s Our Choice ebook for the Apple iPad.  Many (but not all) of the features we want are likely to be present in the upcoming iBooks edition of our textbook.  And as I described in another post, ebooks can be updated frequently and errata corrections pushed out to students practically on-demand, and delivering an ebook to an international student is a lot less daunting than delivering physical books.

Ebook aside, though, it’s worth describing a few of the features that even transfer over to the print version, kind of, because I think we’re learning how books of all formats can be better integrated with online materials.

  • Every code example in the textbook, and many additional ones that are part of the lectures or the homeworks, are up on Pastebin.  So even students who doggedly refuse to learn an editor with syntax highlighting can see what they’re missing, plus Pastebin provides 1-click copy-and-paste so they can try the code themselves.  We created automation to keep the Pastebin links in sync with the URLs that appear in the book and ebook whenever the examples are updated and/or the book is revved.

  • Many book chapters include screencasts to show how to use specific tools.  Anyone can watch these for free on Vimeo(albeit out of context), and we’ll be doing an iBooks version of the book in which the screencasts are embedded right into the ebook.

  • There’s no glossary.  With Wikipedia, who needs one?  Instead, important terms in the book are linked to the corresponding Wikipedia entries.  (In the print book, they appear as URIs in the endnotes of each chapter, but in the Kindle book, the links are live as long as you’re connected to the Internet).

  • At the moment there’s no index.  This may be a hardship if you only own the print version, but the electronic version is searchable.  We anticipate it will be common for print book owners to also own the electronic version (though sadly there’s no way for us to bundle the two purchases, since the print book is created and distributed by the CreateSpace print-on-demand shop and the Kindle ebook is distributed by Amazon, which ironically owns CreateSpace).

  • Separately from term definitions via Wikipedia, the book includes various links to interesting news articles, YouTube videos, and other online materials related to the text.  If you’re reading the ebook on a device like the iPad or Kindle Fire, you can just click on the videos and watch them.  The print book has URIs that you have to type in manually.

So that’s what we’ve been doing and why.  The alpha edition, with some missing chapters, is now available (January 2012) at  By March there will be some minor revisions to it and by Fall we hope to have a beta edition that is content-complete.

Visiting UC Berkeley

Visiting UC Berkeley

Here’s some useful travel info if you’re a colleague visiting UC Berkeley.

Hotels within walking distance of campus: Avoids traffic and parking-pass hassles if walking is an option for you.  Here’s a Google Map of suggested hotels within walking distance, including reservations links and phone numbers, also showing the campus itself, the BART (rapid transit) station, and the locations of Soda Hall (Computer Science) and South Hall (School of Information or iSchool).

Hotels you can’t walk to: Next best is to stay within a short cab ride, bus ride, or BART (train) ride, rather than driving.  There are some big-box hotels in Emeryville (Crowne, Doubletree, etc.)

If Armando is hosting you, you can also email for additional hotel advice, and (important) for parking passes if you will be driving to campus (not recommended if you can avoid it).

Driving/GPS: aim for “corner of Hearst and LeRoy, Berkeley, CA”, which is the entrance to Soda Hall.  Pickup your parking pass from Room 565 Soda Hall from Roxana Infante or Tamille Johnson, who will direct you to the parking structures.

Getting here without a car from Oakland International Airport (OAK):

  • Taxi: $50-60; 30 minutes + up to 15 minutes extra if heavy traffic

  • Public transit:  $6;  45 minutes + some walking time.  From the terminal take the “AirBART” shuttle bus ($3) to the BART (rail) station.  Take a Richmond train and get off at Downtown Berkeley (20 minutes).  The Google map linked above shows the location of the Downtown Berkeley BART station in relation to the campus and hotels. Trains run every 15-20 minutes.

Getting here without a car from San Francisco International airport (SFO):

  • Taxi: $85-95; 40 minutes + up to 30 minutes extra if heavy traffic

  • Public transit: $8.80;  55 minutes + some walking time.  Inside the airport’s International terminal is the BART (rail) station.  Trains leave every 15-20 minutes.  Take train marked “San Francisco/Pittsburg/Bay Point” and transfer at 19th Street/Oakland for Richmond train to Downtown Berkeley.  These transfers are timed and should add zero latency to your trip.

Getting here without a car from downtown San Francisco (financial district, Union Square, etc.):

  • Public transit, $3.85: Have your concierge direct you to the nearest BART (rail) station and take a train for Richmond or Pittsburg/Bay Point, whichever arrives first. (After 7pm and on Sundays, the only choice is Pittsburg/Bay Point.)  The Richmond train goes directly to Downtown Berkeley station (on Google map above).  If you took a Bay Point train, transfer at 19th St. Oakland to a Richmond train.  Trains come every 7 minutes during working hours and every 15-20 minutes outside those hours.

  • Public transit, $4.00: If you’re staying very close to the Transbay Bus Terminal (Howard St. between Beale and Main), the “F” line leaves at :10 and :40 after the hour and drops you off right at the corner of Hearst and LeRoy across from Soda Hall.  In light traffic, this is comparable to BART travel time; in heavy traffic, BART is faster but you have to walk from the BART station to Soda or South Hall (~15 minutes).

Getting here from San Jose Intl. Airport (SJC):

SJC is far away, and public transit is possible but takes a really long time. If you’re flying to SJC, rent a car.  Be advised traffic is quite bad at nearly all hours of the day on I-880, the main freeway connecting Berkeley and San Jose.  Travel time is about 1 hour 10 minutes, plus up to 30 minutes extra if heavy traffic.

Book summary: A Thread Across the Ocean

A Thread Across the Ocean: The Heroic Story of the Transatlantic Cable by John Steele Gordon The most wonderful thing about the writ...