Philosophy and tech startups go pretty well together

I’m a philosophy grad. I mostly cared about analytic philosophy, especially the philosophy of science, but also the philosophy of race. I decided to study philosophy because it seemed to be the closest thing to what I did in high school: argue.

I argued incessantly on forums, chatrooms, comment threads, and my first period sciences sociales class with Mr. Mitchell. I argued there in French, and I did it for 5 minutes a day at least. I tried my damndest to communicate my opinions, and after five years of doing that, I could speak the language pretty decently.

My need to argue has helped me learn a lot of things - including how not to argue, and to instead be fair to someone’s point. But there’s one skill that has become especially important in my life, and which is serving me incredbily well at my new job at a tech startup called GoInstant. It’s the ability to find counterexamples.

Counterexamples
In philosophy, especially in earlier classes, basically all you do is analyze an argument until you understand how it fails to account for one very obvious, very important thing: a state of affairs we call a ‘counterexample.’ It’s simply the one state of affairs that shows the argument your interlocutor is making must be inadequate in some way. When Callicles says that the best people are the strongest people, Socrates points out that the masses are pretty strong, and they do some pretty horrible shit. Bam. Counterexample.

The development process is awfully similar, except the states of affairs that you’re hunting aren’t called counterexamples: they’re called bugs. And the uncovering of bugs is the challenge that keeps developers busy.

At GoInstant, we have an unbelievably enormous project: we’ve got to make our software work on the entire web. Every single webpage should work within our browser, and if one doesn’t, we have to figure out how to do make it work, so that that one state of affairs will be covered by our code.

The greatest good for the greatest number
Except, of course, it’s not that simple. It’s not just as simple as finding all the bugs, all the states of affairs in which our software doesn’t work. Instead, we must first decide: what is most important? 2nd most? 3rd most? etc. etc. ad nauseum.

There’s a normative project behind every single app that has been ever designed: what matters most, given that we have limited time and money to put towards the project? It is the question that fuels all design decisions, for anything. It is the question whose answer separates great products from awful ones. It is the question I intend to spend the rest of my life answering, because it is that complicated and nuanced and fucking cool to work on.

Good answers for the hardest question
This question is a question of what good design really is. There are a lot of answers, but there’s only one way to solve it: find counterexamples. And these counterexamples are states of affairs in which human beings are using an app* and finding it wanting, unable to fulfill its purpose as well as it should (to borrow some more normative terms).

But the complicated thing is that for a design to matter, it also has to be just one thing in an ecosystem of creation: an ecosystem that makes yet more wonderful things. It has to be the product of a deeply talented team, because it’s not easy to make that one thing. It has to generate revenue to power every stage of its development and creation. It’s an organism that’s created and which can give the power to create, and that’s kind of awesome.

Finding a niche
It’s also unbelievably rare. If it grows and has any staying power, it is because it occupied a niche that was brought about from the combination of available technology, models of commerce, political dynamics, and social trends at a particular time and place. To read those signs well is impossible; it’s easier to just occupy the time and place and see what it is that you’ll find yourself needing in five years time. That is to say, it’s always a crap shoot.

There’s someone, or a group of someones, in the design process who will have to make the tough decisions about their little organism. They’ll have to see the connections between commerce and possibility and usefulness and human need, the ones who’ll have to tinker with their creation until it fits. After that, they’ll have to do everything they can to make everyone else aware of those connections. That latter part - the making aware of - is called marketing. Everything before it is product management - or intelligent design, if you think of designers as the sort of god figures of this weird ecological analogy.

So what do you do if you have an idea? To turn it into anything important, you need to do more than just make it a physical object or a collection of lines of code. Importance is determined by how it fares. You need to find out where it sits, and you need to get it there. If there is no spot for it, or if it bleeds money while crossing a desert in search of an oasis, then shit. You’re out of luck, this time. I hope you didn’t risk too much, and I hope you can still change it enough so that it can thrive, somewhere. Probably not where you expected, though.

There’s always the rare possibility that you find the spot for your app, and it grows and flourishes and makes everything that nurtured it just all the stronger for having gotten it to this point. It’s not something that happens often, and a lot of the time, it’s less about being the perfect solution than it is about just having been good enough for the time and place. Until, of course, the perfect solution comes along.

There’s a problem with perfect, though. Nothing that evolved has ever been perfect. And no theory is immune to counterexamples. As long as those two things are true, and they always will be, opportunity can be found. Apps can be made, and can thrive. The universe will keep spinning, and entropy will gather in the practiced hands of an unusual, unpredictable force.

*I’m just gonna use app as shorthand for anything that can be used by a person, ever.