There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different

There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different from disposable marketing content. This is especially toxic when the underlying context and goals are so different. Businesses wants interchangeable programmers for many reasons: so they can ramp team size up and down, so hiring is easy, etc. But the number one reason in my experience is to minimize the bargaining power of the programmers. Execs absolutely _hate_ having star programmers holding them up for raises. Building complicated in-house tooling in a language like lisp might make it rain, but the devs are then in a position to demand a slice. Procurement 101 is always have secondary vendors to keep your main vendors honest. Lower productivity is an acceptable price to avoid being held up. This is a very different context from somewhere like JPL where any programmer there could already leave for more money in industry. Anyone there is already committed to the mission. The cost of lower productivity isn't justified, and might make certain activities simply impossible given the current budgets.