If you code, you might be a philosopher

If you’ve spent any time writing code, you’ve probably experienced The Dread. Not the existential dread of realising we’re all just chemical soups hurtling through space on a rock. I mean the more tangible dread of having to name something in your code.

You sit there, fingers poised above the keyboard, staring at an entity—an object, a class, a function—that does something, but what? What do you call it? "DataProcessor"? Too vague. "ThingDoer"? Too honest. "AbstractFactoryFactory"? A one-way ticket to software architecture jail. The naming problem is real, and it’s one of the reasons why programmers should study philosophy.

“The vocabulary and names of things are often determined, or rather pre-determined by the time any serious examination has even begun: things get named by social convention, precedent, bias and the vagaries of language.”

The Eternal Struggle of Naming Things

Philosophy, at its core, is about defining things—concepts, categories, and ideas—and, more importantly, questioning whether our definitions actually mean anything at all. Programmers, on the other hand, spend their days wrangling abstract concepts into tangible structures. 

The vocabulary and names of things are often determined, or rather pre-determined by the time any serious examination has even begun: things get named by social convention, precedent, bias and the vagaries of language. Now by naming things we don’t mean coming up with new words but rather sharpening existing terms. Philosophy aims to shed a light on these ‘dark precedents’, drag the matter out into the debatable realm: a debate well defined is half conducted, i.e. we can dispense with the cross talk and get straight to the nub of disagreement, which of course there would be if it is to be philosophy at all and not settled science. (Philosophy is often upstream of many ideas that would then become sciences or other humanities.)

Ludwig Wittgenstein, dedicated entire books to the idea that meaning is not fixed but shaped by usage and context. If you’ve ever spent an hour debating whether a variable should be called userList or usersArray, congratulations! You’ve engaged in applied Wittgensteinian thought.

Philosophy can also help us with the inevitable regret that comes with realising your getThing() function should have been fetchDataFromServer() but you’ve already committed it. Much like in philosophy, the words we use in code shape how we think about problems, and once a term gains traction, changing it is like convincing people that "literally" shouldn't mean "figuratively."

Object-Oriented Ontology: When Code Becomes Metaphysics

Object-oriented programming (OOP) is essentially a metaphysics course in disguise. We model the world with classes and objects, hierarchies and relationships, struggling to capture the chaos of reality in neat, structured abstractions. But what even is an object? What makes a Dog class a Dog? Is it its ability to bark()? To fetch()? What if it’s a mute dog or a lazy one? Have we coded ourselves into a philosophical paradox?

This is where ontology, the (uber) branch of philosophy concerned with the nature of being, comes in handy. The ancient Greeks had the same problem: Plato argued that objects in the real world are just imperfect copies of some idealised, unachievable "form." In our case, every instance of Dog in our codebase is just a flawed attempt to capture the essence of Dog-ness, and deep down, we know that someday a product manager will ask us to make it meow instead.

Meanwhile, Aristotle was more of a pragmatist. He said that things are defined not by some unattainable perfection but by their attributes and behaviours. In programming, this is what we call "duck typing"—if it walks like a duck and quacks like a duck, it’s a duck (or, more accurately, a class that implements quack() and waddle()).

““How do we know what we know?” is the core question of both philosophy and any system of formalising thought, which is what programming is.”

Debugging Reality

Finally, philosophy teaches one how to think clearly. Logical reasoning? That’s just an applied form of syllogism. Debugging? That’s just Descartes’ method of systematic doubt—eliminate every assumption until you find the one that's causing the segfault. Even Zeno’s paradoxes, which suggest that motion is impossible, can be helpful the next time your infinite loop convinces you that time has stopped.

And there is of course epistemology, the study of knowledge itself. "How do we know what we know?" is the core question of both philosophy and any system of formalising thought, which is what programming is. Is that bug really a bug, or just an "undocumented feature"? Is the system failing, or do we just not understand how it’s supposed to work? 

After all, coding is about imposing structure on chaos, which is exactly what philosophy has been trying to do for thousands of years. 

So, should programmers study philosophy? Absolutely. It might make you better at writing code, but it definitely will make you better at thinking about code. And if nothing else, it’ll give you some highbrow excuses the next time someone questions your variable names:

"Oh, dataProcessor42? That’s just a reflection of Kierkegaardian despair. The real question is, does it process itself?"