What did I learn this semester? In full honesty, it wasn’t until the final project that I started to feel like I was truly learning something. Coincidentally, the final project was our first expedition into creating a website from the ground up, with functions according to a given prompt by our Professors. Ours was a Trading Card Simulator, and I felt with blunt force my limitations as a Software Engineer and a group member. I’m familiar with a handful of TCGs (Trading Card Games), and so I knew what functions people expected of a digital Trading Card website, but could I execute what I had in mind?
Arguably my favorite part of this semester came in the discussion of User Interfaces. It’s almost a matter of reducing explanations to their most simple, yet recognizable forms. A lot of the fun that I had in this portion of the course came from figuring out how to word something. Here’s a snippet from my personal Trading Card Simulator UI that I was messing around with in private. This didn’t make it to the final deployment of our TCG Simulator, as I was uncertain if it would even function, but it ended up being a nice visual study regardless:
You’ll see me select a Philip Johnson card to offer into a Marketplace. In exchange, I request a Scott Robertson card. That is to say, I’m offering, to the market, one of my Philip Johnsons. And, in exchange, my request is that the other user gives me one of their Scott Robertsons. The information needed for the user while they’re making their trade request is a must. How many copies of their cards do they have? If unknown, they’ll be hesitant to trade at all considering said card might be their only copy. Which card(s) are they missing? Ideally, wouldn’t they want to receive a card they have 0 copies of? Users should get a look at their card collection before they trade, but displaying a massive window with said collection might be too jarring, so let’s make it smaller. But then, how will the user know they’ve selected the right card to trade when they’re all so tiny? Alright, we’ll display a zoom-in on the right to ensure the user knows what card they’ve chosen.
And on top of that, the popup’s display text! Users should always be aware of the cards they’ve selected, so let’s show their names on screen. Let’s make it obvious which card they’re “giving away” and which card they’d like to receive “in exchange” via a text-based confirmation alongside a visual one so that the user can trade with full assurance that their selections are intended. My goal with this entire spiel was to make this screen “obvious”. There shouldn’t be any fear of the uncertain or unknown in such a simple process, so I always thought to myself: “What if this was my first time doing anything?”
My second most favorite part of this semester came from elements of functional programming. There’s still so much that I don’t understand about Software Engineering safe practices and basic mechanics that I can’t proclaim at all that I’ve truly experienced functional programming, but I’ve enjoyed what little I’ve been able to achieve so far. There was a lot of variable passing and inheritance between programs, ergo, giving other functions data using the data generated or defined in prior functions, even between different files, that was present in my last couple weeks of coding that I hadn’t done at all in previous months during class. I likely bit off more than I could chew, but that sense of being tossed into the pool and forced to swim lit a fire under me that acted as crucial motivation during these final weeks.
All in all, what I’m left wondering is what exactly the classes ahead of this one teaches. Are there more basics to learn? Will we now enter the path of specialization and branch off into different skill sets? In terms of now versus then, I’m a lot more confident in being able to pass this course with a much higher score if I take it again. But that doesn’t translate into sheer mastery over the course contents. However, what I’ve got now is a good pace. Best that I keep it going ‘lest my learnings atrophy.