And in general, rewrites often are a bad idea. But Python is hundreds of times slower than languages like Go and it really doesn't have good levers for improvin

And in general, rewrites often are a bad idea. But Python is hundreds of times slower than languages like Go and it really doesn't have good levers for improving performance--the "rewrite the slow parts in C / multiprocessing / numpy" promises rarely pan out due to the overhead of pickling / marshaling to efficient C representations. Unfortunately, our principle engineer lacked any mechanical sympathy--he could write JS and Python but had no idea how V8/CPython worked under the hood or how other languages might compare. Ultimately, the more interesting story is how this person was able to "fail upward" so effectively. Basically, nontechnical management don't understand backend software, so the person who makes it "real" for them via user interface demos is the person they associate with manifesting the working feature, even if user interface demos are superficial. Moreover, management only interacted with features by way of his demos, so they didn't understand how much work was required to productionize his demos. The features he debuted would be handed to another team to productionize and support. That team would appear to move slowly as they mired through his tech debt while this principle engineer was moving onto yet another demo, giving the appearance that he was our prolific 10x engineer.