My CS Online Journey

This week covered asymptotic notations and algorithm analysis, which felt math-heavy at first but started making sense once I applied it to my homework. The textbook reading explained the three main notations: Big-O for worst-case upper bounds, Big-Omega for best-case lower bounds, and Big-Theta for when both are the same. I found the Theta notation video helpful because it showed concrete examples of when to use each one. The best part of this week was seeing how analysis applies to real code through both homework problems. HW2_1 (Closest Pair Problem): I needed to find the minimum distance between any two numbers in an array. The brute force approach would compare every pair, which takes quadratic time. Instead, I sorted the array first and then scanned consecutive elements. This is much faster because sorting takes n log n time and scanning takes linear time. After sorting, the minimum distance must be between adjacent elements, so I only needed one pass through the array. HW2_2 ...

This first week was a solid refresher. I started by watching the video on Euclid's algorithm for GCD. It was insightful to compare it against the basic consecutive integer checking method because it proved that brute force is not always the best answer. Sometimes a simple mathematical insight saves more time than a faster computer ever could. I also worked on Homework 1 this week. The assignment asked us to check for palindromes while ignoring symbols and case. I chose to create a new filtered string with only alphanumeric characters first. It was a good exercise, but it made me think back to the Algorithm Analysis Framework videos. Since I created a new string, I effectively used extra memory space. This connects directly to the space and time tradeoffs mentioned in the syllabus. I also spent some time reviewing the Graph representations and Trees videos. I realized I need to be careful about choosing between adjacency matrices and lists depending on whether the graph is weighted ...

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...