Project Ideas

I’ve been banging my head against the wall for the past few days or probably more than a week now about what projects to give my students. Yesterday, I finally looked at past GIR instructors’ projects to see if I could gather any ideas, and one of the projects blew my mind.

It was for a text-based simplified Blackjack game, and the premise was actually not to write code but to read code already doing what it’s supposed to be doing. The caveat is: the code is a huge text file without any functions, and then there’s a better version where the code is using functions. The students’ task is to use that better version — to call the provided functions — to produce the same functionality as the existing no-functions code. I thought that was such a genius idea, because it incorporates reading code and refactoring, two very big parts of industry practice that students don’t usually get exposed to.

I decided to use that project for the above purpose, but it seemed like the assignment could be done over a week and I really wanted a project that’s more long-lasting. I had skimmed over past GIR instructors’ projects before and had taken some ideas, but the projects weren’t quite big enough. I’m probably biased though because at the university I went to, we had projects assigned three or four weeks before they were due, and I want that for my students as well.

Over the course of today with regard to the Blackjack game, I realized there’s a lot of potential for students to first produce the no-functions code themselves, then refactor repeating code into functions, and then finally use those functions to produce the final product. They’ll also write unit tests for the functions, and maybe integration tests. The tricky part about integration tests is that there’s a randomizer, but maybe I’ll just teach them how to give that randomizer the same number every time. I’ll also make them write comments in their code and style it according to Python styleguide, and I’m toying with the idea of them writing a design document post-fact, which is really just because I don’t talk about design docs until way later in class. Maybe I’ll get them to write a design doc before the refactor, I’m not sure.

I was thinking really hard about how to autograde all of this though, because I don’t want to grade anything by hand. I will give clear guidelines on how exactly the program will work, and so the no-functions code can be autograded that way. The next step which is getting students to point out which code parts are repetitive will be difficult to deal with if everyone’s code is different, and the idea I have right now is to release the code for what the no-functions code should look like for students to refactor. Also, I don’t want students to have incorrect no-functions and then be blocked on proceeding. I really don’t know how to grade the “what’s repeated and how should that be fixed?” question with an autograder.

For the next step after identifying the repeated code, I really want to give function names so I can autograde via unit tests for those functions, but I also want students to design those themselves, to call functions the right names, to style it correctly, and so on. I think there’s a lot of value in starting from scratch. Tradeoffs, I guess. Perhaps I’ll make that a group activity in lab or lecture for students to come up with a classroom solution. The problem with that is, the top students might just give all the answers.

After that, using the functions and again testing functionality should be fine. In fact, the tests would already be written, because they would be the same test cases as the no-functions code.

I’ll also have to figure out how to grade students’ unit tests. I don’t really want to read unit test code, but purely running them and making sure they all pass seems a bit underwhelming.

I also had the idea to give code reviews, but that might be too much work. I’m not sure how that would work either, seeing that homework is due weekly. The feedback loop might take too long that way, and the project would stretch on forever.

I had a great fun time thinking through this project, and I’m really happy that I came up with this idea of getting students to refactor their own code.

Today, I also thought further about the next project, and I searched for “practical programming projects” and came across a few. One that stuck out is an expense tracker, which is funny because a teammate and I were working on a presentation for how to use Firebase to build an expense tracker and the presentation I give at hackathons about Firebase uses building an expense tracker as the example app.

Of course, their expense tracker would be text-based inputs and outputs, and the idea behind this one was to throw all the data structures I teach them into it, including lists, dictionaries, sets, stacks, and queues. I thought this idea was pretty clever actually, because with the premise of receipt categories and lists of receipts belonging to each category, I can do a lot with it. There’s a lot of ways to ask for information, and it can use data structures any way I want. It’s great! I’m really excited to build this project actually.

Ah, I just realized I’m going to have to write the code for it myself, because since I’m coming up with the project, nobody has prewritten code like for the Blackjack game!

I’m going to have students write a design doc for this before they start (again with the autograder problem though), and then actually implement it. I’m really excited for it!

So I think now that I have two longer and bigger projects spanning over at least three or four weeks each, I feel better about my class. They’ll still have weekly homework assignments and then this project will be some work on top of that. Not bad! Pretty happy and relieved to finally have solved this problem, and it was fun to do so!