Finishing up debugging my last testcase for my final project in ICS 314, I’ve become super surprised about how much time I spend in a flow state of fixing bugs and implementing features, very happy with the fact that I easily pay no mind to how huge the final iteration of the spaghetti codebase has actually gotten. The culmination of all the the core software engineering concepts was tested in this final project. We went through concepts like:
Just to name a few.
The development of these skills really crept up on us slowly. I went through near-failure after near-failure of the weekly code exams we were required to do in ICS 314 not really understanding how quickly we were progressing through all aspects of fully functioning software furnished with databases, user interfaces, and fancy algorithms. My final project isn’t the last place that these skills are going to be crucial for; they’re things that are core to a future career in software engineering.
Throughout this class, I’ve noticed that development environments have been one of the most frustrating aspects of software engineering, simply because of the number of moving parts that go into them. Put in a simple definition, development environments are places where programmers or software developers can implement changes to their software. These changes are made on their local system, not on the production system, in order to not disrupt regular service. These systems often require plenty of configuration and they also often break due to many reasons related to software updates, missing packages, or simply misconfiguration. Additionally, when developers collaborate on software, they often have to run a local copy on their own machine, syncing with others using version control. Since many applications require all kinds of pre-built software to run properly on their local machine, it gets very tricky for developers when they want to work together.
Fortunately, the systems and tools used to run these development environments can actually be very simple to grasp conceptually, and personally, they’ve made me really appreciate how easy I have it in the modern age. This class has helped me get a taste of how developers actually run their code in real systems. It may not exactly be meteor framework (our web app platform of choice), but the formula for setting up development environments is generally very much the same for Javascript programming. For most projects utilizing Javascript, node package manager (npm) was used to maintain all of the additional software.
For the most part, the meteor framework and node package manager does all the heavy lifing for a developer. Sure, it may be more complex to use these environments compared to running toy programs off a single javascript file or applet, but no modern web app runs off the development environments you’d find in an intro programming class. ICS 314 is meant to prepare students for realistic, practical development. One of the biggest things I’ve learned from this class is learning to grasp the fundamentals of setting up these complex frameworks and learning that there really is nothing scary about working with massive frameworks with so many moving parts
In this class, we’re expected to develop our skills in building practical software using a variety of standard technologies. When it comes to building apps, we don’t just build everything from scratch. Much like when we join a company, we have to inherit a codebase with defined design patterns and structure. In this class, we use plenty of open source software to build out applications. Open source software includes any type of software that is freely able to be inspected, modified, and enhanced. These open source software can be freely copied and used in any project, and these projects are even allowed to make money from the project, not needing to give a single thing to previous developers of the open source software.
Who would ever write code for free? In the realm of software, open source work is extremely commonplace. Developers have so much access to so many tools that make it relatively simple to create real, working applications. There is absolutely no way a single semester can teach us the intricacies of these top to bottom software frameworks, but there’s definitely enough time to get good at working with what’s already been invented.
I’ve always known about open source tools and software, but one thing this class has taught me was the mindset to use for the use of what’s already been built. For example, in my final project, I considered coding an image selector from scratch, but decided that an open source solution was going to be quicker to implement, easier to understand, and probably (definitely) higher quality than what I was going to create.
Open source software is incredibly useful and has definitely changed the game in this field. I’m really glad that there has been a great overview of the critical aspect of developing software that incorporates other peoples’ work, so we don’t have to reinvent the wheel.
Am I really ready for the outside world of software engineering after taking the class called “software engineering?” I’m actually not really that sure, since I’ve never really worked in a software engineer context. I do know that I’ve developed a lot of confidence in the realm of software engineering, and I think that I’m comfortable saying that I can build working software.
I’m not saying I have the skills to build the next facebook, but I do think that this class has helped me develop the mindset needed for building such things. Even in my career, I hope to learn even more about these concepts I just learned about in this class. I hope that in my career in whatever industry I land up in, that I can remember the positive impact of ICS 314.