That it's out of the ordinary for someone to be able to just pick up a repo/service/project at your company and just go with maybe only a few sentences in a wiki to bootstrap them.
I'm a big fan of git clone, make setup, make style workflow where there is no other work. That this was a wow factor for your coworkers, again, tells me a lot.
Well, this actually seems to be pretty common at smaller companies (that they don't prioritize portability and out-of-the-box usability for internal tools and services), and this wasn't even nominally a software company. I did a lot of work there to try and improve these problems, mostly having nothing to do with Rust, but it was a thankless job.
My observation working at (much) larger, software-oriented companies is that things are better mostly because they have a lot of people working on tools like build systems and commit-blocking linters. Individual engineers on large teams, when incentivized toward pure velocity, still seem to ignore code quality and stewardship to the greatest degree they can get away with.
edit: These are meant as generalizations. Obviously some of us care, despite the industry's best attempts to beat it out of us.
You know cmake exists because "make && make install" by isn't usually that easy, anything beyond a small CLI has a lot of dependencies, and breaks with minor version changes?
I do know that. I don't know why you have to configure anything. For configurable project we make projects that contain the specific configs and wrap the common cmake. For instance "windows phone" wrapping the base app.
This also makes me ponder how you can do CI (builds) if you have to manually configure things. Or do you bake all that into the build config
