The other day, I was chatting with a friend about the book “Programming Pearls.” It’s a brilliant read for any developer—packed with clever solutions and stories about squeezing every drop of performance from your code. And it made me think about code optimisation in the daily jobs of developers. Once upon a time, code optimisation was very high on the priority list of engineers. I would spend hours trying to make my software run faster and use less memory. Why? Because buying new hardware was out of the question. I had to make do with what I had. Now, things have changed. The cloud has flipped the script. Need more power? spin up a bigger server. Want more memory? Click a button. Engineers have the keys to a kingdom of resources, and it’s all a few clicks away. There are no more waiting for the IT department, no more begging for an upgrade. And that is good. This has made code optimisation less urgent. Scale up infrastructure rather than spend days tuning code. The pressure is on to deliver features quickly, so optimisation often takes a back seat. But is that really a bad thing? Not always. The cloud lets us focus on building, experimenting, and delivering value. Startups can launch without worrying about running out of capacity. It’s a fantastic time for innovation. Of course, there are still reasons to care about optimisation. Cloud bills can skyrocket if you’re not careful, and wasteful code means a bigger carbon footprint. Plus, there’s a special pride in writing lean, elegant code. So, has code optimisation lost its importance? It’s not as critical as it once was, but it’s still in the toolkit. Now, we optimise when it matters, not because we’re forced to. In the cloud era, with endless resources at our fingertips, that feels like progress. Should we have a performance KPI to find?