I'm looking forward to Quest's Guy Harrison coming to present at our Sydney Oracle Meetup in three weeks. It's aimed at developers, but I'm hoping some DBAs turn up too. Otherwise we may have a small audience.
I often find myself in an odd position. I think of myself as a developer, or more precisely an Oracle database developer. I used to be an Oracle developer, but then they got involved in ADF (which I leave to the likes of Chris Muir) and I suspect Java will dominate more in future. The OCP track emphasizes PL/SQL development though I like the thought of the "SQL Expert" exam. I've done Oracle Forms work too, and that is distinct from PL/SQL development too even though it also involves writing PL/SQL.
However I work for a consultancy and am in the "Application Development" space, mostly inhabited by Java and Dot.Net people. They have this perception that anyone who understands a database is a DBA. The concept of a "database developer" is alien to them and somewhat repulsive too, I think.
I'm not a DBA. I've done a couple of roles that involve very basic DBA tasks, like installing a database and creating tablespaces. But I couldn't look someone like Nuno in the eye if I claimed to be a DBA. Pythian employs DBAs. Most of the attendees of the Sydney Oracle Meetup are DBAs. They use OEM and RMAN and Grid things and know about ASM and log shipping, DR and replication. I'm not one of them.
A few weeks back the "Database" proposal for StackExchange got renamed at the last minute (ie after people had committed it) to "DBA". Again, it pushes the concept that anyone who knows anything about databases must be a DBA. Don't get me wrong. Most DBAs do know a lot about databases. It would be nice to say 'all' but as a DBA knows there's a big difference between three nines and five nines and you'd never say 100%. But not every database expert is a DBA.
So I'm a bit concerned about my 'space'. The current TIOBE index has PL/SQL down at number 25 with less than a 0.6% rating. A little over a year ago it was at 0.9% I'm not convinced of the validity of the measurement, but I don't know of a better one. It again suggests a de-emphasis on "database developer" as a role although Transact-SQL had a big jump.
I'm spending some time trying to understand Java. Not specifically the code. I've worked on a few small Java programs and individual programs are relatively easy to understand (or they should be). Its how they all fit together in an application that is tricky. Currently I'm in the phase of wondering why there's so much configuration involved, but that may well be because there is proportionally more config for a small app than a big one.