DBAs Need to Learn to Develop

  • Jeff Moden (1/7/2014)


    eccentricDBA (1/7/2014)


    I agree that a DBA should learn how to develop. At the very least they should learn how to use a scripting language (dos batch, bash, cscript, vbscript, perl, powershell). The goal of a DBA is to have a consistent repeatable environment and having the ability to write enough code to automate that process only helps to make you a better DBA.

    You left out the most important scripting language of them all for a DBA... T-SQL. I'm shocked and mortified at the number of people that have "DBA" on their resume that can't do a simple joined update.

    Jeff,

    You are absolutely right. I did forget T-SQL, the most powerfull of all languages when working with databases. Unless you are working with the DB that shall not be named then it would be PL\SQL.

    I really want to go on a rant here about n-tier and ORMs but I'm going to save it for someone else.

    A great craftsman knows his/her tools and knows who to use the appropriate tool, language, for the problem at hand.

    What's the saying? "If all you have is a hammer every things a nail".

    --Carlton

  • eccentricDBA (1/9/2014)


    What's the saying? "If all you have is a hammer every things a nail".

    --Carlton

    The problem is that a lot of people keep going to the store in the next state to buy a new type of hammer for the same old problems. There are some things that ya just gotta use a hammer for. 😉

    --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)
    Intro to Tally Tables and Functions

  • What's the saying? "If all you have is a hammer every things a nail".

    Just don't give Jeff a hammer please because he might break something. :-D:-D:-D:-D:-D:-D:-D

    Hi Steve, great article. I think not only do DBA's need to learn to develop, but developers need to learn something of what a DBA do. You know, in 2012/2013 I was put on the spot as a developer to start administering our database. The company bought a new server for the database (we did not always have a dedicated server for our database because it was only 15 GB) and told me that is your server, that is your database now look after it and I had to suddenly learn a couple of things to administer this database. Well, this opened my eyes to better develop my applications, to look in a new way at the performance of my application. It changed the way I did T-SQL coding and now before I just say select * from table I put the query through it's paces to see how I can better this.

    Next point of order, I think all IT professionals should learn something about each and every field of IT. It does not need to be full on training but at least something that can help you to understand about it.

    I actually tried that and went to sit with our network/server it on a quiet day to learn something but I was summarily told to please learn it somewhere else.

    :-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)

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

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

    Don't rush it. Take this tutorial http://csharp.net-tutorials.com/. It teaches you from basic c# and onward. Once you get it you will enjoy it and there is nothing like another item to add to your CV. Happy coding!

    :-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)

  • I still agree with pretty much all that was said nearly three years ago. My summary is that everyone needs to be able to communicate and have a general understanding of the roles that their colleagues perform as well as their own.

    I hear people saying that we shouldn't raise the entry barrier to our industry. Perhaps they are right but maybe, just maybe, we are setting the bar too low for progression from the junior positions.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Good advice never gets old.

  • Very nice advise!

    The sentence "Follow the local development paradigm as much as possible." is awesome

    Regards

  • 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 know how to even fire up the development environment for C# but I do understand what the Developers go through. A big part of the reason for that is that I 1) sit with the Developers and listen, 2) do 100% code reviews with the Developers and use that time for some bi-directional training/mentoring, and 3) monitor the system for performance challenged code and talk with the Developers rather than issuing unreasonable edicts from some ivory tower. Partially as a result of all that, we have one of the tightest, well versed Developer Teams I've ever worked with and their knowledge in SQL Server actually outstrips the knowledge of another team that works only with SQL Server. They even test for performance problems on new code and code changes and are proud of the improvements they've made.

    On the subject of DBAs learning to write C# I ask, why do so many developers think that's the answer instead of them learning T-SQL and other things about the database? It's a case of the pot calling the kettle black. According to the interviews I've conducted over the last 2 decades and particularly the last decade, 8 in 10 front end developers claim to know SQL and then can't even tell me how to get the bloody current date and time never mind things like how to write SARGable code and why.

    The real key here is that not everyone can know everything especially with this world of babble created by all sorts of 3rd party tools and multiple languages. Even MS screwed up there just within the 4 letter word products that come with SQL Server. With the idea that not everyone can know everything, people simply need to do what many do not... come out of the caves, climb down from the ivory towers, and take the time to communicate with each other to not only make work a joy but to improve the quality/performance of the product AND increase the throughput through the elimination of rework and retest.

    The bad part about that can be found in the form of managers that don't know how to manage. Just because you set a deadline, doesn't mean that it can actually be met. Cracking the whip across people's backs can cause people to move more quickly but you're not fostering an environment for the production of high quality and low rework, which causes multiple times the cost in time than doing it right in the first place. Remember that if you want it real bad, that's likely the way you'll get it... real bad. You, too, need to come down from your ivory tower and see what's happening in the caves, where all the work is actually done. Remember that the really good managers are both enablers and protectors.

    Although all of this has been true since before computers even came out, there's a new shinny name for all of this... DevOps. Embrace it or be swept aside by companies that have.

    Even in a harsh management environment where the managers just don't get it, Developers and DBAs need to realize that they're both on the same team. Start working with each other. Demonstrate methods and techniques to each other. It seems like it takes extra time and will, at first, but once the machine is built and properly maintained, it's amazing what such teams can actually do together.

    On the flip side, any DBA, system or otherwise, that doesn't know how to write some pretty decent T-SQL isn't really a DBA in my eyes. Developers with a decade of supposed experience aren't the only ones that haven't been able to get the current date a time in SQL Server. Even worse, many of them don't even know how to do a native backup/restore without some 3rd party tool. That put's them in the "user" category rather than the "DBA" category, IMHO.

    Being a DBA myself, I have a strong appreciation for what David Poole once said because it's oh-so-true. To paraphrase, "If you're the first person people will seek out for database problems rather than the last, you might be an exceptional DBA". Help the team. Be exceptional.

    --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)
    Intro to Tally Tables and Functions

  • I agree that DBAs need to expand their skillset into development. However, instead of a .NET language, I'd suggest T-SQL (obviously and essentially), PowerShell, SSIS, and maybe SSAS/SSRS if that's in your organizations stack.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Jeff,

    You say so much in there that if I had to I would have to cut and paste the whole thing.

    But you are correct with everything that you said. But one thing I haven't seen mentioned is that unless the managers understand what a DBA is, they have no idea how to manage them.

    I had interviewed a person that after the first question I knew that he wasn't going to work out. He had never seen SS, and his total DB experience was using an application that touched an Oracle DB. My boss had me take a vacation, hired him and told me his personality was a fit for the team. $25K and 3 years later he became a valuable member of the team.

    I took my first DBA class in Sybase many years ago and back then you had to be able to develop or at least understand the principals of development. You needed to know T-SQL, hardware and networking before you could achieve that coveted title of DBA. I still go by that today.

    Your comments about sitting with the developers was a rule I had but was overruled by my manager because it took to much time from the developers. As a result, they don't learn or understand how their code works on a DB. They also do not get to learn the new features of SS which may aid them in better applications.

    But one thing that doesn't change is the looks from the developers, and those who have the nerve tell me "I don't understand, you are only a DBA."

    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

  • Jeff Moden (12/13/2016)


    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.

    ...

    On the subject of DBAs learning to write C# I ask, why do so many developers think that's the answer instead of them learning T-SQL and other things about the database? It's a case of the pot calling the kettle black. According to the interviews I've conducted over the last 2 decades and particularly the last decade, 8 in 10 front end developers claim to know SQL and then can't even tell me how to get the bloody current date and time never mind things like how to write SARGable code and why.

    ...

    Writing the data access code is not difficult. I'm a C# developer that writes his own data access and T-SQL. I've designed databases and tables, but don't put me in charge of moving databases from one server to another, or maintaining database servers.

    There was one application that I did a clean slate rewrite; the old code was in Delphi and the new in C#. The application had one of two searches to find the patient id to put in the immunization record; I thought to speed up the process by incorporating the two searches in a stored procedure to avoid possibly sending a second search to the database; do the search in one round-trip instead of two round-trips. Since our shop uses SQL Server and DB/2, I let the DB/2 DBA create the stored procedure; besides, the DBAs are the only ones with the ability to create and modify the dev, test, and production servers. The use of the stored procedure decreased the runtime of the application by 25 percent.

  • I'm old school, the DBAs I looked up to were usually the best combo of developer/sys admin with excellent all around skills and very good database skills.

    I think more developers need SQL and DBA classes. Maybe get some decent TSQL instead of the some of the crappy Cartesian queries from heck that I have kill after they run for 5 hours...

  • I believe that developers and DBAs can both benefit from advanced T-SQL training.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

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

Viewing 15 posts - 16 through 30 (of 51 total)

You must be logged in to reply to this topic. Login to reply