Marked by Markov

This week, I got to collaborate with Luke and Quinton to peer review our Markov.java files. We shared our code files in our group Discord, which gave us all the chance to carefully walk through the code and respond with specific observations. I think this workflow works really well for our group because we can each review the files at our own pace instead of trying to coordinate one exact meeting time. I really appreciated that the feedback focused on understanding our different decisions rather than treating the review like a high-stakes grading session. My classmates were not difficult to reach this week, but next time I would still try to begin the review earlier so everyone has more time to use the feedback while writing their own journal entries. My initial thought when I saw the Markov project was my stomach dropping and an immediate feeling of dread because I had not noticed the assignment before it closed. It was under the Canvas category HW02, while my normal workflow has been to collect every assignment listed in the current weekly category and add it to my personal to-do list. Because I overlooked that category, my first impression of the assignment included the red “missing” text and a closed submission portal. I still accepted the GitHub Classroom assignment and completed the requirements, even though the effort would not be reflected in my grade. Before writing my first line of code, I read the README, identified the required methods, and separated the assignment into two main stages: building the dictionary of word relationships and using that dictionary to generate sentences. I also reviewed the tests and submission requirements so I could use an almost test-driven approach. I felt most stuck while working on addWord() and trying to make the dictionary match the exact structure expected by the tests. I had to think carefully about when a word should become a key, when it should only be added as a possible follower, and how BEGINS_SENTENCE should be handled after punctuation. What got me moving again was slowing down and focusing on only the relationship between the previous word and the current word. Luke and Quinton approached several parts of the problem differently than I did. In Luke’s addWord() method, he used containsKey() and put() to create a missing list before adding the current word. I used the HashMap method computeIfAbsent(), which creates the list and adds the word in a more compact statement. Luke’s version makes every individual step visible, which may be easier to trace while first learning how the map changes. Luke also built his sentence with string concatenation, while I used a StringBuilder because the sentence changes repeatedly inside a loop. Quinton also used StringBuilder, but his punctuation method looped through every character in PUNCTUATION_MARKS, while I checked the final character using indexOf(). His loop communicates the comparison very explicitly, while I preferred the more compact version. Both Luke and Quinton also assumed that a requested key would contain at least one possible follower, while my randomWord() checked for missing or empty lists and returned null. Comparing our implementations changed how I understood the assignment because it showed me that the same Markov relationship could be built through several valid control-flow choices. Luke emphasized showing every step, Quinton emphasized consistent documentation, and I focused more heavily on conciseness and defensive checks. If I were starting the Markov assignment again today, the biggest thing I would do differently would be to manually trace one short sentence and draw the expected HashMap before implementing addWord(). For example, I could write out which word becomes the key and which word becomes its possible follower after each step. Seeing Luke’s more explicit implementation made me realize that I had been trying to mentally track too many changes to the map at once. I would also change how I organize my coursework by checking every Canvas assignment category and the course calendar instead of relying only on the current weekly category. This change is partly about how I think through programming problems, because I would reduce the algorithm to a small example before coding, but it is also about how I organize my work so that an assignment cannot be accidentally overlooked again. Luke reviewed my code against the Google Java Style Guide and said that my naming scheme and comments followed the guide well. He also said that my version handled empty lists more safely than his because he wrote his with the assumption that the text files would not be empty. He specifically complimented how tightly coded and well implemented my StringBuilder section was, and described the overall file as clean and easy to understand. I agree with his feedback, especially his observation that my defensive checks reflected a different assumption about possible input. While reviewing his file, I noticed that some of his comments were long or repeated exactly what the code already showed, so shortening them would make the file easier to scan. After this review, automating parts of the Google Java Style Guide in IntelliJ feels like a useful habit rather than a shortcut. Automatic formatting can handle mechanical details such as indentation, spacing, and import organization, but it cannot decide whether a comment is useful, whether a method name is descriptive, or whether the logic is easy for another developer to follow.