Opinion: The Demise Of The Low Level Programmer

[In this reprinted #altdevblogaday-opinion piece, Bungie's Andy Firth laments the "low-level" programming skills that many coders are forgoing today, and offers resources for concepts he believes all console programmers should know.] When I started programming, many of the elements we take for granted now did not exist. There was no DirectX, and not many compatible libs were available for the free compilers of the day. So, I had to write my own code for most basic programs, keyboard handlers, mouse handlers, video memory accessors, rasterizers, texture mappers, blitters… The programs I wrote then were 100 percent my own code, and I had to be able to handle anything and everything. Personally, I've always been interested in what was going on under the hood, so this suited me just fine. I always dug into the details, and I almost always end up programming as close to the bone on the hardware (or OS) as I possibly can both to eek out as much performance as possible and to satisfy my own hunger for knowledge. Combine the two, and what you get today is someone who enjoys spending five days making that single function 20x faster, who revels in reducing the memory footprint of the primary data structure by 1 byte per element across the entire program whilst simultaneously writing a pre-caching system to avoid the special case issues,  who... well, you get the picture. I'm an OCD-level sport optimizing geek. To such a degree that I keep a notepad by my bed to take notes when I wake up from a "bug fix" dream or a "eureka optimization" doze. Yes, I'm that sick. Over the last decade, I've been involved in the hiring process at many studios, and in more recent years, I've noticed a pattern. Knowledge of what is generally considered "low-level" programming is waning. Many programmers know enough to get through a C# or C++ test, but they don't understand something as basic (and important) as the behavior of memory or god forbid a cache. They don't seem to grasp that one must understand the native environment you're working in before going ahead and writing a program to run within it. The intricacies of floating point vs fixed point math are completely lost on them as the term "fixed point" brings about a blank stare; "floating point numbers are best right?" I once mentioned bit shifting to an experienced engineer of 10 years and was devastated by the complete lack of basic understanding. It depresses me that so much of what I consider to be essential is simply not being taught anymore. I'm not talking about assembly language per se; even those of us who used to spend hours writing assembly now more often opt to use intrinsics built into compilers to avoid the stress and complication. What I'm talking about is simply the understanding of what is happening when someone does i++ and not ++i, why one might opt to stripe a memory copy/set in certain circumstances. So here goes... a list of things I believe all console programmers (and recommend to all programmers as good reading) should fully understand with links to educate where possible. The programmers I would like to see learning and absorbing these "low level" details are those who would see themselves working in console games. The hardware is fixed for long periods of the time and resources become scarce usually within one game cycle; understanding how to better utilize resources becomes a key part of the job.

So, there you go, I've likely missed some aspects that should make the list but if you can grasp the above then you're more likely to get noticed at interviews and you'll certainly be a better programmer for it. Feel free to suggest more/better links! [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.]