Analytic Philosophy and Software Development

There is a lot of research and scientific work in this field. Philosophy is a wide area where we can see many points of view. Regardless of the profession which students choose, everyone learns the theories of philosophers. Even if you know how to write homework, you can buy custom college essays on philosophy and study excellently.

I’ve always believed, long before I became a software engineer, that my training in philosophy would be helpful for any field like software development or software engineering. But it’s only after having done this for a couple of years that I’m finally starting to understand why it’s so useful to have been trained in analytic philosophy.

There are some common answers that students receive when they ask, “Why should I study philosophy?”. Besides the intrinsic value of philosophy itself, there are several more practical justifications. Philosophy teaches students how to think critically, how to write clearly, and how to analyze complex arguments. These are all useful skills for just about any profession. Although this is all certainly true, I think these skills are not the most important ones that are taught in philosophy.

In short, the most important skill that students can learn from philosophy is the ability to take a vague or ambiguous idea and turn it into something precise — something that can be implemented, communicated, measured, and tested. It’s not about being able to operate within a logical framework; it’s about being able to create an appropriate logical framework in the first place.

Let’s illustrate with an example that will be familiar to the vast majority of us: LinkedIn. Reid Hoffman, the founder of LinkedIn, was a graduate student in philosophy at Stanford before he decided to leave academia and go into the private sector. He was also one of the original partners at PayPal, and has gone on to become an enormously influential venture capitalist. People who are thinking of leaving academia (and philosophy in particular) should check out Hoffman’s writing. He’s done alright for himself, and he’s an excellent writer.

The initial idea behind LinkedIn was that eventually, everyone’s professional identity would have a home somewhere on the internet. LinkedIn was Hoffman’s effort to implement that idea.

Now consider two software developers or engineers: Alice, who comes to LinkedIn very early, before it even has a website, and Bob, who starts work at LinkedIn today. Alice and Bob need to have very different skill sets in order to succeed in their roles. Bob needs to be a good programmer who can understand the massive and complex system that forms the infrastructure of LinkedIn. He needs to be able to add to it, improve it, document it, and work with others to accomplish goals that are most likely driven by fairly well-defined business needs. Logical reasoning, critical thinking, good communication skills, and so on will obviously be very helpful for Bob.

Alice, on the other hand, needs some different skills. Software is necessarily precise and requires exact specifications, but there won’t be any exact specifications of anything when a company like LinkedIn is just getting started. And what specifications there are will probably be revised beyond all recognition as the founders and employees learn more about their business needs. Alice needs to answer questions such as, “What is a person’s professional identity?”, “What activities are valuable to someone who is trying to advance professionally?” and so on. These questions can’t be given vague answers, because at the end of the day, they have to be implemented in a precise way, and an entire infrastructure has to be built to support those answers. In an important way, Alice’s job is far more demanding than Bob’s, because she’s not merely implementing solutions to pre-specified problems; she has to make the problems precise enough to be given practical answers in the first place. Then she’s got to implement them in a way that will enable her to revise those answers later, since they’ll probably not be quite right.

To continue the example, I’d confidently guess that one of Hoffman’s early insights was that a big part of one’s professional identity comprises who you know — in other words, your professional network. Your professional identity not only includes your resume and qualifications, but also anything you write about issues in your profession. These answers are good ones for LinkedIn because they can be implemented in a computer program. They enable us to move from a vague intuition about one’s “professional identity” (whatever that is) to a specifiable solution.

Examples of this transformation of vague idea into precise implementation are easy to find. For instance, people want to stay in touch with their “friends”. But what’s a “friend”? The answer is that a “friend” is someone with whom you’ve mutually agreed to share information. Hence, Facebook. People also want to be able to search for “authoritative” web pages, but what does “authoritative” mean? Sergey Brin and Larry Page’s answer was that an “authoritative” web page is a page that’s been linked-to from many other “authoritative” web pages. That answer can be precisely implemented as Google’s PageRank algorithm.

What all of these incredible success stories have in common is that they’re examples of taking a vague idea and transforming it into something precise. But that skill is very difficult to learn, and it’s exceedingly rare — which is probably why we know the names of people who have it (e.g. Zuckerberg, Hoffman, Brin, and Page). But analytic philosophy is all about taking vague ideas and coming up with precise formulations of them. It’s about creating the right conceptual framework for one’s ideas, and communicating that framework in such a way that it can be unambiguously understood by others.

Not surprisingly, this distinction between operating within a framework and thinking about conceptual frameworks has long been a topic in philosophy (see Carnap’s “Empiricism, Semantics, and Ontology”). The distinction is important, and it’s also highly practical. Once you become aware of the fact that Alice needs skills that go beyond Bob’s, you can avoid making a lot of mistakes. You can focus on the hard work of learning how to build the right framework for answering vague questions. And if you’re running a business, you can avoid the mistaken assumption that Bob and Alice are interchangeable.