How can engineers approach a race against the machine?
Not long after struggling with how to approach work and automation last month, I happened to pick up Nicholas Carr's The Glass Cage (2014) and Eryk Brynjolfsson and Andrew McAfee's Race Against the Machine (2011), which cover some of the same territory. My perspective is similar to Carr's in that we both acknowledge that machinery has brought us many benefits — I even make my living from building more machines and teaching other people to do the same — but remain nonetheless wary about uncritical adoption of machines that at first seem handy helpers, but ultimately prove to be inadequate replacements for human skills and/or straightjackets from which we cannot extricate ourselves.
So what should we be automating, what should we be leaving alone, and how do I reconcile my profession with the possibility that the machines I build will transfer wealth and dignity from the people who used to do the work, to the owners of the machines? As Brynjolfsson and McAfee note, the orthodox economic view is that new jobs have appeared to replace the automated ones — and we've done pretty well by this in the long run — but there's no known principle of economics that assures us that this will proceed always and forever.
The first principle that occurred to me was to recommend that we adopt machines only when they enable us to do things that could not have been done without them: new technologies must be more than faster ways of performing existing work. This also fits with my doubts about the pursuit of fast and easy as a path to satisfaction.
This principle has at least one flaw, obvious to anyone familiar with arguments in favour of economic growth: automating a specific task that could be done by a human may free that human to do something that he or she couldn't do before for lack of time, energy or resources. The orthodox view I mentioned earlier depends on exactly this kind of process. For this reason, I don't think the principle could be sensibly applied on a task-by-task basis.
Nonetheless, the principle gets at what we surely want from machines in general: why bother with them if they simply leave us doing the same things as before (even if we can do them faster)? What's more, Carr points out that being "freed up" isn't much consolation if it means being unemployed and without access to resources that might enable the victim to make use of their notional freedom.
That I can't apply the principle on a task-by-task basis, however, makes pursuing it very difficult: I have no way of determining the worth of any particular engineering project in light of it. (Not that I often get to make such determinations: my need to pay my bills means that what I do is dictated as much as by what other people are willing to pay for as by my private views of what would make the world a better place.) Perhaps the principle isn't hopeless, but it requires a better formulation than what I'm able to come up with at the moment.