Grant Fritchey wrote:
I would like to defend myself, just a little. I didn't say surrender completely. I said, surrender, just a little. A lot of our peers see our rants about idiot <insert IT staff member here> and their dumb ideas and think that we don't allow others to do things. They have to know how to pick their battles and find the right hills to die on. Naming standards? As long as it's not objectively stupid (see DDLTBL as an example, and no, no one ever figures it out right), whatever. Backups? There I'm less likely to surrender.
No defense necessary, my long time and very trusted friend. I'm right there with you in all aspects especially the unspoken idea of carefully listening to what people have to say and the well stated trait of being an enabler rather than a road block. I follow the idea behind the quote that I got from David Poole so many years ago that I cited above. I also strongly subscribe to another quote from Sergiy (a long time denizen of these forums) which is "A Developer must not guess... a Developer must KNOW". I regularly practice the David Poole quote to help Developers, Peers, Managers of all types and, most importantly, myself realize the incredibly important quote by Sergiy.
I thoroughly support the concept that innovation is born of experimentation. It's important to growth to regularly ask the question "What If?" and then trying to answer it or prove it wrong while having no personal agenda behind any of it. If it's not good for the company, it shouldn't be done at the company, period. The lessons learned are always valuable no matter the outcome.
That's also why I give the Developers sys_admin privs on the Development boxes with very few rules to follow (Don't do backups, restores, database Creation/Deletion, GRANTs, Job Creation/Deletion, or SQLCLR without checking with me first.). I also treat the Dev boxes as if they were production so I can do a PIT restore when the inevitable mistake is made and do so without threat of punishment but with the request to be attentive and careful.
I also protect the Developers. If I see them losing a battle to someone that wants them to do something truly stupid, I will step in to provide or help them negotiate possibilities/alternatives or help them explain why the answer must be "No" depending, of course, on the situation.
I also consider the fact that it's not my job to lead the Developers. No... Rather, it's my job to enable the Developers to BE leaders.
Getting back to my T-shirt design, I'm actually proud to say that it applies to none of the Developers that I have to work with (I am truly fortunate). They truly "get it" when it comes to databases and T-SQL and SQL Server and take great pride in quickly solving the impossible and building nasty fast code.
Management is sometimes a bit of a different story. 😀 In a previous company, I once had a C-Level manager tell me that we were migrating to Oracle because we didn't have any Developers that understood set-based logic (they were never given the opportunity to learn) even after I explained the hidden costs and the incredible lost learning involved to do so on top of the initial and recurring costs of ownership. Basically, it was a migration disaster and they continue to pay out the nose to this day because they didn't take all of the steps necessary. SQL is SQL, right? Databases are just a place to store data, right? NOT!
I've also seen management throw hundreds of thousands of dollars (millions in a couple of cases) at purchased solutions that never stood a chance of working the way the wanted. It's sometimes almost as if they've adopted the mantra of keeping up with the Joneses even though that shiny new vehicle has a non-gimbled coffee cup holder mounter to the center of their steering wheel and only has brakes on the two wheels of the right side of the vehicle. I've also literally seen 3 people die because of bad decisions that I warned them about. I predicted layoffs to the month when they would happen two years in advance if they continued their plan and identified a different plan. I took it all the way to the GM and was summarily dismissed because I didn't have a degree and I wasn't a CPA. The company I was working for was basically the "only show in town" for a huge number of people. They laid off about half a compliment of 3,000 people, many of which could no longer afford medication for themselves or a family member and 3 people died as a direct result.
If you think no one will die because of your actions or inactions, I'm here to tell you you can be seriously wrong about that.
So yes, there are compromises to be had and made everyday. But, sometimes you have to drop the "I'm a people person" attitude and stand your ground. You also have to have the proof to do so (A DBA must not guess... a DBA must KNOW!). Remember that being a valued member of a team will sometimes mean that you sometimes have to say "No... wait... let me think about that for a second... HELL NO and here's why again"!
And, for sure, I get a little tired of people saying that DBAs are the ones that must occasionally surrender without making the same suggestions to management and developers. It's a team effort and people should not have an ego about such things. Do what's right for the company and realize that you're not always right and that the latest and greatest "too cool for school" method, application, or tool can have great hidden costs and frequently turns out to be the wrong solution. Remember that "If you want it real bad, that's usually the way you'll get it".
is pronounced "ree-bar
" and is a "Modenism
" for R
ow.First step towards the paradigm shift of writing Set Based code:________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
Helpful Links:How to post code problemsHow to Post Performance ProblemsCreate a Tally Function (fnTally)