In University Wednesday afternoons are dedicated to sports, as this is when most BUSA sports teams play. However, if they’re not interested in sports the students get the afternoon off, and this leaves a gap in the timetable that we couldn’t help but fill.
“Rather Useful Seminars” are dedicated to things that we think the students might find rather useful, but that are not appropriate to put into the main curriculum. I did a couple recently, and sandwiched between them, like the glorious filling between two past their best crusts of bread was a great talk from games industry veteran David Clark. Now I’m cramming all three into one blog post!
My first crust was immediately after the three thing game, and was about getting your game into the market place. It was more about the “Why” than the “How”, and the aim was to convince students that even though it’s unlikely that they will make a lot of money, getting a game (or games) out there is a great way to bolster your portfolio, and a way to get networking. Maybe “publishing games for employability” would have been a better title. Still, I cited some success stories from the games industry, and looked at what that success took, and I talked about the non-monetary goodness you get from publishing.
The following week Dave Clark did his thing again. He gave a great deal of insight into the business side of the industry. What publishers are for, how their role has changed etc. It was a fascinating talk and I know I won’t be able to do it justice here. I would like to extend my thanks for the talk though. A highlight was that Dave also mentioned the importance of networking. It’s something that typical computer scientists don’t enjoy very much, but it opens doors to where you want to go – so it’s got to be done. Thanks again Dave!
Last week I did a seminar on how to comment code. I talked about how commenting is hard, because comments aren’t compiled, they aren’t tested, and there is little feedback as to what makes a good comment. Then I gave some examples of code that I had commented and asked the students which pieces of code were commented well, and which were commented badly. We face a bit of a problem when we’re teaching students code, because often we use comments to tell the students (as people who don’t understand code) exactly what the code does. In the industry (where everyone can read code) this would likely be regarded as over-commenting and cluttering up the code base. A better approach is to consider Why you are doing something a particular way, instead of How.
I also covered using comments to document your code, both through intellisense and using tools like Doxygen, and the worst comment of all – the comment that is incorrect!
The students responded really well to the examples, and seemed to understand what I was saying. Whether they can put it into practice is another matter though. I knew exactly what I was saying, yet I still find commenting my own code well and extremely difficult thing to do!