The first-stage engines of a Saturn V rocket

Rockets and startups

A venture-funded startup is sort of like a space program. Space programs don’t build airplanes that fly in flat, predictable, safe trajectories. They shouldn’t be concerned with doing something pedestrian. Space programs should be concerned with doing something very unusual, perhaps unnatural.

Like a space program, a funded startup is equal parts propaganda and collection of great minds. During the first few rounds of financing, a startup is completely unlike an actual business. It’s all growth: technical growth, metrics growth, mindshare growth, operational growth, staff growth. It’s about gathering smart, driven people and making something new without the confines of traditional market forces. It’s about showing that new thing off to the world, making everyone think that they either really need to have it or that they’re behind in the race to make something like it.

Startups, like space programs, take a bunch of volatile materials and apply them to make an impossible climb. Quite often, those materials explode on the pad or in the first couple minutes of flight. Sometimes all the systems work together, months of effort by teams coordinated by a few masterminds, and the startup or spaceship gets off the ground.

Even if the startup or spaceship survives it’s first minutes, most of it is discarded as it ascends. A Saturn V weighed millions of pounds on the launch pad; what returns to Earth weight thousands of pounds in the end. Systems are built, used, and discarded many times over. Depending on a startup’s exit, what remains is only one of many ideas or systems built over time, sometimes an idea expressed in the heads of a few key people.

Space programs are great. Startups are great. Keep in mind that they are wholly unlike more commonplace human endeavors and you’ll be fine.

The forces of change on the US legislature

As of 2012, the major forces operating on the legislation of the US government are, unscientifically speaking:

  • 60% path dependence
  • 20% regulatory capture
  • 10% marginal progress
  • 9% political posturing

Everything else, I’d guess, is a rounding error that fits in that last 1%.

Path dependence, in short, means that once you decide to do something, it’s difficult to unwind all the decisions that follow that original decision. Once you build a military-industrial complex, farm subsidy program, or medical program for the elderly, it becomes increasingly difficult to stop doing those things. You’re invested.

Regulatory capture is a phenomenon where a regulated industry, say telecom, becomes sufficiently cozy with the institutions regulating them that they can manipulate the regulators to ease the boundaries they must operate within, or even impose rules making it difficult for new competitors to enter the industry. To some extent, the prisoners run the asylum. Barring an extremely jarring event, like a financial emergency, the regulated can grow their profit margins, comfortable knowing that competitors are increasingly unlikely. More often, regulatory capture is about protecting the golden egg. Path dependence, in the form of subsidies and existing contracts, often goes hand-in-hand with regulatory capture.

Marginal progress is exactly what politicians are not rewarded for. They are rewarded for having strong ties to those with strong ties, for saying the right things, and staying out of the public eye. Politicians don’t enhance their career by doing what they tell their voters they seek to do.

Political posturing is what legislators are rewarded for. If they fail to accomplish what they’ve told voters they will do, they can always blameshift it away: not enough political will, distasteful political advesaries, more pressing problems elsewhere.

This seems cynical, but I’ve got my reasons:

  • I find it helps to understand the forces at play before you try to figure out what to invest optimism in.
  • Understanding a system is the first step towards making meaningful changes within it.

Actually, that’s a pretty good way to summarize my approach to understanding the systems of the world: understand the forces, learn the mechanisms, figure out how this system is interconnected to the other systems. The interconnections are the fun parts!

How to make a CIA spy, and other anecdotes

And the hilariously incompetent, such as the OSS operative whose cover was so far blown that when he dropped into his favorite restaurant, the band played “Boo! Boo! I’m a Spy.”

Interesting, new-to-me tidbits on what goes into making CIA spies, what they actually do in the field, and how the practitioners of spy craft have changed over the years. The bad news: spies recruitment doesn’t exactly work like in Spies Like Us. The good news: the CIA and its spying is closer to “just as bad/inept as you’d think” than “as diabolical as a James Bond villain”.

Organizing and decoding problems

My favorite sort of problem involves the interactions between individuals, groups of people, and mechanical rules generated by individuals and groups. Speculating on how the rules were shaped by the experiences of the individuals and groups is a fun game to play when presented with a curious set of circumstances. Conversely, my least favorite problems are those generated by the institutional brain damage of certain kinds of groups. Software and systems shaped by regulations and the particulars of monetary exchange are tedious at best.

I find it quite amusing when answers aren’t “clean” and technological systems aren’t the best solution. Often, no amount of analysis and brilliant coding can make an improvement. What is needed is to understand what people do, why they do it, and persuade them to do otherwise.

This brings me to economics, specifically behavioral economics. If you take away all the math, economics is largely about how people behave in aggregate. It’s a useful tool in understanding how to work with systems that involve people. But there’s more to economics than explaining how people interact in markets.


Russ Roberts, in the process of explaining how economics is not useful as a mechanism for answering questions like “did the stimulus work?” or “when will the housing market recover?”, gets to what really interests me about economics and finance:

“Is economics a science because it is like Darwinian biology? Darwinian biology is very different from the physical sciences. Like economics it is a very useful way to organize your thinking about complex phenomena. But it is not a predictive or very precise science or whatever you want to call it.”

The crux of the biscuit, for me, is right in the middle. Economics is a useful way to organize an intricate and interconnected problem and figure out how to reason about it. In casually studying economics and finance over the couple years, I’ve come to form a better mental model about how the world works.


Its possible that this mental modeling is what I do when I’m coding. I’m poking how some code works, looking at its inner workings, trying to understand how it interacts with the code around it. I sift through revision logs to see how it got to where it is today, talk to others on the team about the code and why it ended up one way and not another. I’m organizing and modeling the code in my head, building up a model that describes .

Lately, I’ve been describing my work as tinkering with lines of code until numbers appear on the screen in the right order. This is invariably greeted with a comforting-to-me response like “I could never do that”. But I really enjoy this. I’m not just debugging my code; I’m sharpening the way the program is organized in my head. Once I’ve got my head around it, I decode that organization into words, code, drawings, etc.

With programs, there is some system of rules, forces, and interactions which describe how the code works or doesn’t. Economics, too, describes a system of rules, forces, and interactions that predicts how a puzzle of human beings operate. Organizing and decoding these technical and social puzzles is great fun.

Clips from unfinished pieces

On the crux of America’s challenges:

Part of the American experiment is answering the question, “how can we best take advantage of abundance?” Beginning with manifest destiny and evident in the machinations of Wall Street, one of the story lines of America is the quest to make sure resources of all kind are abundant and generating wealth. But we’re arguably at a pivot point. Our money and energy don’t go as far as they used to.

How do we make the transition from resource abundance to resource scarcity?

On helping people troubleshoot the Gowalla API:

While this level of self-documentation is quite helpful, sometimes people have questions on the developer list. For this, I’ve found that asking people to show me whatever it is they’re trying to do using curl is invaluable. It’s a win-win situation. Often, dropping down to a lower-level tool like curl helps to focus your thinking and makes silly error obvious. If it doesn’t become obvious to the API developer, they mail the list with the command they think should work. At that point its either obvious to me and I tell them what to change, or I have a nice, isolated test case from which I can easily try to reproduce their problem.

Who gets screwed when a borrower declares bankrupcty?

Is it possible that bankruptcy-declaring-borrowers are screwing lenders in aggregate? I find it really hard to believe that the banking industry, with its legion of lobbyists and regulatory capture, that any group of uncoordinated individuals could screw the banks.

On the other hand, there was lots of screwing on the part of the banks that led to the financial crisis. Whether it was predatory lending, relying on moral hazard to double down on terrible bets, or asinine compensation structures, the financial industry did something very human. They violated social norms. Except, corporations of this size don’t have social norms. They have only market incentives; when the executives, board members, and majority shareholders look at the books, the numbers devoted to “doing the right thing” are probably a rounding error.

On tail recursion and compilers:

Fact of life: modern processors don’t execute your code in the order the compiler spits it out.

If your code has, for instance, two adds followed by an if statement, it’s pretty likely that second add is going to be executed concurrently or after the conditional. In the world of computer architecture, they call this out-of-order execution, and it’s just another service your hard working processor offers to make sure your code runs faster than you ever intended it to.

On shorter cycles of production and the need to get past perfectionism:

Our modes of production are causing us to change how we produce. More and more mediums, be it journalism or software, are produced on shorter timelines. This is leading us to optimize production such that we can bang the content or code that matters into templates that mostly work, but have a tolerance for the rough edges where things don’t work.

On Barack Obama’s 2010 State of the Union speech that preceeded the health care debate:

Just for grins, I went and read the GOP response to the State of the Union. While they had some vague counterpoints policy-wise, it read mostly as subtle and useless jabs combined with carefully-constructed language to console their base. The GOP is a cynical, gutless organization.

On refactoring and deleting code:

People often say that they would miss having a refactoring browser in languages like Ruby, JavaScript, or anything that is reasonably dynamic. My glib response to this sort of comment is invariably “well, the best refactoring I know is to select the code to modify, hit delete, and start over.” Let’s take that apart.

I’ve observed that, despite our best intentions, we are often loathe to change code that we suspect is working, or that we suspect we don’t know why it’s there. And so, like the planet on which we live, applications accrete into Katamari balls of overly-coupled code that is bound only by locality. Cutting this Gordian knot is often the first step in reclaiming a project.

Deleting code is the knife with which we can attack this problem. Many will acknowledge the goodness of deleting code; it is, quite nearly, a virtue unto itself. I’ve observed that some of the best developers I know are always on the lookout for ways they can obviate code. So, by way of a strawman, I hope you see that I’m quite correct in this regard.