December 13, 2016 at 7:53 pm
Ralph Hightower (12/13/2016)
Writing the data access code is not difficult.
If that's true, why do so many people get it wrong? 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2016 at 8:14 pm
ZZartin (12/13/2016)
I don't know where the impression comes from that development is solely limited to customer facing work. If a car mechanic told you he didn't think knowing how to drive was an important skill you'd probably do a double take.
Heh... to funny. I've always wondered why the term "developer" has, over time, been relegated to "front end" or "customer facing" development. I've also wondered why the term "DBA" has been warped to mean someone that can write code, even T-SQL when it's beyond administrative tasks.
As for the car mechanic, I wouldn't actually care if he could drive or not if he knows what's important to me... a properly working car. I don't go to him for his ability to drive... I go to him because he knows how to fix stuff on my car.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2016 at 10:02 pm
I couldn't do my job if I did develop in another language. But then again, I can't do my job because I'm developing in another language. When you think about it, it makes sense.
December 14, 2016 at 12:13 am
xsevensinzx (12/13/2016)
I couldn't do my job if I did develop in another language. But then again, I can't do my job because I'm developing in another language. When you think about it, it makes sense.
Are you sure???
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 14, 2016 at 2:59 am
Ok, Jeff just do what is best for you but stay away from hammers please!!
:-PManie Verster
Developer
Johannesburg
South Africa
I can do all things through Christ who strengthens me. - Holy Bible
I am a man of fixed and unbending principles, the first of which is to be flexible at all times. - Everett Mckinley Dirkson (Well, I am trying. - Manie Verster)
December 14, 2016 at 3:44 am
Sad thing is that I have done more years at programming than 80% of the developers and director. And I have been a DBA longer than development. Yet I have not found many developers who stray into the world of servers
The technical debt on projects is purely down to lack of experience. I'm finding there is a lack of willing to understand in depth any technology. It is simple that if stack overflow doesn't have the answer then it is too difficult.
December 14, 2016 at 5:04 am
Yet Another DBA (12/14/2016)
...if stack overflow doesn't have the answer then it is too difficult.
Unfortunately true.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 14, 2016 at 6:25 am
Gary Varga (12/14/2016)
xsevensinzx (12/13/2016)
I couldn't do my job if I did develop in another language. But then again, I can't do my job because I'm developing in another language. When you think about it, it makes sense.Are you sure???
Yes!
It means how can I do what I was hired to do if I'm doing what I'm not hired to do. In other words, develop software in C# when I should be building the data warehouse for example. 😎
I'm not slamming learning more, but it does has it's pros and cons. When other team members found out I could also develop in other languages, now I see my time tied up developing in those languages versus what I was really hired to do. While I add additional value to my role, it does take up time to develop those skills.
December 14, 2016 at 7:27 am
It means how can I do what I was hired to do if I'm doing what I'm not hired to do. In other words, develop software in C# when I should be building the data warehouse for example
But how can you do the job of a DBA if you cannot code? How can you work with your development staff and guide them so that they are putting out optimal code? How do you know if the developers aren't doing something that causes your performance issues?
It is one thing if your sole purpose in life is the creation of that datawarehouse, but how many find that they have one purpose in life?
The DBA must be the master of all trades, and be able to say that I need the disks setup this way, or LUN's carved out of the SAN that way. One needs to know the impact of the data flow on the network. Should you use stored procedures that call stored procedures on another server, or just do linked servers. And then there is the code, and it's impact on the servers as well.
I wish I was able to concentrate on the Datawarehouse, but I have so many other pieces to watch, understand and assist in optimizing.
Steve Jimmo
Sr DBA
“If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan
December 14, 2016 at 7:42 am
sjimmo (12/14/2016)
It means how can I do what I was hired to do if I'm doing what I'm not hired to do. In other words, develop software in C# when I should be building the data warehouse for example
But how can you do the job of a DBA if you cannot code? How can you work with your development staff and guide them so that they are putting out optimal code? How do you know if the developers aren't doing something that causes your performance issues?
It is one thing if your sole purpose in life is the creation of that datawarehouse, but how many find that they have one purpose in life?
The DBA must be the master of all trades, and be able to say that I need the disks setup this way, or LUN's carved out of the SAN that way. One needs to know the impact of the data flow on the network. Should you use stored procedures that call stored procedures on another server, or just do linked servers. And then there is the code, and it's impact on the servers as well.
I wish I was able to concentrate on the Datawarehouse, but I have so many other pieces to watch, understand and assist in optimizing.
I'm no DBA mind you. I'm the swiss army knife too. However, I'm not hired to be a C# developer. I don't develop software for a living. Just because I work in IT and sit across from your desk does not mean I want to be your desktop support guy either. Sure, I'm happy to help you figure out what your computer is not starting, but it does take away from what I was actually hired to do too.
I don't mean to sound like, "hey this is not my job!" But, you do have to understand that when you start going down the road of wearing multiple hats, especially those you are not compensated for, that your time becomes divided. So, be careful before you find yourself toppled with not just the projects you were hired to do, but all the other projects that other software developers don't have time for that you can backfill on too.
December 14, 2016 at 7:55 am
I'm the swiss army knife too
Unfortunately, in todays world we all are, or at least companies expect us to be.
Also, I, nor do I believe anyone else is advocating that you (or any DBA) literally drop what you are doing to be a developer, creating various applications. But that one should be aware of how.
I don't want to be a developer any more. I did it for over 15 years. But I do find things like PowerShell a valuable tool. Or to be able to create VB Scripts to accomplish various tasks that otherwise would take a lot of coding through other means. What about the need to create batch files to do things for you? With SQL Server being ported to Unix/Linux there will be c script, kscript and others.
It is also up to us to educate those who need to connect to our databases on the proper way to do so, and to be able to retrieve the data efficiently and without being the bully of the sandbox. After all, there can be many more playing in there.
Steve Jimmo
Sr DBA
“If we ever forget that we are One Nation Under God, then we will be a Nation gone under." - Ronald Reagan
December 14, 2016 at 8:03 am
Manie Verster (12/14/2016)
Ok, Jeff just do what is best for you but stay away from hammers please!!
Heh... You know me... I never do what is best for me. I only do what is best for the data, the server, and the next person that may need to make a change to my code in the future.
And, you've hit a bit of a sweet spot for me. Here's some of the "clever" sayings that people always seem to bubble to the surface when they don't get it. (NOT directed at you. The word "hammer" just reminded me of all this).
1. To a hammer, everything is a nail.
This is some really tired, old saying meant to provide a passive aggressive insult/ad hominem attack suggesting that someone has some pretty narrow thinking. What they don't realize is that they themselves don't understand how to use a hammer because it apparently has to many moving parts (one). 😀 Either that or they desperately want some new toy and can't really justify it if someone says it's simple to do with something that we already have and so have to resort to trying to discredit that person. My normal reply has become "When you're trying to drive nails, you should use a hammer or the built in nail gun".
2. SQL Server isn't the center of the local universe.
Really... then turn it off and let's see if you're right. :w00t: Again, people use this when trying to justify something they want to do externally (especially if it includes a new toy) and someone like me says they can do it pretty easily in SQL Server.
3. Just because you can do something in SQL Server, doesn't mean you should.
Another fine bit of passive aggressive rhetoric usually by the same person from #2 above that doesn't understand SQL Server and is trying to justify using a different tool because they don't want to admit they don't know how to do something in SQL Server. Yes, there are places where I agree with the saying but people seem to carpet-bomb with it. My normal retort has become "Just because you can do it outside of SQL Server, doesn't mean you should". Not everything that's "difficult" needs to be solved by PowerShell, SQLCLR, custom scripts in lord knows what language, RegEx, XML, JSON, a bevy of 3rd party add-ons, etc, etc, ad infinitum. T-SQL is actually quite powerful. You just have to know how to use it.
4. We've never done it that way before.
Yeah... I know. That's why you're in trouble now.
5. We've always done it this way.
Yeah... I know. See #4.
6. We have this {$350,000} tool that we use for that.
Yeah... I know. See #4. And great job on your purchase... it relies on SQL Server stored procedures that you have to write just like SSIS and it takes people hours instead of minutes to standup and test a job in it.
The problem is that there's usually only one or two DBAs in a company where there might be 10 or 20 developers. Since management frequently doesn't know any difference between managed code (front end or not) and database code, they do the democratic thing and go with the popular vote of the larger number of people, sometimes with devastating results. It's not necessarily a fault that can be fixed but it is a fact.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2016 at 8:21 am
xsevensinzx (12/14/2016)
Gary Varga (12/14/2016)
xsevensinzx (12/13/2016)
I couldn't do my job if I did develop in another language. But then again, I can't do my job because I'm developing in another language. When you think about it, it makes sense.Are you sure???
Yes!
It means how can I do what I was hired to do if I'm doing what I'm not hired to do. In other words, develop software in C# when I should be building the data warehouse for example. 😎
I'm not slamming learning more, but it does has it's pros and cons. When other team members found out I could also develop in other languages, now I see my time tied up developing in those languages versus what I was really hired to do. While I add additional value to my role, it does take up time to develop those skills.
Thanks for explaining. I get you now. And agree.
Whilst we should all be prepared to turn our hands to whatever is required of us it does not necessarily mean that we should. We have responsibilities and just because something else comes along doesn't necessarily mean that we can lay these aside.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 14, 2016 at 8:35 am
Well said, Jeff!
December 15, 2016 at 4:51 am
Sean Redmond (12/13/2016)
A senior developer who recently left our company expressed the opinion to me that the DBAs should be in charge of the Data Access Layer.He was very definite that we (the DBAs) should be able to code with ease in C#, understand Visual Studio & the Build-process.
Only when the DBAs work with the developers under their conditions as a part of their team, would the friction between the DBAs and developers stop.
I am in two minds about this. It would me several years to get up to a level of C# that is good enough for daily programming, unless, of course, I start learning C# full-time.
Added to that, there are other aspects of SQL Server that I would prefer to master and SQL server is such a broad field.
However, my gut-feeling is that the recently departed developer is correct. I can moan all I like about Entity-Framework, but until I am in a position to do something about it, I have to live with it. It would be advantageous for DBAs to start taking charge of the DAL.
I don't think DBAs should know C# to do programming, at least not in general. Some might, and that's fine. However, I think they should be able to read some C# code and certainly should understand how to compile and automate the builds of code. That will help them understand how they can do the same thing with their code. At least for views/procs/functions. Maybe not tables, but build the others.
Viewing 15 posts - 31 through 45 (of 51 total)
You must be logged in to reply to this topic. Login to reply