Final Blog Entry

• How well do you think the course conveyed these takeaways?

  • test first, test during, test after; test, test, test

    I already believed in the power of testing. I don’t know how well this class sold it to the uninformed.

  • when designing algorithms, demand the weakest iterators (e.g., bidirectional vs. random access)

    My recollection is you briefly discussed in one or two lectures. Maybe it was also mentioned as part of the “allocator” project? If it was intended to be a long-term takeaway, you should have made it a bigger part of the class. Or I should have a better memory.

  • when designing containers, provide the strongest iterators (e.g., random access vs. bidirectional)

    This is a design decision. You might not want to provide the strongest iterator your current implementation allows, because you want the flexibility of changing the implementation later to something that can’t provide as strong an iterator.

  • build adapters on top of containers and iterators

    I think the real principle here is to favor composition over inheritance. A stack has a vector (by default) but is not a vector. A queue has a deque but it is not a deque. This principle applies to all sorts of components, not just containers and iterators.

  • do not use new and delete; use containers or allocators instead

    More generally: use a disciplined approach to memory management, and if your language allows it, encode that approach in the type system.

  • always look for reuse and symmetry in your code

    Maybe an article about the DRY principle (“don’t repeat yourself”) should be one of the papers. It would definitely be better than either of the getter/setter papers.

  • collaboration is essential to the quality of your code and to your well-being in producing it

    I did not find that to be true for my performance in this class.

  • make your code beautiful

    I find it difficult to write beautiful code in C++.

• Were there any other particular takeaways for you?

  Don’t help others on a quiz until you’re confident you’ll finish it yourself. Otherwise you might discover too late that the quiz was timed.

• What required tool did you not know and now find very useful?

  I was already aware of all of the required tools that I find “very useful”. I did get a little more experience with Docker and that is useful.

• In the end, how much did you learn relative to other UT CS classes?

  This is my first semester taking a UT CS class since Fall 1992. I will not try to compare my learning in this class to my learning in classes taken last millennium, because it’s difficult to separate what I learned back then from what I learned in the intervening 30+ years of professional programming.

  This semester, beside OOP, I also took CS 354R Game Technology. I learned much more from that class than from this class, but I think most of what I learned in Game Tech is fairly specific to the Godot game engine.

• Please pick at least 5 of the following that you feel passionate about, tell me whether you loved or hated them, and give me any suggestions for improving them.

I don’t feel passionate about any of these, so I’ll just give my weak feelings about all of them.

• specifications grading

  I like the idea of specifications grading. I read the article by Linda B. Nilson linked from the syllabus. I’m not sure I agree that this course is really an implementation of specifications grading as described by the article.

• cold calling

  I liked the cold calling, but I already knew most of the material covered in this class and I’m comfortable with being wrong in public.

• TA help sessions and office hours

  I went to a couple of Rodrigo’s sessions for specific issues and he was helpful.

  The best part of this class was chatting with Prof. Downing for an hour after class on Mondays and Fridays.

• Ed Discussion

  I think Ed Discussion worked well for this class.

• collaborative quizzes on Canvas

  I didn’t benefit much from the collaboration, and at least once it made me get a 2 instead of a 3.

• collaborative exercises on Ed Lessons

  I didn’t need any collaboration on the exercises, but I didn’t mind helping other students.

• weekly blog entries

  I found this incredibly tedious and not at all useful.

• weekly papers on Perusall

  A good idea spoiled by a lot of terrible papers.

• SOLID papers

  I did not like them, Sam-I-Am.

• getter/setter papers

  Possibly even worse than the SOLID papers.

• project one about grades on HackerRank

  The spec was fine. There was too much paperwork involved outside of the programming.

• projects on HackerRank

  The specs were fine. There was too much paperwork involved outside of the programming, and sometimes we were required to implement bad design decisions.

• rubrics on GitLab issues

  Okay, I do feel a little passionate about this one. I think it was incredibly tedious, unnecessary bureaucratic paperwork.

• pair programming on projects

  I didn’t do any pair programming, and looking at the code of other students to help them would have been academic dishonesty, so I didn’t do that either.

• check test data

  Not particularly interesting. I think Downing’s personal requirement that all projects be in the style of competitive programming problems rules out many project ideas that would be much more suitable for a class supposedly about “OOP”.

• Google Tests

  A useful tool if you have to write in C++.

• acceptance testing

  The best kind of testing.

• continuous integration

  A valuable tool.

• Docker

  Truly an amazing piece of software.

• UML

  Diagrams can be useful. UML is overwrought.

• ethics lectures

  By far the most interesting lectures of the course.