CS373 Spring 2021: Ian Thorne (Final Entry)
Long Term Takeaways
- Test first, test during, test after; test, test, test
- When designing algorithms, demand the weakest capabilities (e.g. iterable vs. indexable)
- When designing containers, provide the strongest capabilities (e.g. indexable vs. iterable)
- Build decorators on top of containers, iterators, and functions
- Utilize the benefits of being lazy (e.g. yield)
- Always look for reuse and symmetry in your code
- Collaboration is essential to the quality of your code and to your well-being in producing it
- Refactor, refactor, refactor
- Make your code beautiful
How well do you think the course conveyed those takeaways?
Overall, I think this course did an excellent job of conveying those takeaways. Some of those takeaways came directly from lectures, others came from working on the web project, and some were the result of something from lecture clicking while working on the web project. Dr. Downing did an excellent job of explaining the particulars of the topics he went over in class. He would also go the extra mile to make sure that everyone in the class not only understood the concept, but the why behind the concept and the benefits that each particular design decision allowed for.
To be more specific, I’ll go one by one (Beware: Lots of words ahead!). For number (1), I felt like Dr. Downing made it very clear in lecture why testing is useful and gave great examples as well. I did feel like the web project didn’t emphasize testing as much, though, because of all the other requirements. I think carving out some time earlier on to set up testing frameworks and continuous integration may have helped. Number (2) was also conveyed very well in class. I don’t recall ever reading that exact sentence, but based on the way the course material was explained, it definitely makes sense. Number (3) goes hand-in-hand with (2), I don’t remember reading that exact sentence, but after the explanations in lecture, it makes a lot of sense. I think number (4) was conveyed well as well, we saw examples of decorators and some use cases for them, but I think spending a little more time on them may have helped (this may be a result of losing time to the winter storm). Number (5) was made extremely clear. Dr. Downing always made sure that everyone understood when a particular design was lazy and really hammered home the benefits and dangers that lazy designs can allow for. I don’t think number (6) was mentioned a ton in class, but the nature of front-end UI work on the web project really emphasized the importance of making code re-usable. A lot of the components on our site were re-used across pages to save work re-implementing things that are essentially the same. Number (7) was also clearly driven home by the web project. The scope of the project is much too big for any team to really be successful without collaborating and communicating effectively. Overall, this class wasn’t the most stressful one I took this semester, and I think that’s thanks to my team. For numbers (8) and (9), I think the lectures and the web project conveyed them. I really appreciated the focus that the class put on refactoring towards the end of the semester, since it’s an important part of software development that a lot of classes don’t really emphasize.
Were there any other particular takeaways for you?
There were a couple more that weren’t listed above that this class really strengthened. They were things I’d sort of learned in previous classes, especially heavily group-focused classes, but this class helped emphasize them. The first would be the importance of really researching, planning, and designing the implementation of things before jumping into programming them. I took the latter approach for the first phase and creating simple static webpages was incredibly difficult, since I barely understood the programming language. On later phases, my group and I made sure to really plan out our implementations and, despite being much more complex, they were far easier to write. The second extra takeaway would be the importance of actively communicating with your team. Even if you’ve done nothing since your last update, which was often the case, it’s much more useful for your group to know where the state of the project is than for them to be left guessing — and panicking (don’t make your teammates panic).
How did you feel about cold calling?
I thought the cold calling was great. It made sure everyone was engaged, since they might have to answer a question, but I think it also clarified a lot of things. When the student that was called on had questions, they were usually questions that lots of other people had (and may not have asked) which resulted in more understanding all around. On top of those things, Dr. Downing does a great job at maintaining a low-stakes, relaxed environment. If you’re called on and you don’t know the answer, don’t worry about it! He’s not trying to stress you out, it’s really just a conversation and he’ll help you out.
How did you feel about office hours?
To be super honest, I only went to office hours once, so my feedback may not be worth that much. I did, however, feel like all four of the TAs were really interested in web development and very invested in making sure that everyone did well on all of the assignments, based on their interactions on Piazza and Teams; so I have to imagine they were great.
How did you feel about lab sessions?
Again, I didn’t ever go to lab sessions, but based on what I saw from the TAs, I imagine they were super helpful. My friends who attended them also felt that they were really helpful.
What required tool did you not know and now find very useful?
I now find Docker very useful! I’d used it before in OOP and in an internship but not much outside of that. This class really showed how useful it can be to set up a toolchain and easily share it with teammates to make sure that everyone is using the exact same software versions.
What’s the most useful web dev tool that your group used that was not required?
Honestly, I’m going to say Prettier, which is a VSCode extension. I’m not sure if it counts, but it automatically styles JavaScript and TypeScript code which saved us a lot of headaches in maintaining our codebase and staying consistent.
How did you feel about your group having to self-teach many, many technologies?
I thought it was really cool to be honest. I feel like it showed us that we’re capable of a lot and it was really satisfying to figure stuff out on my own. I will say that I think there should be some discussion of React in class before phase two of the web project, since there really is a lot to figure out and a lot of students have never worked with JavaScript before. I will also say that it was made much less stressful by the class not having any tests. I think the stress of both might’ve been too much.
Provide some suggestions for improving the course.
I have a couple of suggestions, but I’ll preface them by saying this: this class was absolutely great. I had intended to drop it at the start of the semester but the quality of Dr. Downing’s lectures and the interesting web project convinced me not to and I’m glad that I didn’t.
First, like I mentioned above, I would suggest adding some more explanation of React at the start of the course. It can be super jarring to students who have never worked in JavaScript or with UI before. Being thrown into HTML, CSS, JavaScript, and React all at once was a little stressful. Even if you can’t spare lecture time, just linking a few more tutorials would work wonders (I felt like this one explained most everything we needed at a high-level).
Second, I might suggest removing or shortening the time span of the Collatz assignment. I did like that it introduced Python and the general workflow of submitting assignments to the class (and that it was a relatively low-stakes assignment to start with), but it felt like the time spent on it might’ve been more helpful as extra time on the web project phases. Since phases two and three of the web project needed extensions, taking some time from the Collatz assignment might’ve helped.
Third, I’d suggest updating the assignment specifications. Like the course website says, it’s really difficult to not miss anything in them, but it felt like a lot of that information was very spread out. I think condensing the bulleted lists of requirements and the rubric at the bottom of the page into one rubric or list may help, but having a few more details would be more helpful. There was a lot of explanation of requirements that happened at the end of lecture or on Piazza that some groups missed or didn’t see until later, which can be a little stressful. Creating some centralized list of assignment updates may also help.
Finally — and this one isn’t really an improvement — I’d say to keep the no test design of the course. It took a lot of pressure off not having to worry about tests on top of the web project! The course was definitely still sufficiently challenging and the exercises served as good chances to practice the topics we learned in class.
I’ve already written way too many words so I’ll cap it off by saying that this class was great!
(If you want to check out my group’s website, you can find it here: https://www.dolladollabills.me/)
