> Using Python because it lets you get something working fast. Oops three years later you're locking into Python and your app is slow as hell. You now spend all your time profiling instead of adding features.

Or your app continues to be perfectly usable like almost all Python apps because you’re not doing something CPU-bound in unoptimized code, and you’re not seeing YouTube/Instagram-level growth.

Performance is a real consideration but the better way to approach it is to make sure you understand the bottlenecks in your architecture and have a reasonable plan for replacing code when you need to. I’ve seen more failed apps in fast languages because the developers took so much longer to build things that they never found what users wanted or the performance problems they actually had weren’t what they expected so their Go code being 10% faster mattered less than taking months longer to reach feature parity.

There are situations where performance is critical on day one, of course, so part of your value as a senior engineer should be recognizing which situation you’re in and balancing those needs with your staffing levels, too. Your Bazel/make example is similar: if you’re seeing that kind of performance hit either something’s gone badly astray or you have grown to the point where you can afford to have someone dedicated to setting up more advanced tooling because they’re supporting hundreds of developers.