MSDN Documentation...
-
code-frog wrote:
Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL?
For T-SQL you'd be better off using BOL rather than MSDN.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
I agree. My question is so simple though that I had pretty high hopes they'd cover it right off the top.
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
-
Documentation for documentation. BRILLIANT!:suss::-D Thank you for posting that. I'm off to see if WIKI stands up any better.:jig: But I'll :badger: if it doesn't.;P
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Think it depends on which team writes it. The sample code in the .NET crypto section at MSDN is unprofessional, but the rest of it is pretty damn well written. On the other hand the ODBC stuff on MSDN I read in the past was totally whacked.
-
Think it depends on which team writes it. The sample code in the .NET crypto section at MSDN is unprofessional, but the rest of it is pretty damn well written. On the other hand the ODBC stuff on MSDN I read in the past was totally whacked.
By the way, are the article ratings out there any helpful?
Abhishek It is impossible to change your past. But it is very possible to ruin your present by worring about the future. -Chankya
-
By the way, are the article ratings out there any helpful?
Abhishek It is impossible to change your past. But it is very possible to ruin your present by worring about the future. -Chankya
There's an interesting pattern to it... The top-page article ratings are usually total crap. Most people rate 1 or 8 or 9. The more technical an article gets, the more level-headed the ratings are. The averages are usually around 7 or 8. Simple explanation: most of the clueless people are hitting 1 or 9; the people who actually know what they're talking about vote more fairly. Sort of a trend around all things Microsoft, I think.
-
I agree. My question is so simple though that I had pretty high hopes they'd cover it right off the top.
code-frog wrote:
My question is so simple though that I had pretty high hopes they'd cover it right off the top.
You could always send the MSDN team a cake. :laugh:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
code-frog wrote:
My question is so simple though that I had pretty high hopes they'd cover it right off the top.
You could always send the MSDN team a cake. :laugh:
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
A black one or should I say monochrome?:rolleyes:
-
A black one or should I say monochrome?:rolleyes:
code-frog wrote:
A black one or should I say monochrome?
How about a crawfish flavored cake? :omg::-D
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
code-frog wrote:
Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL?
For T-SQL you'd be better off using BOL rather than MSDN.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
code-frog wrote:
Am I the only one
You are not alone....
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
-
Think it depends on which team writes it. The sample code in the .NET crypto section at MSDN is unprofessional, but the rest of it is pretty damn well written. On the other hand the ODBC stuff on MSDN I read in the past was totally whacked.
reinux wrote:
The sample code in the .NET crypto section at MSDN is unprofessional, but the rest of it is pretty damn well written.
Absolutely, the crypto section is pretty poor.
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
At our place we have a fairly restrictive web proxy, which means most of the useful sites out there are utterly inaccessible. For some stuff I more or less have to use MSDN, and I hate it with fiery passion. I'm used to being able to google something inexplicable and have the resources of the entire web at my fingertips. Having to know in advance which site a given solution is going to be found on, so I can get it added to the proxy, means I very rarely get the same sort of efficiency when I search for information at work compared with at home. There is so much information out there that is so much better than what's available on MSDN that as soon as it's no longer available to you, you suddenly realise just how completely useless MSDN is most of the time. Yes, it's technically correct, but it's extremely dry for the most part and completely unhelpful at least 50% of the time. Thank god I managed to get codeproject added to the proxy. With the release of MSDN2 it's become even worse. I still work with .NET 1.1, and getting information out of MSDN that's actually relevant to what I'm doing has become like getting blood out of a stone.
-
At our place we have a fairly restrictive web proxy, which means most of the useful sites out there are utterly inaccessible. For some stuff I more or less have to use MSDN, and I hate it with fiery passion. I'm used to being able to google something inexplicable and have the resources of the entire web at my fingertips. Having to know in advance which site a given solution is going to be found on, so I can get it added to the proxy, means I very rarely get the same sort of efficiency when I search for information at work compared with at home. There is so much information out there that is so much better than what's available on MSDN that as soon as it's no longer available to you, you suddenly realise just how completely useless MSDN is most of the time. Yes, it's technically correct, but it's extremely dry for the most part and completely unhelpful at least 50% of the time. Thank god I managed to get codeproject added to the proxy. With the release of MSDN2 it's become even worse. I still work with .NET 1.1, and getting information out of MSDN that's actually relevant to what I'm doing has become like getting blood out of a stone.
I too find it easier and more helpful to simply surf for answers to most of my (relatively simple) questions. With that said, could I reclaim the disk space by removing MSDN from my computer or will that mess up VS 2003? Thanks, Larry
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Hi, Glad to notice someone else thinks the same.. I was a delphi programmer and now programming in C#, MS VS is good stuff but the help is nothing compared to the borland helpfiles... like said, for some reason you always get the wrong information. Otherwise the intellisense (code completion) is already a great help and ofcours codeproject is offering a lot of good stuff. Greetz Kurt
-
I too find it easier and more helpful to simply surf for answers to most of my (relatively simple) questions. With that said, could I reclaim the disk space by removing MSDN from my computer or will that mess up VS 2003? Thanks, Larry
I did remove MDSN from my machine. I too find it, most all the time, useless. They may cover all the pieces but not from the point of view I'm coming from. I want to answer a question and they want to write documentation. They are writing a reference manual not sure of what questions people will be asking. A Google search of microsoft.public news groups or the web in general will usually find you the answer right away. Often you could click "I'm Feeling Lucky".
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
The worst MSDN pages are those that just have the method, paramter(s) and return type. It so looks like auto generated code documentation. Nothing more then what intellisense gives you. It would be good if they code link to a relevent code sample. I have found that sometimes a code sample exists but in an obscure place. Maybe there could be a way to automate adding more useful links. Like say text matching and then using rating on relevence of links. Or maybe using some kind of if you found this interesting you may also want to see what other people visited next (like Amazon).
-
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
Yes, err, I mean, no. Again, No. To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line To be roughly correct while still maintaining a positive bottom line
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify! || Fold With Us! || sighist -
Am I the only one that looks at some of the MSDN documentation and admits that yes it is correct and yes it does provide relevant information (that has nothing really to do with my question) but aside from that it's entirely unhelpful?:sigh: Sometimes it's the only source that is right (rare, almost endagered) most of the time it's relevant but useless (so common you have to wonder if they do it on purpose). Am I the only one? If not why do they do this? Why waste money telling me some of the most dry background information there is on a bit in transact SQL while telling me nothing about using bits in transact SQL? Why? Why? Why?:^) I think I'm going to fold up shop and start selling watches from door-to-door. It's gotta be easier...:rolleyes:
When reading MSDN doco the question I most frequently ask myself is (especially in respect of examples) - "Now why would I want to do that!". And it's predictably postmodern in its presentation, too much focus on what (form) and not enough on why (substance). But it sure beats dragging half a dozen CICS manuals out of the the bookshelf, only to find you dont have the one you need, and it'll take six weeks to get it!. PhilD