JHammond CSUMB

Working as a group using GitHub with branches, pull requests, merges, and code reviews. This stood out the most and should probably be all five points because it reflects how real software teams actually work. Learning how to coordinate changes, review other people’s code, and merge conflicts was extremely valuable, and I honestly wish this had been introduced much earlier in the program. Given how group centric the CSUMB computer science program is, we have been working on group projects since the first class, and this course made it clear that I had already developed some bad habits over the past two years. The AWS lab. Cloud infrastructure is everywhere in the professional world, and getting hands on experience with EC2, RDS, security groups, and deployment helped connect a lot of abstract ideas to real systems. I hear these terms constantly at work, and while the lab did not make me an expert, simply understanding what something like an S3 bucket is when it comes up has been incred...

     Agile and Plan and Document processes approach development very differently. Agile focuses on short iterations and frequent changes, which can be useful, but it can also feel chaotic when requirements keep shifting and there isn’t much long-term planning. Plan and Document puts more emphasis on fully defining requirements and design up front, which can make expectations clearer and reduce confusion later in the project. While Agile allows teams to adapt as they go, it sometimes leads to rework or unclear direction if not managed carefully. Plan and Document can be slower to start, but it provides more structure and documentation, which can be helpful for larger or more regulated projects.

     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.