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

 
12
Kudos
 
12
Kudos

Now read this

Solving for the Last Mile of Transportation

Cities should be built for people, not cars. Ridesharing was the last major shift in transportation, and I was fortunate to have been a part of it. The perspectives I gained at Lyft really struck me — even after I left, I never stopped... Continue →