I liked these interviews but I do find the result kind of... apathetic? I feel like you can read these and just come to a sense that nothing is engineering because everything is amorphous, which is not (I think) Hillel’s thesis but he doesn’t really want to anchor the discussion in principle because he is fundamentally asking for opinions.
For a more principled approach, I would say (as one of these “licensed engineers who has not done as much actual engineering”) that engineering as I have seen it kind of has three really major themes:
• Prototyping/building/creation. Tinkering. I guess the reason we don't talk about this is that everybody finds it trivial? But when you talk to ChemEs and they discuss optimizing pipelines for chemical processes you do see that it can get a little abstract so it's worth pointing to as a baseline.
• An underlying scientific theory that guides the models used. Building stuff has happened since way before science but engineering is clearly a postscientific endeavor, “here’s the underlying mechanical principles of how this works.” This is probably the sketchier principle in how we talk about “is this software design really engineering,” we tend to not have a firm scientific understanding of the problem domain of building software. Some things like CAP theorem, patch theories in version control (Darcs, Pijul), distributed consensus algorithms, TCP/IP, I would say really rise to that challenge and say something hard-learned about real systems. Things like OS kernels also have so much trial and error, so much prototyping that it feels like “yes you really did do enough hypothesis-test-reëvaluate cycles that the result embodies a model of the problem domain that counts as a scientific understanding.” But a lot of our work is just gluing systems together and that seems more “electrician” than “electrical engineering.” Now, science uses math, so people think of engineering as highly mathematical, I am not sure that it has to be. Whereas I do think it has to be scientifically based.
• The last big thing that I think we don't talk about enough is risk assessment. The reason that we’re doing all of this science and math to build a bridge, is so that we can assess how strong it needs to be to just barely survive the peak loads that it will ever have, and then double that strength just in case.
I think that when we say “not all programmers are doing software engineering” a good proxy for that is looking at, first, do you have a scientific model of the sorts of approaches that you can do; and then, do you use it to assess numerically the kind of loads that your system will come under up-front and design accordingly—writes per second, queries per second—and set realistic targets and choose caching and consensus and whatever else to achieve those and measure that you have... Or do you work via crude heuristics, “we use Kubernetes so I'm sure it will scale later, we do ‘best practices’ so we don't have to think about those,” and related kludges where we can comfortably say you're just tinkering rather than being principled about it.
And then, this reveals that maybe you don't need to be doing engineering, maybe you really do just need to tinker in the problem space while you achieve better product-market fit. Maybe you are doing science rather than engineering, and that is okay. Like, the idea that you are going to launch the next space shuttle with your reliability, I am sure that makes for a very energized, focused workplace, but it's not a precondition, it's not the only way to get there.