The demise of the low level Programmer.
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% 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 5 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 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. (feel free to suggest more/better links)
- Floating Point Numbers
- They are very useful but often used in situations where they simply don't suit the solution the programmer is attempting to write. The following links should provide some background and info on where they are not so useful, what the pitfalls are and sometimes even how to avoid them.
- Fixed Point Numbers
- Fixed point math is mildly old school but it is VERY useful both to understand its makeup and to use. Sadly because it is considered old school many of the online sources are out of date.
- Processor Cache Behavior / Memory
- Bit Shifting
- useful hacks (use carefully)
- Branch Prediction
- This may be lower level that people think they need to go... but they'd be wrong. Understanding how the hardware you're programming for treats branches can affect performance to a HUGE degree... far more than most programmers may appreciate re: death by a thousand cuts
- This isn't really low-level but something i consider "basic" and its an area where many programmers are simply lacking in understanding. Do yourself a favor and play around with this link, read the links it sends you to for each algorithm and try to grasp when each might be used, the properties as described and the next time you need to sort something... consult it.
- another good link with sub links: http://corte.si//posts/code/visualisingsorting/index.html
- a funny one (but still strangely useful), the bubble sort dance: http://www.youtube.com/watch?v=lyZQPjUT5B4
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.
Edit 8/8/2011 - It seems I didn't do a very good job at explaining the core audience for the article, I apologize for that. 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 HW is fixed for long periods of the time and resources become scarce usually within 1 game cycle; understanding how to better utilize resources becomes a key part of the job.
While i believe that most programmers would benefit from understanding more about the medium they work in it is certainly not required
Hopefully you enjoyed the article in the spirit it was intended.