Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345»»»

Hiring Guitarists Expand / Collapse
Author
Message
Posted Friday, July 12, 2013 1:58 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
Points: 22, Visits: 64
jfogel (7/12/2013)
Vila Restal (7/12/2013)


And I maintain my point: A DBA needs to be reliable but behind the scenes. The customer (the audience) shouldn't know they're there because the only time they do is when support is explaining to the customer why they've lost all their data ( because the numpty DBA deleted it all).


Yes, because it is ALWAYS the DBA who screws up? I don't know what to make of the above and I hope I'm simply not reading it right.


Indeed you're not reading it write if you think that's what it says (it doesn't say that).

It means what I said (sheesh):

DBAs are not customer facing people. the good ones are unsung heroes if you like: when they're good everything ticks a long without a hitch but when they're bad - that's when they become known (that was the point of that example - along with making it clear that plenty of DBAs are numptys and if you're thinking of employing a DBA you want to be sure you don't get one of them). But they are, by definition, behind the scenes and should be much more like sound engineers in attitude and role than the performers such as guitarists and singers. And any DBA with the obvious lack of people skills (irrational hatred of 'coders' and misquoting people and not listening to what people are actually saying) that perhaps some DBAs might have should definitely not be allowed anywhere near a customer.

I think that this is uncovering two very important tests of any DBA interview process: that they listen to people and comprehend what's being said to them (vital to being a good DBA imho) and that they are team players and respect other people's roles in the process and work to accommodate the requirements of the developers and customers. Companies with DBAs that don't do that have a major problem on their hands.
Post #1473224
Posted Friday, July 12, 2013 2:08 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, October 24, 2014 7:31 AM
Points: 372, Visits: 974
Am I reading it write or right?

Cheers
Post #1473228
Posted Friday, July 12, 2013 2:30 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
Points: 22, Visits: 64
jfogel (7/12/2013)
Am I reading it write or right?


Neither! You are reading it wrong.

I didn't say what you said I said. You know that. You even quoted me and went on to say something completely different.

How else can I phrase that?

One example of a DBA that messed up does not mean that it's always the DBAs that do. I can give examples of coders that do and doctors and politicians and bankers and economists etc etc. This is elementary stuff! I shouldn't need to explain that to you. I'm sure you're not stupid. Please try not to be.

It was an example of the only way a DBA becomes known to the world because when they do mess up it's often quite catastrophic. Sound engineers are the same: if they do a good job nobody knows. But everyone in the audience knows when they make a mistake. A DBA and a sound engineer should not want to be the centre of attention (like a guitarist or singer does) because the only time that happens is when they get fired!

Now: was that an honest mistake of yours (taking what I said to mean that when it obviously doesn't like I made a mistake writing 'write' instead of 'right')? Or were you just deliberately being provocative?
Post #1473231
Posted Friday, July 12, 2013 2:35 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, October 24, 2014 7:31 AM
Points: 372, Visits: 974
Just stop.

You wrote:

"Indeed you're not reading it write if you think that's what it says (it doesn't say that)."

And I asked if I read it write or right. You are acting so uppity and saying people need to comprehend but you misuse words and speak in circles. Give it a rest. Go play an instrument, have a beer or anything other than continue to post in this thread.


Cheers
Post #1473233
Posted Friday, July 12, 2013 3:30 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
Points: 22, Visits: 64
jfogel (7/12/2013)
Just stop.

You wrote:

"Indeed you're not reading it write if you think that's what it says (it doesn't say that)."

And I asked if I read it write or right. You are acting so uppity and saying people need to comprehend but you misuse words and speak in circles. Give it a rest. Go play an instrument, have a beer or anything other than continue to post in this thread.


I spelled one word wrong! and acknowledged it!!

Vila Restal (7/12/2013)
like I made a mistake writing 'write' instead of 'right'


and you then say all that above? (you explain your 'joke'? really?!!!)


So I'm misusing words? (plural)?!
Give it a rest?!!

No, you sir owe me an apology for misquoting me. Accusing me of saying that all mistakes are made by DBAs (or had you forgotten about that).

Acting so uppity? Uppity is not the word and I am not acting. I am annoyed at what you said. It is a basic logical fallacy to take what I said and equate it to "it's always DBAs that make mistakes". Then you pick up on a spelling mistake as an oh so witty comeback. I'd expect that on YouTube comments. Not here.

You accused me of an opinion and you were wrong. I explained that you were wrong. And now you say I'm being uppity. You would be too.

Why did you bother to post if you don't care about the topic?

As it happens I do care about the topic and I think people reading this might be wanting some thoughts about hiring DBAs: what makes a good DBA and what doesn't. If I'm speaking in circles it's because a couple of people are (I half suspect deliberately) not comprehending what I'm saying (and I'm not using long words or making particularly complicated so it's getting quite frustrating).

My point was and is:

DBAs are more like sound engineers than guitarists. That is not an insult to DBAs or sound engineers. Both perform vital difficult roles that need lots of training and experience to be any good at. A band with a bad sound engineer will sound like a swarm of hornets to the audience no matter how good musicians they are. Database developers (coders) will produce a shockingly unreliable and poorly performing product for the customer if they don't have a good DBA no matter how good they are at their job.


I was then picked up on that point as talking about flat-file DBAs only. And that was wrong. That's not what I meant and it came from a basic misunderstanding of what a sound engineer does. (Regarding it as a lowly role - less than a guitarist, which it isn't.)

By way of explaining why DBAs are and should remain behind the scenes (like a sound engineer) I gave a link to an example of a DBA making a name for himself in the company where he works. (I.e. by screwing up and getting fired.)

You then chipped in suggesting that that means I think DBAs are the only ones that make mistakes, which of course, to anyone with a basic grasp of logic, it doesn't.

That was annoying. I expect you know that's not what I meant or what it proves. But, just in case you didn't, I explained that to you.

You then came back with your oh so witty comment about a misspelled word.


That is not speaking in circles. I am trying to stay on topic here and you are trying to annoy me.
If you disagree with what I'm saying then please do but make sure you understand what I'm saying (including what a sound engineer does and how difficult and vital that work is) and what I'm not saying (that a DBAs job is easy or unimportant or they are the only ones who make mistakes).

Otherwise, of course you can make comments about the article irrespective of what I've said. But if you're going to comment on what I've said please keep it on topic and respectful.

Misquoting me and trying to make witty put downs is not appropriate for this discussion or forum and I did neither of those to you or anyone else so I don't see why you are doing that.
Post #1473249
Posted Friday, July 12, 2013 4:03 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 10:15 PM
Points: 35,399, Visits: 31,959
Easy guys. We're all in this together.

--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1473254
Posted Monday, July 15, 2013 3:32 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, September 9, 2014 5:45 AM
Points: 4, Visits: 31
Steve - thanks for those thoughts. I wish life were that simple. I seem to have spent most of my time trying to stop the lunatics taking over the asylum! The more skilled the lunatic the worse the situation can become. I need all my team - experts to novice - to talk to me and explain their approaches. It is the "talk to me" bit that is vital. I always ask for alternative solutions even if the first one offered is a clear winner. Arrogance and the closed mind really annoy me and I always ask questions at interview to try to winkle this out. I would rather a colleague who needs to develop but is a good team player, than a guy/gal (the guys are worst believe me) bristling with Microsoft accreditations and finely honed interview responses.
Post #1473552
Posted Monday, July 15, 2013 9:30 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 6:11 AM
Points: 363, Visits: 2,542
Vila Restal (7/12/2013)

That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?

The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.

But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.
Post #1473725
Posted Monday, July 15, 2013 10:00 AM


SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, September 11, 2014 12:01 PM
Points: 76, Visits: 232
patrickmcginnis59 10839 (7/15/2013)
Vila Restal (7/12/2013)

That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?

The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.

But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.


The first shot in the "adversarial point of view" was fired by coders. If you were around, or have read the history, you well know that Codd was vilified by the coding camp. The RM/sql database blew a large hole in IMS, which was Codd's explicit agenda. For those who don't know, IMS was/is IBM's hierarchical datastore, aimed mostly at COBOL copybooks, and requires a lot of coding just to keep breathing. IBM didn't take kindly to Codd; which is how Ellison beat them to a working product.

The issue isn't individuals. The issue is work product. Coders spew out more LoC to get more moolah. That's their motivation. That's how they get more moolah; not by being smart and lazy, but by typing more. (Database folks look for the least amount of effort to get the maximum amount of benefit.) Anything to keep their butts in their cubes; the more convoluted the better. That's why we *still* have the "software problem" 60 years on. Codd showed us a much, much better way for those applications which depend on stored data, for multi-use(rs). Coders are repelled by that, in my experience. "We will do data management in the client". Heard that too many times to count. That's adversarial.

Organic Normal Form™ schemas (supported by triggers, procs, and other server side entities) provide an opportunity to ditch the three-chord knucklehead for Clapton (i.e., not so much code and much more database). IOW, yet again, smart database development stresses effort in the database design, and any code in extremis. This is not the coders way. It just isn't; as these comments have demonstrated.
Post #1473748
Posted Monday, July 15, 2013 11:06 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Today @ 6:11 AM
Points: 363, Visits: 2,542
RobertYoung (7/15/2013)
patrickmcginnis59 10839 (7/15/2013)
Vila Restal (7/12/2013)

That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?

The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.

But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.


The first shot in the "adversarial point of view" was fired by coders. If you were around, or have read the history, you well know that Codd was vilified by the coding camp. The RM/sql database blew a large hole in IMS, which was Codd's explicit agenda. For those who don't know, IMS was/is IBM's hierarchical datastore, aimed mostly at COBOL copybooks, and requires a lot of coding just to keep breathing. IBM didn't take kindly to Codd; which is how Ellison beat them to a working product.

That doesn't really follow what I've read, the original "shot" you describe seems more like a decision by IBM to protect their existing hierarchical oriented product, and the subsequent efforts to isolate developers from Codd's ideas doesn't really seem to have been a decision made by developers themselves.

https://en.wikipedia.org/wiki/Edgar_F._Codd

Coders spew out more LoC to get more moolah.


This seems to be opposed to much discussion of desireable development practices I've run across, so I'm thinking a strawman might be under construction here This in no way precludes the instances of bad development, but I'm thinking that you won't find many notable leading developers ascribing to "more LoC means better systems."
Post #1473797
« Prev Topic | Next Topic »

Add to briefcase «««12345»»»

Permissions Expand / Collapse