My CS Online Journey

This class has provided a clear view of the transition from writing code to engineering systems. Below are the five most important things I learned in the course and the reasons why I believe they are vital for my development as a software engineer. 1. The Difference Between Programming and Engineering I used to think these terms were interchangeable, but I now understand that software engineering is "programming integrated over time". Programming is about the immediate task of solving a problem, whereas engineering is about making sure that solution can survive changes in teams, technology, and requirements over several years. This shift in perspective is important because it changes how I prioritize code quality and documentation. 2. The Power of the Testing Pyramid Before this class, I viewed testing as a final check rather than a continuous process. Learning about the "Testing Pyramid" taught me to build a foundation of many small, fast unit tests rather than re...

This week’s module was a distinct shift from the Agile methodologies we have been focusing on for most of the course. It was interesting to dive into the "Plan and Document" process, often called Waterfall, and see how it contrasts with the iterative approach we are used to. The most obvious difference is the structure itself. The lecture described this process as a series of phases- requirements, design, implementation, and verification, that flow downward like water. In our Agile labs, we are used to doing a little bit of design, coding, and testing all at the same time within a sprint. However, with the Plan and Document approach, there is a strict rule that you generally need to finish the current phase and produce a specific document, like the System Design Document, before you can move on to the next stage . One of the biggest takeaways for me was understanding why someone would choose this rigid structure over Agile. I used to think Waterfall was just "old fashion...

This week’s learning focused on the critical distinction between simple testing and the broader mindset of Quality Assurance (QA). I learned that QA is not merely a final phase of development but an attitude that must permeate requirements, design, and coding. A significant portion of the material covered the Therac-25 case study, a tragic example where a radiation machine malfunctioned in 1986 due to software failures, causing fatal overdoses. The root causes were complex: software was reused from an older model that relied on hardware safety interlocks which the Therac-25 lacked, and a race condition occurred between concurrent tasks when technicians entered data too rapidly. This taught me that we must design for faults, carefully analyze how software interacts with hardware, and never assume inputs will be reasonable. I also expanded my technical vocabulary regarding test coverage. I learned the hierarchy of coverage levels, ranging from basic S0 (Method Coverage) and S1 (Call Cove...

This week, I focused on Chapter 14 of Software Engineering at Google, which discusses the importance of "larger tests" such as integration, system, and end-to-end tests. The core concept I learned is "fidelity," which describes how accurately a test environment represents the actual production system. The text explains that while unit tests are excellent for their speed and reliability, they inherently lack fidelity because they test components in isolation. Consequently, unit tests often fail to catch critical issues that arise from component interactions, data configuration discrepancies, or environmental differences. To bridge this gap, software engineers must employ larger tests, accepting the trade-offs of slower execution times and increased potential for nondeterminism, often called flakiness. The chapter also suggests strategies to mitigate these costs, such as using hermetic Systems Under Test (SUTs) to isolate tests from external network noise and data var...