An obvious point that took me way too long to appreciate: in software engineering, you should probably optimize for speed even when you don't have to, because it's one of the easiest/best ways to prioritize subtraction and parsimony in the solution space. https://www.nature.com/articles/d41586-021-00592-0 ….
-
Why not sidestep all the controversy and express it as "optimize for simplicity" - then I think we all agree. Optimizing for speed can often add complexity.
1. Simplicity is a vague concept, whereas speed is comparatively easy to measure. 2. There are multiple kinds of simplicity. Some have terrible effects on speed. You don't want those in production software.
-
-
I concede parts of that, yes. For me, though, what works best is: 1. optimize for simplicity (which I concede requires skill and experience and common culture to define) 2. measure speed (since it's "easy") and deviate from (1) when required
-
Because, in prod software, often one does not care about speed at all. "simplest" code is many orders of magnitude fast enough, and doesn't need to scale. Obviously, care deeply about the exceptions, but they are rare.
- Show replies
New conversation -
-
-
I prefer to optimize for *not building software at all* unless you absolutely must. Corporations have engineers who want to write code, and often the answer is to use something that already exists.
- End of conversation
New conversation -
-
-
But you do. If the slow but simple code only runs seldomly, and its speed doesn't matter, keeping it simple rather that unrolling loops and doing tricks w the data structures, is a win.
-
In most software, only a small % of the code actually needs to be fast (because it runs often, or in interactive visualizations/output).
End of conversation
New conversation -
-
-
Obviously you're talking about two different things. Removing UX steps is good. Making code less reliable and harder to maintain to save some milliseconds when you're about to make a network call that'll take 0.2s, less so.
-
Seems like a good summary to me.
End of conversation
New conversation -
-
-
Here's a definition of simple code: the fewest lines of normally formatted source. Bugs are correlated to number of lines, suggesting there's something real there. Too much abstraction costs many lines, especially in languages with lots of ceremony, like Java.
-
Of course if your language of choice is Lisp, then you can get yourself in trouble. It's harder to get into the same kind of trouble in C.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.