DBAs Need to Learn to Develop

  • Steve Jones - SSC Editor (12/15/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.

    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.

    I cannot remember the last language I couldn't read at all. Usually you can get the gist. Especially when you have coded in a reasonable number of disparate languages.

    Gaz

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

  • I believe that DBA's dramatically increase their value when they can speak the language of the groups with which they interact. Speaking to businessmen, for example, requires a vastly different mindset and language than speaking to other DBA's, and the same applies to interactions between developers and DBA's. Thus, I believe that DBA's should be very familiar with what's going on in the data access layer, ESPECIALLY if an ORM or anything that generates SQL code is in play. A DBA can almost literally save the day by modifying generated code to improve performance and increase data integrity.

    That being said, I don't think that DBA's should take over development. There are different roles that DBA's can perform, and database development is not database maintenance. Both are full time occupations in their own right.

  • Gary Varga - Tuesday, January 7, 2014 1:51 AM

    There are too many people in the technical side of IT who do not have a foundation in IT knowledge. We should all understand binary, logic, declarative programming, functional programming, distributed systems etc. The level of understanding depends upon what role(s) we need to perform but we must all have a broad understanding of the basics.Oh, and Jeff, too true :crazy:

    The trouble is that most people think they do understand logic; unfortuntely they think that logic is two-valued.  Both developers and DBAs should learn that there are many non-boolean logics in use in mathematics. One of the most interesting things to look at in mathematics is how different mathematics becomes if you use a logic with more than just two values (effectively banning proofs based on the excluded middle) - it's far less different than most people who haven't seriously studied it assume.  They should also know some basic set theory (if the people who produced the ANSI standard for SQL had understood set theory even at high-school maths level they wouldn't have screwed up the SUM aggregate function the way they did).   They need to know basic maths and a basic understand enough about hardware to see how doing things with it affects performance, and to be able to develop a good understanding of how the software will interpret their descriptions of what to do into actions to be performed by hardware.  There's not much point in teaching them none of that and teaching them instead how to throw chunks of C++ or SQL or Powershell commands or SqL Agent jobsteps and schedules together.   If they are taught the underlying maths, logic, engineering principles, and models (relational, logical, functional, procedural, process-oriented, and maybe even OO) then they can learn the language-specific stuff later (actually they are pretty likely to learn some of it in parallel, in their own time) and will probably be able to use it well instead of badly.

    Tom

  • Jeff Moden - Tuesday, December 13, 2016 7:53 AM

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

    Three good points there Jeff. 

    But on the first one, plese remember that it's a two-way thing - I've seen a lot of the kettles (so-called DBAs) refusing to consider anything other that SQL and calling the pts (Devs) black because they won't learn it. 

    The second one is something that far too many managers don't know.

    I find it frightening that so many people don't understand the third one - and that so many companies don't embrace it and so much management training taught that anything like DevOps is a disastrous mistake, although competent managers have known that's the way to go for at least 5 decades.

    Tom

  • TomThomson - Saturday, January 14, 2017 6:58 PM

    Jeff Moden - Tuesday, December 13, 2016 7:53 AM

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

    Three good points there Jeff. 

    But on the first one, plese remember that it's a two-way thing - I've seen a lot of the kettles (so-called DBAs) refusing to consider anything other that SQL and calling the pts (Devs) black because they won't learn it. 

    The second one is something that far too many managers don't know.

    I find it frightening that so many people don't understand the third one - and that so many companies don't embrace it and so much management training taught that anything like DevOps is a disastrous mistake, although competent managers have known that's the way to go for at least 5 decades.

    Absolutely agreed on the first one, Tom.  It is, indeed, a two way street.  Very fortunately for me, I used to be a "front ender".  Despite the seeming changes in the world of code since then, not much has actually changed since then, especially when it comes to ridiculous schedules and demands. That's why I asked to sit with the Developers when I first started working at my current company.  It's worked out very well. I do peer reviews and use the time to mentor.  I even help "protect" them when users and managers try the ol' drive-by-shooting thing on them.  They've gotten very good in the world of databases and they take great pride in the accuracy and the performance of their code.  They've even taken to bragging about how they improved the performance (and I'm not talking about just a little bit, either) of legacy code either by tweaking it or replacing it.

     I help them and they help me.  It's a DBA/Developer relationship that I've never seen before and I'm really proud and honored to have been a part of it all.

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

  • I know this post is 3 years old but I get a real laugh out of the title every time I run across it as I mutter "So do developers". 😉

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

  • Jeff Moden - Saturday, January 14, 2017 10:42 PM

    I know this post is 3 years old but I get a real laugh out of the title every time I run across it as I mutter "So do developers". 😉

    So true. So true. :'(

    Gaz

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

Viewing 7 posts - 46 through 51 (of 51 total)

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