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 Thursday, July 11, 2013 10:30 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
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.
Post #1472692
Posted Thursday, July 11, 2013 10:49 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 8:58 PM
Points: 28, Visits: 114
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.

Post #1472854
Posted Thursday, July 11, 2013 11:47 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:42 PM
Points: 635, Visits: 2,215
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.
Post #1472859
Posted Friday, July 12, 2013 1:46 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
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.
Post #1472888
Posted Friday, July 12, 2013 8:20 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
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.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1473062
Posted Friday, July 12, 2013 10:01 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
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. 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.
Post #1473129
Posted Friday, July 12, 2013 11:07 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
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. 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.


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")
Post #1473153
Posted Friday, July 12, 2013 11:31 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
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?
Post #1473163
Posted Friday, July 12, 2013 12:01 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, August 15, 2013 3:19 AM
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).
Post #1473191
Posted Friday, July 12, 2013 12:20 PM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, September 15, 2014 10:24 AM
Points: 371, Visits: 967
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
Post #1473208
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse