Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Hiring Guitarists


Hiring Guitarists

Author
Message
RobertYoung
RobertYoung
SSC-Enthusiastic
SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)

Group: General Forum Members
Points: 100 Visits: 232
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.


And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.
Frank W Fulton Jr
Frank W Fulton Jr
SSC Rookie
SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)

Group: General Forum Members
Points: 38 Visits: 132
When I interview people, I always ask somewhere during the interview if they play a musical instrument. Even if they say they dabble in tuba or oboe, that for me is a plus. I cannot explain it; but they usually make better decisions and are more flexible in finding solutions. I think it has to do with the mathematics of music and the improvisation skills from playing with others.
Jim P.
Jim P.
Say Hey Kid
Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)Say Hey Kid (681 reputation)

Group: General Forum Members
Points: 681 Visits: 2215
RobertYoung (7/11/2013)
And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.


I consider that a narrow view.

I'm a production DBA. I need to know how to troubleshoot production data at both the DB/OS interaction level and what is a bug in the SW. My last company used primarily delivered SW. I found a bug that the delivered SW failed on the INSERT statement but the UPDATE statement worked.

My current company is/was a SW producer. On the production end I still needed to know when the end-user failed versus a failed stored proc that I had to report as a bug.

But at the same time I've done development work. So I know that sometimes the DB should be flat, or whether to build it in.



----------------
Jim P.

A little bit of this and a little byte of that can cause bloatware.
Vila Restal
Vila Restal
Grasshopper
Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)

Group: General Forum Members
Points: 22 Visits: 64
RobertYoung (7/11/2013)
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.


And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.


I don't see why you would say that. Sound engineering is complicated, takes a lot of experience and isn't done to make the band happy: the sound engineer's duty is to the music and the listeners. Good sound engineers are hard to come by. The sound engineers you're thinking of are the jobsworths: just plug it all in, get the levels right, job done. (And in that sense the anology holds with the jobsworth DBAs.)

If a DBA wants to be a 'performer' (strutting on stage) then I think they've picked the wrong vocation in life and I wouldn't want to hire or work with such a person as a DBA whatever the structure of the database.
TravisDBA
TravisDBA
UDP Broadcaster
UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)UDP Broadcaster (1.5K reputation)

Group: General Forum Members
Points: 1466 Visits: 3069
Senior DBA's must be able to work under pressure while at the same time always maintaining their cool. If they can't do that then they are not the right person for the job, plain and simple.:-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
RobertYoung
RobertYoung
SSC-Enthusiastic
SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)

Group: General Forum Members
Points: 100 Visits: 232
Vila Restal (7/12/2013)
RobertYoung (7/11/2013)
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.


And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.


I don't see why you would say that.


Because, as I said originally, there are multiple types of DBA, and what you describe is the code-centric data DBA under the thumb of coders. No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P Building an Organic Normal Form™ schema isn't something that one guy/gal does over lunch, while the coders are playing frisbee. It's real work, with real payoff. That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub. Coders never want to hear about a tech that makes less code.

Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.
Vila Restal
Vila Restal
Grasshopper
Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)

Group: General Forum Members
Points: 22 Visits: 64
RobertYoung (7/12/2013)
Vila Restal (7/12/2013)
RobertYoung (7/11/2013)
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.


And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.


I don't see why you would say that.


Because, as I said originally, there are multiple types of DBA, and what you describe is the code-centric data DBA under the thumb of coders. No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P Building an Organic Normal Form™ schema isn't something that one guy/gal does over lunch, while the coders are playing frisbee. It's real work, with real payoff. That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub. Coders never want to hear about a tech that makes less code.

Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.


OK, so you've shown that you don't like coders and that DBA's mustn't be subservient to them but not why the 'DBA is more like a Sound Engineer rather than Guitarist' point is wrong. If you're going to say I'm wrong on that point, which is what you are doing (it's all I said), please explain why and not just explain that DBA's mustn't work for the coders, which isn't what I said and is another point entirely.

And why this tirade against coders? Where did you get the impression that I was suggesting a DBA's work was easy or unimportant? Do you understand what a sound engineer does? That was the title of the article: Hiring Guitarists. My point is simply that a company hiring a good DBA is more like a band hiring a good sound engineer rather than a guitarist.

It is annoying to have someone disagree with you and then give complete non-sequitur reasons for it:

RobertYoung (7/12/2013)
what you describe is the code-centric data DBA under the thumb of coders.


No it isn't. Not my intention or my opinion or what I did.

RobertYoung (7/12/2013)
No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P


Codd's rules take 10 minutes to learn and a good DBA or developer learns them from first principle (would come to them by their own reasoning) not by wrote.
All DBAs have learnt SQL surely (of one flavour or another).
I've not learnt "..." though. Is it useful for being a DBA?
Surely no human being with any self-respect has any desire to kowtow to anyone else. The DBA/coder subset is no different.

(And wow! You really don't like "coders" do you?)

RobertYoung (7/12/2013)
Building an Organic Normal Form schema isn't something that one guy/gal does over lunch


Sounds more like development than administration to me but ok, let's call him a DBA for sake of argument

RobertYoung (7/12/2013)
t's real work, with real payoff.


I never said it wasn't

RobertYoung (7/12/2013)
That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub.


Well duh. Relational databases are better. I agree and I never said they weren't.

RobertYoung (7/12/2013)
Coders never want to hear about a tech that makes less code.

Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.


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?


To everyone else: am I being trolled here? ("I'll just quote some random guy, say I'm disagreeing with him and go into a tirade against coders")
RobertYoung
RobertYoung
SSC-Enthusiastic
SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)

Group: General Forum Members
Points: 100 Visits: 232
Trolled? You're the one who reduced DBA to not even a guitarist!

Well, what can I say, but what I said originally: there are DBAs who rule the data (the singers) and there are DBAs who don't (sound guys, roadies, drum techs, etc.). The notion that *no* DBA can be the singer is where the fundamental disagreement lies. Screen oriented apps (games, embedded, iStuff apps, and the like) have little need for a persistent, coherent data store.

However, for those apps which can/do use an RDBMS, then there is a fork in the development road: treat the data as un-normalized files (cater to the coders) or as Organic Normal Form™ data (put the logic with the data in the engine through DRI, etc.). The former is no different from COBOL/VSAM of the late 60s, while the latter isn't. I've been in the room when coders (COBOL/java as it happens) insist on "doing the transactions in the application". So, I'm not making this up. Those coders weren't going to give up their power over the application, as they saw it. The simple fact is that relying on the RDBMS engine to enforce data integrity reduces the amount of data on the server and (non-generated) code on the client. Coders see that as stealing from their rice bowl. And it is. So be it.

To put it starkly: if *your* DBA said to you, "I can show you how to eliminate 90% of LoC out in the application and reduce data footprint by 75% by using SS (or whatever) relationally", would you graciously say, "thanks". Or would you look for some excuse to keep writing code?
Vila Restal
Vila Restal
Grasshopper
Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)

Group: General Forum Members
Points: 22 Visits: 64
RobertYoung (7/12/2013)
Trolled? You're the one who reduced DBA to not even a guitarist!


Not even a guitarist?

Firstly, you seem to think that only the musicians are important in a band. Wrong!
Secondly, you seem to think that the DBA is the most important person in a company. Also wrong!

I am a person who wears both DBA and developer hats (and the two are distinct although often performed by the same person). We are here talking about the DBA role only, not a DBA/developer.

But anyway, I see now why you disagree: You think only guitarists (at the very least) and singers (or even only the performers on stage) are important to music and DBAs should be equated to only these most exalted people and it's an insult to equate them to a lowly sound engineer.

Try these links. You might find them enlightening:

http://en.wikipedia.org/wiki/Eddie_Kramer
http://en.wikipedia.org/wiki/Andy_Johns
http://en.wikipedia.org/wiki/James_Guthrie_(record_producer)
http://en.wikipedia.org/wiki/Leslie_Ann_Jones

Or indeed anybody in the lists of engineers of note on http://en.wikipedia.org/wiki/Audio_engineer

You obviously haven't any understanding of how integral and essential these people are to the music that has enriched your life.

Not even a guitarist indeed. As an amateur guitarist myself I find that insulting.

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).
jfogel
jfogel
SSC-Addicted
SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)SSC-Addicted (445 reputation)

Group: General Forum Members
Points: 445 Visits: 1152
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.

Cheers
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search