My developer never listens to me

  • I'm a sql server DBA and this is my first full time job. Our company is compromised of 25 employees (very small). They want me to guide the developers. But the developers could not take it. They all hate me. The main reason is im 25 and they have issues listening to me . I have one particular developer who yells at me always. He looks at me as if I don't know anything about Administration. My manager is asking me to compromise. Again my manager is letting him to do his way. I don't understand they want me to control the database , at the same time they are letting developers to do what they want with the database. Now they are asking me to write the stored procedures for new applications. I don't know if this is my responsibility. I have never seen any company where DBA writes all the stored proc for the application. Also I feel it is going to increase the hatred that developers have on me. I don't know how to handle this, how to handle the developers. I badly need some help.

  • This what I recommend, When ever a Programmer is making a change to the database, like adding a stored proc or a table, check it and see if they comply to your standards. (For example performance, object qualification and for tables, Index and primary keys etc) and then send an email to them CCing your Manager what you found wrong. Also in that email you should explain why you think it is wrong. What is cost of having an object like that on the DB. Dont be too forceful. Try to be diplomatic about it. The developers should get a feeling that you know what you are talking about. And Managers should know that doing it the developer way might bring the DB down.

    -Roy

  • Thanks for ur reply. Frankly thats what I'm doing. My manager doesn't want me to send emails. He wants me to talk to them in person and before I joined, they had bad experiences by letting developers leading the database. Also whenever I make changes to their code I explain them why I want to make the change and its impact on Database. The developers doesn't want me to review their code and my manager is worried that the developers will lose interest in their work, so he is letting them do their way.

  • My developers don't listen to me either.

    From the sounds of things, I'd do three things. First, when they have an issue with something that you propose, gather all the statistics that show you're right, before & after execution plans, performance tests, whatever, and then present them to them in a cool, logical fashion. People will still try, but when you've got mathematical facts on your side, there's very little they can argue with. Second, start educating them by showing them better practices for the stuff they're doing, where to go to get help and information, stuff like that. Be helpful. Be Courteous. Be Nice. Third, YELL BACK! Sometimes people are just bullies. Bullies understand one thing very well, a punch to the nose. While you can't really do that, you can give them back what they give you. Just do the nice, helpful, courteous route first.

    One other thing I'd suggest. Get as much documentation together on standards and best practices as you can. Get it into the developers hands as fast as possible and be as consistent in its application as you possibly can be. This way they'll know what to expect.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • YELL BACK is a pretty good option. I have had to do that. We the DBA have managed to be the most hated department of our company..:D

    But we are not here to make just friends. Keep in mind that your primary responsibility is your DB. You are responsible for it. When things get nasty on the DB side, the developers are just going to blame you. So will the Management.

    -Roy

  • Thanks a lot.

  • I have to agree with all 3 of Grant's suggestions. I would add a 4th, get with your manager and clarify why you were hired in the first place and what he/she actually expects you to be doing.

    If your manager wants you to meet with the developer when you find an issue, then meet with them, but set up the meeting using your calendaring system and include in it your agenda which would be the email you would prefer to send. Make sure your manager is invited so he/she knows you are trying to meet with the developer.

    As Grant said, don't back down when confronted by the developers, you were hired to be the DBA for a reason.

  • Oh, I just thought of another one you can do. When you suggest some change to schema or process that will improve up time or performanc and the developers baulk, hand them your pager/cell phone. Tell them "OK, we'll do it your way. You can get the alerts at 3AM. Have fun."

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • I've always been in small shops in more of a Hybrid role where I do DBA and SQL developer tasks, and to be honest have been more of a SQL developer than a DBA. Meaning I have done installs, backups, security, but have not been as diligent in doing more maintenance tasks, like index rebuilds and DBCC checks, and have been more dependent on SQL Server taking care of itself (autoshrink, auto update stats) and being reactive instead of proactive.

    All that being said to say I can relate to both sides of the situation you are in. While you should stand up for yourself and what you believe to be right, try not to be confrontational, and be willing to admit you are wrong if and when you find out you were wrong. As far as writing all the sp's, it sounds like they really want a Hybrid DBA\Developer and you need that clarified. In a small shop I would expect to write some sp's, but, as has been mentioned, you should be educating your developers on how to write them efficiently.

  • Thanks Guys. Grant Fritchey, as you said I told them and you know what they tell about me now? That I'm arrogant. Seriously I don't care what they talk about me or anything. I did talk to my manager clearly. He just want me to take the shit that they throw at me and be good to them. All he is saying is that I'm too young , so I have to adjust. I told him clearly that I care to do my job and if you have an issue with that, then don't expect me to pick up calls at 3:00 AM.

  • You're preaching to the choir now. I have a name plate (made by my boss as a joke/award) that says "The Scary DBA" because I've lifted scalps in the past.

    The thing is, you have to work with people. It's hard. It's never easy. But, the thing is, they have to work with you too. If you can prove through documentation and testing that what you're proposing is right, it just shouldn't be an issue. After all, everyone should have the same goal, deliver the best product you can for the company. Keeping that in mind will help you deal with them better. Maybe reminding them of that will help their attitudes.

    I've been in plenty of places where the DBA's wrote every stored proc. At my current company, we support so many developers on so many projects we can't possibly write all the procs. However, we're still responsible for all the procs, so we document our best practices and standards then hold very regular reviews to catch issues. When we catch something, we don't send emails saying "Your proc stinks, you're a moron." Instead we send an email explaining what when wrong and what kinds of problems it can cause and hey, let me know if you need any help.

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

  • Remember that ultimately your boss is writing your reviews and any future references you might need. If your boss is not supportive when you do what you were hired for, have good documentation to make your case to his boss. Also I would be looking as they really do not want a DBA.

  • Thanks a lot Guys.

  • Considering that they want you to write some procs, you need to understand in a small company you'll tend to wear many hats. When I worked at a company with 35 employees, I did reporting, development, and admin while still managing a mainframe system and I also acted as the backup network administrator. I was happy that they entrusted a lot and variety of projects. I work at a large company now and we are all functionally segregated to where I solely do admin and work with the developers when they need something. Works well, but in your situation, just glean as much experience as you can in that small environment and it'll better prepare you for a future larger environment.

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

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