1. 6
  1. 14

    I have to disagree, at least partially. A couple years ago I started learning the norman layout on a columnar keyboard (Ergodox, then Planck). I crashed from ~100 wpm to 9 wpm and it took weeks to crawl above 30 wpm (I took regular typing tests). I absolutely was a less productive programmer, and I had plenty of time to think about it as I crawled my way through the days. I think there are two main factors this doesn’t take into account.

    First, I think this back-of-the-envelope calculation is roughly accurate, but it’s about lines of finished code. Producing 100 lines of production code can require producing more than ten times that much in drafts, tests, debugging, typos, and intermediate forms. We’ve all had that day (…or week…) debugging that ends with a one-line fix, right?

    Second, this only accounts for code. A significant amount of my work is communicating with coworkers and users on Slack/email/tickets or writing documentation. That all greatly outweighs the raw code I produce, and I would not be an effective programmer if I wasn’t doing it.

    More subjectively, it’s a distraction to not be able to type quickly. Not just if you’re crawling along at 10 wpm and have to consciously think about each key, but when I was only typing at 40 or 50 wpm I couldn’t get down thoughts as fluidly as I could think them. Above 60 or 70 wpm this faded away and I’d agree that it’s not a bottleneck, but it is a loss of performance.

    1. 8

      More subjectively, it’s a distraction to not be able to type quickly.

      I can’t agree more. I didn’t think text input speed was an issue until I started trying to type code on a phone keyboard. The speed of doing that is just unbearably slow.

      1. 5

        I see what you’re saying, but I think it misses the spirit of the argument in the article, which is probably better summarized as “For developers who can touch-type, the amount of code required to be typed is not a programming bottleneck” We could probably soften the statement a bit more and still get to the heart of what the author saying which is “Exchanging verbosity for functional simplicity and reliability is a net win.” I agree with both of those statements. I don’t think the argument about wpm is even necessary. I’ve failed to ship plenty of features on time, and never once was the problem that I couldn’t type the code in fast enough. That’s never even been close to being a concern. On the other hand, chasing down runtime type errors, shared mutable state, isolated data in invalid states, and similar issues have often cost myself and teammates quite a bit of time. Of course, poor organization and planning can outweigh any of those factors, but when it comes to the actual code, I’ll take verbose stronger guarantees over terse weak contracts any day of the week.

        1. 2

          Notice that the author presents a class with a builder that’s 78 lines alongside the mythical man month finding that programmers produce 10 lines a day.

          Something tells me he would not be ok taking an entire day, or even 8 days(!) to produce it. Reasoning about averages has a lot of pitfalls.

        2. 5

          Some people type code slowly. And they get the code done fine. But in my experience the same people also struggle to contribute on Slack channels, to respond in depth to emails, to write comprehensive commit messages, to document what they’re doing and the assumptions they’ve made. Maybe they do some of them, but not all.

          Also I would suggest that if you’re making decisions as to whether types should have reference or value semantics based on the number of lines of code required, that’s a serious language flaw.

          1. 5

            Another related consideration is reading speed. When doing code review, a 50-line PR is a lot more attractive than a 500-line one.

            1. 5

              The author acknowledges that people spend much more time reading code than writing it, but then fails to address the fact that reading 10 times as much code takes 10 times as much effort, and that understanding it (when it’s very dense) or finding bugs (when it’s just boilerplate) takes much more than that.

              1. 5

                Similarly, if I interrupt you for 10s every 5 mins, that’s only 3% of your time. Shouldn’t be a bottleneck, right?

                1. 5

                  What if typing slowly makes you a better programmer? Perhaps because you won’t put up with having to write 78 lines of repetitive boilerplate to accomplish a record value type? Laziness is a virtue…

                  1. 4

                    The majority of this article doesn’t address the thesis. The author makes a perfectly reasonable if somewhat uninspiring argument to arithmetic to back up the title, but then the majority of the piece is about how (to paraphrase) terseness is not a great virtue in programming.

                    In this I think he fails to convince. He presents two code samples, one quite short and one extremely long and arguably quite unpleasant to try to wade through. And his argument is that the second is to be preferred because, semantically, it’s better. Well, no duh! I don’t think it’s very convincing to compare bad code to better code and then argue that because this particular implementation in this particular language is longer, then it’s not reasonable to prefer short code to long code. At the risk of stating the obvious, the rule of thumb is that one should prefer short code to long code all other things being equal.

                    In this case the author undercuts himself because he mentions offhand that he’d prefer to do this in a language where you could accomplish something with the same semantics much more tersely. Which would seem to be exactly the sentiment he was trying to contort himself out of saying.

                    Nobody would argue that terseness is a virtue because (or simply because; I hate to type) you get to type less. Being able to communicate The Right Thing in the simplest terms, with the least structure, with the least vocabulary, makes your work easier to read, less likely to contain errors, and in a well-designed system, more combosable.

                    1. 3

                      Oh, that kind of typing. I was expecting type systems :D

                      While it takes longer to type, it comes with several benefits. The main benefit is that because it’s immutable, it can have structural equality

                      Fix your language.

                      Seriously, if your language is not expressive enough for your needs, try fixing it in some way. Not necessarily a clean way. You can use a code generator/preprocessor! That’s kind of the oldest “avoid typing” tool :)

                      The author even mentioned F#:

                      Such a declarative approach to types produces an immutable record with the same capabilities as the 78 lines of C# code.

                      If you need to write C#, why not do some preprocessing to add that capability to C#?

                      1. 2

                        8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.

                        Do we specify the typing speed required by a secretary in words typed per day?

                        1. 2

                          I often need to perform conceptually simple changes, but they require several modifications in multiple places.

                          Now I probably need to become a master at sed or something like that, but I’d say I am indeed often times limited by the speed of my typing.

                          It would help reducing the loss of focus due to spending time thinking about how an edit operation will be performed.

                          1. 1

                            This is an incorrect, tired assumption. I suspect it will be resolved or forgotten over the next 20 years as ML and BCIs change the way we interact with our development environments.