todo.md

A place for thoughts and possible revisions.

If you're a student and you're reading this, and you have anything to add (comments, complaints, or anything) please let me know! Maybe email me :) .

Week 1

• Since this is a 100 level course, maybe it's okay to have week-1 as an intro to everything, without a whole bunch of content, to give people a second to settle in (I know I used to appreciate that). That said, if people were willing, it might be better to just jump straight into the lab we have here for week-2, and save a bit of time :) .

Week 2

• Using makefiles (and shell scripts...) was probably unnecessary. It would probably be better to go straight to compiling on the command line, as week-3's lab does.

Week 5

• In the challenge: exponentiation requires either loops or pow() (from <cmath>), neither of which we've gone over yet. But, one student noticed this (without any prompting) and another was able to look up pow() very quickly once I told him it existed, so maybe it's okay :) .
• This is the first week where things are more of an experiment than a tutorial. Yay!
• It's also the first week that this exercise is being used as the lab (to turn in). I think it worked pretty well :) (I'm proud of it at least).
• It's also the first week of using a roster to check off everyone who completed the assignment (which I think was better, not just for being easier? but also because it made an opportunity for immediate feedback).
• I'm still meaning to get people drawing on the board eventually, and to get them searching for their own stuff online (since that's a really valuable skill).
• Everybody finished before lab was over! A few came close to taking longer, but I saw nothing there to be worried about, and this is really encouraging :) .
• By far the most common error I saw was to use a + instead of a '+' when testing for which operator was entered by the user in the calculator program.

Week 6

• Needs to be organized more simply, and probably a bit easier.
• Should have spent more time on Boolean stuff earlier (that's okay... we'll work on it next week :) ).
  • A lot of people had a real conceptual problem with the idea of if (i) ... (for some int called i) in part 2 of "Review: Boolean Expressions".
  • A few people (at least) weren't able to fix all the errors in "Warm-up: Broken Code". Didn't have time to see what all of their questions were... I did see a few people having a problem understanding the error in if (choice == 'y' || 'Y') ....
  • The instructions for "Predefined Functions (a.k.a. Library Functions)" might not have been clear enough. Not sure how they could be improved at the moment though...
• Almost no one got to "Preview: User Defined Functions". I think the concepts that were there might just be rolled into Week 8's lab, or whenever it's convenient.
• It seems like people tend to read the exercise and write the program in tandem with each other (instead of reading the whole subsection and then writing the program). This is not a bad thing... It does mean that in the future I should probably put anything I wish everyone to see (like "Sample runs") at the beginning.

Week 7

• I think spending a whole lecture and lab going over booleans was really good. It was an easier lab. The faster students finished really fast, and a few took the whole time. Myprogramming lab seems to be quite good for this topic. Also, the truth table worksheet was nice, because it helped to make apparent some of the misconceptions people had (even some of the faster students) :) .

Week 8

• This one went both better and worse than I had imagined. A few people came up with a solution very quickly. That was pretty cool. On the other hand, a few people didn't quite understand within the lab period. Mostly because they didn't design (in groups) first, like the prompt said to, I imagine.. Mostly because that's probably a bit awkward, and I failed to properly encourage it.
• I probably should have stopped around 30-45 minutes in, and called a group design session in the front, so I could help everyone who hadn't gotten it by themselves yet. Alternately, we could have required them to turn in a "structure chart" (i.e. a design picture), or something like that.
• It was cool to see the different ideas people came up with :) . I remember 3, besides mine, distinctly (and actually, the solution I had come up with was in the minority). The majority of people I saw implemented it with multiple while loops -- one for each case (so, one for pulling out all the "M"s, then all the "CM"s, etc.).
• There were quite a few students that looked up an algorithm online. Perfectly acceptable, I think, according to what we've been allowing (and sometimes advocating, about looking stuff up) in the past. But still, half the point was algorithm design, and so it would have been better if everyone had done it on their own. Probably, finding some way to get them all to design it on paper (or on the whiteboard! preferably) would help a lot with that.

Week 9

• Took a lot longer than I thought it would, but not too long, and I think it went really well :)
• A lot of people misinterpreted the assignment at first... Many tried to use a loop around a cout statement that printed the diamond literally. Quite a few also thought that they were supposed to use a loop to print the diamond three times for each type of loop (separating the different types of loops into different files).
• Everyone was really shy about coming to the board, lol. But when I kept prodding, eventually a small group came up, and we designed it, and it went really well. After that, I erased our work, on purpose -- and within a few minutes most of the rest of the class came up, and we went through the process again (except that many of them were more shy than the first group, understandably).
• The ideas behind this assignment -- that you can make one variable be essentially the reverse of another (decrementing as the other increments, for example), and that you can shift the point at which a variable is zero, within loops -- seemed new for almost the entire class. But that was mostly intentional :) -- they weren't intended to get it on their own, only to participate in the design process, and to see how much easier it is to code once you have your main ideas figured out.
• Once we had designed the loops, almost none of them had problems deciding where to cout << " "; or cout << "* ";, etc.
• Also, there were only a few people that I saw having minor problems converting between the different types of loops -- and I'm pretty sure everyone would have gotten that eventually, in groups, without undue difficulty. I think mostly, it was just them being unfamiliar with the syntax, since it's still a bit new.

Week 10

• Took most everyone a little while, but that is to be expected.
• Error in the "memory-4" picture: int c[3]; should reserve 3 slots in memory.

Week 11

• (Spring Recess)

Week 12

• I'm writing this super late... but IIRC, this lab was about average. I don't think everyone got to the "Palindromes" part.
• There was still some confusion about using loops. I feel like, while projects and examples and such are better than drilling with MyProgrammingLab in general, there needs to be a lot more programming work in order for this (more traditional?) method to produce the same level of proficiency in basic stuff...

Week 13

• Again, I should have written this a while ago, as I don't remember the lab very well.
• We went over the algorithm 3 different ways in class: once on the board, once on the computer, and once with Josh sorting five people in the front of the class by height :) (which was fun). When we got to the lab, students still had trouble knowing exactly what was going on. But I think, once they thought about it for a while, most of them got it. Josh said that his section didn't really have any problems, so my thought is that introducing sort, and then trying to implement even a simple sorting algorithm just two hours later, is a bit too quick.

Week 14

• Maze project! I think we had about 3 people in the Thursday lab that had theirs finished (less housekeeping details) by the end of the first lab (though, those three students are typically pretty fast, and they stayed the whole 3 hours and 45 minutes).
• We took this opportunity to introduce GitHub (at the beginning of lab), which took a while (understandably). I tried (and so did the professor) to explain what it was good for, but I'm not sure if it quite caught on. I haven't really thought of a good way to explain it yet... it's just one of those things that made sense to me, when I learned about it after a year or two of programming (hey! let's keep track of everything!). But it's an important concept, so I'm glad we introduced it.
• I demo'd my solution to this assignment (which was surprisingly simple, yet fun, to me at least). I could have done a better job presenting it. I think presenting it was better than not though, to give the students a feel for what they were trying to accomplish.
• A lot of people were a bit confused about how to start, IIRC, which makes sense. It might be good, in class, or at the beginning of lab, or something, to go over the control flow concepts in this project, which really are pretty different than anything we've done thus far, even though the C++ features being used are fairly simple (and we went over all of them a while ago).

Week 15

• Attendance is down (in both the lab and the lecture) like crazy. I think people are mostly over it...
• There were quite a few of those who showed up who hadn't really started their maze project till this week... lol
• Some people were still having issues with nested for loops for accessing each element of the array in tern, etc. I think we probably didn't give them enough to practice with...
• Besides that though, it was just a really calm, almost last lab (since next week is optional).
• Some of the typically faster students came up with some fun extensions :) it was really cool to see :)

Week 16

• Really relaxed. People finished their maze projects. We were going to do a review, but since people were still working on projects, it didn't happen.