Philosophy-Induced Software Engineering: How Philosophy Can Make You a Better Engineer

Philosophy and engineering are two subjects that can be viewed as two different worlds. Unrelated and of no use to each other. Philosophy is theoretical in its investigation, and engineering is an extremely practical discipline. In this write-up, I claim that these two fields have more in common than one might think and that learning philosophy helps make an engineer more thorough.

Note that I will usually use the term engineer to refer to a software engineer. Although, the first and weaker claim can be extended to most engineering disciplines.

What Do I Mean by Philosophy?

Philosophy can mean different things to different people – for more on this, refer to the first section in my write-up on philosophy and programmers. For our purposes, we will distinguish between philosophy as a discipline and philosophical thinking as the thought process involved in tackling problems. Philosophy as a discipline or a field of study has different branches that examine knowledge, language, logic, ethics, and science. Philosophical thinking is the general capacity to ponder and examine things in a systematic approach. I may use the term philosophy to refer to philosophical thinking in some sections of this discussion.

Okay, You're Saying Logic

Engineers are trained to be analytical and logical in their thinking. I took logic in school and did plenty of math. Yet, that is not enough because, in engineering, there is always a system that you work within. It is unusual to challenge that system – that does happen and may lead to great outcomes, but rather rare.

In philosophy, however, it is almost always about challenging the system, if you had one at all.

Philosophy Is a Logic Exercise

Philosophy discusses difficult and seemly unsolvable questions in almost every area of knowledge. Questions that challenge preconceived notions and challenge "common sense" lead people to come up with all kinds of creative solutions. Sometimes the solution is not to answer the question but to redefine the question.

One philosophical problem that we can draw direct parallels to engineering is the barber's paradox. Barber's paradox asks us to imagine a town with a law that requires all men to be cleanly shaved. And says that the barber shaves only the men that do not shave themselves. In other words, all the men who do not shave themselves have to go to the barber. Otherwise, they will have to shave themselves. The question here is, who shaves the barber? If the barber shaves himself, then he does not go to the barber (that is himself). And if the barber does not shave himself, then he has to go to the barber (also himself). Both cases are contradictions.

Ignoring the mathematical roots of the paradox, this puzzle shows an example of a system design that sets the conditions you will have to operate in, which may make some tasks impossible to accomplish. The constraints that our system had set made finding the "shaving behavior" of the barber non-deterministic. It could be any of the two conditions; it is up to the implementer. Imagine having a language spec with a similar constraint, and it is up to the compiler maintainers to choose a behavior – we have many examples of this with the C compilers.

You might say this is a mathematical puzzle, not really philosophy, so I will give another example. However, this time I will take the other direction. I will give an example in engineering that maps to philosophy. This time, I will talk about my approach to debugging. I call it skeptic debugging.

Skeptic debugging is to assume that nothing is working in your application and then start building your confidence layer by layer, which means if I start by assuming that my application is broken to the point where it fails to boot. I start by ensuring it boots, then confirm that I can navigate to the page where the faulty feature is, and so on, until I find the point where my expectations are not met.

Skeptic debugging is a bottom-up approach as opposed to the top-down approach where you would jump into where the feature is and try to mess around until you get sick of it and then realize that nothing is wrong here, but it is the layer below that is broken.

I think skeptic debugging, as the name implies, directly maps to the skepticism (precisely, cartesian skepticism) in the philosophy of knowledge or epistemology. That is the process of validating one's beliefs, starting from the most foundational beliefs one has.

Philosophy Directly Influences Engineering Decisions

Some fields of philosophy have immediate implications on how we approach engineering, and in some cases, philosophy might obligate you not to do engineering – as in some ethical dilemmas.

Let us start with ethics. Ethics (or moral philosophy) is the study of what makes an act right or wrong and how we decide what is valuable. Value theory studies the why, how, and to what extent humans should value anything (including a person, a concept, or an object). This is crucial when designing any kind of autonomous robots, especially autonomous vehicles where we have to design robots to make decisions in some variants of the trolly problems. In the trolly problem, the vehicle is the agent having to decide whether, for example, to prioritize the safety of its passengers, another vehicle's, or the pedestrians'.

Another example is the philosophy of language. Philosophy of language studies how language is used and how it is understood. This is the root of natural language processing in computing. Natural language processing (NLP) tries to understand the user's language and tries to produce utterances in response. NLP specialists have been trying to model human languages in structures that computers could then interpret, attempts that have followed language philosophers like Chomsky's Syntactic Structures. There is also a paper titled Wittgenstein’s Philosophy of Language The Philosophical Origins of Modern NLP Thinking, that I think is a great resource to get a further picture of how philosophical understanding of human language has influenced computational understanding.

How Do I Start?

Philosophy is a skill that can be acquired by reading a few books or even dozens of them. Philosophy's core values are acquired through challenging the ideas. Take an idea, and try to understand it very well to the point where you know where it fails to achieve a certain goal and object to it. You may ultimately agree with the end result, but you can object to the reasoning that led to this result. It is all about learning to grasp ideas and challenge them systematically.

One approach that I think is helpful to get started is to find a reading partner or, better yet, partners – the optimal size is 3 to 5 at most. You decide on a reading passage as a group, read it, and then come prepared to explain it to each other and critique it. It may be helpful at the beginning for each one to research how other philosophers have objected to the selected passage. For some more difficult passages, you may also need to research how others have interpreted the text to aid you in understanding it before heading to the discussion.

Now, the question is, where do we get these topics and passages from? I recommend starting with a history of philosophy book^[1]. These books usually provide an overview of the philosophical problems that have risen throughout history (usually up to the 1900s). Then you choose one of the topics to dive deeper into. But now, how do you find the texts for that topic? Once you know the topic, you can look for college courses' syllabi. Colleges post these publically and would usually include the readings for the course.