JHammond CSUMB

     Writing system tests this week really pushed me to understand how the code operates as a whole rather than looking at methods in isolation. To get the tests working, I had to track how the controllers, services, repositories, and security layers interact and how a change in one place affects the rest of the flow. One issue I had to fix was the use of a hard coded email in the controller where the code should have been using the token from the authenticated user. Updating that forced me to understand exactly how the token is passed through the system and why relying on the hard coded value was causing failures. System testing does not let you rely on assumptions because you have to understand the full request path, the data dependencies, and how all of the pieces fit together. It ended up being one of the best ways to learn the actual structure and inter dependencies of the project.

     This week I got a lot more comfortable working with Git, specifically using pull requests as part of our team workflow. Creating branches, making changes, and opening PRs feels much more natural now, and I’m starting to appreciate how they help track work and keep everything organized. In my own personal projects outside of school, I’ve had a bad habit of doing everything directly in main, so this class workflow is helping me build better branching habits. Since our team is working in different files, we haven’t really run into merge conflicts yet, so the review and merge process has been pretty straightforward. Overall, it was a good chance to get more hands-on practice with PRs and see how they fit into collaborative development.

     One thing that really surprised me from Software Engineering at Google is how much thought goes into what happens after the code is written. I didn’t expect things like code reviews and testing to take up such a big role compared to just writing the actual program. What stood out to me was how important it is that someone else can come in later and understand and maintain the code without everything breaking. Before this, I kind of saw programming as a solo task, but now I see that it’s more about building something that a whole team can work on and improve over time. It changed how I look at what it means to be a software engineer.

     Git is really useful for managing code because it keeps a full record of every change and lets people work on separate branches without stepping on each other’s work. It makes collaboration smoother and gives you the safety of rolling back if something goes wrong. But Git can’t solve every type of conflict. If two developers make different edits to the same spot in the code, Git can’t tell which one is correct. It also won’t help when the changes technically merge but create logical or design problems. In those cases, developers still need to talk things out and decide how the code should actually behave.

     This week I learned how React uses components to build web pages and how data can be passed from a parent to a child using props. I also learned about hooks like useState, which manages state, and useEffect, which runs code when something changes or when the page first loads. I think React is really powerful because it makes it easy to create reusable and interactive parts of a website, and it updates the page quickly without needing to reload everything. One weakness of React is that it can be hard to learn at first because there are so many new concepts like JSX, hooks, and state management. It also requires setting up several tools and libraries to get a full project working, which was a bit overwhelming.

     At first, I honestly thought this Software Engineering course would just be like a harder version of the Java class, with more coding and tougher assignments. But after finishing week 1, especially working with REST APIs, I realized it is not just about writing code. It is about the whole process of building software, like planning out how everything fits together, writing unit tests to catch mistakes, and making sure the program can grow and work with other systems. It made me see that software engineering is more about good design and process than just coding itself.