Seemed an especially relevant discussion, given my recent immersion in Intel (where they build chips that run the assembly code spat out by compilers – or that generated by really hardcore software engineers).
Every once in a while I get lured in by the taunts from these demi-gods: until I learn the depths of what’s going on behind the scenes, having a true understanding of how the software works (and how to make it work/work better) will continue to elude me.
I pride myself on being able to dig deep to troubleshoot weird/opaque issues, and to come up with better ways to make existing software work. No matter how much I already know about TCP/IP headers, registry structures, sysinternals tools, APIs, and DLL dependency mapping, my natural curiosity always gets the better of me. I want to be able to answer the next layer of questions, and to do that it seems I have to keep peeling away the layers of how my computers work.
I must’ve hit a natural inflection point recently, as I finally made the leap from skimming other people’s code to writing my own. I can’t exactly say whether it was just time + frustration that finally drove me over the edge, or if I recently reached some level of expertise in my problem-solving skills. One way or another, something finally allowed me to be able to articulate the problems (and possible steps to solving them) that is necessary to both articulate achievable software requirements and write the code that might actually approximate fulfilment of those requirements.
All that said, I think it’s hard to imagine going from VB.NET to Assembler without envisioning a cliff-face learning curve. Good freakin luck making that leap. I’ll be lucky if I get my brain wrapped around C++ and Java in the next year or two, let alone non-OO languages or their machine-level equivalents. Heh.
So what does this thread on Slashdot tell me, exactly? It’s a typical array of folks like me just trying to earn a living, along with the requisite grumpy old farts and disrespectful kiddies. Seems to me that there are three main bodies of opinion:
- The largest number of folks are fine having some level of understanding of what goes on between the CPU microcode and the high-level programming languages – i.e. the actual compiled code that’s run by the CPU. If you don’t understand what’s going on under the hood, then you’re likely to make some pretty classic mistakes that lead to less-than-stellar performance, security or both.
- So long as you can *read* some assembler and maybe add a dash of ability to predict how your own code might behave at this level, then you’re worthy of being called a professional coder.
- One poster commented, “It’s good to know what goes on under the hood, sure. But in many, many software developer tasks, early optimization is the root of all evil.” I’m in full agreement with this philosophy – diving into the code head first (or head-up-arse first) does no good if the purpose for writing the code isn’t understood, and the major functionality hasn’t been demonstrated to be possible (let alone workable as a whole).
- Multiple posters made the point that, while a really skilled developer can write really efficient and elegant assembly code, 99% of developers are (a) hacks or (b) wasting time doing something that quality, modern compilers do really well these days. “It’s no use being a mediocre assembly programmer.“
- The folks I really love are the hardcore “That’s no’ oatmeal!” types – until you can write your code directly in assembler, don’t bother me kid, and I hope your code never tries to infiltrate my box. Keep your crap code out of my way, ’cause obviously you suck until you’ve mastered byte-by-byte electron pushing.
However, there was one insight that really caught my eye: [among the reasons you might need proficiency in assembly language] “You’re writing malware to exploit a buffer overflow vulnerability.” Those writing the really quality malware these days are taking advantage of any and every layer of the software stack – that’s where the money is, and it’s where you can stay as far ahead of the originators of the software you’re exploiting as possible. [Given the increased entree of organized criminals into this arena, I expect the incentives for skilled coders here to only increase.]
And I can’t wait for the hackers to focus their attention on exploiting implementation idiosyncracies in the virtualization stacks and the underlying hardware – CPUs, chipsets, video, I/O, storage/mobo/video/networking firmware, etc. etc. etc. Imagine trying to roll out fixes for hardware… (rolled eyes)