Thursday, May 5, 2016

What we learned in CS222, Spring 2016 edition

It's that time of year again, where I like to share a short retrospective on CS222. You may recall that I had thought about making some significant revisions to the course, particularly with respect to the trio of assignment, project, and achievement. In particular, I thought about incorporating student portfolios, but as I read more about this approach, I saw strong encouragements that students should be able to pick what goes into their portfolio. With the short, holiday-packed winter break, I didn't have time to really dig into the research on portfolio-based grading and integrate it into CS222. Summer is a more relaxed time for making this kind of structural change.

As always, I have several notes sketched out, in various places, about what went well and what didn't go well. I keep coming back to the idea of a more structured approach to project planning, particularly with respect to user stories. So many students do this badly, even after repeated feedback, and then have difficulty with their project for lack of concrete requirements. I really don't want to muddy the iterative approach by having additional items due in the middle of it, so maybe I need to structure the days leading up to the first iteration more carefully... but that might mean dropping or shortening the two-week project, which tends to be an important learning experience and turning point for students. Clearly, there are a lot of unknowns, and I need to spend some time thinking about it.

Without further ado, here's the student-generated list of what they learned in CS222 this semester, with the number of votes:
Clean code*24
Descriptive naming2
It's OK to start over4
CRC cards2
User stories8
Mode-view separation5
Team development*12
Pair programming 4
implementing libraries2
object vs data structure
code for the readers2
commenting best practices1
definition of OO9
functional programming1
stack overflow is KING
test coverage
test coverage exploitation
builder desing pattern1
observer design pattern
Drefus model of skill acquisition
game & mobile development
user-centered design2
dependencies on List
Scala (presentation)
quantum computing
AI efficacy
Acceptance testing2
critical components
intellectual property5
8am is troublesome ("sucks")3
classroom is awkward
walk on the left
BNL- not as good as in the past
IntelliJ is more featured than Eclipse
IntelliJ is better than Elipse2
Gradle is fragile
Github is complex2
Github is powerful
github has a steep learning curve
IntelliJ has a steep learning curve3
Finishing / shipping a project2
Time management3
Slack is great
Don't generate code you couldn't write1
Team communication is key5
Horizontal & vertical formatting
Egyptian vs K&R braces
DocumentBuilder (XML)
Package naming conventions
Unit testing4
Constant naming
Magic numbers
Essay reflections
Idea -> reality2
Don't procrastinate2
Critical thinking5
NPR is phasing out RSS
Making an app
Design thinking framework
Jar files
Managing scope1
Burndown chart
Technical debt
Timers are a pain
Compiler warnings1
Don't update mid-iteration
Network interfacing
UI design3
HBox & VBox
Scene Builder
Android Studio
Pizza makes apps
Adjusting sleep schedule
Open Source Licensing1
Dr. G dislikes textbook authors
Donut sticks -> no real wheat
RMS is eccentric
There is no silver bullet1
Studio 368 only has 4 CS majors
Caffeine is good3
Dr. G likes jazz
Ragtime is racist
They won't kick you out of RB1091
How to take constructive criticism1
How to give constructive criticism
Better to have compiler warnings than nothing at all
Working with unfamiliar APIs
Don't program alone3
Inner classes
Take breaks when coding
Review code in short segments
Commit frequently
Don't push broken code
Working in iterations
Sometimes you have to break code to fix it

The three marked with asterisks were the top three on which students could write their final reflective essays.

There are no real surprises here. It was an 8AM class, so I would have been surprised if this had not come up on the list. There are usually a few personal things about me on there; I know someone said "Dr. G. likes tea," which I did not actually write up. The Ragtime reference is from a discussion we had in class the morning after I had seen the musical for the first time, and---through what I remember to be a far-reaching discussion---brought the racist themes of both Ragtime-the-art and Ragtime-the-production into comparison with diversity in software development.

Git, GitHub, and IntelliJ came up frequently, although not with very strong weight. These are the tools that I myself only started using last summer, and sometimes they still trip me up. As I have mentioned before, I do think the switch to GitHub is worth the effort since it's such a popular tool: if we're going to deal with a real version control system, we may as well use one that also has cultural purchase and can land students internships and jobs.

I get more and more students taking on Android projects. Whether this is related to the similarity between Android Studio and IntelliJ, I cannot say, but it does complicate evaluation. I really don't know gradle besides the very basics, and I have no reason to learn it with my current projects, where Maven is working fine for me. I suppose it's OK, though, for students to see that I don't know everything, and I have to also poke around on Google and Stack Overflow when things go wrong. With all the different versions of IDEs and Android libraries, it tends to take longer to clone and build a project than it does to evaluate it.

That's it for CS222 this semester. I have around thirty essays to grade before I can really call it done, but those are pretty easy: they are student reflections, a final stab at tying their real, authentic experiences to the big essential questions of the course.

Someday, I should do something with all this "what we learned" data...

No comments:

Post a Comment