Web application coding projects are about as complex as anything a student has ever encountered in their entire lives. There are so many moving parts: the variables, the functions, and the debugging of the code are already challenging, without introducing the way web pages, cascading style sheets and JavaScript programs interact (or don't, and having to figure out why).
Debugging is excruciatingly difficult, because unlike straight JavaScript programs it is much harder to figure out why something did not happen. There is often no simple "Console Log" error message. Students need to run through how the application is supposed to work in their minds, putting in various flags to figure out at what points things break, and then come up with theories about why it said "undefined" instead of "2".
Having worked out all the complexity, students then attend to craftsmanship, learning their brand-new web design skills (deciding what elements to put where, and how to style them with fonts, colors, and images). A "natural" coder who is facile with logic and structure may be quite awkward at design at first, just imagining what they want to see before they struggle with the realization of their designs.
Because the decision to hold this elective was made over the summer, we did not have much time to recruit in the fall, and ended up with just two students. One was an experienced programmer, and the other totally new to it. By the middle of the quarter, both students were equally challenged or joyful when engaging with hard problems and then discovering the solutions that make everything work. Coding is hard, and fun. Ask them!
Developing RPS was quite the challenge for me. I was still new to coding and had only been working with simple concepts. It was pretty fun learning more and more different ones though.
Bugs in RPS were frequent so I was stressed half of the time but the relief of figuring out a solution was completely worth it (with Mr. M's help usually).
Anyways, I experimented with HTML and CSS for the first time with RPS. It isn't as difficult as it looks, although it meant even more concepts to remember which isn't something I have much strength in.
I think this program is when I realized that even when coding is fun, it WILL give you a headache. In my opinion, that's the best part :)
This is a refactoring of Mr. M's version, which he maintains is the best possible game-based training for coding.
My first major project was very engaging throughout the entire process; from design to implementation, there was always a puzzle to solve. That's what it felt like really, in making this game, I was really just playing puzzle games in class. To add to this fact, Mastermind is itself a puzzle game, so my experience coding has basically been solving a puzzle game of puzzle games about a puzzle game.
The first step was literally playing Mastermind until I figured out how it worked, afterwards, I drew up diagrams to help me write down how exactly Mastermind worked. Even then, I still write a single piece of code until after I was done drawing the user interface for the program. When I did begin coding, since I had already made a framework for me to follow, all I was really doing was translating English to code, and Googling how to solve any problems I found along the way. Lots and lots of Googling. Through this project, I experienced firsthand the fact that coding is really just a Googling simulator disguised as a profession.
- Kevin Le
My second project was considerably easier than my first, in part due to it essentially being a copy of my first project (Mastermind). Thus, I mainly coded in the ability to type in characters (instead of selecting colors), reworked the user interface to display letters instead of just colors, and reworked the program to work with letters instead of colors.
These three things were no easy feat, however, as I had yet to work with coding keyboard inputs into programs, so I had to consult Google. It was through this project, I really got into the groove of trial and error with Google by my side.
Later, I compared my first version of Wordle to the original. From this, I adjusted how I wrote code massively; rather than creating large walls of code that would overwhelm anyone not innately familiar with its inner workings, I decided to compartmentalize every bit of code that I could, which I think made my code a lot more readable in the end- a fact that I am very proud of. I also picked up new "vocabulary", or rather, snippets of code from the internet, that I added to my mental toolkit, which is something that I am glad I did.
- Kevin Le
Tic-Tac-Toe took 2 months to finish- and just in pop-ups. Its logic is pretty simple to me now but when I first started working on flowcharting the code, it didn't seem so.
I'll admit that this program was way more stressful than RPS. For example, I had to utilize "forEach" which did NOT make sense to me for a while. It was really useful for my "diag" functions though.
Besides its complexity and annoying bugs, developing Tic-Tac-Toe was enjoyable. I'm thinking of making a web-based user interface on my own time!
Unlike my previous two projects, I was coding this project in a completely new paradigm/coding philosophy. Whereas coding functions (as I did prior) was similar to writing a cooking recipe, object-oriented programming was more like managing a restaurant: each "object" (block of code) had defined tasks and would give and take ingredients and dishes to and from other objects, and "classes" are like different professions, so some "objects" have the same class, like how there are multiple chefs working in a restaurant.
After flowcharting the logic behind Tic Tac Toe, Mr. Moreinis wanted to experiment with ChatGPT (an artificial intelligence that will probably take over the world in the next decade) and asked it to produce an Object-Oriented Programming version of Tic-Tac-Toe in JavaScript, which it managed to do near perfectly. As a challenge, I never referenced this "cheatsheet" except at the very beginning to marvel at the power of our new gods, and so off I went, first designing the user interface, and then afterward delving into the logic behind the program.
- Kevin Le