Is a programmer required to learn and memorize all syntax, or is it ok to keep handy some documentation?
Would it affect the way that managers look at coders?
What are the downside of depending on intellisense and auto-complete technologies and pdf documentation?
It is completely normal. Hardly anyone can say that he/she knows the syntax of every PHP or Java class, function or framework.
Your brain is better used for problem solving than for memorizing things.
Obviously you tend to memorize things you use in a daily basis but as soon as several month pass without doing that specific thing, you forget the syntax.
If remembering syntax was key in developing, computers would have already substituted humans in that field.
Using your brain for abstraction, imagination, problem solving and pattern recognition is priceless. For everything else, there's Master Card. (1)
(1) Or in this case documentation, auto-completion etc.
What you shouldn't definitively do is ask your co-workers every time you don't remember the syntax of something. That would be laziness.
In terms of memorization, I think it's pretty crucial to have a solid knowledge of your language's core syntax. That does not mean, however, that you need to memorize the core libraries. For Java that's the JSCL, for C#/VB that's .NET, for PHP it's, well... that.
Anyway, point is, know your syntax, but not necessarily every class, function, and/or method. Knowing the syntax is like knowing grammar in english: you know how a sentence should be formed. Knowing the libraries is more akin to vocabulary. If you don't know a word, you can look it up pretty easily; you may not find the perfect word, but you'll find something suitable. If you don't know the grammar, you're going to have a much harder time getting a message across clearly and correctly, and a much harder time looking up what you need when you need it.
I'm going to tell you a story.
Up until about May 30th 1999, John Carmack did not know that scissor test was not enabled by default in OpenGL.
The next thing is sort of funny. I had been suspecting that a lot of the OpenGL drivers were clearing the entire depth buffer for each of the 3D icons on the status bar, instead of limiting it to the scissor region. I added code to the g200 driver to explicitly crop the clear region in the driver, but it never got executed. A little more investigation showed that I had been making an improper assumption for years -- scissor is not enabled by default. Doh.
Finding this out came to him totally by accident, in the context of doing something else, and gave his code a fairly nice performance increase (given that he works in an area where performance is hugely important, this is worth noting):
Now I know that I was just being an idiot about that for the last three years... With scissor enabled, most of the cards got a few percent faster.
It's also worth noting his self-awareness here: "I was just being an idiot about that for the last three years".
Now, if he had read the documentation ("The test is initially disabled"), he would have been aware that scissor test was disabled by default and would not have made that mistake.
Is this a case where reading documentation would have made John Carmack a bad programmer? Is this a case where not reading documentation made John Carmack a better programmer? I don't think I need to answer those questions.
As for intellisense, it's important to realize that intellisense is a productivity tool, designed to save your time. You type "." or "->" and up pops a list of members, you type the first few characters of the one you want, and hey-presto! That's your precious time it's saved, it may have also saved you breaking a build owing to that supid typo you made because you hadn't had your coffee yet, and you've now got more time to get on with doing productive stuff instead of just grinding out code.
Intellisense is not designed as a crutch for bad programmers, it's an example of what Fred Brooks calls a "Sharp Tool".
By the same logic that one may dismiss intellisense, one comes to the obvious end conclusion that any tool designed to increase programmer productivity is also something that may make one a bad programmer. That's a dangerous line of thinking because next thing you'll be rejecting compilers and debuggers.
When I was back in college last century, one of my lecturers told us that "the best programmers are lazy". That's very tongue-in-cheek, and what he meant was that the best programmers find ways to maximize their productive time and minimize time spent doing donkey work. I still think that's good advice today.
Is a programmer required to learn and memorize all syntax, or is it ok to keep handy some documentation?
No and yes. Programmers who can't learn new things from documentation are crippled. They can't solve new problems. All they can do is cut-and-paste code that someone else has written. I prefer programmers who read documentation, because they know enough not to reinvent existing library functions. In hiring, I rarely care if the candidate has any experience with our current implementation language. We may start using a new language any day now, so I want people who are happy to work in multiple languages.
Would it affect the way that managers look at coders?
No, except for a subset of measure zero.
No way; on the contrary, it makes you a way better programmer since they are productivity tools, and programmers using them makes a program faster/better. The purpose of the programmer is to make a program not to know how a library or framework has some methods or classes called.
A programmer doesn't necessarily need to know the syntax of a language; but in someway it obliged to know it since the modern IDE immediately alerts him/her if something is wrong, so s/he will definitely learn it just to stop the IDE prompting error messages. I really cannot imagine anyone programming with red underlines under some words, before solving the issue. Regarding the utility of a library s/he should know only that a library can perform a certain functionality and eventually s/he will find a way to use it.
I can say that code completion really helps a programmer to find new functionality of a given library. Any good library is based on abstraction - interfaces. Suppose we have an interface Sort that is supposed to perform some logic of sorting; now this logic can be performed in some various ways but I as a programmer don't know what the given library can really do with it. So I type Sort sort = Ctrl+Space and immediately all the possible implementations appear (I have really discovered new things about many libraries in this way). Among the implementations QuickSort appears, but I don't really know so much about it so (in my IDE - Intellij) I press Ctrl+Q and I immediately see the documentation of the class, and I see how it can be used. Things go further as I might be interested how QuickSort is implemented so I press Ctrl+B and choose to download the implementation from Maven repository and I immediately see implementation code.
