Surrender, Just a Little
-
Comments posted to this topic are about the item Surrender, Just a Little
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
Man! You are so right! This is going to be totally liberating for me!
To commemorate my new found joyous method for doing my job without being a bottleneck, I've designed a special Black T-Shirt (everyone in IT wears Black shirts, right?). Here it is. Enjoy! 😀
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - Jeff Moden wrote:
Man! You are so right! This is going to be totally liberating for me!
To commemorate my new found joyous method for doing my job without being a bottleneck, I've designed a special Black T-Shirt (everyone in IT wears Black shirts, right?). Here it is. Enjoy! 😀
Hell Yeah.
Can I also have one of those ???
-
If you try and control everything not only do you become the bottleneck you limit the lessons that others learn.
It's not for everyone but I find being an approachable mentor is the most effective approach. They experiment, they make mistakes, they learn and you are there so none of the mistakes are fatal.
If you are approachable they share willingly, proactively,more and early enough for you to suggest alternative approaches. Teach once learn twice.
If you start with the approach of ranting about the latest syphilitic turd that has been curled off in production and the level of incompetence demonstrated then they won't talk to you. You will always be on the back foot discovering stuff too late to correct it and having to say NO a lot more thus being seen as more of a blocker.
An awful lot in life depends on reputation and bluff. The worst that can happen is that a reputable BS artist convinces the powers that be that RDBMS are a dying breed and that only massive rollout and migration to (insert desirable CV fodder here) will future proof the company. If that happens you'll be trapped on an eternal integration nightmare that captain BS didn't consider
-
I agree, David. In fact, IIRC, I believe it was you I quoted about being an Exceptional DBA. Something like "When it comes to database problems, if you are the first person they seek out rather than the last, you might be an Exceptional DBA".
And, I practice being a good and understanding mentor every day.
I also wouldn't be a good mentor if I didn't give someone the "opportunity to fail" (which must not be confused with setting someone up to fail). There are two ways for someone to learn very well on their own... to try but fail and to try but succeed. Be there to help if they fail and be there to applaud when they succeed.
But, sometimes, someone has to say "No and the reasons why". It's not being a bottleneck to do so. In most cases, you're trying to keep people from walking on broken glass barefoot. You can try to sweep up the broken glass when you see it's important that they have to walk there. You can even help them don protective footware to be sure. But, sometimes the broken glass is knee-deep and cemented in place and still they cannot see the danger and you just have to say "No".
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
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.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning - 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.
pick your battles - my old sysadmin had a phrase - "keep your powder dry".. meaning if it's not worth the fight then wait... no one likes a DBA that grumbles at everything. to quote grant's recent article , we become seen as "cantankerous"
I have developers that I know will do stupid things, but I still force a smile before I answer their call and say "how can I help buddy?" rather than "your code is <insert any word you like here>"
MVDBA
-
Grant,
This has been on my mind for a while. I *am* a bottleneck. Things would get done faster if I loosened up the reins. When I realised a couple of days ago that there's a thing that needs to be done, but there's no rush for it, it's a perfect opportunity for me to train it out. I've arranged for my team to work with me on it, while I document the steps, and then they can go through the same process in a test system to be sure they understand it. It's a win-win-win -- for me, for my company, and for my team.
ConnieOI
-
"Never give up! Never surrender!" ~ Commander Jason Nesmith
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses -
I love this!
- Connie wrote:
Grant,
This has been on my mind for a while. I *am* a bottleneck. Things would get done faster if I loosened up the reins. When I realised a couple of days ago that there's a thing that needs to be done, but there's no rush for it, it's a perfect opportunity for me to train it out. I've arranged for my team to work with me on it, while I document the steps, and then they can go through the same process in a test system to be sure they understand it. It's a win-win-win -- for me, for my company, and for my team.
ConnieOI
NICE!
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
I am not at all surprised to find a DBA love-fest going on in here. As usual, The Universe Will Be Saved From Stupidity If You Idiots Will Just Shut Up And Do As I Say.
I am convinced that this is a personality type issue. Really good DBAs almost always have this very annoying attitude. Members of the development team--something very different from that.
Since it is ubiquitous, I have learned to overlook it and just roll with it. Doing so helps me get my change requests approved faster. I know who really owns the data: it is the client, not you, my DBA friends, whom I love dearly.
- GeorgeCopeland wrote:
I am not at all surprised to find a DBA love-fest going on in here. As usual, The Universe Will Be Saved From Stupidity If You Idiots Will Just Shut Up And Do As I Say.
I am convinced that this is a personality type issue. Really good DBAs almost always have this very annoying attitude. Members of the development team--something very different from that.
Since it is ubiquitous, I have learned to overlook it and just roll with it. Doing so helps me get my change requests approved faster. I know who really owns the data: it is the client, not you, my DBA friends, whom I love dearly.
I just heard that from my project manager in a meeting - are you spying on me 🙂
MVDBA
- 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".
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
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.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) - Jeff Moden wrote:
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 .
DOUBLE FACE PALM AND A MASSIVE WTF
I could teach my dog set based logic.... and oracle also kinda relies on the same set based understanding
MVDBA
Viewing 15 posts - 1 through 15 (of 40 total)
You must be logged in to reply to this topic. Login to reply