This Trimester, I helped my lecturers run the Programming half of the SAE Study for a Day. The Study for a Days give prospective students the opportunity to do work related to their disciplines and get a feel for what they’ll be doing if they pursue game development. For me, these sessions provide glimpses into the skills and experience of these people before going in – and the skill gaps themselves tend to be very wide.
In the most recent SFAD, we created a digital Board Game Assistant, for students to apply to their pre-existing board game ideas. The Assistant would track the current turns, rotation of play, dice rolls in a number of scenarios and track points, with many more functions to spare. Our lecturer would guide the session, and myself (and a team of others) would assist with difficulties to keep the students on track. What makes the SFAD sessions so enjoyable is learning about the wide variety of students and their skill levels. A few students had more programming expertise than I think I would ever have in the next few years. Not all students shared similar skillsets and accommodating those without a long history of programming provides an interesting challenge.
Assuming No Knowledge Whatsoever
In many cases where a student is struggling, I always assume that they have little to no knowledge of the language and systems they are creating in. From square one, I explain – in general terms – what the problems they are encountering are, and why. Even if the issue is as simple as a missing semicolon, I explain why the missing semicolon breaks their code, and how they can keep an eye out for that bug themselves. For example, a few times some students were missing closing brackets for conditionals which broke their code. Here, the problem is that the missing bracket leaves the conditional open forever and the statement doesn’t know when to end. The reasoning is that all conditional statements rely on a separate block of code to contain their functions. If the code isn’t contained, the system may break or assume that all of the other code in the block belongs to it, executing it when its condition is met. When explaining faults, I assume no knowledge, in the hope that they learn something new about their mistakes and how to fix them.
Nobody wants to make mistakes, but we do nonetheless. Mistakes are inevitable, but they provide opportunities for us to learn from them. During SFADs, many students have never coded before in their lives, or not to a trimester one level. For some students, their self-confidence is in jeopardy when coding, and they may not be comfortable making mistakes that they think are obvious to others. In these situations, I try to apply a deft touch when speaking with them, assuring them that their mistakes are normal and get the best of all of us. In these situations, it helps to know that everyone makes mistakes, and empathising with them helps to cultivate their confidence and lessen the gap between their experience and my own.
I believe that a core component in helping students in all stages of their study is to try to engage them long-term. Coding can be a trial, so I make an effort to show them how it doesn’t need to be boring. Creating your own prototypes, working on projects from scratch, showing them the type of work that their skills will later contribute to, are all helpers in retaining motivation. Knowing that their game development idols do the same things they do helps to understand that we share the same burden, in my experience.
I try to bring these three things to the table whenever someone asks for help. Personally, these three methods have helped me through many of life’s challenges, and I apply them in the hope that someone stays on track for their own goals instead of falling off course.