Automation for the people: The programmer's dilemma

In the delicate relationship between technologists

"Use the left lane to take the Treasure Island exit," the voice on Luann's phone said. That didn't make sense. We've only lived in the Bay Area for a few months and had never driven across the Bay Bridge, but I'm still embarrassed to say I failed to override the robot. As we circled back around to continue across the bridge I thought I heard another voice. It sounded like Nick Carr saying, "I told you so!"

In "The Glass Cage," Carr considers the many ways in which our growing reliance on automation can erode our skill and judgement. As was true in the case of his earlier book, "The Shallows," which grew out of an Atlantic Monthly article with the sensational title "Is Google making us stupid?," "The Glass Cage" has been criticized as the antitechnology rant of a Luddite. 

But Carr is not only describing a real problem, he is also pointing to an important and necessary solution. Killing the machines isn't an option. They are our essential partners from now on, for better and worse. We need to figure out how to improve that partnership.

That's a responsibility both users and developers of automation must shoulder. As users, for example, we can be more mindful of what's being automated on our behalf. It's easy to forget about our spam filters, for example. Occasionally we should review what they hide from us. But we want no news to be good news. We are creatures of habit, and the habit of doing something occasionally is tough to acquire.

Of course we users can also wield our own automation. Recurring calendar events are an excellent way to remind ourselves about occasional tasks. Setting a biweekly reminder to check your junk folder might help you do it. Yes, I'm mindful that using one form of automation to monitor another points to an infinite regress.

Here's a better example: When I bought a Sears dishwasher years ago, I was told I could call annually for five years to schedule an appointment for a checkup. This wasn't part of the extended warranty, which I'd declined. It was preventive maintenance, and it was free, but you had to call. I set up an calendar alert that fired once a year to remind me to make the call. They always sounded surprised to hear from me, but they always came.

When you create a recurring event you're writing a simple program whose pseudocode might be: "Once a month, pop up a reminder to review my junk filters." It's a natural thing for a programmer to do and an example of the sort of computational thinking that many others can profitably learn and apply. How do we transfer that knowledge and encourage its use?

People learn by imitation. If you're a natural automator, modeling that behavior within your team or organization may be a way to lead by example. But be careful. Showing people how to create recurring calendar events is one thing; showing them how to configure Web servers and write nontrivial code is another. If you can do those things, and the situation requires them, you might be a candidate for a role I call "toolsmith."

Here's how not to think about that role:

Bruno Oliveira

It's not about winning and losing, it's about working together. My most enjoyable and productive experiences as a toolsmith look more like this:






The second chart captures a lot of what I've learned about how to automate a manual workflow in a team setting. The toolsmith is, crucially, an embedded member of the team, enacting the same workflow as everyone else. Discovery of opportunities to automate, deployment of interim solutions, and evaluation of outcomes all form a collaborative cycle. When everyone's a stakeholder, including the toolsmith, humane automation can emerge.

That's a delicate arrangement, of course, not applicable in many situations. How do we replicate the pattern and scale it out? The answer, Nick Carr says, is "adapative automation," a regime in which people and computers work together, trading awareness and control in a fluid back-and-forth exchange. It's far-fetched to imagine we can create software that behaves like a toolsmith who is also a participant and stakeholder. But that might be a useful way to think about what adaptive automation could be.

Read More Updates :- Techies | Update