Walk on the Wild Side

  • Comments posted to this topic are about the item Walk on the Wild Side

  • Good pick!

    Now a days Administrators are more busy than before, with increasing number of database instances they are managing.

    A DBA with database development experience has much confidence, problem solving skills and even WILD taste as well, than a full classified DBA. 😀

  • Most administrators I have worked with are quite proficient in troubleshooting their area of hardware/software, however the one thing they would benefit from the switch over to development is understanding how (and in some cases why) seemingly obvious problems and issues are sometimes overlooked when the money and business decisions come into the picture.

    Often I have come across administrators complaining that a particular part of the installation process is very tedious and involves a lot of manual interaction - and the reason is generally that the business did not decide it to be worthwhile to spend more time on what is a "one-time" activity.

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com

    Follow me on
    Twitter: @sqltwins

  • There is a huge advantage in pulling the tekkies out of IT and having them learn part of the business.

    In another life and century I worked for a major motor carrier. People who did not deal with drivers could take a 2 day course called Driver Reality. We learned a lot. We even got to see people in cars pull in front of rigs in traffic. Fortunately the cars were not crushed since the truck driver would have been blamed. Few if any ever went on to become truck drivers. But we learned an entirely different aspect of the business and returned to the tech world with a slightly altered view of the world.

    ------------
    Buy the ticket, take the ride. -- Hunter S. Thompson

  • I agree with the benefits of having the production support/DBA folks learn the business they are supporting. When I was in 2nd line support it was very helpful to know the data when troubleshooting failed jobs, for example before sending a report or 'all clear' email, a quick validation check would show that someone making 100,000 sales in one day probably indicated a data quality issue. If you have no knowledge of the business these anomalies don't jump out at you.



    SQL Tips and Scripts
    SQLWorks Blog

  • I currently work as a DBA, system administrator (mostly for SQL Servers, but a few web servers) and a web application developer. I feel that working across all of those really does give me a unique perpective on how the "other side" works. I've found that since I know a little more about web servers and IIS than the average developer, I can more easily communicate my needs to the server admins. Even though I can technically take care of my own needs, I want to have someone else in the loop, and keep up good relations between the admins and developers. Sometimes when another DBA or developer starts attacking someone else's design, I can typically understand why it was designed that way (since requirements change so often) and help resolve the resulting conflicts between the two.

    While this to some degree makes me a "jack of all trades, master of none", it keeps me busy and interested in what I'm doing. While the politics of my organization are a little too harsh for my liking most of the time, I find that I don't really want to leave and possibly be stuck with only one job.

  • I definitely approve of cross-training; I'd note that the most advanced DBA written maintenance, backup, etc. scripts I've seen are extremely simple by any experienced developer's standards, and I often encounter "that's too complex" resistance from DBA's on requirements thatare both few and fairly simple for any real development project.

    Likewise, developers should cross-train on the database admin side, and everyone in IT should know more about the business, if only to be able to ask better questions about requests coming from the business, which can lead to providing better service.

    P.S. at large companies with regulatory boundaries, I haven't seen personal relationships bend rules and regulations (I'm sure it happens, but it can in some industries generate major fines, firings, investigations, and/or lawsuits), but I have seen them bend the "process" - not the rule, certainly not the regulation, but instead of sending an official request and getting a denial back 4-8 days later with the reason and then you try again, you can ask a question or explain the situation first, and have a much better chance of sending an actionable (and accurate) request. Perhaps you even get a faster response when it's important and you explain that in a sidebar.

  • I work at one of those regulated companies (banks) too...there are no rules that a good relationship can break, hell if my Mother was the DBA she couldn't give me elevated rights...and she says i'm the best developer around.

    However, the comment about iterating through a few scenarios and getting better information before actually submitting whatever request you're working on is absolutely true.



    SQL Tips and Scripts
    SQLWorks Blog

  • Steve,

    Right on Brother! You have to know how the other side lives or you live yourself in a land of misconceptions and ignorance.

    I agree with others that often Ops will install something that appears to be awkward, complex, and just plain tricky. Little do they realize that to make what the business requires or demands that it has to be awkward, complex, and tricky. Not knowing what is required on the other side is like playing quarterback in American Football and not being able to see the defensive team members. If all you see is your team and are limited to only your perceptions, you elevate the risk of failure to unacceptable levels on every front. Not a game most of us would want to play.

    M.

    Not all gray hairs are Dinosaurs!

  • As a database/web developer for over 16 years, I completely agree with the idea of cross training when it comes to developers and DBAs. Doing so gives each a better perspective on what the other does as well as making it more efficient to troubleshoot developmental issues that might be related to either the database end or the application calling the database. I have always thought a developer should know more about the DBA side so that if a problem comes up that "appears" to be a problem that has to be resolved by the DBA, the developer can point the DBA in the right direction to troubleshoot. This is of course reversed when the two put their heads together and the DBA points the developer to the right place to look in their code for the problem. Part of the reason I do this is because I want the problem solved asap and part of it is because I figure the DBA is extremely busy and if I point him in the right place to look in the database that will save him time in rectifying the problem.

  • I would extend this further and say management should have to spend some time doing or at least shadowing both of these jobs.

    Then again I believe everyone should have at least some training in computer programming in today's highly technical society.

    I loved how the judge in the Oracle vs Google case was able to use his own programming experience to tell the Oracle lawyers that something they were arguing was really hard was actually quite simple.

  • G Bryant McClellan (10/23/2012)


    There is a huge advantage in pulling the tekkies out of IT and having them learn part of the business.

    In another life and century I worked for a major motor carrier. People who did not deal with drivers could take a 2 day course called Driver Reality. We learned a lot. We even got to see people in cars pull in front of rigs in traffic. Fortunately the cars were not crushed since the truck driver would have been blamed. Few if any ever went on to become truck drivers. But we learned an entirely different aspect of the business and returned to the tech world with a slightly altered view of the world.

    There would be a huge advantage in having business people pulled out of the area they work in, to spend time in IT.

    Of course, the next question is whether they would be competent enough to do so, and if their personalities would allow them to actually gain from it. Recently I had to deal with an end user that felt is was appropriate to grunt every second as I attempted to ask her co-worker for examples. This person was a manager, by the way. I find most end users have absolutely no patience for what we have to go through, and don't even want to answer our questions in order to help them. The preference is to just blame the technical people.

    Dave

  • I have experience as a developer, and mainly work as an analyst right now. Most of the products we use come from external vendors, where we have little control over things.

    I do know that my experience has led to teamwork that ended up identifying and fixing bugs much faster, since I understand how programs function, and can frequently point them in the right direction much faster.

    As others have said in this thread, seeing the other side is a great idea. It must come with the right attitude though, and I don't see a lot of people who are willing to keep a positive attitude, for a variety of reasons.

    Dave

  • Production administrators are the best. It is my preference to sit with them in order to know specifically how an application behaves or what the real inpact would be if changes were to be made.

  • djackson 22568 (10/23/2012)


    There would be a huge advantage in having business people pulled out of the area they work in, to spend time in IT.

    This makes some sense, especially in terms of some limited, relatively easy tasks, like report writing. Maybe query structure, have them learn a few things they might use later, but also understand how hard this can be.

Viewing 15 posts - 1 through 14 (of 14 total)

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