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
#teamReadability
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.
That doesn't sound right. I would urge you to come and talk about in #emacs@freenode if you haven't already!
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.
"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.
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.