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 |
| TDD* | 16 |
| SRP | 6 |
| DRY | 7 |
| Descriptive naming | 2 |
| It's OK to start over | 4 |
| CRC cards | 2 |
| SMART | 2 |
| User stories | 8 |
| Mode-view separation | 5 |
| Team development* | 12 |
| Pair programming | 4 |
| Red-Green-Refactor | 1 |
| git | 9 |
| enum | |
| dependencies | 2 |
| implementing libraries | 2 |
| object vs data structure | |
| code for the readers | 2 |
| parsers | |
| commenting best practices | 1 |
| definition of OO | 9 |
| bots | |
| functional programming | 1 |
| polymorphism | |
| encapsulation | 2 |
| inheritance | |
| abstraction | |
| stack overflow is KING | |
| scrum | 3 |
| agile | |
| android | |
| gradle | |
| test coverage | |
| test coverage exploitation | |
| multithreading | 2 |
| builder desing pattern | 1 |
| observer design pattern | |
| Drefus model of skill acquisition | |
| personas | |
| game & mobile development | |
| user-centered design | 2 |
| dependencies on List | |
| Scala (presentation) | |
| quantum computing | |
| AI efficacy | |
| prototyping | 3 |
| Acceptance testing | 2 |
| critical components | |
| intellectual property | 5 |
| 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 Elipse | 2 |
| Gradle is fragile | |
| Github is complex | 2 |
| Github is powerful | |
| github has a steep learning curve | |
| IntelliJ has a steep learning curve | 3 |
| Pitching | 1 |
| Finishing / shipping a project | 2 |
| Time management | 3 |
| Slack is great | |
| JavaFX | 3 |
| FXML | |
| Don't generate code you couldn't write | 1 |
| Team communication is key | 5 |
| Horizontal & vertical formatting | |
| Egyptian vs K&R braces | |
| DocumentBuilder (XML) | |
| Package naming conventions | |
| Unit testing | 4 |
| Constant naming | |
| Magic numbers | |
| Essay reflections | |
| Idea -> reality | 2 |
| Creativity | 3 |
| Don't procrastinate | 2 |
| Critical thinking | 5 |
| NPR is phasing out RSS | |
| Making an app | |
| Design thinking framework | |
| Jar files | |
| Managing scope | 1 |
| Burndown chart | |
| Technical debt | |
| Mocking | |
| Debugging | |
| Timers are a pain | |
| Compiler warnings | 1 |
| Don't update mid-iteration | |
| Network interfacing | |
| UI design | 3 |
| HBox & VBox | |
| Scene Builder | |
| Android Studio | |
| Dedication | 2 |
| Pizza makes apps | |
| Branching | 1 |
| Forking | |
| Adjusting sleep schedule | |
| Open Source Licensing | 1 |
| Dr. G dislikes textbook authors | |
| Donut sticks -> no real wheat | |
| RMS is eccentric | |
| There is no silver bullet | 1 |
| Studio 368 only has 4 CS majors | |
| Caffeine is good | 3 |
| Dr. G likes jazz | |
| Ragtime is racist | |
| They won't kick you out of RB109 | 1 |
| How to take constructive criticism | 1 |
| How to give constructive criticism | |
| Better to have compiler warnings than nothing at all | |
| Working with unfamiliar APIs | |
| Don't program alone | 3 |
| Controllers | 1 |
| 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...
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