If your code is short, obvious, and working - then you are an expendable nobody.
If your code is 10M lines of incomprehensible shit - then you are an irreplaceable demigod.
Doesn't matter if both programmers' code has the exact same functionality.
These tools are generally much too complex. I don't think that e.g. CMake builds are easier to understand and analyze. From a certain size it's almost impossible to fully understand and check such a system.
One could argue that this is the case with any type of system. This is true, but you have to bear in mind that important findings and principles of software engineering from the last fifty years seem to have passed by without a trace, especially when it comes to build systems. For example, most of these systems still use dynamically typed scripting languages to specify the build, even though these are increasingly being replaced by better languages due to their well-known disadvantages, e.g. languages that are accessible to a static check at compile time using suitable tools, or that do not leave the discovery of errors and backdoors to chance discovery at runtime.
Autotools, CMake, Qmake and even newer developments such as Meson or GN suffer from the same problems.
> There’s better build systems like CMake or meson (at least that’s what I’m told), but in fact plain Makefiles are superior.
There is no reason for this assumption. Non of these tools supports e.g. static analysis.
Anyway, such constraints are also available in GN, and in CMake or Autotools you can implement them yourself, but they suffer from the same restriction I mentioned (not amenable to static analysis, limited verifiability at runtime due to combinatorial explosion of possible system states, etc.).
