Calling Out Bad Advice

Question

Calling Out Bad Advice

Tim Mitchell

SSCoach

Points: 15681
More actions
December 21, 2010 at 9:23 pm

#144033

Comments posted to this topic are about the item Calling Out Bad Advice
Tim Mitchell, Microsoft Data Platform MVP
Data Warehouse and ETL Consultant
TimMitchell.net | @Tim_Mitchell | Tyleris.com
ETL Best Practices

Viewing 15 posts - 1 through 15 (of 31 total)

You must be logged in to reply to this topic. Login to reply

Elliott Whitlow SSC Guru Points: 102402 More actions · Answer 1

I tend to like to use the "I believe you are mistaken" route, and here is a URL clearing it up?

I also have to agree that every post and every article and every blog post puts your skills on display. I know that for me there was a certain level of angst when I first submitted my articles for publication here.

I've been doing this for a long time and many things are not right vs. wrong but style. But I too have seen outright wrong advice and it needs to be combatted.

CEWI

TravisDBA SSCoach Points: 15780 More actions · Answer 2

No one ever gets it 100% right every single time they post on on a forum to my knowledage anyway. That is why we call them FORUMS. They are a meeting place for debate and discussion. They don't claim to be factual sources like encyclopedias, MSDN, or BOL (and even those have known to be wrong in the past as well). Most people here can put up with the occasional error you might see on a forum post (or even an article or BLOG) versus the overwhelming accurate and very helpful information these forums and this site do provide. It's not that big of deal in the big picture IMHO. 😀

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

lenne_dk SSC Journeyman Points: 92 More actions · Answer 3

Most true professionals due a good job of self-screening,

Not here, it seems 🙂

A correction is due, if you do not mind...

Nakul Vachhrajani SSChampion Points: 10294 More actions · Answer 4

I would say giving feedback on an write-up is more like doing a peer-review. When we review code, we try to not use words like "you" or "me" or even the name of the developer. We always say and write "the code...". This is a conscious effort on the part of the reviewer and does help a lot in keeping personal/emotional effects at bay.

Here's what can be done:

There can be a feedback center (or a small checkbox at the bottom of the editor, near the "save/post" buttons) where users can directly reference the particular article or piece of information that one finds to be incorrect and add their comments. A discreet Email can be sent out to the originator of the article, who can then take the corrective action while a visual indicator set on the piece indicates pending changes to all new visitors.

No names disclosed, no emotional angle attached and hence, no harm done.

At all costs, everyone who reads a write-up should keep in mind that the poster has spent some time and energy to research and share something with the world. That is worth appreciating, and some minor errors (unless technically incorrect) should be ignored.

Thanks & Regards,
Nakul Vachhrajani.
http://nakulvachhrajani.com

Follow me on
Twitter: @sqltwins

Paul Randal One Orange Chip Points: 29544 More actions · Answer 5

The vast majority of the time I try to be very supportive when giving constructive criticism, but sometimes if the person *repeatedly* posts incorrect things, a harsh wake-up call is warranted IMHO. I did just that a week or so ago on Twitter (maybe the incident to which you're referring Tim?) because the advice was so blatantly misleading from such a widely read blog - it would have had many DBAs struggling to figure out why their system wasn't exhibiting the behavior specified. That's incredibly unhelpful and damaging and needed to be put right immediately, especially as the blog post in question had just been widely RT'd around the community.

I've seen the same thing happen on the MSDN forums with people that constantly reply with dubious or downright misleading information, and I've seen SQL Server Magazine publish un-reviewed articles that speak of regularly shrinking databases - which provoked a wide backlash and a retraction.

Sometimes it can be difficult to figure out what method to take when correcting bad advice, as you especially have to be 100% certain that what you're correcting is, in fact, bad advice.

But good editorial!

Paul Randal
CEO, SQLskills.com: Check out SQLskills online training!
Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

dma-669038 SSCrazy Points: 2773 More actions · Answer 6

In many cases I have seen misleading blog posts or replies have their origins in some paper or information published by MS itself and not cleared up later. I have myself had two issues with MS on widely accepted problem issues - the problem with GUIDs and fragmentation, and the problem with # of tempdb files being equal to the # of cores. Granted i didnt speak to someone at the top at MS, mostly the CSS engineers and our TAM, but they were not able to give me a MS link that agreed to these two issues as often explained by well known authorities such as Kim and Paul. (Perhaps there is one now, this was a year or so ago).Where i work for example the management is not very well educated on who is an authority on SQL and who is not outside of MS, they go largely by the book. MS needs to update and correct documentation on a much more frequent basis, and perhaps remove what has been proven outdated.

On how the correction should be made, yes I think Paul is right, people can and should be called out when they have a wide audience and post misleading info. But perhaps writing to them personally would be better than doing so in public. Just my 2 cents.

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 7

One of my favorite topics, and a very difficult one at that. I personally handle things differently depending on the who/what/where of the content. Inaccuracies on the forums is one thing, and people are a bit more likely to read through the majority of comments on a forums post before deciding to follow advice. An article or newsletter from a major publishing site like SQL Server Central, or the competetors that is blatently wrong; Game On, because the editors should have done a better job before publishing incorrect content.

Experience shows that fewer people read the comments on Articles than forums, especially when they have to click a Join the Discussion button to find the comments. Some really bad articles have pages of comments correcting wrong information, and the authors never fixed the article, which is possible to do, I've made changes to my own Articles on here when information changed with Service Packs, or through further understanding. Expecting that the Discussion forums for an Article will police your bad content is wrong thinking, and that's not targeted at SSC, but the community at large because it happens all over.

OCTom SSChampion Points: 11785 More actions · Answer 8

My 2 cents worth:

When correcting/criticising someone:

1. Don't make it personal.

2. Make it about the code and/or advice.

3. Use positive instead of negative terms.

4. Give an alternative and explain why it's better.

When being corrected/criticised:

1. Don't take it personally.

2. Remember it's about the code and/or advice.

3. If you are wrong, accept the criticism/correction gracefully.

4. If you are not wrong, use the first four steps above to correct the corrector.

And, for both, remember there are many ways to accomplish a task or solve a problem. Your way may be just one of many and it may not work in all installations.

Tim Mitchell SSCoach Points: 15681 More actions · Answer 9

lenne_dk (12/22/2010)
Most true professionals due a good job of self-screening,
Not here, it seems 🙂
A correction is due, if you do not mind...

Indeed, sir! Thanks for pointing this out, I missed it during the edit.

Tim Mitchell, Microsoft Data Platform MVP
Data Warehouse and ETL Consultant
TimMitchell.net | @Tim_Mitchell | Tyleris.com
ETL Best Practices

Tim Mitchell SSCoach Points: 15681 More actions · Answer 10

I did just that a week or so ago on Twitter (maybe the incident to which you're referring Tim?) because the advice was so blatantly misleading from such a widely read blog - it would have had many DBAs struggling to figure out why their system wasn't exhibiting the behavior specified.

Paul, this editorial was written a few months ago, so any similarities to recent events is purely coincidental 🙂

But you're right - the same method doesn't work for everybody. Nobody wants to hear that their baby is ugly, but some people respond to it better than others. It's a fine line to walk, knowing how to gently correct without alienating a well-intentioned writer.

Tim Mitchell, Microsoft Data Platform MVP
Data Warehouse and ETL Consultant
TimMitchell.net | @Tim_Mitchell | Tyleris.com
ETL Best Practices

timothypepin SSC Veteran Points: 249 More actions · Answer 11

lenne_dk (12/22/2010)
Most true professionals due a good job of self-screening,
Not here, it seems 🙂
A correction is due, if you do not mind...

I got a good chuckle out of it myself. I found it especially ironic on that particular sentence.

john.arnott SSChampion Points: 11882 More actions · Answer 12

OCTom (12/22/2010)
My 2 cents worth:
When correcting/criticising someone:
1. Don't make it personal.
2. Make it about the code and/or advice.
3. Use positive instead of negative terms.
4. Give an alternative and explain why it's better.
When being corrected/criticised:
1. Don't take it personally.
2. Remember it's about the code and/or advice.
3. If you are wrong, accept the criticism/correction gracefully.
4. If you are not wrong, use the first four steps above to correct the corrector.
And, for both, remember there are many ways to accomplish a task or solve a problem. Your way may be just one of many and it may not work in all installations.

Excellent advice ( 🙂 ).

One way to keep the conversation about what was written is to request clarification. It's usually much better received to say something like "I don't quite understand how this works....", rather than "This doesn't work."

Alan Vogan SSCrazy Points: 2513 More actions · Answer 13

I'm a reader of all this wonderful advice this community puts out. I always make sure that I've read several articles on whatever topic I'm researching, just to double/triple check that there is general consensus. When I see ego's clash or fighting over a topic, I tend to move on to the next website where more rational discourse is taking place.

Just remember what Tom said above. And what your Mama taught you. Be nice. Play nice. If you don't have anything good to say, then keep your mouth shut.

And for those of you who remember, it's now time to sing the Grandmother Song by Steve Martin. 1,2,3... Be courteous kind and forgiving... :hehe:

GSquared SSC Guru Points: 260824 More actions · Answer 14

I have to say that my response to bad advice depends on where it is, what it is, what it's about, the tone it's delivered in, and the history of the person writing it.

If, for example, I see a minor error in a piece of complex code, in reply to a poorly written request for help, I'll just suggest a correction and nothing more.

On the other hand, if I see something posted that could result in serious data loss, posted in an authoritative manner, without clarification that it will result in data loss (I see this pretty regularly), I'll jump on it a little more harshly. Since that's the kind of thing that can result in losses for companies and job-loss for the DBA affected, I treat it a little more seriously.

When corrected myself (happens more often than I like), I take my error personally, but not the correction. If I posted something that will cause a problem for someone else, that's serious to me, even if it isn't to anyone else. That's certainly not a flaw in the person correcting me.

- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon