5626463547 | San Jose, CA 95126

Moving from Philosophy to Programming: Additional Reasons

In  The Natural Move from Philosophy to Programming, I argued that the transition from philosophy to programming is natural – that is, not surprising – because both fields have conceptual overlap. I emphasized the overlap of metaphysical concepts in that particular post. In this post, I want to provide another argument for that conclusion by focusing on other features that both philosophers and programmers might share. The argument here is more controversial because it will depend on features that I regard as contributory toward being an excellent philosopher or programmer, and that is something about which we can disagree. The structure of the argument is like this:

Philosophers who are successful, generally, have features F1, F2, …, and Fn.

Programmers who are successful, generally, have features F1, F2, …, and Fn.

So philosophers who are successful stand a good chance of being successful programmers.

The argument as stated is not valid, obviously. The inference to 3 is supposed to be inductive. There may be lots of objections already. So let me explain how I intend you to understand this argument.

First, the features in question are not just any features that a philosopher or programmer happens to have. Rather, they are features that contribute to their being excellent philosophers or programmers. (Again, there is room for disagreement about what those features are.)

Second, the “generally” qualifier is going for something more than existential quantification (i.e., there is at least one x such that…) but also less than universal quantification. Perhaps something in the ballpark of “most” or “a very large percentage” left suitably vague. There are going to be excellent philosophers who fail to have one or more of the features I plan on identifying. There might be some philosophers who fail to have any of them, although I highly doubt it. But generally, successful philosophers will have most or maybe all of the features I plan on identifying. The same comments here hold true of programmers. (If you complain that I am relying on evidence that is too subjective rather than a scientific survey, go get some money, conduct a x-phi survey, publish your paper, and then thank me for the idea. You’re welcome.)

Third, there is one feature that programmers have that philosophers do not have in virtue of being philosophers but which is necessary for being a good programmer: it is being a competent coder. Being a good epistemologist is going to require specialized knowledge about the field of epistemology, just like being a good Ruby programmer requires specialized knowledge of the Ruby syntax (among other things). Being a successful programmer requires knowing how to code and philosophers generally lack that. So the conclusion of the argument above should really be qualified like this:

3*. Were a philosopher to acquire knowledge of how to code, a philosopher stands a good chance of being a successful programmer.

Likewise, I could have inferred:

3**. Were a programmer to acquire the specialized knowledge of some field of philosophy, a programmer stands a good chance of being successful at that field.

Finally, I need to say something about what I mean by “being successful”.  Used of philosophers, I do not intend that only successful philosophers are those who acquire tenure-track jobs, moving expenses paid in full. There are too many other factors involved in acquiring a job in philosophy for anyone to reasonably think that the job was acquired by merit alone. Instead, I am imagining a successful philosopher to be one who does philosophy excellently, whether in an academic position or not, whether publishing or not. Saying what a successful programmer means in this context gets me into identifying those features, F1…Fn, that I planned on identifying anyway. So I’ll jump into that now.

Shared Features

1. Being a strong researcher.   As far as I am aware, there are very few philosophers who can get away with reading almost nobody (as far as we can tell from their writings) but able to produce much thought-provoking work. Harry Frankfurt, I think, is one of these people. For the rest of us, tons of research goes into each paper: looking on JSTOR, Google Scholar, Phil Papers, finding the relevant abstracts, etc, trying to find the relevant information as efficiently as possible. In programming, you are inevitably going to be thrown into a problem that you have not encountered before. This will require looking up information on sites like Stack Overflow or reading documentation for APIs / services or for libraries (basically, classes we can import into an application that we ourselves did not build but need to know how to use). The trouble is that documentation varies in quality from causing your eyes to bleed up to being comprehensible within the first few minutes of reading. Additionally, many of the answers online are simply incorrect or inapplicable to your problem. In order to get anything done as a programmer, you will need to know how to find the right sort of information.

2. Being able to construct clear arguments. You are in a room with two other programmers. One of them suggests that we can get an application up and running quickly with WordPress (a platform that makes up for about 22% of all internet sites, according to the last statistic I read). Another programmer says that we need something more enterprise level for the longer term and therefore should use .NET.  If you choose to side with one or neither of them, you will have to make arguments to convince your colleagues. As a programmer, if you work in a team you will be asked to make recommendations. Typically, this involves saying why you are making the recommendation you are making. Here’s a scenario where this happens: your project manager asks you how long it will take to add a certain feature to a web application; you provide a number that seems too long and are asked to justify your answer to the project manager so that she can justify that answer to the client. If you cannot construct a clear and convincing argument, your project manager will not be as understanding.

3. Being creative / artistic ability. One way in which a philosopher has to be creative or has an artistic ability is in deciding how to construct and convey his or her arguments. This involves making decisions like, “how much formal machinery do I need?”, “how much should my argument involve Chisholming down from one proposition to the next?”, “how much sign-posting do I need to provide the reader?” and so on. And then there are philosophers whose voices are so clearly recognizable that it wouldn’t matter that you skipped over the author’s name in the paper before realizing who wrote the piece (I’m thinking of someone like Alvin Plantinga, for instance).  Programming requires making creative decisions as well in structuring your code. There are times where I have looked at code that I have not seen before, but I could tell who wrote the code from knowing the coding patterns of my colleagues.

Another way in which philosophy requires creativity, I think, is in taking existing ideas or previously unexplored cases, and then making connections in ways previously ignored or not appreciated.  Now enters Steve Jobs:

4. Empathy.  As a philosopher, you construct your arguments with an eye for considering what objections might be raised much like a chess player considers his opponent’s future moves. When you teach your students, your students raise questions that are a little off the mark. You try to make sense to yourself why the student asked that particular question in class without embarrassing him. You are reading a book where the author did a somewhat careless job conveying an idea but you have to write a book review; you try to make the best sense of what the author was trying to say before ripping into the author (some book reviews fail at this, I know). All of these are typical situations philosophers find themselves in, and resolving these cases requires being able to put oneself in another’s shoes: in the opponent’s, in the student’s, and in the author’s.

As a programmer, you will be given a statement of work (SOW) where the instructions for what features should be included are unclear. You will be asked to look at code that you did not write and you will have to figure out, without comments from the author, why the code was written the way it was. A client will ask for a certain feature that makes not a lick of sense given what else you know. In order to resolve these situations, you will need to put yourself in the other’s shoes: in the PM’s, in the other programmer’s, and in the client’s.

5. Imaginative Abilities.  Perhaps I shouldn’t say “imaginative” since I don’t intend you to be thinking of images. What I have in mind is that when you do philosophy, you have to think of lots of possibilities. What if someone were to challenge this premise, then what? How might someone get around this argument? Have I considered all of the possible positions one might plausibly take with respect to this question?

When you are working on an application, you will also be forced to think about lots of possibilities. What is the quickest way I can get the computer to process this data? What are the reasons the application runs an exception (i.e., breaks) at this particular line in the code (fortunately, sometimes we will be told the reason, i.e., OutOfBoundsException)? What are some of the ways a user of the application might try to pass bad data through a form on the site and thereby corrupt the database?What are the pros and cons of building the application in these various possible ways?

6. The Love of Learning. I suspect that if philosophers did not love asking questions or care about learning, they wouldn’t be very good philosophers. (If you are a skeptic, you still probably regard some views are more reasonable than others; so then treat “learning” as an instance of acquiring a more reasonably held view even if it doesn’t amount to knowledge).  Technology is changing so quickly. If you learn how to be excellent at one particular area of programming, that might last you only five years, unless, that is, your goal is only to maintain old (aka “legacy”) code. You have to always be learning new things. This is one of the things that might be attractive to you if you are coming out of academia.

Summing Up

I am confident that you noticed that many of the features that I’ve highlighted are not peculiar to philosophy as such, but are shared by many humanities fields. Nonetheless, these are features/skills/abilities/whatever that you’ll need if you become a programmer. What I have done here is try to fill out the argument from last time by showing that there’s more features you probably already have that make you a good candidate to go into programming if you have come from philosophy.

In the next post, I will spend some time taking about the ways in which you can transition into a programming job.

2015-08-24T05:41:02+00:00 August 24th, 2015|2 Comments


  1. Joseph October 19, 2016 at 7:52 pm

    Thanks for pointing me to this, James! I’ve read both this one and your previous one on the transition from philosophy to programming. I’m just about the check out the starter guide.

  2. James A. Gibson October 19, 2016 at 10:19 pm

    Something else I don’t remember mentioning, but you might want to look into, is Coursera. I know people at work who have used it and they thought it to be very beneficial to them. Full disclosure: I know people who work for Coursera; but I myself have used one of their competitors.

Comments are closed.