I read a lot of SQL blogs, both new and old. What’s striking is how many blogs seem to cover the same subjects from different angles, over and over again.
This isn’t to knock anyone’s blogging at all — but what I do want to do is try to proffer an explanation as to why this happens.
Many SQL bloggers are consultants. That means we work with (hopefully) many clients, and end up seeing the same very basic problems over and over again.
For FTEs who blog, this can still happen. They may be overseeing developers who often forget lessons learned.
Of course, some FTEs get to deal with lots of very specific, or brand new problems, and have some leisure and luxury to really explore them.
Michael talks a lot about matters of concurrency and blocking. Joe talks a lot about column store, and optimizer issues.
What’s With Developers?
When new developers start, they often
- Have minimal SQL Server experience
- Have bad SQL Server experience
- Have never had SQL Server training
That means that existing code is the standard they look to when they’re writing new code. Any bad habits you’ve got in there become part of your code’s culture, and people will repeat them.
I LEARNED IT FROM WATCHING YOU
If you’ve got any code smells, you can bet that developers will pick up on them for all the wrong reasons.
Functions, non-SARGable queries, poorly written dynamic SQL, bad hints, local variables, table variables — you name it.
That doesn’t rule out finding some bad or old advice out there on the internet, though. There’s plenty of that to go around.
Good DBAs often get called Bad Names
They need to enforce standards that make life difficult for other people, who are often developers.
Stuff that’s easy or convenient for devs is often quite difficult and inconvenient for SQL Server
- No, you can’t use that function
- No, you can’t add a 50 column index
- No, you can’t just join on LEFT(REPLACE(REPLACE(SUBSTRING(CASE WHEN…
For every story you hear about a grumpy DBA, you’ve probably got a person who has been fixing the same type of problems for many years.
By the time developers listen to them, they’re off to a new job. Now grumpy DBA has to start over with whomever replaces them.
Low Standards, No Standards, Bad Standards
Defeating bad coding culture needs a two-pronged approach
- Fix old code so that bad ideas don’t get enshrined as “the way its done”
- Review new code for relapses into bad practices
Another worthwhile approach is to get developers appropriate training or resources, so that they can recognize bad patterns on their own.
Often, that kind of empowerment is more productive than having them report all their code to a figurehead for review.
Thanks for reading!
Brent says: when I was getting started, I repeated a lot of bad practices when I was handed code to start with. “Here, always start with this stored procedure template, it’s what we’ve been using for years.” It was just the default, and no one ever questioned why – me included.