Opinion: Why I Became An Educator

[In this reprinted #altdevblogaday-opinion piece, Gamer Camp's Alex Darby explains how the perceived "worsening of understanding of the low-level underpinnings of programming languages" has driven him to become an educator.] I've always felt that my education left me woefully underprepared for the realities of the workplace, let alone the realities of the workplace in the Video Game Industry. I've learned almost all of what I consider to be the core knowledge required by game programmers out of necessity whilst doing my job; and each time I've made one of these fundamental discoveries, I've felt that there was no good reason why I couldn't have been told about it during my education. Kneel before the Sinclair ZX Spectrum+ I had no formal training in Computer Science before I studied for a degree in Computer Science, but, like most programmers of my generation, I learned to program in BASIC on one of the 1980s' many cheap personal computers – in my case a Sinclair ZX Spectrum+. Eventually, I ended up studying Computer Science at university (Jt Hons Comp Sci / AI & Psychology). When I went to university, C++ was still a new language and the template keyword wasn't in the language standard. In fact, according to Wikipedia, there wasn't a langauge standard until 1998, which is five years after I started university. As I assume most other people were back then, I was taught language syntax in lectures, and set a lot of coursework to force me to apply that syntax and allow my learning to be assessed. Unfairly or fairly, I genuinely don't feel that I learned anything significant about programming directly from the people who ostensibly educated me in it. I may have learned how to program whilst solving the problems that the lecturers had set; but I was taught far, far more by one or two specific people around me (thanks Nigel and Matt) when I was solving them than by the lecturers who had read language syntax at me. The BjibleEven back then in 1993 – before what we now think of as the internet was really in existence – the langauge syntax of C++ could be easily learned from a book (e.g. "The C++ Programming Language" by Bjarne Stroustrup – also known as the "Bjible"), but the syntax of the language isn't the code that executes – so why did no-one explain those parts of it to me? Ironically, I managed to sail through university and get a job at Codemasters with the functional level of knowledge that I had been given by a year's worth of C++ syntax lectures and coursework, but I was in for a massive shock when I actually started work. Two of the guys I knew at Codies were doing a Sega Saturn port of the PSOne version of Micro Machines V3. They had reverse engineered the opcodes of the Saturn's sound chip using a multimeter and an oscilloscope and, from what I recall, were using their findings to get extra texture memory by storing textures in sound RAM. At that point in time, I literally didn't know what the stack was, and heap was just another word for a badly organised pile. What those two guys were doing was literally and figuratively completely beyond me. Needless to say I learned fast, I had to. I was also lucky enough to be around programmers who had that level of knowledge and were more than happy to share it. Over the years, I have seen a consistent worsening of understanding of the low-level underpinnings of programming languages from graduates – which is, I suppose, to be expected given the ongoing trend toward teaching only Java on traditional Computer Science Degrees (at least in the UK). However, more worryingly, I have also seen a constantly surprising lack of low-level knowledge and understanding demonstrated by theoretically experienced programmers. One of my main motivations in becoming an educator is to try to address this issue; as most of the really horrible hard to track down bugs I've seen over the years have arisen from some subtle disconnect between what a programmer thinks they're asking the compiler to do and what they're actually asking it to do. Without a thorough understanding of the underpinnings of C++ – i.e. how the engine of the C++ language is implemented – you can't possibly properly understand the implications of the C++ code that you're writing. Even if you understand the way that C++ works internally then, sooner or later, you're still going to have to worry about the implications of any given implementational choice for the way the code executes on the specific hardware architecture it will execute on. It's a lot to take in. Very few people get it right all of the time – and I'm not foolish enough to claim to be one of them – but that's not a get-out-of-jail-free card… If you're only thinking about what you want the compiler to do, and not worrying about what you're actually telling the compiler to do, then you're much more likely to get it wrong. Remember: All code is bad, especially your own – and if it compiles first time and seems to work, then it's probably wrong. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]