Justin Li

Software Engineers

2015-11-21

There is an Atlantic article on software "engineers" that got a lot of press, and in general I agree with the message that programmers need to be conscious of the societal implications of their work. But I actually find its thesis a little confused. The author seems to be arguing that we should stop using the "software engineer" label, while simultaneously saying that software failures can lead to increasingly large disasters - a problem that removing a label won't fix.

Then there's the "hermetic" argument, that "real engineering" engages the world, unlike software that seems limited to the digital realm. Well, sure, but you don't blame the civil engineering if a new bridge made traffic worse. The "software engineers" at Uber are not doing anything wrong - it's Uber the company that's flaunting transportation-services oversight. I would also argue that sometimes software wasn't written to be used in large scale - the Shellshock bug was discovered in 2014 but was introduced in 1989, before most of the Internet was using Linux (or really, before the Internet actually existed), which necessarily means the damage would be contained.

To be fair, this does not apply to programmers writing code that allow data breaches - but perhaps that's illuminatory. As the article itself says, software engineer "could mean anything from Javascript programmers to roboticists". The problem is not the "engineer" - it's that "software" is so broad that it is meaningless in this context. I suspect that one reason why software has proved impossible to certify (outside of limited areas) is that there is too much of it, and it's changing too quickly. A civil engineering undergraduate curriculum is mostly stable, which is good, considering we have been building bridges for three thousand years. Software, in comparison, has only existed for thirty years, about one percent of that period, and there's barely a concensus on what must be taught at the undergraduate level. That doesn't necessarily excuse its failings, but it makes them understandable.

One wonders how nuclear engineering, which has had much the same time frame, came to develop so quickly. Arguably, it's that the demand for nuclear engineer is nowhere as high as the demand for software "engineers".