You can’t run with the machines
I recently read “The Second Machine Age” by Erik Brynjolfsson and Andrew McAfee. The major points the book makes—that information technology and digitization is exponential, that automation is rapidly expanding into even cognitive tasks that until recently were thought doable only by humans, that the digital worldwide economy rewards winners and leaves even close seconds in the dust—are all quite well-known by now, but the authors have tied them together with a narrative that makes the book a good single place to read about them.
I particularly looked forward to the chapter titled “Racing With The Machines: Recommendations for Individuals”, in which they suggest what kind of work will be left for humans to do, and what skills we should try and develop to stay ahead of automation. I really wanted to know if they had cracked the nut of how we would stay gainfully employed. I was disappointed.
The the authors looked at prior attempts by Levy and Murnane that tried to predict limits on what activities would still require humans. They said that computers are good at following rules and bad at pattern-recognition, giving the example of driving a car as being too cognitively and sensorially complex to be automated. As the authors say in the book: “so much for that distinction.” Then they go right ahead and make their own prediction of the next frontier that computers will be unable to cross:
Our recommendations about how people can remain valuable knowledge workers in the new machine age are straightforward: work to improve the skills of ideation, large-frame pattern recognition, and complex communication instead of just the three Rs. And whenever possible, take advantage of self-organizing learning environments, which have a track record of developing these skills in people.
The biggest problem with this advice is that it is skating to where the puck is, not where it is going to be.
The example they lean on the most is freestyle chess where teams of humans and chess programs compete against each other (hence the title of the chapter). It turns out that the combination of a chess program guided by a human is more powerful than either alone. Freestyle chess is also a central example in Tyler Cowen’s latest book. Unlike Brynjolfsson and McAfee, Cowen wonders if this is just a transitional phase, and if humans will ultimately not add any value in this pairing.
Their recommendation about “ideation” and “large-frame pattern recognition” is not concrete enough. What does that mean specifically for someone choosing a college major today? And more importantly, can we be sure that those activities will remain out of the reach of computers by the time they graduate?
The debate about whether human thought is computable is an open one, but the vast majority of human cognitive activity does not happen anywhere near that threshold. In an ironic similarity to the diagonal cut, perhaps the only people secure in their isolation from automation are mathematicians probing the bounds of what is computable, and how.
But each one of the rest of us has to wonder if, within our lifetimes, our jobs are automatable. I program for a living, and while a good fraction of what I do is intellectually challenging, there is also some that makes me feel like just an operator.
Many non-technical authors think of Kasparov losing to Big Blue as a major milestone in AI, but that was largely due arriving at a point in time that Moore’s Law delivered enough computing beef to “solve” an exponentially complex game like chess. A more meaningful threshold would be when insight can be computed. For example, could a computer propose an algorithm with the simple elegance of Quicksort?
“Running with the machines” is a temporary strategy at best. That is simply the halfway house between humans doing something and it being fully automated. A more accurate phrase would be “run by the machines”, because cheap human labor is crowdsourced for the kinds of problems that are just barely outside a computer’s (current) reach.
I see two strategies for staying ahead of automation:
The first is to be the one doing the automation. In other words, to be a programmer. (Massive disclaimer: of course I would say that, being a programmer.) More bluntly, be the hunter instead of the hunted. The problem is that not everybody is able or willing to do that.
The second strategy is to be a doctor of machines. Large computing systems show organic behavior, and tending to them often requires the same mindset and behaviors as a doctor diagnosing and tending to patients. I like to draw an analogy to cities. A (relatively) small number of people initially construct the infrastructure (pipes, wires, roads), but a much larger number of people maintain them continuously.
We will have interesting lives.
More on fat vs thin clients
Ex-Googler Amit Patel made an insightful comment on my post about fat and thin clients that I totally agree with, and so I’m just going to reproduce it here in full:
1 - Net connectivity does not necessarily mean “thin client”. I can use net connectivity for data and still do a lot of processing on the client.
2 - The server/client power ratio doesn’t matter unless I’m actually trying to solve those large problems.
3 - There are some problems that need large machines and there are also some problems that could fit on either side. We’re not trying to figure out whether web search is going to be running on the phone. The real question is where the small things run.
4 - I do use my phone and tablet when I don’t have net connectivity. They are not bricks (maybe this is different in Androidland). Most of the things I do aren’t big problems. Even some previously big problems that only fit on a big computer now fit on my phone (like maps).
5 - Bandwidth and storage keeps getting better. Latency and availability aren’t improving much. Bandwidth and storage makes the “sync all my data among all my devices” model work for a larger and larger subset of my data. My data is not growing as quickly as storage, so I can see all my data fitting on my phone within a decade.
For any given problem, do I ever want to give up low latency and high availability to have it run on the server instead of my client? Generally, not unless it’s a much better experience to compensate for the slowness and unavailability. For most everything I do (text editing, word processing, photo processing, web browsing, games, email, social networking), it’s hard to justify.
Unfortunately most of today’s client apps are based on the old model assuming no networking. You email files around if you want to share. I think we can do much better by using synchronization among multiple clients as a fundamental building block. Data and compute stay local but when you have connectivity you synchronize with other places the data is stored. Google Wave was a stab at this. OneNote too, I think. Git does this for programming. DropBox is built on this model but it handles only simple synchronization at the moment. They have the potential to build infrastructure for apps to synchronize in a more structured way (like Wave), but I don’t know if they’re planning to do this.
Asynchronous Learning is More Inclusive
Maha Bala and Brad Meier take on the default assumption that synchronous modes are best for online learning. They make the argument that when expanded to a worldwide audience, enforcing synchronicity is incredibly biased: against certain time zones, against people with families who want to choose their own time, and against people who do not have the hardware or bandwidth for streaming audio-visuals. Asynchronous modes not only even out that bias but also promote deeper reflection.
[one of the authors] has had experiences facilitating web-based video dialogue, and even though she sees it could have enormous potential when it works well, very often it does not. When we learn online, we are not together in one room, and we need to recognize not only the limitations of that, but the openness of its possibilities.
The strengths of online learning, especially in massive courses such as MOOCs, and especially for adult learners, might lie in their asynchronous interactive components.
Read the whole thing.
Despite protestations that they are backed by “decades of research,” these claims don’t actually have much supporting data. They are widely cited, but it turns out that very few people think it worth their time to locate the original sources of the research and check what the data actually said. I spent a few months doing just that for my book.
What I found was that these claims owed most of their popularity to what the webcomic xkcd dubbed “Citogenesis”.
The process goes like this: someone acknowledged as an Authority makes a fairly informal claim, like “defects cost exponentially more to fix over time.” Later authors, looking to borrow the Authority’s authority, refer to the claim as “research.” A further generation counts these indirect citations as if they were themselves original research: the claim now looks very strong, as it appears to be backed by multiple replications. Later “studies” of the same topic may take the result so much for granted that they dispense with actually collecting the relevant data, but will still be counted as additional confirmation.”
– The Making of Myths, Laurent Bossavit
Consider a process to decide who receives some award or benefit; and suppose we want to make sure the process is not biased against some disadvantaged group, which I’ll call Group G. If a person just makes the decision, we can ask them whether they were fair to members of Group G. Or we can ask them why decided the way they did. Either way, they can simply lie about their true motivation and process, to construct a story that is consistent with non-discrimination; or they might honestly believe their decision was fair even though it reflected unconscious bias. At the risk of massive understatement: history teaches that this kind of bias in human decision-making is difficult to prevent.
An algorithm, by contrast, cannot hide from everyone the details of how it reached its decision. If you want to know that an algorithm didn’t use information about a person’s Group G status, you can verify that the Group G status wasn’t provided to the algorithm. Or, if you prefer, you can re-run the algorithm with the Group G status field changed, to see if the result would have been different. Or you can collect statistics on whether certain parts of the algorithm have a disparate impact on Group G members as compared to the rest of the population.”
– Algorithms can be more accountable than people, Ed Felten
The Automatic Corporation
Corporations can be thought of as information-processing feedback loops. They propose products, introduce them into the marketplace, learn from the performance of the products, and adjust. They do this while trying to maximize some value function, typically profit.
So why can’t they be completely automated? I mean that literally. Could we have software that carries out all those functions?
Software could propose new products within a design space. It could monitor the performance of those products in the marketplace, and then learn from the feedback and adjust accordingly, all while maximizing its value function. If the product is a webapp, most of these steps are already within the reach of full automation. For physical products, what’s missing is APIs that allow a program to order physical products, and move them around in the physical world.
A limited version of what I’m describing already exists. High-frequency trading firms are already pure software, mostly beyond human control or comprehension. The flash crash of 2010 demonstrated this. Companies that are centered around logistics, like FedEx or Walmart, can be already thought of as complex software entities where human worker bees carry out the machine’s instructions.
This happens naturally, because over time more and more of the business logic of a company becomes encoded in software. Humans still have some control (or so they think) but mostly what they’re doing is supplying parameters to the computation. A modern corporation is so complex that it does not fit in the brain of a single person (or a small number of persons). Software carries the slack.
The intermediate step to a fully automated corporation is one where tasks requiring humans are performed not by employees but are broken into micro-tasks and fulfilled by crowdsourcing (using, for example, services like Mechanical Turk).
Corporations do not scale, and eventually die. That’s because they scale sub-linearly. Their productivity metrics scale by an exponent of ⅘ on the number of employees.
I hypothesize that the management overhead which makes corporations grow sub-linearly is due to the limited information processing capability of individual humans. People at the top do not have local on-the-ground information: how are individual products performing, what are customers’ complaints etc. And the rank-and-file folks on the ground do not have the relevant high-level information: how does what I’m doing translate to the value that the corporation as a whole seeks to maximize? In fact, the the flow of value and information is so complex that employees have pretty much given up on determining that relationship, and know of it only at a macro P&L-center level.
An algorithm will have no such problems with acting on both global as well as fine-grained local information. In fact, I suspect that the more information it gets to act on, the better decisions it will make, making automatic corporations grow super-linearly.
One objection to being a purely automatic corporation might be that it precludes visionary, groundbreaking products, because it resembles incremental hill climbing and is susceptible to get stuck in local maxima. But a visionary, groundbreaking product is (initially) indistinguishable from picking a new random point in the product space, and hill-climbing from there. There is no reason why the automatic corporation couldn’t allocate some fraction of its resources to exploring new points in the space completely unrelated to its current neighborhood.
The CEO of an automatic corporation will be a devops engineer: fixing software bugs, writing “features” (i.e. new ways for the corporation to behave), watching performance dashboards (imagine all the pretty graphs!), and providing some vestige of human input to tune parameters used by the software. Eventually they can take their hands off the steering wheel, having configured everything to run on auto-pilot, and set up alerts to page their phone if something really goes wrong.
Automatic corporations will start within narrow domains, where the product design area and value functions are relatively simple. But they will gradually move upmarket. This is a familiar pattern in the dissemination of most new technologies. There will be a smattering of small automatic corporations by the end of the decade.
Pebbles and Projects
I’m growing increasingly frustrated with how little today’s patchwork of messaging/email and docs matches my workflow needs.
What I really need to keep track of are not emails and docs and appointments, but projects.
Imagine these emails/docs as pebbles, and each project as a collection of pebbles. This project is red pebbles. That one is blue pebbles. Yet another one is yellow pebbles. Then imagine throwing all of them on the floor. Then imagine being asked “can you construct for me a coherent state of all the yellow pebbles?” That’s how it feels trying get a high-level view of a project from all these pebbles flying around.
I feel like email and shared docs are like assembly language, and we need an abstraction above them. The analogy is fitting, because a high-level language is restrictive: you can do more things and have more control in assembly. But with the restriction comes freedom to express more complexity more succintly.
The problem with every project management solution that I’ve seen is this: it assumes it is the only thing in the world. “If you use this tool, and only this tool, and capture every little detail as it happens, then this tool will give you a coherent state of the world, yaaay!” Of course, life never works that way.
I’m not saying this is an easy problem to solve. I don’t even know what a first approximation of the solution would look like. But I do know there an opportunity here.
“The lighting field has its own Moore’s Law, an LED counterpart called Haitz’s Law. In 2000, Dr. Roland Haitz, then with Agilent Technologies, predicted that the cost of LED lighting will fall by a factor of 10, while “flux per lamp” (what we call brilliance or luminosity) will increase by a factor of 20 per decade. How long that trend will continue is also a matter of intense debate, but solid-state lighting (SSL) technology is based on semiconductor components, so the technology price fix is in, at least for now, and lighting is likely to keep getting cheaper.”
– Drowning in light
I’ve been following Venkatesh Rao’s writing since he achieved net stardom with his Gervais Principle essay. Gotta be honest—it’s heavy reading and requires way more concentration than the regular popcorn the net serves up.
But in a departure from his usually cold hard intellectual style, his recent piece about how the quality of light affects our work and our rhythms really tugged at my heart. A lot of that was because of the most powerful rhetoric device—nostalgia. Because I grew up in India in the 80s and 90s and also went through those load-shedding hours. It was inconvenience, boredom, excitement and respite all rolled into one.
Dark evenings without power were a special time for children. The candle-lit hours on porches and balconies were a strange mix of an ethereal kind of intimacy, beckoning darkness, and thoughts that retreated from both sunlight and electric lights.
You could do nothing useful during those hours. There was no TV or radio. Reading was difficult. Candle-lit meals tended to be either quick, simple affairs whipped up in semi-darkness, or leftovers. Families who turned the blacked-out evenings into family time generally sat out on the porch. Adults would use the time to tell family stories to children. Teenagers and some couples would stroll up and down the street, occasionally stopping to chat with neighbors. Younger kids would run around squealing and playing, seemingly possessed by the strange euphoria-inducing forces leaking in from another world. Or they would huddle together and try to scare each other with ghost stories.
The tool divergence
It used to be that the platform on which most software was developed was also the one on which most of it was deployed—-the personal desktop computer. As a developer you only needed one machine.
Now, the target deployment platform is an app for a phone or tablet. But you still need a big desktop machine to develop them.
The first effect of this development-deployment divergence is that it cements the new position of the desktop as a specialized factory machine.
But another effect is that it raises the barrier to casual hacking. In the PC age a kid who wanted to write software just needed to download a bunch of simple tools and was off running. But today that kid would need to setup a complicated toolchain on a beefy desktop. And that too in an age when they think of desktops as something quaint, and might very well not even have one, because their “primary device” is just their phone or tablet.
Even the term “primary device” probably sounds funny to them. Growing up if someone asked me what my primary device was I’d laugh at them because my PC was my only device and it was all I needed or wanted.
So here’s my wish—-and challenge. Make it so that a young person who gets the urge can code and build something on their phone or tablet. I suspect it will be easier with the extra screen real estate on a tablet, but the big problem is the same. Make it so that some of that infinite interstitial time that their phone soaks up can be filled with programming. What if at the end of that Apple ad the teenager presented his family with a cool app rather than a movie?
The Programming Language Consensus
If you look at features in mainstream programming languages over the last couple of decades, they seem to be converging around a common set of core features, surrounded by fashion, preference and whim. These core features are:
- first class functions
- lists and maps are part of the language
These features first originated in dynamically typed scripting languages like Python. (Well, they originated in Lisp, but then everything originated in Lisp.) Then they gradually found their way into statically typed compiled languages like C++1 and Java. Some of the most anticipated features of Java 8 are lambda expressions and type inference.
There is a subtle distinction between succinctness and expressivity. Expressivity almost always leads to succinct code. My favorite example is list comprehensions. But succinctness is also about omitting unnecessary verbiage. A good example is type inference enabling the omission of spelling out types.
Go had all three from the get-go.
Two things that are not yet part of this common core are objects and concurrency. I almost added “object orientation” to the list above, but then Go’s model of defining structs and interfaces made me think otherwise. It reminds me of Niklaus Wirth’s philosophy of understanding programs by looking at their data structures first. As for concurrency, there are wildly different ways of expressing it, but I have a hunch that the CSP model adopted by Go (and Erlang) will prevail. Maybe in another few years there will be five items on the list of common language features.
This is a good thing, because it looks like we’re gradually finding our way towards abstractions and constructs that are proving to be widely useful and broadly applicable. It is also rendering irrelevant many of the PL community’s fiercest debates. The agitation over static vs dynamic types starts fading when a C++ or Java code snippet with range-based for loops, lambdas and omitted type declarations looks very much like a Python or Ruby one. I was also surprised to see that while Go is very much a systems language, in chatting with other programmers I found Go eating more share from Java and Python than C++.
“Most writers manage to get by because, as the deadline creeps closer, their fears of turning in nothing eventually surpasses their fears of turning in something terrible.”
– Why Writers Are the Worst Procrastinators, by Megan McArdle
I’ve followed Kevin Kelly’s work for a while, and in my humble opinion he is our foremost apologist for technology. If you want an introduction to his work, this Edge interview is a dense yet readable summary.
I call myself a protopian, not a utopian. I believe in progress in an incremental way where every year it’s better than the year before but not by very much—just a micro amount. I don’t believe in utopia where there’s any kind of a world without problems brought on by technology. Every new technology creates almost as many problems that it solves. For most people that statement would suggest that technology is kind of a wash. It’s kind of neutral, because if you’re creating as many problems as it solves, then it’s a 50/50 wash, but the difference in my protopian view versus, say, a neutral view is that all these new technologies bring new possibilities that did not exist before, including the new possibility of doing harm versus good.
Many years ago, before I had a GPS-enabled smartphone with maps, we went on a roadtrip along the coast of Maine, stopping at nearly a dozen lighthouses. When I look back, I myself am surprised that I was able to pull that off without clutching my phone the whole way. But it was a memorable roadtrip. We saw all the lighthouses we wanted to see, and got a glorious experience of the Maine coast.
How did I navigate? In the days (weeks?) before the trip, I drew maps on paper of our entire route, with all the places we wanted to see. I used Google Maps as the source. It was probably tens of pages of hand-drawn maps. It was tedious, but it did have advantages:
I wish I had saved that paper, because it would be a memento as evocative as the pictures from that trip.
(In 2001, LineDrive tried to address some of these issues by automatically generating driving directions in a style similar to hand-drawn maps.)
I tell you this story not to reminisce about my travels (well, maybe a little bit) but to point out that analog artifacts still have affordances that give them advantages over digital devices. Even today, for complex multi-hop trips I prefer to hand-draw maps on paper.
I want my digital interfaces to be more organic and analog, and my analog experiences to make it into my digital corpus effortlessly.
“In publishing, meanwhile, the deal with the customer has always been dead simple, and the advent of digital has not changed it: You pay the asking price, and we give you the whole thing. It would make little sense to break novels or biographies into pieces, and they’re not dependent on the advertising that has kept journalism and television artificially inexpensive and that deceives the consumer into thinking the content is inexpensive to make.”
– The Publishing Industry is Thriving, by Evan Hughes