Depends on your string really. If your string are immutable (as in C#), it's not the same amortized cost and you end up wanting to use a StringBuilder almost ev

Depends on your string really. If your string are immutable (as in C#), it's not the same amortized cost and you end up wanting to use a StringBuilder almost every time. It's not premature optimization - it's just the standard pattern for performant coding. But I see your point - I inadvertently gave an example that is performance basics in some languages and fine tuning in others. The lock example is perhaps more relevant. Another good example is appropriate caching. Often services want to parse something (e.g. an ini file) and cache it in memory. Caching the right (fully parsed) format will lead to a highly performant configuration system - taking less than 1% of CPU time - but let some juniors do parsing on top of the caching layer rather than underneath your caching layer - and suddenly your config system is 5-10% or your service CPU and is a target for optimization. Most of my daily work in growing juniors is patterns like this, nothing a language would help with.