He also told me we would almost certainly need to 
    rewrite everything at least once, so not to dwell too 
    long on the initial stuff.

    Build the MVP, build it quickly, get it in front of users. 
    It just needs to work, you're not going to get marks, or 
    customers, for backend coding style. 

1000% agree. Overengineering things is the death of MVPs. But man this is hard to do in many real world situations.

Stakeholders and managers want you to keep adding incremental features. Never had a situation where they were like "okay, cool MVP, see you in a few months after you tear it down and rebuild it 'for real'."

That "build a fast crappy MVP" mentality takes serious buy in from stakeholders from day one. That mentality might be common in SV and other startup communities but boy is it tough to find elsewhere.

That CIO is brilliant. That's the kind of wisdom you get with experience. Always good when stakeholders ask for additional features because the MVP isn't completely throw-away and then my team doesn't know the language. Then they learn the language, but we need to hire new devs and grow, and no one in the market knows the language. I always tell the new hires that we have a lot of learning opportunities - Go, Ruby, Python, Elixir - you name it. All the fresh college grads can't wait to jump in and contribute within 2 hours of getting hired. My grand-grand father always said "If you can't pick up a new language in a day, you aren't a good programmer and don't belong on Hacker News." He also said using C#/Java/Python is "sus booomer ** fr".

This is excellent advice. The "worse is better" manifesto says similarly:

> The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads.

https://www.dreamsongs.com/RiseOfWorseIsBetter.html