5 min read
Opinion: Why I Became An Educator
In this reprinted #altdevblogaday-opinion piece, Gamer Camp's Alex Darby explains how shoddy understanding of low-level programming drove him to become an educator.
Kneel before the Sinclair ZX Spectrum+
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.]