2 ms·

If that's the stick we measure with, then don't forget to count how many times code is executed.

fnordpiglet 4y ago
My saying for that measure is “make it work, make it right, make it fast, make it small.” Those are the dimensions the machine cares about, after all the readable code is translated for the machine from the original written form.
- dataflow 4y ago
  > make it work, make it right, make it fast, make it small I'm not entirely sure I understand the difference between the first two (?) given that if something is working wrong, then I would call it broken, not working. But these are a bit beside the point I was trying to make. > after all the readable code is translated Prioritizing readability before all of those breaks your own yardstick though. Your metric for prioritization was the frequency of each event, and it seems you just changed your metric when it didn't give the outcome you liked! Note I'm not taking a stance on the priorities here, just pointing out that the argument you put forward only looks convincing when you conveniently omit the half of the story about execution. The moment the listener thinks "but my code will execute several orders of magnitude more frequently than it will be read by a human", it breaks down. Execution is arguably the more important half too, since horribly unmaintainable code that runs can still deliver some value, whereas perfect code that doesn't run doesn't deliver any value! I imagine probably a better yardstick is the cost/benefit trade-off of the code in the long run - trying to estimate SWE-minutes it costs in the future vs. how much money it would save in execution.
  - asddubs 4y ago
    The difference between the first two is how ugly the code is
    - fnordpiglet 4y ago
      Yeah make it work means don’t spend time figuring out how to do it right - just make it work first. Then you’ll usually know exactly how to make it right. Once it’s made right it’ll be more obvious how to make it fast. Once it’s fast, you’ll see the fat left over and you can trim it down. The benefit of this approach is you can choose when to stop - often working is enough, and these days things rarely reach small.
  - fnordpiglet 4y ago
    It’s contextual of course. The vast majority of code isn’t executed millions of time but is bootstrap to the primary kernel of execution. This kernel of execution tends to be fairly small in LOC space while dominating CPU time. Likewise most of the energy in software goes into the less expensive logic that configures the “interesting work” dominating the CPU. Readable code would take the bitflipping raw execution code and wrap it in an abstraction that’s easy to reason about as black box. Further, I’d say human time, velocity, and code agility is considerably more important than CPU time. CPUs are machines. They exist to do work and can do it without tire indefinitely. Being correct for the task is almost always (almost!) more important than being computationally optimal. That’s specifically why the metric stops there - even if I have to scale my farm by a factor of 10 due to inefficiency in the abstractions, it’s still a fraction of the cost of one engineers effort in a year. Obviously this breaks down at a certain point and at certain scales and at certain tasks. Finally making it work, right, fast, small by no means don’t write readable code at any let alone all stages. There’s very rarely any reason working, right, fast, small code is unreadable (aka unmaintainable). They are orthogonal concepts because readable code is about human ergonomics and work, right, fast, small is about architectural and runtime optimization phases.

My saying for that measure is “make it work, make it right, make it fast, make it small.” Those are the dimensions the machine cares about, after all the readable code is translated for the machine from the original written form.

dataflow 4y ago
> make it work, make it right, make it fast, make it small I'm not entirely sure I understand the difference between the first two (?) given that if something is working wrong, then I would call it broken, not working. But these are a bit beside the point I was trying to make. > after all the readable code is translated Prioritizing readability before all of those breaks your own yardstick though. Your metric for prioritization was the frequency of each event, and it seems you just changed your metric when it didn't give the outcome you liked! Note I'm not taking a stance on the priorities here, just pointing out that the argument you put forward only looks convincing when you conveniently omit the half of the story about execution. The moment the listener thinks "but my code will execute several orders of magnitude more frequently than it will be read by a human", it breaks down. Execution is arguably the more important half too, since horribly unmaintainable code that runs can still deliver some value, whereas perfect code that doesn't run doesn't deliver any value! I imagine probably a better yardstick is the cost/benefit trade-off of the code in the long run - trying to estimate SWE-minutes it costs in the future vs. how much money it would save in execution.
- asddubs 4y ago
  The difference between the first two is how ugly the code is
  - fnordpiglet 4y ago
    Yeah make it work means don’t spend time figuring out how to do it right - just make it work first. Then you’ll usually know exactly how to make it right. Once it’s made right it’ll be more obvious how to make it fast. Once it’s fast, you’ll see the fat left over and you can trim it down. The benefit of this approach is you can choose when to stop - often working is enough, and these days things rarely reach small.
- fnordpiglet 4y ago
  It’s contextual of course. The vast majority of code isn’t executed millions of time but is bootstrap to the primary kernel of execution. This kernel of execution tends to be fairly small in LOC space while dominating CPU time. Likewise most of the energy in software goes into the less expensive logic that configures the “interesting work” dominating the CPU. Readable code would take the bitflipping raw execution code and wrap it in an abstraction that’s easy to reason about as black box. Further, I’d say human time, velocity, and code agility is considerably more important than CPU time. CPUs are machines. They exist to do work and can do it without tire indefinitely. Being correct for the task is almost always (almost!) more important than being computationally optimal. That’s specifically why the metric stops there - even if I have to scale my farm by a factor of 10 due to inefficiency in the abstractions, it’s still a fraction of the cost of one engineers effort in a year. Obviously this breaks down at a certain point and at certain scales and at certain tasks. Finally making it work, right, fast, small by no means don’t write readable code at any let alone all stages. There’s very rarely any reason working, right, fast, small code is unreadable (aka unmaintainable). They are orthogonal concepts because readable code is about human ergonomics and work, right, fast, small is about architectural and runtime optimization phases.