Dealing with programmers
-
Hi Community,
Dealing with programmers turns to be a difficult challenge, when they ignore his duties, because they do not have time to design a better index strategy, update his code to embrace new functionalities, or learn anything new related to their database management system. It turns to be something frustrating, like tryng to move a rock upon a hill.
Yes, I'm expressing my inner feelings, :angry:, what do you think community.
Best regards
-
Give developers a "play" database with no security. Create a "Development" database where they can only change data while all structural changes must go through you so the team is only down during scheduled updates.
-
What I think is, what is meant by "ignore his duties?"
Are the programmers sitting around playing on their phones all day and just not working? That's a management issue, a disciplinary issue.Do they "not have time to design a better index strategy, update his code to embrace new functionalities..." because they're in a constant fire-fighting mode trying to stomp out bugs in the existing software? Why? Are they being pushed to constantly release new features, change existing features, etc with unreasonable deadlines or insufficient staff? Again, more of a management issue.
As for "...or learn anything new related to their database management system" that comes down in part to personality. Some people simply don't feel the need to expand their knowledge beyond the bare minimum to do their job, or don't want to use any of their own time to learn and feel all learning should be provided by the employer. I've worked with some of the latter (not programmers, more sysadmin types,) there's generally not much you can do to get them to start learning. For them, you can give them a "sandbox" to learn in at work, but you also need to find the time for them to play in that sandbox. Some of them, even then, will not use that time to learn anything new...
-
In a number of places I've worked, the "database developers" have really just been ".Net developers" that also just happen to work on the databases too. In this kind if case, I've always tried to help them understand indexing strategies and even do periodic reviews of existing indexes and poorly performing queries to determine if existing indexes need changed, removed, or new ones added.
- luismarinaray - Friday, April 14, 2017 10:50 AM
What I think is that you need to have the proverbial serious "come to Jesus" meeting with the managers to establish standards and a method of enforcing them. And, my personal opinion, Developers should NOT be designing tables or indexes. That also means that the managers need to get a grip on their schedule expectations.
--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 - Friday, April 14, 2017 7:50 PM
With my DBA hat on I tell the developer (me) that.
And with my developer hat on I just laugh at the DBA.
😛Far away is close at hand in the images of elsewhere.
Anon. - David Burrows - Tuesday, April 18, 2017 2:15 AM
Agreed on both but, with your developer hat on, would you create an NVARCHAR(1) column to store a single digit or would you create a NUMERIC(18,0) to store a value of something between 0 and 255 or would you create all character columns as NVARCHAR(MAX) or even NVARCHAR(4000).
Once you've been a DBA, you can't actually ever forget just because you need to wear your developer hat. 😉
--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 - Wednesday, May 10, 2017 1:07 PM
Never and if I caught myself even thinking it, I would fire myself from the pork chop launcher :Whistling:
Once you've been a DBA, you can't actually ever forget just because you need to wear your developer hat. 😉
Since I'll never be a true DBA I will keep my developer hat on 😛Far away is close at hand in the images of elsewhere.
Anon. - Jeff Moden - Wednesday, May 10, 2017 1:07 PM
Not to be picky, but don't all of your examples fall in the developer arena anyway? After all, correct variable typing is kind of programming 101...
- roger.plowman - Friday, May 12, 2017 12:28 PM
Actually, I stand corrected... And, no... you're not being picky at all. I seems that it doesn't matter what people's titles are, a lot of them miss (or flat out don't know) such important basics and that certainly includes people that tout the label "DBA" after their name.
--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 - Sunday, May 14, 2017 8:49 AM
I'm not sure I fully agree. A "pure" developer wouldn't be discussing data types using the DB terminology for it. If there's an expectation that the devs stay out of the table definition business then there's also expectations that they'd be using terminology based on the language they are developing in such as "string" or "stream" or "array of character". Should they be involved in implementing constraints appropriate to the object they're using? Absolutely, but they would define their own using their own terminology, since data types are the business of the data modeler (which may also be wearing the DBA hat as well.)
This unfortunately involves having to translate "optional" flags into nullable or variable length data types on the data side.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? - Matt Miller (4) - Sunday, May 14, 2017 11:52 AM
I'm thinking that's a major part of the problem. They don't know what they don't know and, yet, their managers (who also don't know what they don't know) think it's ok if the Developer uses tools that create columns as NUMERIC(18,0) for all integers and NVARCHAR(128) or (256) for all character based columns as a default.
I worked "with" a Developer that claimed to be an "expert" and he did this a whole lot. When I asked him why he didn't use correct sizing, he misused Knuth's parable about pre-optimization being the root of all evil. When I asked him when he intended to do the correct sizing and data-typing, his answer was that there was no need since the database was just a place to store data. He was also the first one to claim that the server was slow and that's why his code on his tables was slow. 😉
In other words, Developers (front-end or otherwise) are frequently used as data modelers and, while some are very good at it, I find that's the exception rather than the rule. Unfortunately, I've found the same to be true for many Database Developers and, so called, Data Modelers and DBAs.
A recent example of something that I had to correct was where a fairly good Developer created columns for NPA and NXX (3 digit area code and 3 digit exchange) using NUMERIC(3,0) on what will become a large table. For those that miss the nuance here, the NUMERIC data-type takes 5 bytes for anything from 1 to 9 digits of precision. A SMALLINT easily handles 3 digit numbers and only takes 2 bytes, which is less than half the size both in the Clustered Index and in every Non Clustered Index on either or both of those two columns.
With that, I'll have to disagree with your disagreement and suggest that front-end Developers can no longer be just "pure" Developers anymore than "pure" Systems DBAs can any longer get along without knowing how to use T-SQL.. 😉
--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 - Sunday, May 14, 2017 12:52 PM
Oh - I've seen all of these and more. Tools are tools, and blind adherence to "convenience" will always land you in trouble from a quality perspective.
You still seem to be actively arguing both sides of the coin though, which I was reacting to. As for us - we've allowed certain scrum-based dev teams to model their own tables but it doesn't leave their playground unless it gets blessed: thankfully, by now they've fought and lost the battle enough they don't even complain about the review step anymore 😛 . We haven't been particularly successful in spreading that expertise too far outside of the DB team, so we compensated with a process fix instead.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? - Matt Miller (4) - Sunday, May 14, 2017 7:39 PM
I have to argue both sides of the coin because the coin has two very important sides (3, actually, if you include the edge). 😉 The problem in many shops is that they keep mistaking the two sides of the coin as two coins. The "Us vs Them" (whichever side one happens to take up with) is a very real problem that costs everyone. I'm very fortunate to work in a shop where both sides realize they're part of the same coin (known as "The Company") and work with each other (I started out sitting with the Developers so we could help each other at the drop of a hat an we all sit close to the folks in QA) not only to get the job done but get it done right. What is the right way? IMHO, there's only one answer and that would be code/objects that don't have to come back for rework regardless of reason.
--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)
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply