dev / progress

Unlearning Good Habits

This Domain Is Not That One

I wanna hang a map of the world in my house. Then I’m gonna put pins into all the locations that I’ve traveled to. But first, I’m gonna have to travel to the top two corners of the map so it won’t fall down.

– Mitch Hedberg

I enjoy computational modeling. “Fuck around and find out” simulation edition captures both my attention and imagination. That’s good because the activity requires both. Not only are complex systems difficult to unravel but your in silico representation can be, too. The distance between what you think you have modeled and what you have actually modeled grows by accident with ease – and not always with awareness.

To defend against this outcome, simulation work generally entails good modeling hygeine. You code in such a way that maximizes inspectability. You trace what you feasibly can. You write functions that are easy to test and you err on the side of excess coverage. You move extremely slowly, and only after your confidence is rock-solid. Your practice is driven by one (often painfully-)learned lesson: it is too easy to make unobservable errors.

Building a startup isn’t like building a computational model, apparently.I say “apparently” because “who the fuck am I?” right. In contextually-appropriate terms, I haven’t been validated, yet. What is a good habit in one domain is not a good habit in the other.

Successful entrepreneurs insist that you move as quickly as possible. The problem, as characterized by them, is a familiar one:

the distance between what you’re trying to build and what people want built is often vast.

Your goal is to shrink it as quickly as possible – at a minimum, before your money runs out. But being “right” means something profoundly different.

If an accidentally introduced artifact produced a compelling yet inevitably inaccurate representation of some aspect of what you are modeling, you are wrong. It doesn’t matter if you “get a good fit.” That’s not the point. You have’t discovered anything and the outcome isn’t more knowledge. Best case scenario: you fooled yourself. Worst case? You fooled a lot of other people, too.

Conversely, if you build something that people want but your theory accounting for why they would want it is wrong – who cares? You’re not searching for Truth, Beauty, and Justice here. You’re optimizing for a goodness of fit test measured, inevitably, in cash flows. The errors are extremely legible. And course corrections don’t render the entire codebase as suspect.

That doesn’t make it any easier. It just makes it a different kind of hard. So its worth recognizing that good habits are domain-dependent. Because their misapplication makes things harder.