Jen Pahlka and Clay Shirky at Code for America Summit

I’m at Code for America’s 2013 summit in San Francisco today, an impressive gathering put together by an extremely impressive civic innovation organization. I’m one of the advisors to Code for All, a sister project to Code for America led by Catherine Bracy, old friend from the Berkman Center, and was able to meet the first Code for All partners from Jamaica, Germany and Mexico at CfA’s amazing headquarters yesterday.

Code for America has done something pretty astounding. They’ve found a way to bring geeks into local governments to build innovative new projects in a way that’s fiscally sustainable. They’ve got support from the governments who host these geeks and from the central players in the US tech economy, and they’ve emerged as a central organizing node for the government innovation community.

Jen Pahlka, the founder of Code for America, opens her remarks with the classic Margaret Mead “Never doubt that a small group of people can change the world” quote, and admits that she never got her degree in anthropology because the classes were too early in the morning. She notes that many people working on civic change feel like they are a small group, though we’re able to come together into a movement today. She hopes that this isn’t a movement of sameness, but of diversity, which sometimes creates conflict and chaos. When we come together, we get new applications and APIs, but more importantly, we get a community and a common mission.

The common beliefs of this group include the idea that government can work of the people, by the people and for the people, even in the 21st century. We have in common the idea that we can do things better together. Code for America welcomes anyone who has these values, and – and here she emphasizes her words very carefully – are doing something. Code for America is a reaction to Tim O’Reilly’s injunction to the tech industry to “work on stuff that matters”. CfA, she tells us, works on the stuff that matters the most.

Jen is supposed to be working as deputy CTO under Todd Park in the White House on a yearlong break from the organization… though she’s on furlough at the moment. She explains her decision to move into government for a year by explaining how inspired she is by people working in government. “In order to honor all of you – all the public servants in government and the fellows to work with them – I felt like I could not pass up this experience.”

Answering the inevitable question: “How’s it going in DC?”, she answers that it’s both deeply rewarding and the hardest thing she’s ever done, including starting Code for America. She offers warm thanks to Bob Sofman and Abhi Nemani who’ve been leading the organization during her year off.

Clay Shirky start his talk at the Code for America summit with some internet history:

Larry Sanger is an epistemologist, hired into one of the few epistemology jobs, working on Nupedia, a new encyclopedia working with experts to build a carefully fact-checked new encyclopedia. Nine months into Nupedia, they’ve created about a dozen articles. Sanger realizes this isn’t working and goes to Jimmy Wales, the guy who hired him, and suggests using Ward Cunningham’s wiki software. Wikipedia is born and the rest is history – in weeks, it outpaces Nupedia and Nupedia rapidly shuts down.

Patrick McConlogue, a New York city entrepreneur who works at Kickass Capital, caught sight of a homeless guy on the streets of New York and proposes teaching him to program as a way of addressing the problem of “the unjustly homeless”. McConlogue never bothered to learn the homeless guy’s name, and the details of the story led to ferocious online criticism of McConlogue’s plans to teach a homeless man to program. In the criticism of McConlogue, Shirky was struck by the idea that tech startups encourage thinking that doesn’t consider limitations and constraints, which might be appropriate for the tech industry, but doesn’t work well in the social change space.

This sounded wrong to Shirky, who started re-reading the comments through this lens, looking both at the criticisms of McConlogue’s idea and the voluminous criticism of Leo, the homeless guy, for being homeless. Matt Yglesias was similarly skeptical, but looked at possible solutions: how do we address homelessness, which begins with looking for ways to create affordable housing. Clay draws a distinction between this sort of helpful criticism – which was very harsh to McConlogue’s approach, but ultimately helpful – and corrosive criticism, which doesn’t make you smarter but just tries to get you to stop looking at the problem.

Clay notes that he’s lived through two sorting out times: the question of whether the web would be important, and questions of whether social media would spread. In these periods of sorting out, technology looks like a solution in search of a problem, because at that point it is. Over time, we find answers to the question – will it work? will it scale – and it ultimately does. Clay suggests that we’re now at that point with civic media. We need to listen to the helpful critics, and we need to stop listening to the corrosive ones so we can keep moving forward.

“If you want to feel like a genius, go to a place where people are doing something new and predict that they’ll fail. You’ll almost always get it right. It’s a cheap high.” There’s a great deal of space between “nothing will work” and “almost nothing will work”. The easiest problems to take on, Clay tells us, are pure technical problems where you just need information. It’s not an accident that applications to report potholes are the great success story in this space – there’s no pothole lobby. Potholes are projects and they have solutions.

One step up from technical problems are managerial problems. In starting a bike sharing program in New York, the organizers posted a map and asked people to request bike stations. The resulting map, where everyone requested a station outside their homes, was a rhetorical document that helped build support for the program. Managerial problems don’t just solve technical problems – they have to do with building support and constituencies for solutions. And then there are political problems.

It is not possible to imagine a city without prostitutes, Clay tells us. People don’t agree what the goal is when they address prostitution. Some people want sex work to stop and some people want it to be a better job. At the political level, you’re not dealing with problems – you’re dealing with dilemmas and you only have tradeoffs, not solutions.

When people want to distract you, Clay tells us, they tell you the problem you’re working on is not the real problem. “Don’t work on potholes – work on traffic flow citywide.” Work at that scale and you’ll get criticized for not working on something concrete and achievable because you can always find a way to criticize a project’s scale.

Clay urges us to understand that the most important resource we’ve got is our own ability to change our minds. As he got on the plane to come to San Francisco, he learned that Leo, the homeless guy with the javascript books, got arrested for sleeping in the park. McConlogue saw that Leo had been arrested and has tried to bail them out of jail. Clay argues that McConlogue has turned from someone who characterizes people as “justly homeless” to someone who tries to bail a homeless man out of jail. Whether or not he will end up being a fairy godfather to Leo, or forgetting about this project soon, McConlogue would not have learned what he’s learned without starting with the wrong idea and testing it in the world.

The possibility of learning as you go is the potential of the people in this room, Clay tells us. We can’t find major solutions by planning better or by starting an endless series of unconferences and hackathons: hackathons don’t produce running code, but better understanding of problems and better social capital. In the internet community, we’ve all thought through Nupedia and we think we understand how it ground to a halt through bureaucracy. But many of us fail to understand that the people who made Nupedia fail were the people who make Wikipedia succeed, the same folks who’d been building Nupedia. Wikipedia was a plan B.

When you build a prototype, you’re building up your understanding of the process. When you build a prototype, you’re not solving the client’s problem – you’re often showing show the client that they don’t understand the problem, as people often don’t tell you what they need until you can show them something that is concretely wrong. If we can commit to working on problems before discovering at first that we’re wrong, we can take on the most challenging problems that face us.