[atwebb]

To add onto this, being a "developer DBA" can be clutch. OP has a background in application programming and can relate to other groups a lot easier and inherently understand pain points and reasoning behind certain architecture decisions.

[busterarm]

As a young-ish developer mostly interested in database and backend work, what skills/path would you say is necessary to function in a full-fledged DBA role?

I'm finding in my contracting work that my database skills are above-average and usually one of the big things that I'm relied upon for and I think this is worth pursuing.

[atwebb]

Honestly? From what I've seen, the main skill would be, don't go into a DBA role. DBAs are operational/administrative roles by nature (maintain the DB, account/security stuff, respond to server/DB issues). What, I think, you're getting at is more architecture and system building. Having the ability to consider DB bottlenecks and interactions along with a strong foundation in application programming will provide a great base to do interesting work.

Then again, maybe DBAs aren't as bogged down by the minutiae in some places and have more of an ability to troubshoot and resolve DB code/structure problems. It always seems like that's their job but they never have enough time to properly do it with the myriad of other requests.

[busterarm]

Years ago I worked at a financial that had a large tech staff but we only had one full-time DBA. He was a really young, sharp guy and he got to work with basically every department in the company helping them out with stuff. He had his own office, nobody ever disturbed him, he only had to report to one person (rarely) and he got paid fantastically well.

Looked like a sweet deal.

[matwood]

I've been a DBA officially and unofficially off and on my whole career. On one hand it is great. UIs and front end software is like fashion and always changing. What lives on is the data those programs generate. Understanding that the data will outlive almost any program put in front of is a good thing to remember.

On the other hand there is a lot of pressure as the DBA. Backups, redundancy, security, etc... all fall onto the DBA to get done and done right. Fat finger a script and blow away a key table sucks (a DBA isn't a DBA until they have done this once), but it drives the point home that backups, backups, backups are key.

EDIT

The other part is the blame for lots of woes will end up on the DBAs desk. I'm a fix it and move on kind of person, but if you take things like that personally a DBA position might not be for you.

[RefactorCareer]

I've had unofficial DBAs roles in the past, and it wasn't really the type of job that suited me personally (I like UI work as much as db work). I know they're in big demand though, so definitely a good path to look into if you're okay with all of the things listed.

[atwebb]

Yeah, it can also be an always on-call group with limited options supporting software written by dozens/hundreds of different devs with little to no DB knowledge but is crucial to running the company.

[liquidcool]

One thing to explore is reporting. Reporting on large enough data, putting into a data warehouse/star schema, etc., gets you into "business intelligence" territory. That puts you in touch with a lot of managers, providing clear value. Data visualization (dashboards) can be fun, too.

[sliverstorm]

From personal observation, giardini's suggestion to grow a Unix beard might actually be a solid step #1.

[busterarm]

I can't do the beard, but I'm basically an oldschool unix neckbeard anyway.