From time to time, I see statements like this:
Ruby's key insight was to stop this kind of bending over backwards for the compiler and spoil the programmer with beauty they'd appreciate. https://t.co/TWCJAzIv0J— DHH (@dhh) March 28, 2017
If you're littering incidental line noise, like !== undefined, to save 10 nanoseconds or less, you've clearly chosen machine over human.— DHH (@dhh) March 28, 2017
The logic here is: “programmers shouldn’t spend too much time optimizing things, because programmers deserve beautiful experiences and high productivity.” Machines are fast enough, and developer time is valuable.
As a programmer myself, at first I’m tempted to agree with this. Who doesn’t want beautiful experiences and high productivity? Sign me up!
But let’s consider the phrase “choosing machine over human.” This is very programmer-centric framing. When we optimize code, are we doing it purely for the benefit of machines? No, of course not — we do it for our human users. Many of whom are now visiting our websites on underpowered mobile devices (which can benefit from optimization).
Rather than “humans (who are programmers) vs. machines,” a more, well, human way of framing this tradeoff is: “humans creating software” vs. “humans using software.”
If you optimize a program, the humans using the software benefit, while the humans creating the software are inconvenienced. Which humans deserve priority: the (small) group of humans creating software, or the (likely much larger) group of humans using software, benefiting from optimizations?
The answer, of course, depends.
I believe optimization is not always worth spending time on. And I know from experience that making extreme optimizations can result in code that’s hard to maintain.
But I also believe that having a pro-programmer bias, when making optimization decisions, is not healthy. We shouldn’t be forcing false choices between “pleasing the machine” and “pleasing the programmer.” Fetishizing programmers can come at a cost — a cost to the humans using software.
If you reframe it as “pleasing the end user” vs. “pleasing the programmer,” you’ll reach a more intellectually honest — and a more human — decision.