More than just Programmers

I came this article yesterday. In brief, it talks about a group of veteran programmers – 20+ years of experience, these guys – who lament about today’s programmers lacking the skill to work at low levels of software or even hardware, content to stay programming at high-level languages with their work. It talks about debugging hardware, optimizing loops, and sitting down to architect a solid design prior to coding.
And as I read which skills I lack and am apparently worse off without (and I’m not even sarcastic here, I fully admit to not knowing how my Python code gets babelfished to assembly), I was annoyed that the previous generation of engineers didn’t seem to understand the workflow of the modern developer. We didn’t have the luxury to flowchart out giant systems, because the infrastructure and requirements kept on changing anyway, and we had to think about how the end-user would screw up their input, not to mention handling all the flakey third-party API’s.
Hence my haughty response: a lot of programmers today do more than just programming.

In fact, understanding the business realities is a pretty important skill expected of today’s developers. Agile product management came into popularity because spending months refining a spec and more months implementing it wasn’t an effective technique to create products – requirements change, technologies change, and system structures change. Building shakily on top of MySQL and ActiveRecord might cause pain in the long run, but it may not even matter if product would not exist because it took too long to architect the “right” engineering.
Abstraction seems to be lost to this group of veteran developers as well. The idea that having a lower layer’s implementation details be abstracted by a friendlier interface is a core principle in computer science, a concept that makes complex systems manageable and understandable. True, there are instances when abstractions break down and it makes sense to dig past it for performance, but today’s hardware advances have made computing cycles cheap and storage effectively infinite. The right thing to do is profile bottlenecks and optimize based on results, not prematurely optimize a loop to brag that, well, you can optimize a loop.
Then there’s that difference in software complexity in the past 10-20 years that make a FORTRAN command line program vastly different from a Python controller generating HTML and Javascript to be interacted by an end user expecting a pleasant user interface. The software stack itself has become more complicated, so of course engineers are going to specialize in parts of the stack; it’s like an old doctor complaining about how today’s ontological surgeons don’t know how perform lobotomies.
It really comes down to a shift in popularity. No doubt there are engineers who work close to the hardware, figuring out exactly when in the GPU pipeline the voxel loads into a register or the memory footprint of an OS after a cold boot, but the most popular software fields happens to be mobile and web, which is what today’s engineers have focused on and developed skills around.