September 24, 2009 at 9:05 pm
Comments posted to this topic are about the item Check Yourself
September 25, 2009 at 6:38 am
As a developer, anytime I find code, I never - NEVER just copy and paste. I look it through for A) does it do what I want? and B) Do I understand everything it says/does? If not....back to research. I also always reference the original author and/or the site I get it from not only for my reference but for anybody else who happens to also come along behind me so that they can better understand what it is.
Great editorial btw, I see this everyday on the forums where I like to help others myself. So often these....developers/administrators/etc just want code to do what they want, not that they want to understand it, break it down and learn from it. I cannot tell you the headaches I have had to sort out because people just copy and paste with no apparent logic or reason. It is difficult enough to decipher one persons code let alone several in one shot!! 😛
Thanks and happy coding!!
dminder
September 25, 2009 at 6:50 am
Flat out, it depends. I get something from Jeff, Gail, Lynn, the usual suspects, I will review it and test it, but I'll generally assume it's right. I get something from other sources, I'll try to vet it, get second opinions, do a bit more research, and then review it and test it. I don't think I've ever simply copied & pasted code from online to my production system, ever.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
September 25, 2009 at 7:02 am
I always review code I get from AnyWhere - co-workers included - to make sure I understand it before I start working with it. And it always goes on a test system first, with comments about where it came from. If it's pretty simple (SELECT xxx, yyy from zzzz) I won't spend a lot of time researching it, but anything complex or esoteric or unclear definitely gets researched and cross-checked to the best of my ability. Which sometimes means running it by co-workers with better SQL skills than mine. If we can't understand it, it doesn't go anywhere other than Notepad.
Steph Brown
September 25, 2009 at 7:12 am
This is a great reminder about not only understanding what you are about to do with the advice, but learning from it as well.
Working in a support environment, we often are looking for that quick fix to a customers problem and more often than not, just go with the advice or suggestion.
It goes back to the old adage, you are only as good as your last backup. Just throwing code or a solution at something without doing your own testing first is always
a bad idea!
September 25, 2009 at 7:43 am
As a developer/DBA I will admit I don't usually vet the responses I use. I use other people's posted replies quite frequently (today I looked for one to solve my "Transaction context in use by another session" problem without luck) and, though I always test the solution on my local/test database, and only use it if I understand it, I almost never vet it because:
(a) It was due to be done yesterday
(b) If it breaks in 2 years time it'll be me that fixes it again.
September 25, 2009 at 7:54 am
What is this "research" of which you speak?
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
September 25, 2009 at 7:56 am
I'm basically with Grant on this one. If I know the source and I know that they are conscientious about testing I'll usually use it, although even then I usually run it against a test/dev system first to make sure I understand it.
I can't find the post now, but Buck Woody had a blog post about being sure to understand and test any scripts/code you get online before using it in production. If/when I find it I'll post it.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
September 25, 2009 at 8:14 am
Very Good Article: What I see a lot, are replies that do not provide the best answer. I understand that people often provide a solution without looking at other possible solutions. I often told my developers, especially junior, to check your solution by attempting another solution.
With that being said, at least check the solution, or at a minimum think about it.
Curtis Smith
SQL Server DBA
Well in worked in Theory ...
September 25, 2009 at 9:11 am
I always test as much as I can before putting on a production server, even if I know the source. Everyone is human even the best, they can all make mistakes. That way if anything goes wrong I blame myself for not testing hard enough, rather than the person who supplied the solution.
There are always times we need to do things quickly. But we must weigh up the risk versus gain in this case, and make it our own call.
I am reminded of the following quote:
Eric Cantona "By all means take advice form other people. But remain true to yourself. "
September 25, 2009 at 10:05 am
You always have to test info you get from online assistance because 1) they may not have really understood your problem 2) you may not have correctly explained your problem 3) you may not have really understood the answer.
Unless you test you are just throwing darts and hoping for the best.
You don't get what you EXpect, you get what you INspect. That applies to almost everything in life (especially contractors doing work on your house).
September 25, 2009 at 10:10 am
Jack Corbett (9/25/2009)
I'm basically with Grant on this one. If I know the source and I know that they are conscientious about testing I'll usually use it, although even then I usually run it against a test/dev system first to make sure I understand it.
So then you are saying the same as me and I say "I'm with Stephanie". Regan was famous for quoting and old Russian proverb which goes "Trust, but verify".
OK. The cut and paste worked fine on my tiny laptop instance. How does that scale to my test box with half a million rows? Does it choke on a production box with 4 million rows? Now that the queries come back in rapid order do my inserts and updates now time out?
Unless it was handed to you on stone tablets from the mountain top with fire, smoke, and earthquakes you have to check it. Even then.
Even this. Check everything.
ATBCharles Kincaid
September 25, 2009 at 1:37 pm
I think Charles said it the best here... "Trust, but verify". If you trust the source (like Grant mentioned), then the verify process can be abbreviated. And if you don't understand the code, it should never be used until you do.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
September 25, 2009 at 1:38 pm
Typically, my questions are about how to get Reporting Services to do what I want, so it's never a "cut and paste" solution. I try to glean the concept from the answer and apply it to my situation.
If I'm getting code from the internet somewhere, I will pull it into query analyzer and test it to make sure it does what I want it to do. (I'm almost always doing Select only.)
I really appreciate the help I get here.
September 27, 2009 at 10:21 am
HI Jones
This is good practice if time permits. But one should post the results if they turned out to be wrong.
This helps others to see how much percentage of solutions ae turning out to be wrong.
good suggestion i beleive
Srinivas
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply