At the start of my classes and calls, I ask folks to introduce themselves – not by what it says on their email signature, but by the kind of tasks they spend most of their time on. Here’s what I show onscreen to help illustrate it:
Down the left hand side of the screen are the list of things involved with building and hosting a database application. Developers generally start their careers from the top and work down, gradually getting more involved with the database engine. Systems administrators start from the bottom and work up.
Sometimes folks will say, “I do all that stuff.” Yes, of course you know how to do all of that, but pay attention to what it says inside the boxes: which ones do you do daily, versus just every now and then? Like me, sure, I can design a table – but I don’t do that every day.
When you’re a junior jack-of-all-trades in a shop with just a couple/few database servers, you do whatever gets thrown your way. You find yourself jumping around from task to task. You tend to Google everything you’re doing, making sure you’re doing it right, and reading as you go. I used to be the guy responsible for the servers, the desktops, the printers, cobbling together a web app with “Classic” ASP (and I use that term very loosely), and oh yeah, the database server. However, that job role is not database developer, development DBA, nor production DBA. It’s just jack-of-all-trades.
All 3 of those positions – database developer, dev DBA, and prod DBA – can make good money, as evidenced in our annual salary survey. But as you’re thinking about your future career direction and the next job role you want to take, think about which of those duties you love doing the most – the ones you’d want to be doing daily – and that determines where you’ll be the happiest.
A developer monitors performance daily if they’re a worthy developer. Autotrace is good to have enabled for spotting silly execution plans. After the system is tuned and the schema is analyzed, it’s up to the developer to make final query tweaks using hints and whatnot.
A lot of this is going to depend on the environment. When I was a development DBA we had 300+ clients. As a developer I did care about performance but if a particular client’s system started running slow their IT staff was the first stop with our support being the second. Development looked at aggregations across all clients or particular issues that support passed along.
I reference this chart frequently. And just had an occasion to reference it again today.
It occurs to me that the skills listed for Developer / Development DBA thrive with any migration of an existing product to a managed cloud offering.
(personally I’m fortunate that’s true)
Thanks, glad you like it!
I made the conscious choice to specialize in the dev DBA role when I saw the writing on the wall for managed cloud offerings (plus I got sick and tired of fixing Availability Groups.) The Dev & Dev DBA roles even become more valuable in managed cloud offerings!
I’m had to generalize again when I was contracting, but I’m moving back to Dev DBA now I’m salaried again. I just enjoy it more.