[The article is concerned with a kind of philosophy of software existence. As a pragmatist (programmer), I'm more interested in addressing the first question co

[The article is concerned with a kind of philosophy of software existence. As a pragmatist (programmer), I'm more interested in addressing the first question concretely, as it pertains to what HackerNews is mostly focused on.] After decades of loving the craft of crafting ever larger software systems, I've settled down to this description of what we devs actually produce: Our fundamental spacial unit is "Information Representation". Yeah, that means data with its explicit semantics supplied by a type system. Whether amorphous (Python) or mostly concrete (C/C++) or whatever else, those are the bricks we use to construct our systems, because that is what our microprocessors are actually manipulating, by hook or crook. What our software does temporally is to "Integrate" that data. Sometimes, it's character values coming in as input, with command-line functionality as output -- e.g. OS command-line commands. Sometimes, it's web-service requests coming in, and db accesses going out, with a lot of semi-permanent state being held in session data somewhere and a mostly-permanent database data somewhere. Regardless, the {input, state, output} is the spacial dimension being integrated in our logic. And note that "in and out" are the same as "call and response" in this description; the real idea is "How does the data flow, and what is the source, and where are the destinations?" Of course, there are different temporal dimensions to our dev work: design-time, test-time, build-time, deploy-time, run-time. Each project has its own needs, so, just like advanced maths, we combine our integrations hierarchically to build up the entire system. The coup de grace is the overarching notion, the "Engine". Before real-world engines are used, they are designed, tested/verified, and planned for being assembled in production. Once constructed, engines are prepared, tested, delivered, started, run while being manipulated/tweaked, and then they finish either by choice for maintenance or because their task is finished or because they failed. That's the cycle of use. It doesn't look like our industry is very mature in how it approaches software systems as engines, especially with respect to maintenance. It would help if we understood that the fundamental unit of time is change, which is all that ever matters in the entire universe, but most especially in our software systems.