Khiem's CS Journey

 Learning Journal — End of Semester 1. Reading my own Project 1 code now Opening Project 1 again, the first thing I noticed is that the code actually reads like something I designed on purpose. When I was writing it, each file felt like its own fire to put out. Rereading it now, I can see the shape of the whole thing: four pile classes implementing one Pile interface, a Game class that orchestrates them, and a Code enum that lets every method report success or failure in a structured way. The class I'd rewrite first is Game.java. Right now it's a fat controller that holds every pile, every flag, and every method for moving cards. It works, but the UI has no way to know when state changes unless something explicitly asks. If I wrote it today I'd apply the Observer pattern: Game would maintain a list of listeners and fire an event after every successful move, and the UI would subscribe instead of polling. That's a real separation of concerns, and it would make the mode...

1. Who did you work with on this review, and how did the collaboration actually go? I worked with David Renteria. The collaboration went well, but it was not constant. We checked in at different points to compare ideas and make sure our logic aligned. If your team was hard to reach, how did you handle it — and what would you do differently next time? There were times he was hard to reach. I kept working instead of waiting and saved questions for later. Next time, I would set clear checkpoints so we stay aligned. 2. Walk through how you approached the Markov assignment from the moment you first read it. What did you do before you wrote your first line of code? I focused on understanding the problem first. I saw it as mapping each word to possible next words. I planned to use a HashMap and thought about handling sentence starts and punctuation before coding. Looking back, at what point did you feel most lost or stuck — and what got you moving again? I got stuck on handling sentence e...

1. Your Approach and What It Revealed I started with the card class first since deck depends on it. I didn’t really plan ahead - I opened the file and built everything from scratch. My usual approach is to figure things out as I go and adjust based on errors or what breaks. For this project, that worked fine because card is mostly self-contained, so everything flowed naturally into Deck . That said, for more complex systems, I’d probably spend a bit more time planning how classes interact upfront instead of relying purely on trial and error. 2. The Peer Review: What You Saw and What You Learned I worked with Eric during the review. One difference I noticed was how we handled checking opposite colors. He wrote the logic directly in the card class, while I called a method from the Suit enum. I think my approach is better because it avoids duplicating logic. If the color rules ever change, my version only needs to be updated in one place, while his would require c...