5 ms·

When is typing speed ever really the bottleneck? Code gets read 100x more often than it gets written, and any editor or IDE worth it's salt can auto-complete fa

by mvid 12y ago

When is typing speed ever really the bottleneck? Code gets read 100x more often than it gets written, and any editor or IDE worth it's salt can auto-complete faster than you can think anyway. #teamReadability

JackMorgan 12y ago
So why use a wordy language that makes you read twice as many characters to get the same concepts? It would take a few weeks to learn to read the smaller language, but the rest of your career to gain the benefits. Why write down to the skill of the least skilled member?
- mvid 12y ago
  If you are looking only to optimize your career and expertise, do whatever you want. If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. The least skilled team member is still a team member. The fresh grad, the intern, the customer support rep with an interest in code, the new hire. Why are you so willing to discount any of these members as not valuable? Just because they don't have an innate skill and interest in code golf? Reading symbols is a near instantaneous exercise. You can tell the difference between "i" and "index" with no extra work. Stopping to think to decipher the meaning of cryptic code is slow. It doesn't hurt to use a full word instead of a single letter variable name, or an explicit function call instead of an alias to some cryptic character. We don't use languages anymore that benefit from have a small file size. Reading will always be more important than writing, until you get down to hardware drivers and kernels.
  - marcosdumay 12y ago
    > If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. "All levels of talent" is such a can of worms. No, not even in a team environment you should have all code accessible to all levels of talent. That's just a recipe failure. Anyway, that isn't really relevant to the argument of how many characters you should use in a variable name.
  - JackMorgan 12y ago
    Oh, I wasn't talking about variable names, those are certainly the fastest to read and communicate the complexities of a domain. I was talking about programming languages that require 3-4x the code/boilerplate to write the same logic. For example, F# usually needs roughly half the lines and way less than half the characters than the equivalent C# code, assuming all the same variable and function names. Other examples are Scala, Haskell, Clojure, Go, or even lambdas and the Linq features of C#. I've heard others argue we shouldn't use these because "jr members won't understand them". Usually the person arguing this position is not junior, and does not know the feature or language now. Which leads me to believe it has nothing to do with junior members at all, and everything to do with them. Edit: I also think that writing down to the least skilled member is disrespectful to them and you. It's pandering to treat them as too ignorant or stupid to learn powerful concepts, no matter who they are. I also think most people who make this argument disregard the sheer cliff wall of difficulty that is modern software development. The difference in difficulty between an entire C# stack with inheritance, interfaces, threads, polymorphism, and mutable class state and all that plus lambdas is really minor.
read 12y ago
How about movement? Typing speed is the bottleneck when you are racing to discharge a thought. It's what the article calls: “transcription fluency”: How quickly and fluidly you can get down — “transcribe” — the stuff that’s in your head. ...you don’t want a bottleneck between the ideas they’re forming and the writing. What you suggested doesn't address how you get to the final outcome. You suggested: Code gets read 100x more often than it gets written. Well, good code is, bad code isn't. How do you produce good code? Plus, writing code isn't only about writing but also about deleting; IDEs don't have autodeletion. And typing isn't only about typing. It's also about moving to the place where you want to type. One thing I want more from IDEs is auto-movement within the same file. Emacs has this to some extent. Pressing Ctrl+<up arrow> jumps up an entire function, because Emacs (in Linux) is cognizant of the barriers of a function [1]. Emacs on Mac OS X doesn't, and it's the #1 productivity killer for me when coding. It takes too long to move. I might stop using Mac OS X precisely because of this [2]. [1] - Or at least whitespace between lines of code or basic blocks. [2] - I haven't stopped using it, because you can't get a Debian with working wifi on a MacBook Air. So, ironically, typing speed is a bottleneck for me when the OS doesn't have good hardware drivers, and that wasn't an issue with paper and pencil. Things get complicated fast; I hadn't seen that coming.
- eqyiel 12y ago
  > Pressing Ctrl+<up arrow> jumps up an entire function, because Emacs (in Linux) is cognizant of the barriers of a function. Emacs on Mac OS X doesn't, and it's the #1 productivity killer for me when coding. That doesn't sound right. I would urge you to come and talk about in #emacs@freenode if you haven't already!
DougWebb 12y ago
For me, that auto-complete is useful about a third of the time, and the rest of the time it's like having someone hovering over your shoulder saying "Did you mean ...?" every few keystrokes. If a person did that to me I'd tell them to shut up for a second and wait, and they'll see what I mean as soon as I finish typing it.

by mvid 12y ago

JackMorgan 12y ago

So why use a wordy language that makes you read twice as many characters to get the same concepts? It would take a few weeks to learn to read the smaller language, but the rest of your career to gain the benefits. Why write down to the skill of the least skilled member?

mvid 12y ago
If you are looking only to optimize your career and expertise, do whatever you want. If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. The least skilled team member is still a team member. The fresh grad, the intern, the customer support rep with an interest in code, the new hire. Why are you so willing to discount any of these members as not valuable? Just because they don't have an innate skill and interest in code golf? Reading symbols is a near instantaneous exercise. You can tell the difference between "i" and "index" with no extra work. Stopping to think to decipher the meaning of cryptic code is slow. It doesn't hurt to use a full word instead of a single letter variable name, or an explicit function call instead of an alias to some cryptic character. We don't use languages anymore that benefit from have a small file size. Reading will always be more important than writing, until you get down to hardware drivers and kernels.
- marcosdumay 12y ago
  > If you care about having a codebase that is accessible to all levels of talent, then you should optimize for readable code. "All levels of talent" is such a can of worms. No, not even in a team environment you should have all code accessible to all levels of talent. That's just a recipe failure. Anyway, that isn't really relevant to the argument of how many characters you should use in a variable name.
- JackMorgan 12y ago
  Oh, I wasn't talking about variable names, those are certainly the fastest to read and communicate the complexities of a domain. I was talking about programming languages that require 3-4x the code/boilerplate to write the same logic. For example, F# usually needs roughly half the lines and way less than half the characters than the equivalent C# code, assuming all the same variable and function names. Other examples are Scala, Haskell, Clojure, Go, or even lambdas and the Linq features of C#. I've heard others argue we shouldn't use these because "jr members won't understand them". Usually the person arguing this position is not junior, and does not know the feature or language now. Which leads me to believe it has nothing to do with junior members at all, and everything to do with them. Edit: I also think that writing down to the least skilled member is disrespectful to them and you. It's pandering to treat them as too ignorant or stupid to learn powerful concepts, no matter who they are. I also think most people who make this argument disregard the sheer cliff wall of difficulty that is modern software development. The difference in difficulty between an entire C# stack with inheritance, interfaces, threads, polymorphism, and mutable class state and all that plus lambdas is really minor.

read 12y ago

How about movement? Typing speed is the bottleneck when you are racing to discharge a thought. It's what the article calls: “transcription fluency”: How quickly and fluidly you can get down — “transcribe” — the stuff that’s in your head. ...you don’t want a bottleneck between the ideas they’re forming and the writing. What you suggested doesn't address how you get to the final outcome. You suggested: Code gets read 100x more often than it gets written. Well, good code is, bad code isn't. How do you produce good code? Plus, writing code isn't only about writing but also about deleting; IDEs don't have autodeletion. And typing isn't only about typing. It's also about moving to the place where you want to type. One thing I want more from IDEs is auto-movement within the same file. Emacs has this to some extent. Pressing Ctrl+<up arrow> jumps up an entire function, because Emacs (in Linux) is cognizant of the barriers of a function [1]. Emacs on Mac OS X doesn't, and it's the #1 productivity killer for me when coding. It takes too long to move. I might stop using Mac OS X precisely because of this [2]. [1] - Or at least whitespace between lines of code or basic blocks. [2] - I haven't stopped using it, because you can't get a Debian with working wifi on a MacBook Air. So, ironically, typing speed is a bottleneck for me when the OS doesn't have good hardware drivers, and that wasn't an issue with paper and pencil. Things get complicated fast; I hadn't seen that coming.

eqyiel 12y ago
> Pressing Ctrl+<up arrow> jumps up an entire function, because Emacs (in Linux) is cognizant of the barriers of a function. Emacs on Mac OS X doesn't, and it's the #1 productivity killer for me when coding. That doesn't sound right. I would urge you to come and talk about in #emacs@freenode if you haven't already!

DougWebb 12y ago

For me, that auto-complete is useful about a third of the time, and the rest of the time it's like having someone hovering over your shoulder saying "Did you mean ...?" every few keystrokes. If a person did that to me I'd tell them to shut up for a second and wait, and they'll see what I mean as soon as I finish typing it.