Hacker News Reader

>Those students who are trying to transcribe lectures and not actually learning anything? My guess is it's because they're burning cycles mentally saying "'the', I need to find 't' and an 'h', aaaaaand 'e'. 'quick', where the hell is 'q'?"

I wouldn't be so sure. I can write and type just fine, but I always learned better in class by listening to the teacher instead of trying to produce a pile of notes. All of the kids I remember that wasted their time writing down everything the teacher said without really listening to them, did just the same with computers or old-fashioned pen and paper.

> All of the kids I remember that wasted their time writing down everything the teacher said without really listening to them, did just the same with computers or old-fashioned pen and paper.

I was the same way throughout school, but I think the causal relationship might be reversed. The students who take notes almost robotically might just do so because they have poor verbal memory.

I always listened best by having my hand do something. So I often wrote (unreadable) notes, doodled around, and made drawings. Never used these notes for anything, but when I was studying afterwards, I could use them as an aid to remember the lectures better: at this doodle of a flying Christmas tree with antlers, the professor explained such or so. Very odd.

One can listen and take notes at the same time. I found that taking notes helped a lot, even though I hardly ever to never reviewed them later. But it helped to strengthen what I was listening to.

The simple takeaway is that different people learn differently. Don't assume what works for you will work for others and vice versa.

I wasn't really trying to judge anyone's preferred method of learning (though I see how I came off that way), just arguing that the "guy who takes tons of notes but learns very little" phenomenon has nothing to do with typing skills. I had a few people in mind from my school days who would practically transcribe each lecture, producing pages of minutes and never putting their pen down for a moment, yet understand less by the end than the stoner in the back who slept through half of it.

> the two probably intersect more often than you think they do

One of the reasons I like more terse, concise languages is because it allows me to get the idea represented quicker, so I spend more time thinking about the problem and solution and less time transcribing the solution.

There is,of course, a downside in legibility, but I believe that's mostly mitigated for people familiar enough with the language.

You can have the best of both world with an IDE with good autocomplete where you only have to type a few characters and hit tab most of the time, resulting in less time typing and improved legibility.

> resulting in less time typing and improved legibility

...and more time correcting the text that the IDE autocompleted wrongly.

What experience are you basing that on? That has never happened to me. It shows you what it's going to put in before it puts it in and gives you a drop-down menu.

Well, that's correcting the choice, only before its applied, what has little impact on how much attention the IDE grabs from you.

I've had both before and after application errors, on different IDEs and different codebases (some sets of names change the probability distribution). But Visual Studio seems to be the worst ofender, stealing not only the up and down arrows for navigation, but also open parentesis, space, enter, period, and colon, for application... and I'm sure I forgot some keys.

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

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?

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.

> 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.

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.

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.

> 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!

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.

> If you struggle with typing, the first thing you're likely to do is reach for the mouse for anything other than text entry. Which means you reeaach over to the mouse, then mooooove the mouse, click, and...what was it you were doing again?

The same thoughtless action that comes from using a familiar tool for expression can carry over to any tool, including the mouse. I don't think about the keys or where my fingers are in relation to the keyboard when I'm typing this--the thoughts just go from my head straight to the text box where my eyes corroborate what my brain is thinking. But the same can be said for when I'm browsing the web and I move my hand to the mouse and scroll down... I don't think about it, it just happens. My brain thinks, "I wonder what's further down the page" and my body responds accordingly.

That said, there's much to be said for the efficiency of a keyboard. A few months ago I installed the Vimium Chrome extension and I've been trying to get myself to use the keyboard for scrolling down and clicking links. It's hard. My brain instinctively (still, after months) tells my hand to move to the mouse. I often need to take my hand off the mouse and go back to the keyboard to force myself to use the keyboard shortcuts.

The same is true with reading code: if your brain has no association with curly braces, you're not going to be able to scan a chunk of code and intuitively separate code within curly braces from code outside the curly braces.

So there's more to it all than just the difficulty or familiarity with the tools. It's also about skill and habits.

If you are worried about typing speed slowing down your coding, I would assume that your code is not very well thought through in the first place. When I was at university a while ago, we were told to go and write the algorithm down on paper before coding it - a practice I find way more helpful today than any unit testing framework.

The niggley little things that cause syntax errors are likely to cause an order of magnitude more mental effort than trying to find a key. Or a crap algorithm because you dived straight into the code.

As a side note, many terminals have tab completion and most IDE's have something similar. I can't touch type, but I don't think I need to in this day and age. And I go pretty fast. So much of your argument is irrelevant for developers.

I think you're assuming that because people can't type that that implies they don't remember where the keys are located. People who can't type simply have developed different muscle memory, which is probably less efficient than typing. However, as many people have explained, it's not such a big deal. There has been code completion, in some form, for decades: http://www.emacswiki.org/emacs/HippieExpand

Also, consider that people seldom type "M...y...C...l...a...s...s", they type My<TAB>

And soon we'll be typing "var foo = 2"

There's so much code completion in a modern IDE:

if<TAB> for<TAB> r<TAB>

I agree completely. I've always found that listening and transcribing are mutually exclusive. In university taking comprehensive notes were often helpful, but I would usually not know what had been discussed in the class until I re-read the notes later.