From memory, \w. Conceptually, this is because in regular expressions, capitalization indicates negation. \w matches word characters, \W matches non-word characters, \d matches digits, \D matches non-digits, \s matches whitespace, \S matches non-whitespace.
Having a conceptual understanding helps to be able to extrapolate more information with less memorization.
I don't mean this as a refutation of your overall point; I think your point is correct, that using cheat sheets allows you to save mental bandwidth. I just think this wasn't a great example.
Why is it static void main(argc, argv) in Java? Well, that's the way C did it. Why did C give main() function arguments, as opposed to (say) environment variables? Well, that's just the way it's done. Why is return 0 success and other values fail? Convention. Why are curly braces used to delimit code and parentheses used to delimit arguments? Because the spec authors said so.
Basically, I think most of what constitutes programming can be done without ever typing a line of code. It's the process of decomposing a large task into small, simple ones, in a way that can be processed efficiently. The rest is just notation.
Pedagogy is absolutely fine, but at the same time we all stand on the shoulders of giants. Nobody is writing their own TCP/IP stack, we all rely on "copied and pasted" code (encapsulated in a library) so that we can focus on business logic. Obviously if you don't know what you're doing you can easily cause a mess, but the physical act of typing is probably the least important part of programming. Conceptual understanding is what matters, and the random syntax and half dozen keyword modifiers you will learn by typing are not going to push you very far in conceptual understanding.
Sure you can look down and see where they are. But its just that your brain on enough practice has mapped your fingers to the pattern of what you wish to do. There is very little memory involved in all this exercise.
The bad part about not having this kind of muscle memory is you have will have a whole lot of unnecessary overhead of working out things by sight and coordinating it with hand movements, which is very distracting when you have something requiring very high focus to do on hand. Especially in things like music, timing is everything. Working out things by sight is a straight no-go to even start with.
IDE makes it easy for you to work with complex navigation patterns, whether its bugs or understanding some part of your code or debugging. IDE is a tool designed to make that workflow easy for you. Its not a tool designed to make typing easy. And using tools like to these to avoid learning typing, makes it more hard in situations when you can't find your way out without typing.
In my opinion, the author's goal was to make a blog post. So he searched around for something like an original thought... and he found a glimmer (merely) of a thought: that hand-typing helps you READ content better than copy&pasting does.
It's more of an observation, actually... An independently repeatable one, sure... :)
Automate for speed, not for lack of understanding :)
Rote memorization is actually very useful; frankly, I think that its abandonment as a pedagogical tool is partially to blame for modern students' appalling lack of education.
Sometimes you gotta recite 'amo, amas, amat' over and over until you've got it right.
Honestly what I tended to do was pick up 80% of the characters and fill in the last 20% from context, just like filling in unknown words in a sentence out of context. And much like with foreign languages I was better speaking than receiving.
You see, when I was studying for an amateur radio license, I had a realization. Memorizing page after page of meaningless numbers and acronyms could actually instill a sense of curiousity about what those numbers and acronyms meant. What is a sideband and why does it single? Who is a Hertz? Why would I want to limit third-order distortion to below 0.1% of the principal frequency? You see, nobody had ever told me that it might be good to be curious about the thing I'm doing!
Sorry, this is meaningless drivel. Yes, you should know what the keywords do in a function declaration, but once you are aware of what 'static' means then typing it yet one more time does not help you whatsoever in the least. Yes, you should know know what various delimeters do in your language, but if you're not sure just go look it up, it doesn't make sense to fight it.
The reality is that there are all kinds of things that are best left in reference material. I have the Regular Expression Cheatsheet pinned right next to my desk; I could easily write a regex without it but by having a reference right there I conserve that mental bandwidth for tasks that matter. Pop quiz: which is the code for a word character, \w or \W? Is that something you want to be thinking about while you're also trying to juggle business logic for three other classes?
The same thing applies to all kinds of other things. We have documentation for a reason, memorizing the order of function arguments for a function I only use once a year is a waste of brain space. Some functions have all kinds of quirky behavior that you really need to double-check unless you use it daily - for example, anything in the C stdlib. It's not worth introducing bugs for the sake of avoiding using your IDE.
It's true that for skilled programmers, most of what we do is thinking about how to solve the problem rather than mechanically typing it in. But that's no reason to make the act of typing it in needlessly difficult. Programmers have been using intelligent assist systems for as long as we have had interactive computer systems, dating right back to vi/emacs macros.
These are a good thing: after I've encapsulated fields in getters/setters for my first five classes, the next thousand that I'm going to do over the course of the year buy me nothing, and I might as well let my IDE handle the mechanical act of declaring ten pairs of getters/setters for yet another class.