I've been telling students and others that "reading the manual is the shortcut" for years. I really believe it. When a program isn't working out the way one expects re-visiting the manual is often a great short cut. Sometimes the manual in question is really the documentation for the project or the program. Often the manual in question is the language manual for the programming language being used or the documentation for the class/function libraries that are being used.
Often times there are functions/methods/classes that have already been created that can be used. Lots of shortcuts can be found that way. Manuals, in today's world the word manual often means online documentation of course, can also be a great way to understand error message as well.
No one knows it all. Manuals, online or old-fashioned paper books, can be a great source of information. I have a whole bookcase of programming books and I refer to them often. Real life is an open book test and knowing how and when to use books can be a huge advantage in life.
[Note: I am away on vacation this week so I decided to finish up this series and have these posts show up while I am away.]
This is the twenty-fourth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
What a load of crap. This proverb is true for students and beginners. Anyone really pushing the curve will run into problems with the manuals, because edge cases are barely, if at all, covered in manuals...
Well I have to disagree. By manuals I include things like a complete language definition/specification. You'd be surprised how often people pushing the edge make incorrect assumptions about how a language handles specific things. People who are pushing the curve may require additional or more specialized documentation but the experts know how to make the most from those books.