Coming into this class, I was intimidated, but optimistic. It would be my second time taking 314, something I found embarrassing to admit in earlier essays. I even recall writing a similar reflection around this time last year. I didn’t have the most programming experience, especially when compared most of my peers, and naturally the imposter syndrome constantly lurked in the background. Despite this, the class never felt impossible. I wanted to properly digest the classwork, instead of repeat my past mistakes and mindlessly complete the work. I did the work, I rarely missed an assignment, and even came to some of the TA sessions. So what did I learn exactly? What did I gain from this course that wasn’t as apparent my first time taking it?
One thing I should make clear is that there is never one tool that can do everything perfectly, every tool has its advantages and disadvantages. The same can be said with development environments. For example, I’m writing this essay in IntelliJ, which is capable of integrating project specific definitions and lets you easily edit programs while being aware of the language you’re writing in. While I could’ve written this in something like Notepad, IntelliJ lets me check if I have any typos and I can also have a live preview of what my final essay will look like before publishing my changes to GitHub. It’s more complicated to use but for larger projects, like my final group project, having these integrations and definitions can greatly expedite the time I spend writing code. The simpler things are, the more often you’ll be doing them. Once you get the hang of learning how a development environment works, things like changing the name of a method become exponentially easier. When I first got into programming and had to use jGrasp, another developer environment, to write most of my programs, I thought it was generally fine but I never realized how simple and obsolete it actually was. It taught me the importance of possessing a broad experience of differing tools. Once you try new tools, their strengths and drawbacks become contextualized and better inform your development choices in the future. You don’t have to do something the same way everytime, sometimes it’s better to experiment and reflect.
In summary, configuration management extends beyond web application development and plays a significant role software engineering. It ensures consistency, traceability, and reproducibility, regardless of the target platform or system. A common exercise I had to do was ensure I had proper versions of NPM and node so that my programs could function, even if the versions were not technically the latest version. Staying on a stable version, rather than mindlessly updating each and every component of my configuration, is imperative when making sure systems don’t break, important in more than just web development. It also makes it easier to debug your system when you have this consistency in place. This taught me the importance of version control, having to routinely keep multiple versions of the same software with the expectation that I may have to switch to another version if something breaks. This also taught me a broader lesson: If you’re gonna work on something… always, always, always plan in advance and prepare for the worst case scenario. Even if you plan something ahead of time and it sounds fine in theory, assume something will go wrong. And if you’re collaborating with other people on one project, something will definitely go wrong. Trust me when I say that planning ahead and talking things out with your other colleagues takes way less time than you think it does, and more importantly, saves more time in the long run.
This course went from being one of my hardest classes to being one of my favorites. There’s not much else I can say other than it challenged me in many ways. The amount of practical knowledge I gained from the WODs and all the other assignments were instrumental in making me a more competent and informed software engineer.