I only started my teaching career at the start of this year, fresh out of university, as a bit of extra income while trying to get Pub Games off the ground. Depsite the intention of it being stop-gap work, I’ve quite enjoyed the challenges that I’ve faced, and its been extremely rewarding to see some of the work thats come out of my students so far.
As a bit of background, I’ve been teaching level design and game design theory, and applying them practically using primarily UDK. My first class was a VET class, which is where a group of students from high school (mostly aged 15-16) come in one half-day a week. This is only the second year that games has been taught at this TAFE so there were some fairly unknown factors going into this year, but by and large its been fairly successful. Successful enough that the institute asked if I was interested in teaching an UnrealScript subject in another course, which I gladly accepted.
I’m only a few weeks into teaching this subject, but so far its a whole new and different challenge – certainly much different to what I expected it to be. These students have prior programming experience through a semester of Java. This part has been fairly beneficial, as syntactically and conceptually, UnrealScript is most similar to Java in its design.
Unreal does alot of things somewhat unconventionally. Theres alot of basic configuration required just to get code to compile, or to get a mutator appearing inside of its UI. Editing ini files, localization files and setting up package structure is something that is preferable to avoid, but in this case its necessary. I could have run with teaching Java games programing, XNA, or something similar. But the goal for this class was to produce something with tangible, fun results throughout the semester, and Unreal makes that fairly easy to do.
I expected that teaching the structure of Unreal – directory layouts, relevant files to keep in mind, etc – would be one of the more difficult things. I was spot on there. But the primary and most unexpected challenge that I’m facing is the lack of what I call “structured logic” – thinking about how to create and structure a function, class, application.
TAFE is primarily a hands-on approach, rather than the lecture-lab/tutorial split that University has. At TAFE, the goal is to get students actively involved and working for the duration of the class, rather than talking at them for a few hours, and then setting them on a task for two hours. For programming, this presents a huge issue with the sheer amount of theory that needs to be taught. Luckily, alot of basic concepts were taught during their semester of Java, which has gotten me off the hook there. However, being able to break up a problem or task in order to decompose it into a set of variables, functions and logical steps has been quite the challenge.
I’m fairly disappointed in myself for not expecting this, and even for taking two classes to realize it. For the UnrealScript subject, I set out with some assumptions – which I’ve found to be wrong – and aimed to create a fun creative semester getting the students to create fun mutators and crazy weapons. That being said, I think new teachers generally set out to teach too much and underestimate the amount of work that can be involved in conveying what they might see as simple concepts. Understanding how people learn, and figuring out different ways to explain the same concept until everyone understands it IS teaching at its very core.
I still haven’t figured out a good way to teach structured logic yet, however I have a good idea on where to start. To me, one of the most invaluable techniques that any programmer – especially beginner programmers – can learn is the Pseudocode Programming Process, or the PPP. The PPP is a process whereby you structure your class/routine using purely English-like statements, and then write code around those comments. I first read about it in Code Complete and there are some discussions about it online, notably none other than Jeff Atwood’s Coding Horror post. While I agree with Jeff for the most part – I personally don’t use the process and prefer to think in code – I think it can be a very valuable part of a teachers toolbox when approaching problem solving and structure.
The second challenge that I’ve found is something that I’ve always taken for granted, and thats general IT skills. Within the first few weeks of my VET class, I instructed my students to mount and run DOOM through DOSBOX. To my horror (although once again, I should have expected it) most of the students had no idea about how to use a command line! Similarly, alot of habits that seasoned developers get into like use of shortcut keys, information identification and even typing speed present issues that must be overcome in the process of teaching.
In the end not only are you teaching programmming, or level design, or game design. You’re also teaching alot of “soft” IT related skills that are crucial to being productive in this specific field. This relates back to the earlier point of underestimating the amount of work involved in teaching. If your sole goal is to teach programming, or level design, then I’m sure that much more content could be crammed into a subject. But what use is teaching that if the students lack other skills that can enhance their overall productivity and ability to learn in the future?
Theres a common and somewhat disrespectful saying that “those who cannot do, teach”. As someone who feels fairly competent in what they do for a job, I see two main purposes in teaching.
Primarily, its to spread your experience and knowledge from the real world. Alot of teachers, especially at universities, come from purely academic backgrounds and often lack real world perspective and experience. Having set up a studio, putting processes and infrastructure in place and running into real world roadblocks gives you so much more insight into the practical challenges that graduates will face from day one on the job.
As a secondary goal, there is alot of self-improvement to be made while teaching. I’ve found that I’ve become far more proficient with UDK as the year has gone. Not only that, but plenty of students are very creative and will challenge your own creativity and approaches to problem solving.
Several years ago if you told me that I’d be teaching and enjoying doing it, I would have laughed. But I now see myself enjoying some of the challenges and benefits of being a teacher. I’ve also started teaching an introductory programming subject at university, where I’ve encountered many of the same challenges. This shows that the issues discussed in this post are probably not isolated to just a few classes. Instead, perhaps we need to look at harder requirements and understanding of technology before students take on programming.
The main piece of advice I was given before I started teaching was “teach how you would like to be taught”. I genuinely believe that one of the great advantages I had as a student was the relationship and interaction I had with my teachers, especially outside of class. One lecturer in particular at university was almost like a mentor for me. His door was always open for a chat. This was my goal – to not only be a teacher, but to be a mentor. To be someone who was accessible to all of his students. Not just in those 5 hours a week of class time, but all week. Building a great relationship with your students seems to be a key factor to both your own improvement as a teacher, and getting the best out of every student you teach.