Wednesday, April 11, 2012

The Demise of the Low-Level Programmer...

Andy Firth talks about a topic I've posted on several times:
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.
The gist of my earlier posts: I'm serially astounded just how productive it is possible for programmers to be without a well-rounded understanding of how computers work.   The understanding of floating point vs. fixed point arithmetic that Andy mentions is one of my favorite examples.  Though I work in a team packed with more-than-just-competent programmers, I doubt that one in ten of them actually understands IEEE-754 floating point representation.  Perhaps one in five could do a decent job of explaining two's complement arithmetic – and far less would have even heard of one's complement arithmetic.  I've had the same experience as Andy – many times – with respect to bit shifting (and bit twiddling in general). 

I won't say all this depresses me, as Andy says.  But it certainly worries me, especially with my experience working with Soviet-trained developers in Estonia who understood these things far better than my American colleagues.  Also, as I mentioned above, it surprises me that it is possible for programmers to become very good indeed without having this backdrop of deep understanding...

1 comment:

  1. Its funny, I've had similar conversations with friends about this. I think overall productivity is probably higher, you don't have to implement your own linked list code in every app for example, or your own file handling, logging etc., but the downside is the missing understanding of how these things work "under the hoods" which I think hurts debugging and troubleshooting ability the most. I was fortunate enough to work with some brilliant systems programmers early in my career and learned a lot and that was probably some of the most fascinating work I've done over the years. I think like a lot of things, the advances will increase productivity, but over time the detail knowledge will be lost to everyone but some specialists.