How does ancient philosophy inform the building of software? Here is Lisie Lillianfeld's (excellent) answer. Mine is a bit different, largely because I worked more on Platonic metaphysics and less on Maimonides et al. So here's my answer.
This is about the connections between software and the philosophy itself, not the studying of it. So, for example, nothing like "writing a big long Ph.D. prepared me for managing big long software projects." If you want to know what I think about that, this document has much of it.
My view of software is metaphysics-heavy in that I think you can't lose focus on questions of things' structures and essences (see, e.g., here and here). Most software involves modeling some fragment of the world in code, and I think you can't do this without an accurate sense of what that fragment of the world is really like:
I like to think I'd have views like this even without my years with Plato, but who knows. Being an ancient philosopher keeps me asking what, precisely, things are. You're trained to ask the sorts of questions I just discussed.
A metaphysical mindset is also helpful in thinking about dependency management, which is central to software. I'm particularly glad to have been trained into the idea that there can be many kinds of dependencies. The graph describing the temporal flow of data in a system is usually not the best dependency graph; temporal dependency is not the same thing as dependency of modules or objects. Of course you don't have to read Plato and Aristotle to be sensitized to that idea, but it sure helps.
Here again, much of the benefit is simply in being able to take these questions seriously. Contemporary philosophy can be hostile to "pure metaphysics;" ancient Greek philosophy was, emphatically, not.
Finally, a word on distributed systems. There were ancient debates about the structure of the soul: there are (among others) a Socratic view according to which the soul is one faculty and an Aristotelian view according to which the soul has several coordinated parts. The question is important in its own right, but studying it also teaches two broader metaphysical lessons. First, that complex structures have (so to speak) a lot of overhead, even if they don't seem at first to be very complicated. Many interfaces (so to speak) are required and much can go wrong. It is enough to make one sympathetic to the slogan that distributed systems are terrible, and to avoid them if at all possible. Second, however, that complex structures really can do a lot that simple ones can't, and if you can manage the overhead, they have tremendous power.
I'll never pretend that spending years and years reading Plato is necessary for being a good software engineer, but it's definitely pleasant. I've come to believe that a metaphysics-friendly mindset is more useful in software than a metaphysics-hostile one, and I'm grateful for the time I spent with some of the very friendliest.
2/3/2025