The Rule of Everything in Software Development: Everything should be subject to cost/benefit! Corollaries: (...don't do that!) - If you paint yourself in

The Rule of Everything in Software Development: Everything should be subject to cost/benefit! Corollaries: (...don't do that!) - If you paint yourself into an untenable corner, you lose! - If you plant a time bomb that explodes and kills you, you lose! - If you sink yourself too deeply into technical debt, you die! You lose! Avoiding pre-optimization is just the flip side of the intelligent cost/benefit analysis coin. Don't start writing hyper-optimized code everywhere. However, also don't architect your real-time game system such that making string comparisons is inextricably the most common operation. Here's a solution that I've found. It's not foolproof, but it will get you out of trouble quite often. Code such that you can change your mind. HN user jerf's "microtyping" technique in Golang let me do that with my side project. I committed the egregious error I mentioned above, of using string identifiers for the UUID of my MMO game entities. But because I followed the "microtyping" technique and did not directly use type string, but rather used ShipID, I could simply redefine: //type ShipID string // old bad way type ShipID struct { // new way A int64 B int64 } Where possible, your code changes should be bijections. Renamings should be bijections and never surjections. The bigger your changes, and the more automation is involved, the more you should hew to bijective changes.