As with any technique for dealing with opponents (whether in communication or karate), one needs to use good judgment. No technique is good for all situations, and may need modification, as with changing the tone of voice and speaking more slowly.
Practice and experience and patience are key, grasshopper.
jpowers (aka NotquiteXena)
I've been having a lot of fun with the "weapons parody"... might as well continue with that...
I almost never raise my voice to or use sarcasm on users, the developers I work with/mentor, the DBA's, or even my managers. The proverbial "bat" that I keep talking about always works and it's always the right thing to do to help folks... the "bat" is usually in the form of a million row test table and demonstrable code comparisons and performance tests which, of course, include scalability tests. Even disk and memory configurations can be tested in such a manner. One can argue until they're blue in the face but "a person forced against their will, is of the same opinion still". The only way to get someone to change their opinion is with clear and absolute proof... if you can't provide such proof, then there's no sense in arguing. Even ego-maniacs respond correctly to such proof.
My boss (who is NOT an ego maniac :D) wanted to import 1.2 million rows of data on a daily basis for a project. I told him, as I've suggested to him at least a dozen times, that BULK INSERT with a BCP format file would be the best way to go. He said "Dangit, Jeff... I'm tired of hearing about BCP and BULK INSERT! We're using Java to do the import and that's my final word!" Heh... he was under a bit of pressure. Anyway, I said "ok" and walked away and wrote the BULK INSERT and the format file. I gave the Java developer time to build his code and put it into production. As Java code goes, the developer did a brilliant job (which my boss was quick to rub in my face a bit). I took my code over to the developer, who I knew had a bit of intellectual curiosity, and demo'd it to him... his took 16 minutes and did no verification of content... mine did verify content and it only took 51 seconds. Needless to say, he was amazed and said "I'll be right back." I went out for a smoke break. Just as I was done, my boss (who also smoked) came out and said "Jeff, I'm sorry... showed me what your code did and you were right on with the BULK INSERT. I'll never question you again." "Heh...", I said, "You should always question me... you should always ask me if there's a better way even if it's not about data" and to this day, he does.
Demonstrable code, soft words, and a bit of patience... that's the kind of "bat" I'm talking about. It hasn't failed me yet. It even works on people I don't know so well provided that your not arrogant about it. Arrogance will make the "bat" slip out of your hands because people will go out of their way to NOT use your methods if you are arrogant.
Flipping things around, someone says they want to do something and you know it will harm the data. Now, what do you do? Soft yet firm "No... that will harm the data in the following manner" followed by an explanation. Sure, you'll run into the "I'm your manager and I said do it" in which case you break out the other "bat"... "I can't... it would break the data and you and I would both be fired for it. I know you're in a hurry but let's work on this together so we can both keep our jobs."
Every once in a while, you'll run into some blatherskites like what Loner used to work for that will insist that the change be made or you'll be fired. Michigan is an Oracle and DB2 state with very few decent SQL Server jobs available. I would hate to be fired for such a thing and if running it up the chain of command doesn't work, then I still don't mind getting fired... I have a reputation to protect and will do so even if it means getting fired. Yeah, I know... lot's of folks aren't in a position to dig in that hard, but at least take it to the edge. Here's the 3 rules I operate by...
[font="Arial Black"]Jeff Moden's Three Rules of DBA's.[/font]
1. A DBA may not injure data or performance of the data or, through inaction, allow data or performance of the data to come to harm.
2. A DBA must obey orders given to it by "Users", except where such orders would conflict with the First Law.
3. A DBA must protect "Users" existence as long as such protection does not conflict with the First Law.
(Defininition of "Users" is anyone including but not limited to Developers, Designers, Data Modelers, Dev Managers, Project Managers, Customers, other DBA's, Ops personnel, one's immediate supervisor, or anyone else who, by command, code, design, setting, or device, may impart changes to the schema, the data, or the server).
Part of protecting the "Users existence" is keeping them from doing something that violates the first law especially where it could cost them their job... 🙂 When they finally realize that you're on their side and that you're not just butting heads, life in the shop becomes almost conflict free.