Software Engineering Was Never Just About Websites
12 May 2026
More Than Just Building Websites
When I first entered ICS 314, I honestly thought software engineering was mostly going to be about learning how to build websites. I expected to spend the semester learning frontend design, React components, databases, and deployment. While those were definitely important parts of the course, I eventually realized the actual purpose of software engineering goes much deeper than simply making web applications work. Software engineering is really about creating systems that are organized, maintainable, collaborative, scalable, and understandable by other people besides yourself. By the end of the course, I realized that many of the concepts we learned could apply to almost any large project involving teamwork, organization, and problem solving, even outside web development.
Agile Project Management and Organized Chaos
One of the most important concepts I learned was Agile Project Management, specifically a style called Issue Driven Project Management (IDPM). Agile Project Management is a method of organizing work where projects are broken into smaller tasks that can be completed gradually while adapting to changes over time. Instead of trying to plan everything perfectly from the start, Agile focuses on flexibility, iteration, and continuous improvement. In ICS 314, we used Issue Driven Project Management by creating GitHub issues for individual tasks, assigning them to milestones, estimating effort, and tracking progress throughout the project.
At first, this process honestly felt excessive. Creating issues, labeling tasks, assigning estimates, and updating project boards sometimes seemed slower than simply jumping directly into coding. However, the longer our final project continued, the more valuable this structure became. Without organized task tracking, projects quickly become chaotic. Team members accidentally overlap work, forget unfinished features, or lose track of bugs hidden somewhere deep in the codebase waiting to attack at the worst possible moment. There were definitely moments during the semester where a “small fix” unexpectedly turned into two hours of debugging while everyone silently stared at terminal errors like archaeologists trying to decode ancient ruins.
What surprised me most was realizing that Agile Project Management is not limited to software development at all. The idea of breaking large goals into smaller manageable tasks can apply almost anywhere. Research projects, robotics competitions, internships, event planning, scientific studies, and even personal goals could benefit from issue based organization. For example, in bioinformatics or AI research projects, large objectives like building a machine learning pipeline could easily be divided into smaller tasks such as collecting data, cleaning datasets, testing models, evaluating accuracy, and documenting results. Agile methods help prevent projects from becoming overwhelming because progress becomes visible step by step rather than feeling like one giant impossible objective.
When GitHub Stops Feeling Like a Backup Folder
Another major concept I learned was Configuration Management. Before this class, I mostly thought GitHub was just a place to upload code backups. I did not fully understand why version control systems mattered so much. Configuration Management is the process of tracking and controlling changes within a software project so that developers can collaborate without accidentally destroying each other’s work. Tools like Git and GitHub help teams manage versions of files, organize branches, merge updates, and restore older versions if something breaks.
This became extremely important during team development. There is a very unique type of fear that occurs when you pull changes from GitHub and suddenly your previously working project starts producing errors you have never seen before. Merge conflicts felt less like technical problems and more like emotional experiences. However, over time I realized Configuration Management is what makes modern collaborative software development even possible. Without it, large projects involving dozens or hundreds of developers would collapse into confusion almost immediately.
What makes Configuration Management important beyond web development is that it teaches organization and accountability. In many fields, whether engineering, research, design, or cybersecurity, projects evolve constantly over time. Being able to track changes, document modifications, and safely experiment without permanently breaking previous work is incredibly valuable. Even outside coding, version management concepts could apply to collaborative writing, research papers, scientific documentation, or creative media projects where multiple people contribute simultaneously.
Ethics, Responsibility, and the WatchMe Debate
A third topic that stood out to me was Ethics in Software Engineering. Before this course, I usually thought of programming as mostly technical problem solving. However, software engineering ethics emphasizes that software affects real people and real communities. Ethical software engineering means considering issues such as privacy, accessibility, bias, security, transparency, and the social consequences of technology.
One of the biggest realizations I had was that programmers are not just writing code in isolation. Software decisions can shape how people communicate, access information, apply for jobs, receive healthcare, or interact with governments and businesses. Even seemingly small design decisions can affect user experiences in major ways. This became especially meaningful to me during the ethics debate we held on the last day of class about facial recognition systems and AI surveillance technologies. Going into the debate, I originally thought ethics in software engineering mostly meant “do not hack people” or “do not intentionally make harmful software.” However, the debate made me realize ethical engineering is much more complicated because harmful systems are not always created by obviously evil people. Sometimes harmful systems are built by ordinary developers who are simply focused on making the software function correctly without fully questioning who could be affected by it later.
Our debate focused on a fictional company called WatchMe Inc and its facial recognition system called GetFace, which was being sold to law enforcement agencies despite violating several ethical guidelines involving privacy, informed consent, security, and citizen rights. During the debate, we discussed issues such as using people’s facial data without consent, the inability for citizens to access or delete their own information, the lack of dedicated security professionals protecting biometric data, and the possibility of racial bias or wrongful identification. What made the discussion so impactful to me was realizing that software bugs or design flaws in systems like these are not just “technical problems.” A false match in a facial recognition system could lead to someone being unfairly questioned, watched, or even arrested. Suddenly, code stopped feeling abstract and started feeling connected to real human consequences.
One idea that stayed with me was the discussion about bias in facial recognition systems. We talked about how some studies showed significantly higher error rates for darker skinned women compared to lighter skinned men. Before this discussion, I had never really thought about how an algorithm could unintentionally reinforce existing inequalities. It made me realize that technology is not automatically neutral simply because a computer generated the result. If biased training data or flawed systems are deployed carelessly, the software can quietly repeat and scale unfair treatment across entire communities.
The debate also changed how I think about responsibility as a developer. One of the strongest points discussed was that ethical engineers cannot simply hide behind the excuse of “I was just following orders” or “someone else would build it anyway.” The ACM Code of Ethics emphasizes that computing professionals should prioritize the public good, avoid harm, respect privacy, and carefully evaluate risks. That idea genuinely stuck with me because it reframed software engineering as something much larger than programming alone. A good engineer is not only someone who can make a system run efficiently, but also someone willing to question whether the system should exist in its current form at all. What made the debate especially memorable was how emotional and realistic it became. Instead of discussing abstract theories, we started imagining real scenarios. What if your own face was scraped online and placed into a surveillance database without your consent? What if an incorrect algorithmic match affected someone in your family? Those questions transformed the discussion from a technical classroom exercise into something deeply human. It reminded me that software engineering decisions are ultimately decisions about people. Ethics in software engineering extends far beyond web applications because technology now exists in almost every industry. AI, robotics, healthcare systems, financial systems, cybersecurity tools, and even educational platforms all require ethical decision making. The course helped me understand that technical skill alone is not enough to make someone a good software engineer. Developers also need responsibility, communication skills, empathy, and awareness of how their work impacts others.
Software Engineering Beyond the Classroom
Overall, ICS 314 changed my understanding of what software engineering actually means. At the beginning of the course, I mainly associated software engineering with writing code and building websites. By the end, I realized software engineering is really about collaboration, organization, adaptability, communication, and responsible problem solving. Concepts such as Agile Project Management, Configuration Management, and Ethics in Software Engineering are valuable not because they only help create web applications, but because they help people manage complex systems and work effectively with others in almost any technical field.