Blogging from the Bottom Up

Thanks for reading my new blog, Bottom-Up! If you’re not familiar with my past work, I’m a grad student in computer science at Princeton and a sometime writer with a focus on technology policy. Over the last five years or so, I’ve gradually accumulated a number of group blogging opportunites. They’re all great blogs, and I’d love to write regularly for all of them, but I’m started to find myself stretched pretty thin. So this is my attempt to consolidate and focus my energies on a single blogging project.

This blog is going to be a bit of an experiment. The typical blog is tightly coupled to the news cycle. That makes for a lively read, but it tends to produce a kind of scatter-shot effect, with little connection between one post and the next. I’m going to try to achieve a bit more continuity and coherence here. Posts may run long, and if a topic strikes my fancy I may do several posts in a row about it. I’m not going to try to hit every story that shows up on Techmeme; if you’re looking for comprehensive coverage of tech policy (or anything else) I suggest you look elsewhere.

Lest that scare you off, I’m very conscious of the dangers of the opposite extreme. Nothing is more tedious than excessive naval-gazing, especially from a writer with no editor and no word limits. Blogging is fundamentally a conversational medium, so I plan to jump into the blogospheric fray on a regular basis.

One of my goals for the blog is to bring some of the key insights of the tech policy world to broader public policy conversations. In his brilliant book, Here Comes Everybody, NYU’s Clay Shirky devotes several paragraphs to “The Social Origins of Good Ideas,” a paper by Chicago sociologist Ronald Burt. Burt studied the process of idea-generation in a large electronics firm, and found that the most creative individuals were often those who had regular conversations with people outside their own departments. As Burt describes it:

People whose networks span structural holes have early access to diverse, often contradictory, information and interpretations which gives them a competitive advantage in delivering good ideas. People connected to groups beyond their own can expect to find themselves delivering valuable ideas, seeming to be gifted with creativity. This is not creativity born of deep intellectual ability. It is creativity as an import-export business. An idea mundane in one group can be a valuable insight in another.

I’ve found technology policy to be a remarkably fertile source of interesting ideas about the broader worlds of business and public policy. This is true for at least three reasons.

First, the rapid pace of technological change means that it’s fairly common for important arguments to get settled with one side as a decisive winner. Most industries aren’t like that. People have been arguing about health care reform for decades, and they were making pretty much the same arguments in 1948, 1965, or 1994 as they are today. That’s not true in tech policy. It’s easy to look back at the major technology debates of the last couple of decades and spot clear winners (open networks, free software) and losers (encryption export controls, micropayments, “thin clients”). And knowing who lost a given debate makes it much easier to say something interesting about why they got it wrong.

Second, the software industry is home to extraordinary institutional diversity. Again, other industries aren’t like that. For example, car companies pretty much all look the same: large, capital-intensive, and bureaucratic. In contrast, software is produced by all sorts of people and institutions: large software companies, small startups, ideologically-driven non-profits, academics, loose networks of volunteers, and so on. I think we can learn a lot about the effectiveness of different kinds of organizations by observing what happens when Microsoft, say, has to compete directly with a small startup like Google circa 1999 or a non-profit organization like Mozilla today.

Finally, computer programmers have unique experience dealing with problems of scale and complexity. Almost any working programmer can tell stories where she built software that worked flawlessly with a handful of test users, only to encounter unexpected problems “scaling up” to thousands or millions of users. Programmers have developed some interesting techniques to manage problems of scale and complexity. Many professions face problems of scale and complexity, but very few face it as acutely or as regularly as computer programmers do. Therefore, I think examining them can produce insights that will be valuable to people who have no intention of writing computer code.

So thanks for reading, and I hope you’ll stick around. A link to the RSS feed can be found at the bottom of the page.