3 ms·

Write slow code now, profile and optimize later is how we got all slow software because second step - optimization practically never happens in my experience.

Write slow code now, profile and optimize later is how we got all slow software because second step - optimization practically never happens in my experience. Along with the heuristic that hardware and electricity are cheap, developers are expensive. That's probably why managers in my experience almost never ask developers to optimize slow code - they believe it would be cheaper to use more hardware if this fixes the problem (in some areas like HFT or GamDev more hardware is not the answer so optimization do happen). In rare cases I've seen optimization being done initiative always come from IC (who knew that the code could work fast / use less resources). So nowadays writing code I assume that it never will be optimized later and try to do less dump stuff from the beginning.

moonchrome 4y ago
If it doesn't happen then it doesn't matter.
- citrin_ru 4y ago
  It doesn't matter in a sense that most companies continue to be profitable even paying significantly more for hardware / clouds than they potentially can. But it is sad to see nevertheless. Also it increases CO² emissions.
radicalbyte 4y ago
The heuristic is one of those for the mid-experience developer. That's the point where you spend two weeks re-implementing Set<T> to save 1 cycle. Or over abstract. Lots of developers never get past that point. Experienced devs - such as yourself - generally know how to write reasonably fast code that is also clean (or easy to extend) first time. In my opinion we should be more explicit about this in the heuristics.
Zvez 4y ago
>Write slow code now, profile and optimize later is how we got all slow software because second step We got slow software because we were ok to get slow software. If being fast is not in requirements it means it doesn't matter (for whoever is responsible for defining priorities). Places where performance matters it is never sacrificed.
- curtainsforus 4y ago
  This is a fully general counterargument for why anything that is bad is actually good because it doesn't matter. "Places where air quality matters it is never sacrificed".
- _aavaa_ 4y ago
  Doesn't matter for what/who? It's doesn't matter from the business angle since there isn't any competition that works better. But it definitely matters for me. I am not okay with slow software, and being forced to use it is frankly insulting. Teams (to pick a punching bag) hogging my system resources doesn't impact its adoption since I'm forced to use it. Teams could be 10x slower and I'd probably still be forced to use it. But it wouldn't be because speed doesn't matter.

moonchrome 4y ago

If it doesn't happen then it doesn't matter.

citrin_ru 4y ago
It doesn't matter in a sense that most companies continue to be profitable even paying significantly more for hardware / clouds than they potentially can. But it is sad to see nevertheless. Also it increases CO² emissions.

radicalbyte 4y ago

The heuristic is one of those for the mid-experience developer. That's the point where you spend two weeks re-implementing Set<T> to save 1 cycle. Or over abstract. Lots of developers never get past that point. Experienced devs - such as yourself - generally know how to write reasonably fast code that is also clean (or easy to extend) first time. In my opinion we should be more explicit about this in the heuristics.

Zvez 4y ago

>Write slow code now, profile and optimize later is how we got all slow software because second step We got slow software because we were ok to get slow software. If being fast is not in requirements it means it doesn't matter (for whoever is responsible for defining priorities). Places where performance matters it is never sacrificed.

curtainsforus 4y ago
This is a fully general counterargument for why anything that is bad is actually good because it doesn't matter. "Places where air quality matters it is never sacrificed".
_aavaa_ 4y ago
Doesn't matter for what/who? It's doesn't matter from the business angle since there isn't any competition that works better. But it definitely matters for me. I am not okay with slow software, and being forced to use it is frankly insulting. Teams (to pick a punching bag) hogging my system resources doesn't impact its adoption since I'm forced to use it. Teams could be 10x slower and I'd probably still be forced to use it. But it wouldn't be because speed doesn't matter.