CST 438 - Software Engineering Week 1

Git-ting Back in The Game

It has been some time since my last post due to my packed schedule, but I genuinely enjoy writing these blog posts to help lock in the weekly material covered in class.

GitHub

In CST 462s, I worked on the LibreOffice project, an open-source productivity tool suite with a behemoth codebase that was initially overwhelming to me. While daunting at first, it gave me practical experience with many of the concepts that will be covered in this class. I branched each piece of code I worked on, made several commits, and dodged merge conflicts like a pro. Along the way, I improved my ability to navigate complex repositories, collaborate with a large developer community, and adhere to industry-standard version control practices.

Software Engineering

Up until now, most of what we've been doing is programming, which is kind of like vibe coding compared to software engineering. In the real world, you're never just writing isolated, short-lived programs; your code will always interact with larger systems. Software engineering requires planning, foresight, and systemic understanding so vibe coded implementations don’t bring the whole house of cards down. Reading about Google’s development methodologies and contrasting them with LibreOffice’s was eye-opening. My team and I often dreaded rebuilding LibreOffice’s massive codebase, which could take up to eight hours depending on your device’s performance. That’s not a knock on LibreOffice; Google just has the luxury of optimizing every tiny workflow inefficiency, down to making sure engineers never run out of dry-erase markers. 

JUnit 

Unit testing is like a safety net for your code, ensuring every little piece does what it’s supposed to before the whole system comes together. We used mocks and stubs to isolate method behavior without relying on full project components, which helped keep tests focused and independent. This process is a skill in itself, and I know it’s an area where I could improve; especially when it comes to writing thorough, meaningful tests. Test-driven development, in particular, breaks my brain a little because I’m used to vibe coding, and TDD feels like starting at the finish line and working backward. It’s a totally different mindset, but I can see how it forces you to think more deliberately about design and functionality from the get go.

Summary

This week was all about getting into the groove of software engineering, diving deeper into version control, structured development practices, and testing. The shift from programming to software engineering is a big step, and it's precisely what developers in the real world are expected to do, making it perhaps the most important aspect of professional development.