Airline check-in desks, I think, is their reason for being. A lot of typing done there, 24/7, with customers that are about to miss their flight waiting in line. If the keyboard goes down, money can be lost. So they use keyboards that don't break.
The reliability of the keyboard doesn't matter for software engineers. You just get another $20 one out of the supply closet while you get your next cup of coffee.
(I used to be a big Topre keyboard fan and owned quite a few. I didn't buy them for reliability, though, I bought them because I liked them. That's not a good "enterprise" reason, though, which is why they're not standard-issue for software engineers.)
For 90% of companies, increasing software engineer productivity by just a few dozen bps is worth thousands of dollars a year. On top of a $4k laptop, $2k screens, etc. a $400 keyboard is totally reasonable. If your company won't let you get stuff like this they're probably being irrationally stingy.
I've been in this business a long time and the idea that we are limited by the typing speed of the programmer is just about the biggest crock I've heard so far. Thinking of the concrete details from Google's 2016 paper where they reported a gross commit rate of 1000 lines of code per engineer per week, inclusive of large-scale automatic refactoring and configuration changes that were 75% of the volume. That leaves your typical engineer on the hook for just 50 lines of code per day which honestly that still sounds a little high. Programmers are limited by cognition, not I/O rate.
I'm limited by typing speed. I can type about 120 words per minute, but there are still times when my idea is not instantly conveyed to the computer. In that case, I'm forgetting new ideas while interfacing with a piece of machinery.
1000 lines of code per engineer per week is probably a factor here. Think about a flow where you're bottlenecked by typing something. You then don't finish the thing because you have a sprint planning meeting. You come back and forget where you left off, and never check in the code you half-wrote. If you finished before the meeting, then your line-modified count would have increased by 50 lines or something. But now you spent an hour doing nothing, as far as the lines-of-code counter says. That's a problem!
Typing speed is back pressure on ideas. When a system is overloaded, it should apply back-pressure so that the producer produces less. That's what your keyboard does. The question is: do you want back-pressure against your ideas? If not, you need to add a buffer that can account for the bursts. Typing faster is that buffer.
I think an honest evaluation would reveal that the interrupted program and the forgotten ideas stood even chances of being of negative value anyway. Getting the programmer away from the keyboard is an organizational defense mechanism.
"Net lines of code" has ~nothing to do with amount of time spent typing, and a good keyboard lets me type without wasting brain power on keyboard-related proprioception.
This reminds me of my amazement to learn from the YT teardown movement (AvE, etc) that professional tradesmen often consider a topline Makita or Dewalt cordless tool to be good to go for one job (e.g.,a single commercial high-rise building) and after that, it's time to get (aka, bill for) a new one.
I believe software folks could take some cues from that practice.
