This journal serves as both journal #7 and #8 for CST 338
Look back at the HW1
HW1 was the Markov homework. I recall first attempting it by simply just coding whatever I deemed fit as a good starting point. While this method "worked" and I eventually finished the assignment, I think I could had saved myself a lot of the headaches if I just took the time to read the whole direction document first and made a picture diagram that connected all the methods and who was calling who. I suppose for my brain, a UML diagram simply isn't enough.
Highlight at least two victories.
I suppose one of the victories is that I find it somewhat easier to read a code when thrown into the middle of it. Usually reading a code is easy when already cognitively knowing where I began and where I ended, especially if I am the one who created that code. However, what if it is not my own creation and I'm just thrown into a code that without a guidance on the starting point? Well, I'll just have to figure it out, and that's a practice I was able to participate in throughout this class. A lot of the assignments already had all the "fragmented puzzle pieces," as in I was not the one making all the fields and methods. Instead, I had to put them together in a cohesive manner. Reviewing other people's code also meant I had to review code that may have looked substantially different from mine or one's that lacked descriptive comments. I still don't find it easy per say, but not anxiously freaking out at the thought of being thrown into someone else's code is a small step victory.
A large victory is actually finally understanding (somewhat) on properly understanding and using GitHub and its various features. Yes, there are tons of video tutorials but none of them seem to help for a beginner like me when so many jargons were thrown in and nuance cases were never discussed. For example, it's like almost everyone just assumed everyone already knew what a "pull request" was. I did not, and if someone simply just said "it just means asking permission to merge your code to the remote main branch" would have saved me so many headaches. That's all it would have taken. Instead, I had to sit through several numerous 5-10 minutes tutorial videos that never got to the point and were begging for subscribers. Or having to figure out the nuances of "commit and push" the hard way. For example, apparently if I already merged my local branch to my local main and I remained checkout in my local main branch, and then press commit and push, my local branch just never shows up in the remote repository. Instead, I have to physically remained checkout in my local branch and then press commit and push before that branch gets inserted into the remote repository. That didn't sound intuitive since I assumed commit and push would mean actually committing and pushing every code and branch I made, but apparently that's not the actual case Or how no one ever mentioned that if you commit your changes locally, for some reason you now cannot commit and push to the remote repository because GitHub no longer recognizes there were code changes anymore, so now you have to make a silly little change like inserting a period in the comment section to actually force GitHub now to allow users to commit and push. It is these reasons (and many more) that I consider it a massive victory that I now somewhat understand how to use GitHub.