Okay, I’ll be real—coming into this class, I thought it was just going to be about building websites. You know, the usual HTML, CSS, a little JavaScript, maybe slap on some React and call it a day. But no. This course was a crash course in how to not fall apart when building software with other people. Between pushing broken code to GitHub, writing issues at 1am, and figuring out what the heck a design pattern even is, I realized this class wasn’t just about making things look pretty on a browser. It was about learning how real software engineers work—especially when you’re tired, the deadline is tomorrow, and your team is ghosting you.
Two things that stuck with me most are Agile Project Management (specifically Issue Driven Project Management) and Coding Standards. They’re not flashy, but they make life way easier when used right—and I can see them being useful outside of just building web apps.
Before this class, “project management” just meant writing everything in Notes and hoping for the best. Then I met Agile. Agile is a way of managing software projects where you work in short cycles, delivering small chunks of working stuff instead of one big final product. It’s like doing your homework in parts instead of cramming the night before. (Something I aspire to do.)
We used a specific kind of Agile called Issue Driven Project Management (IDPM). Basically, everything we wanted to do—fix a bug, add a page, update a button—got turned into a GitHub “issue.” Every issue had a person assigned, a deadline, and a clear description. It sounds simple, but when your brain is fried and you’re juggling five other classes, having a list of things to do spelled out in one place is a lifesaver.
Each week, we had milestones with specific goals. One week it was just getting the pages to render. Another week it was making sure user login worked. The point is, breaking things down like this helped my team stay focused and actually finish the project without panicking last-minute (mostly).
I could totally see myself using IDPM for stuff outside of web dev. Even for a group presentation or a personal side project, it helps to break things up, assign tasks, and just make sure everyone knows what’s going on. No one likes carrying a group project, and this helped keep it fair.
Another thing I didn’t think much about before this class was coding standards. At first, it felt nitpicky. Like, why does it matter if I use camelCase or if my file has an extra space at the end? But after working on a team project where multiple people touched the same codebase, it definitely mattered.
Coding standards are basically rules for how code should look and behave—things like naming conventions, indentation, file organization, and even what kind of comments to use. We followed a style guide for JavaScript/TypeScript and React, and while it felt strict at first, it made our code way easier to read and debug (especially when we were all exhausted and just trying to fix one bug without breaking everything else).
What clicked for me was realizing that coding standards aren’t about being perfect—they’re about being consistent. When everyone’s code looks the same, you can jump into any file and figure out what’s going on faster. That applies anywhere you write code, not just websites. It’s something I’ll bring with me to future internships or even just personal projects, especially if I ever work with other people again.
So yeah, this class was a lot more than just making web apps. I learned how to organize chaos (thank you IDPM) and how to write cleaner, more understandable code (thanks, coding standards). I didn’t always love the grind, but I’m glad I stuck with it. These tools will definitely help me not just as a programmer, but as someone who works on teams, juggles tasks, and wants to do more than just copy-paste from StackOverflow.