Don’t Prematurely Optimize

When performance wasn’t a consideration from day one, inefficiency becomes endemic, corrupting every square mibbibyte of the project. Why not iterate a giant array instead of using hashes? Why not use LINQ everywhere, repeatedly and inefficiently filtering a massively excessive superset of the needed data?

Source: Yafla

I disagree.

Firstly, I feel that the array vs hash and LINQ examples are fairly contrived. In reality, a good engineer shouldn’t even consider those approaches in the first place. There’s rarely a compelling reason to do so.

A decent solution of either example would take marginally more time and produce way better code. And that’s a trade-off a good engineer makes in a heartbeat from experience.

Engineering is about making business goals/optimization trade-off decisions. Constantly. One of the many traits of good engineers is how quickly and accurately (on hindsight) we can make such decisions. Unless the business goal is optimization.

I find that these debates often come down to an either-or proposition: “put off optimization indefinitely” or “optimize to the max the whole way through.” But it should never be so black and white. From a business view, both approaches are wrong, as they tend to entail unnecessary costs.

After much programming experience, including trying both extremes, I’ve learned that a middle road is the most cost-effective.

-Jarret on Hacker News


Now read this


Every opportunity has its costs. On hindsight, we celebrate the great ones and try not to regret the missed ones. How then, should we approach opportunities that come our way? To me, it’s about understanding how we want to mold... Continue →