My CS Online Journey

What is the most interesting thing you have learned in your reading of "Software Engineering at Google"? One of the most significant concepts presented in the text is Hyrum's Law. It states that with a sufficient number of users, all observable behaviors of a system will be depended on by someone, regardless of the official interface contract. This principle highlights the inherent difficulty in maintaining software over time because even undocumented behaviors effectively become part of the public API. It suggests that rigorous adherence to published contracts is often insufficient to prevent breaking downstream users when changes occur. Ideally, an API owner would have the flexibility to change implementation details that are not part of the strict interface promise, but Hyrum's Law suggests this flexibility is an illusion in practice. As a result, discussions about software maintenance must account for this phenomenon much like discussions about thermodynamics must...

This week, I learned the importance of Version Control Systems (VCS) and gained practical experience using Git. After finishing the lab exercises, I can see why Git is such a critical tool for software engineering, particularly when working in teams. The Benefits of Using Git The primary advantage of Git is its ability to track the entire history of a project. By maintaining a sequence of snapshots, Git allows developers to pinpoint exactly which versions include specific new features or bug fixes. This history also makes it possible to undo mistakes using commands like revert or reset if a change causes issues. Another major benefit is the branching system. Branches allow us to maintain multiple independent versions of a project simultaneously. For instance, I can work on a new feature or a bug fix in a separate branch without affecting the main code base until the work is verified and ready to be merged. Finally, Git simplifies the complex task of merging changes from multiple develo...

This week's lab was a practical and comprehensive project where I built a React frontend from the ground up to interface with our existing Spring Boot backend. The main takeaway was a clear understanding of how React's core features work in a full-stack context. I learned to build the application's structure entirely from components, creating separate, reusable pieces of UI like Register, Login, and OrderHistory. I also became very familiar with React's hooks: useState was essential for managing all form inputs, useEffect was used to fetch data once when the OrderHistory component loaded, and useRef provided a way to directly control the EditOrder dialog modal. In my opinion, React's primary strength is how it simplifies UI development through component reusability and state management. Being able to create a single Messages component and use it on multiple pages was very efficient. The way useState automatically updates the UI when the state changes is also a power...

Before starting CST438, I had the common programmer's perspective: that the central skill lay in writing functional code and mastering complex syntax or data structures. I anticipated the course would focus heavily on project management and architectural design, the mechanics of building features. However, after reviewing the labs and materials, it's clear that Software Engineering is fundamentally different from programming. It's defined as "programming integrated over time", meaning the primary challenge is not creation, but ensuring the software's sustainability and maintainability over a lifespan that could span decades. After the first week, my opinion has profoundly changed, shifting the focus from individual code creation to organizational sustainability over time. It's now clear that the central engineering problem isn't getting code to work once, but ensuring it survives, scales, and is safely maintainable for decades. The course empha...

This course helped me understand how databases really work and how much thought goes into building them correctly. The three most important things I learned are database design, SQL querying, and how databases connect to real applications. 1. Database Design and Normalization Early in the course, I learned how to take messy real-world information and organize it into clear, structured tables. Normalization, especially the first three normal forms, showed me how to prevent duplicate data and keep everything consistent. Working on the prescription database lab made this feel practical. I saw how choosing the right primary and foreign keys can make inserts, updates, and lookups smoother and more reliable. 2. SQL Querying and Joins Writing SQL queries became one of the most useful skills I picked up. Learning how to use SELECT , JOIN , and GROUP BY taught me to think logically about how data connects across tables. It wasn’t just about remembering commands; it was about asking the rig...

 MongoDB and MySQL are both widely used databases, but they serve different purposes depending on the type of data and the goals of the application. MySQL is a relational database that organizes information into tables made up of rows and columns. It uses structured query language (SQL) to define schemas, create relationships, and perform queries such as SELECT , JOIN , and UPDATE . MongoDB, on the other hand, is a NoSQL database that stores data as flexible JSON-like documents inside collections. Each document can have its own structure, which makes MongoDB more adaptable to unstructured or frequently changing data. Both systems share some important similarities. They are open source, support indexing for faster data access, and allow basic operations like inserting, reading, updating, and deleting data. Both also offer replication for high availability and tools for monitoring and backups. In our SQL labs, we practiced commands such as CREATE TABLE , INSERT INTO , and SELECT *...

I finished the Lab 18 peer reviews and focused on whether each ER diagram actually supports the prescription workflow. The strongest designs kept prescriptions separate from fills and stored drug prices in a way that preserves history, which makes reporting and auditing sane. I flagged fixes like using IDs for foreign keys instead of names, adding required attributes such as a pharmacy phone, and tightening a few relationship cardinalities so the rules are explicit. I also looked for basic normalization slips and confirmed that the chosen keys would prevent duplicate patients, doctors, and fills. The point was not the diagram aesthetics but whether constraints and keys would keep real data clean and predictable over time. I also moved from Workbench queries to JDBC inside a small Spring MVC app and got comfortable with the essentials. I bind inputs with prepared statements, remember that parameters are 1 based, iterate result sets cleanly, handle NULLs correctly using wasNull for prim...