Week Two: “Dream is Collatzing”
Welcome back to my weekly update on Professor Downing’s Software Engineering class. This is part deux. I’ll skip the balderdash this time, as the requirements for this post (as well as all the subsequent ones, I hypothesize) are notably stricter than the first one, i.e. here I must explicitly bold and answer the specified seven questions about the class. So it goes.
What did you do this past week?
Judiciously watched every lecture, check. Caught Tuesday’s help session with the TAs/proctors, check. Wrote the second blog post, che-. Overall, I’ve been trying my best to stay on top of the work and material for this class, a strategy that’s proven fruitful for my previous computer science classes.
Most importantly, I made major headway in the Collatz project. My program is still failing the third test case on HackerRank (more on this later), but the progress I’ve reached owes a lot to following the workflow delineated by Professor Downing. By framing the development process under realistic technologies and standards, completing the rather basic specifications of this project becomes a revealing journey. At this point, I’m comfortable utilizing Docker, GNU Make, and many GitLab features, e.g. repository forking, Issues, and CI/CD, in a project environment. I’m sure that I will learn even more by the end.
Also, from the help session I learned that it’s best for each team member to start off the main group project taking on the developer role that he/she is most interested in getting experience in, because it’s difficult to overcome the workflow inertia required to pivot positions once everyone gets into a groove. This is just something to keep in mind.
What’s in your way?
That third test case. I’ve implemented the suggested optimizations from class, including caching, and running my program against this one still times out. Because of all of the different kinds of testing I’ve done, I’m fairly certain that my code is correct, so this is a question of performance. There must be some trick that would push my program across the line of success. Maybe I can use multiple hash tables instead of one? That just came to me; I’ll see if it works.
What will you do next week?
For the next week, I’m planning on learning more about software engineering by completing the Collatz project and other assignments. I’ll also attend all of my classes, so maybe I’ll get cold-called by Professor Downing. That would be exciting.
What was your experience of assertions, unit tests, and coverage?
I’ve used all three techniques in my Collatz project many, many times now. Assertions are useful for ensuring that the function invariants are not violated, by checking argument validity, preconditions, and postconditions. Unit tests helpfully isolate segments of a program for assessing correctness. Coverage is a new one I learned this past week, but its purpose is intuitive: testing ought to maximize efficiency by broadly scanning for the correctness of all statements, conditional branches, and edge cases. Coverage facilitates this for us.
How are you doing and holding up? What’s been most helpful for you in terms of support at this time?
I’m good, thanks for asking Mr. Prompter. 😊
Like I said before, I’m trying my best right now, and the songs I’m jamming out to right now (Phoebe Bridgers — Kyoto; Lonker See—Gdynia80; Run the Jewels — a few words for the firing squad) are keeping me motivated and sane in these difficult times.
What made you happy this week?
Among my school courses, internship applications, and various other technical and creative endeavors, there’s been a lot of work that this week has been ramping up towards; in the meantime I revisited two of my all-time favorite movies, Robert Zemeckis’ sci-fi classic Back to the Future and Howard Hawks’ screwball masterpiece His Girl Friday. Both made me, for lack of a better word, happy.
What’s your pick-of-the-week or tip-of-the-week?
I saw that my friend Jeffery Wu mentioned the usefulness of a desk lamp in mitigating eye strain, so I thought that I ought to give a shout-out to the most underrated office item that I use — the standing desk. Central to the desk’s design is a mechanism that alters the top’s verticality, so I can alternate between sitting and standing at the press of a button. Ergonomic gaming chairs be damned, this is where it’s at. I would recommend any sort of height-adjustable standing desk for anyone who thinks they sit too much throughout the day. If you’re interested, here’s a NY Times article with the most detailed analysis on these things imaginable.
I have no idea what’s gonna happen next week, but I know one thing for sure: I’ll see you in the next blog post. Good bye!
