Once More, Unto the Breach
08 May 2023Once More, Unto the Breach
To be honest, after finishing Software Development I, I didn’t plan so far ahead that I knew I would be taking Software Development II years down the line, especially since other classes held me back at the time. In the end, this class challenged my ability to create a website for a customer with specific needs, and not because I had to put project-based coding on hold for the past few years to focus on other classes.
Where’s First Gear Again?
It really has been a while since I last worked in a group to deliver a website. Only this time, that website has to be built to a customer’s needs and demands, not the group’s internal goals. The last time I worked with Meteor and Mongo was around 2019, which meant that my skills with those languages were a bit on the rusty side. All the pieces were there, though, so I just had to see what I did for the 314 class. The difference, though, is the presence of Bootstrap, which I had no experience using. It took a lot of documentation reading, but I managed to piece together some knowledge to get through it. That didn’t stop me from messing up every now and again, but triple-checking the documentation was a lifesaver.
Two Steps Forward, Three Steps Back
When we first started the project, we had thought that the customer wanted the website to be a scheduler. Something like a calendar that shows a room’s availability over the course of a week. To that end, I was assigned to work on a date picker component so a user would be able to reserve the room for one reason or another. Visually speaking, the component was supposed to have a popout with a calendar on it and the user was able to select the date by clicking. From there, other components were able to use the data from the calendar component. To that end, I went out in search of a pre-made component or package that could be integrated into the project. The first one seemed straightforward, but unfortunately I couldn’t seem to get it to work for some reason or another. This issue persisted for a few weeks. At least until I managed to find a different Meteor package that worked with the project that. However, then came time for the customer milestone. That was when we found out that customer didn’t necessarily need a scheduling website, but one that kept track of the rooms, the staff assigned to the rooms, and the resources each room had. This meant that whatever was being worked on for the room requests would more than likely be scrapped. Whaich meant that the date picker I speent so much time on would be scrapped as well. It’s honestly disappointing to know that it was all for naught but we all had to re-orient our goals to something closer to what the customer wanted. Still, it could have been avoided if we contacted the customer and just asked for clarifications so we wouldn’t have had to waste so much time on a feature that wasn’t meant to be, but in the end, hindsight is 20/20.
Murphy’s Law Rears Its Ugly Head
There’s an old adage known as Murphy’s Law. And that law states that anything that can go wrong, will go wrong. With coding of any kind, this law rings true. Specifically when it comes to coding, there would be variation of it:
Code never works perfectly the first time around.
Over the next few weeks, after I shifted focus to the admin management page and the room tab on that page, its been a slew of bug hunting and squishing. Once a feature was “added”, it was a hunt to find everything that could go wrong with a page. It’s an inevitable truth that as coders, we have to find where and how the code breaks and make it so that the code doesn’t break when similar situations pop up. Some of the errors are minor, like the alignment of parts of the website that could be easily fixed by modifying a few values or adding an extra <div> statement. Other errors were of the “break the website” kind, where the core functions of what we were trying to implement just plain failed. With the latter, it’s a good thing we were working in a team. I would have hated to bang my head against the keyboard trying to figure something out on my own.
Last to Pick, Last to be Picked
Often, when new issues pop up, I’m admittedly not the first to jump at them unless they’re directly related to an issue I recently completed, leaving me to pick from a few of the less-desired things to fix or implement. It’s often a bit frustrating, especially when it’s related to something I intended to fix. It can’t be denied that these issues need to be taken care of sooner rather than later, either. I should have shown greater initiative when picking issues to work on so I could push my skills even further, but sadly, I did not. Granted, there were certain personal events that hampered my motivation which shouldn’t be used as filler in this essay, but in the end, that doesn’t constitute much of an excuse. In the end, I need to work on taking up the initiative in future projects.
Into the Wild Blue Yonder
After all that’s said and done, now what? I’m starting to feel like this is just a part of the navigation section of a flying lesson and I’ve yet to be able to land the plane on my own. But like learning to fly, if I’m ever to get anywhere, I’ve got no choice but to put my hands on the controls and fly. And if I’m to get anywhere near competent, that means I have to keep on practicing. While this class was a challenge, I still have a long journey ahead of me if I want to call myself competent in programming. One cannot simply pilot an aircraft from Honolulu to San Francisco without knowing how to land the plane, after all. And I speak from experience in that regard.