Reflection on Software Engineering

11 Aug 2025

Reflection on Software Engineering

Coming into this class, I honestly thought it was just going to be about making web apps. I figured we’d learn some frameworks, build a few projects, and that would be it. But pretty quickly I realized the bigger goal was to understand how software gets built in a way that’s organized, sustainable, and works well when you have more than just one person coding. The web development part was just the toolset. We were really learning the foundations of software engineering that can be used anywhere.

One of the first big takeaways for me was configuration management. Before this class, I knew Git existed, but I mostly used it as a way to upload code to GitHub without really thinking about version control as a discipline. Now I see it’s way more than that, it’s about keeping track of every change, understanding who did what and why, and making sure nothing gets lost in the shuffle. When we worked on group projects, branching and merging kept us from stepping on each other’s toes. I can see how this would be crucial outside of web development too. If I were working on a research project that used complex simulations, keeping track of different versions of the code and data would be the difference between getting accurate results and wasting weeks on bad runs.

Another big concept for me was Agile Project Management, specifically the version we used called Issue Driven Project Management (IDPM). At first, the idea of breaking everything into “issues” and tracking them in a project board felt like extra work. But once I got used to it, it made things so much easier to manage. It forced me to think in smaller steps instead of just staring at this huge list of things I knew had to get done “sometime.” I also liked how IDPM made it obvious when we were making progress, closing an issue felt like a mini victory. I could definitely see myself using this for non-coding projects too, like organizing an event or managing a video production schedule. It’s basically a way to keep things moving forward without getting overwhelmed.

Lastly, design patterns really clicked for me this semester. At first, they seemed kind of abstract like, why not just write the code that works and move on? But the more examples we saw, the more I realized that patterns are about building things in a way that can be reused and understood by other developers. We used the Model-View-Controller (MVC) pattern a lot, which kept the data, logic, and UI separate. I can see how the same thinking would apply in, say, building an app for a sensor network, keeping the data processing separate from the visualization makes it easier to change one without breaking the other.

Looking back, I think what I learned in this class will stick with me long after the details of the web stack fade. Configuration management taught me how to work with others without creating chaos. Agile and IDPM taught me how to stay organized and make steady progress. Design patterns taught me how to think about code as part of a bigger system, not just a one-off solution. These aren’t just web development skills, they’re skills I’ll be able to carry into whatever kind of software (or even non-software) projects I take on in the future.