At the beginning of February, I gave a pre-con at SQL Saturday #357 in Cleveland, entitled, “50 Things All SQL Server Developers Need to Know.” I had a lot of fun putting the content together, and I learned a lot through the process. I had only ever given one pre-con before, on a similar topic, but I co-presented that one and didn’t even touch the computer until well into the day. This time, it was all mine, for better or worse.
I’ll start out by saying that I did have a great day. There were a lot of fantastic questions, which sparked some interesting conversations, and at any point during the day I felt the audience (29, all told) was as involved in the seminar as I would expect anyone to be involved in any 8-hour seminar. I got some really great feedback, too. However, I did have a few people who shared that I may have oversold “developer” in the title.
While it’s true, I did lay down a lot of seemingly DBA-ish fundamentals in the morning, and I did spend more time on those topics than I intended, the balance of material (not time) was very much intentional. I’ve been working with SQL Server for a long time and one of the primary factors that lead to inefficiencies in SQL Server is a reluctance to embrace those DBA fundamentals. One comment was actually, verbatim, “I don’t need to know any of that DBA stuff.”
For anyone with kids, or has for other reasons seen Monsters University, there is an important line that may strike a chord here: Sulley justified not studying because, “I don’t need to know any of that stuff to scare.” The whole moral of the story, at least how I took it, was that scaring kids was not just about growling and baring teeth.
In the SQL Server world, the same kind of thing is true: not every database problem is solved the same way you would solve it in a scripting language or in object-oriented programming. Sometimes the knowledge of fundamentals like indexes, statistics, locking, the plan cache, and how SQL Server uses memory can be very helpful in writing the most efficient stored procedure or recognizing why a query is having performance issues.
Here were the top-level agenda items:
- Core Components
- Query Processing
- Waits and Locking
- Indexes and Partitioning
- Statistics and Cardinality
- Metadata Analysis of SQL Queries
- Influencing Query Processing
- Patterns and Anti-Patterns
- Simulating Production
- Recovery & Backups 101
- Optimizing tempdb
Almost all of those sections dealt with the developer side of things, or at least covered the concept so that developer content later would have some context. One that is obviously more DBA-centric was one I placed toward the end of the day: Recovery & Backups 101. This was a whopping three slides, and was included only because so many developers set up their databases locally in full recovery and then panic when the log file fills their C:\ drive. So while admittedly a slide or two here and there were not strictly developer-oriented, they were all put into the deck with the developer in mind.
In a post-event conversation, one attendee confirmed that even the DBA-centric material was interesting and useful, but felt it was wasteful for him specifically, because he has no control over the DBA aspects of his environment. My arguments against this line of thinking:
- You may not have control over any of those aspects now, but what about tomorrow, next week, next month? You could become the new DBA when the current person in that role wins the lottery, gets hired by Microsoft, or switches to Oracle. The company’s policies on who can make decisions about hardware, database design, etc. could change. You could – gasp – take a better opportunity, at your current employer or elsewhere, with more responsibility that doesn’t quite fit inside the same silo you have now.
- Even if you can’t directly control some of the variables in the DBA realm, having the background can go a long way in both fostering communication where you can at least influence change, and earning the trust of the DBAs (demonstrating an attempt to understand their domain).
- Even if you *never* get any control (the company’s policies don’t change, and you stay in that role until you retire), that knowledge can be used as ammunition any time you are trying to sway the company or the DBAs on a decision, or even to help you better understand why they made a certain decision.
I’m trying to be better about understanding the developer’s plight, too. I’m not getting very far yet, but I have been much more open than I used to be about having conversations involving ORMs, EF, nHibernate, and the like. Having dealt with some short-lived implementations and some much longer-running repair engagements, I still have some serious doubts about whether they make you any more productive in the long run, but the passion people have for them makes me believe that there is more to them than I understand at the moment. I’ve also long been helping folks on Stack Exchange, my blog, and elsewhere to solve query problems that /deep down/ I don’t think should ever be solved by SQL Server – things like splitting comma-separated strings, sending e-mail from a trigger, or using a cursor to process orders. I try to understand the developer’s approach to a problem and discuss it with them; in a previous life, I would just obliterate it and re-write it myself.
I’m going way off-topic here, at least in terms of the message I wanted to get across. Generally, more knowledge is never useless, unless you gained it at the cost of something much more detrimental. I can’t think of a single book I’ve ever read that I regret having done so – even if I don’t use any of that knowledge regularly. I have an Economics degree that I don’t use at all, but I am glad that I spent four years earning it. In the whole developer vs. DBA sphere, I think both sides tend to look across at the other and deem them to be a black box, and I do believe a better employee tries to see the other side’s perspective. In fact I shouldn’t even label that as “developer vs. DBA” – it’s often portrayed as this epic battle that shouldn’t really exist, when really it’s just that our different backgrounds shape our opinions against each other. Obviously you’re both working together to produce something, and the more you understand about each other’s craft, the better.
