I actually think software engineering has quite a bit in common with construction. We both work off blueprints, we have certain regulations that our creations have to adhere to, and we acquire skills as we gain experience that allow us to shortcut the conceptual underpinnings of the work of creation. A framer, for example, should have a rudimentary understanding of physics. They should know why certain shapes are strong, and how much load a given frame can bear. As they gain experience, however, they begin to recognize shortcuts. A joist in one circumstance should be 6x8", 10x14" in another. The knowledge of which implementation needs each size is not, however, rigorously determined or proven. The framer knows from experience which is required.
The same is true of software engineers. We gain, through experience, the knowledge as to what solutions are suitable for a particular problem. In general, however, we don't arrive at this knowledge through rigorous proofs. We arrive at it by empirical testing, and figuring out which solutions work best in a given scenario. Just as the framer is generally unconcerned with the principles of architectural engineering for the business of building a house, so too is the software engineer generally unconcerned with the theoretical underpinnings of their code when it comes to building a product. Certainly, if one is designing a new non-relational database language, or a new search algorithm, then you'd better have a very good grounding in theory. When it comes time to implement them, however, we generally accept that they are theoretically correct and concern ourselves with making it work in the real world. In the same way, a framer will generally accept that the architect knew what they were doing, and not concern themselves with the theoretical correctness of what they're building.