CS371p Spring 2022: Kyzer Polzin: Final Entry

Kyzer Polzin
4 min readMay 7, 2022

Course Takeaways:

  • test first, test during, test after; test, test, test
  • when designing algorithms, demand the weakest iterators (e.g., bidirectional vs. random access)
  • when designing containers, provide the strongest iterators (e.g., random access vs. bidirectional)
  • build adapters on top of containers and iterators
  • do not use new and delete; use allocators instead
  • 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? I think these takeaways were thoroughly explained and demanded of us. They were emphasized in the quizzes and on exercises and the fact that we reviewed past material most lectures, it made these takeaways easy to acknowledge and prioritize. I think the testing takeaway was the one I got the most from, as we were constantly having to update our design as we went along because hackerrank, unit, and acceptance tests exposed flaws in logic.
  • Were there any other particular takeaways for you? One particular takeaway I had was to continuously integrate. Since we use Gitlab’s CI pipeline in this class, its easy to test and continually check the status of your repo. Oftentimes, I couldn’t get a passing pipeline until I was almost completely done with the project. However, the whole point of continuous integration (as we read in one week’s paper) is that you’re supposed to commit often so its easier to source bugs.
  • How did you feel about cold calling? I enjoyed the cold calling. Along with the quizzes, it helps to ensure decent attendance in the course and keeps you engaged. It wasn’t as nerve racking as it seems and you usually only get called on once every few weeks. It also forced me to go and review notes before classes so that I could be prepared if he was to call on me. This helped my performance on quizzes and exercises as well.
  • How did you feel about specifications grading? I actually don’t mind it. It is a little worrying as the variance in my grade can be huge because of it (for example, my grade can go from a C- to an A because of a single grade on a project). It also requires a ton of time to track your own grade and see your performance in the course which I think is a little unfair to students (they shouldn’t have to tally up their grades to have an idea of their performance in the course). However, the grading system does accomplish its purpose, it keeps you active in every facet of the class throughout the semester. There’s also a little leeway built-in so you can choose to sacrifice on some assignments if it is needed.
  • How did you feel about help sessions and office hours? I only went a couple of times to each, but each time I went the TAs were helpful.
  • How did you feel about the support from the TAs? The TAs were helpful when asking for help on projects and exercises. They were moderately active in Discord and on Ed Discussion as well. However, I did get the most support from fellow classmates as we were diligent in answering each other’s questions and giving high-level advice.
  • You should have read five papers that describe SOLID design: Single Responsibility, Open-Closed Principle, Liskov Substitution, Interface Segregation, and Dependency Inversion. What insights have they given you? You should have read two papers that advised minimizing getters and setters. What insights have they given you? I’ve combined these questions because my insights were the same: have a good design. All of these papers were centered around designing your projects in a way in which they are flexible and don’t do jobs outside of their intended scope. Accomplishing this can simply be done with a good design. We practiced this in our projects with UML diagrams, and even though they had to be updated as we made progress, it gave us a good starting point and allowed us to have a concept of where to start.
  • What required tool did you not know and now find very useful? I found gcov useful. It was always helpful to know what parts of code weren’t being tested or were simply unnecessary as it could be a case that never happens.
  • In the end, how much did you learn relative to other UT CS classes? I learned a decent amount from this course. However, I feel like I learned C++ more than I did object-oriented-programming. Most of what was covered in class was just C++ semantics, we learned about the nitty gritty of OOP from the papers. It was cool when Downing would connect the topics in class though and actually demonstrate implementing these designs in our class code.
  • Give me your suggestions for improving the course, but apologies in advance; specifications grading will remain. Maybe restructure how lectures are. I feel like I learned a lot this semester, but I don’t know how many of the OOP principles will stick with me. I think if we really emphasized the ideas in the papers, like eliminating getters or setters, with a lecture or two, then I would be a lot more comfortable with the principle’s of OOP and would be able to make better design decisions in the future.

I enjoyed OOP this year. The class is a lot of work, but it isn’t all too difficult. Stay on top of the assignments and make sure you review class notes and are aware of deadlines, because if you slack off for even a little bit, your grade can definitely suffer. Good luck to any future students!

--

--

Kyzer Polzin

Current CS student at UT Austin sharing my journey