I’ve got two passions in life: public policy wonkery and building things. I decided to work in public policy because the stakes of public problems are simply too high. Markets work incredibly well to foster solutions to a very specific domain of problem. When some product can be excluded from those not paying; when one person’s consumption prevents another’s; when people are able to pay: these are the conditions in which markets excel.
But many things that we as a society value don’t fit this mold. Markets don’t provide healthcare or education to those unable to pay. Clean air, safe roads, effective regulation – these are goods that markets aren’t well-suited to handle. For such goods, we look to an entity independent of market incentives; we pool our resources and work together; commonly, such action comes through government.
I often find myself contemplating a question: what if we could make the delivery of public services 20 percent more effective? For these services, often geared toward those with the least among us, what would the human impact be? To borrow from the economist Robert Lucas, once you start thinking about the ramifications, it becomes hard to think about anything else.
The frustration of policy is that, while the scope for potential impact is large, getting there is a complex process, one in which even the fiercest individual efforts are often blunted by sheer circumstance.
So in my spare time, I build things.
I’ve stayed up to ungodly hours on a Saturday night learning Selenium to automate browser tasks. Before that, it was building a Department of Labor wage data explorer with Rails, and scraping California legislative databases with Scrapy. The dopamine bursts from building things come more often and more quickly than in the abstract – if impactful – work necessary in public policy.
I’m coding for America because I want to combine that thrill of building with the impact of public service, to focus high-productivity tools on the high-impact problems that government confronts. In so many public problems, weekend hackers like myself can see the contours of a solution: simple tools that can be prototyped in a day and yet improve the workflow of 80 percent of policymakers – or civil servants, or citizens – dealing with that problem.
Understanding such profound possibilities is what keeps me up late at night, scraping legislative data, perusing government APIs, and cursing Javascript’s object model: I want more high-impact tools.
Building effective tools requires both communicating technical constraints (preferably without using ORM or Nginx in a meeting with users) as well as understanding the “soft” requirements for success unique to public problems: stakeholder buy-in; political context; the trade-offs of legislative, agency, or private actions. Most critically, public-minded technologists must focus on building for the problems where a technicalsolution actually makes sense.
Building truly impactful tools requires bridging these disparate knowledge domains. I came to Code For America to be that bridge.
(And because, hey, Javascript’s pretty fun – even with prototype inheritance.)
Questions? Comments? Hit us up @codeforamerica.
Leave a Reply
You must be logged in to post a comment.