> If you can explain accurately how to optimally structure SQL queries, you can probably write database code yourself.
Yes, probably. That doesn't mean your role on the project, in the company, or in your job description isn't "Database Administrator." Or operations engineer or reliability engineer or whatever fancy name you want to call the fact that you are more responsible for running the system than building it.
A more realistic example, though, is that a DBA and developer collaborate; the DBA collects and analyzes data from the production system and shares this information along with recommendations to the developer, who is ultimately responsible for restructuring the query.
In a very small team there's probably no need for these roles to be divided.
Sure, but I think that in this case the difference between your view of an operations engineer and a developer are fairly minimal in terms of skill. They're both development roles.
When I was interning at Google I noticed that these roles were differentiated as SRE and SWE. I didn't notice a lot of competency difference, just different application areas of the same competence. I think many SREs and SWEs could probably switch roles successfully.
That's more or less the point. System administration vs. software development is as much about priorities, mindset, and day to day environment than technical competence. This is true at all levels, whether you are pushing boundaries Google or supporting internal corporate users.
I never had a google internship or anything similar, and my first technical job out of college involved supporting an internally developed, browser-based ActiveX/.asp/vbscript tool for viewing and annotating loan documents. For a long time we on the systems team were unable to upgrade IE on user workstations because of a critical, easily reproducible bug in the document viewer tool. Eventually, I managed to get access to a snapshot of their codebase and tracked down the bug in a few hours (despite never having written a line of .asp or vbscript in my life and not having access to any of the documentation for the 3rd party libraries and activex components). The devs, of course, didn't listen to me anyway, despite my basically handing a solution to them. The bug remained for another year until that section of code was incidentally re-written to support some other feature.
The next company I worked for, a web company, had a much better relationship between development and operations. It might have helped that we had a lot of Indian developers, who didn't seem to have the same prejudices that western devs do: that system administrators are people who just aren't skilled enough to do development.
Yes, probably. That doesn't mean your role on the project, in the company, or in your job description isn't "Database Administrator." Or operations engineer or reliability engineer or whatever fancy name you want to call the fact that you are more responsible for running the system than building it.
A more realistic example, though, is that a DBA and developer collaborate; the DBA collects and analyzes data from the production system and shares this information along with recommendations to the developer, who is ultimately responsible for restructuring the query.
In a very small team there's probably no need for these roles to be divided.