Re: Software Engineering/Database Administrator

Gump wrote:
> Hi JJack
>
> Good question. Extremely subjective, but good question. Note you're
> likely to end up more confused asking a question like this. Anyway,
> here's my two cents worth (keep the change)...
>
> Fact: There will always be software engineering roles and there will
> always be database administrator roles.
>
> Don't let anyone convince you otherwise. People will tell you
database
> administration is becoming more and more automated meaning the role
of
> the DBA is becoming obsolete. This statement does not hold true and
> probably never will. Think about it... the database engine is built
by
> software engineers. Are you going to tell me that they're finally
> going to get it right and produce the first ever perfect automated
> system? I sincerely doubt it.

I agree with you except: the Oracle marketing and general HR population think otherwise. This is one of those perceptual things, meaning even though the role exists and will probably expand and marketing and HR people are wrong, the work that happens to be titled DBA is being spread around to jobs with other titles. This would be a trivial distinction except for the context of being a DBA as a major.

>
> Fact: There will always be a greater number of software engineer
roles
> available on the market compared to DBA roles.
>
> That's an obvious one. In a development environment for any single
> database being managed by say a few DBAs there will always be at
least
> a handful of developers, probably more.
>
> Some people favour this ratio and choose a software engineering
career
> based on this fact. But there's two ways to look at this. With less
> DBAs around there is less competition. If demand for DBAs rises
> (supply and demand rises and falls in all markets worldwide) you
> suddenly find yourself in a rather attractive negotiating position.
> Take a look at the market next time an Oracle Database desupport date
> rolls around. "Where are the DBAs? We need to upgrade!!!"

The thing is, they are not looking for new DBA's (and perhaps not old ones, either :-O ). I personally benefit greatly from obsolescence (limited supply does work!), but would not advise someone new to explictly go that route. However, such upgrades need bodies and such situations can be a great way for a newbie to get into the musical chairs of the profession, if such a situation presents itself. ie, get hired for the gruntwork and position for upward mobility.

>
>
> Fact: A good DBA is typically paid more than a developer.
>
> Some will argue this is crap. And they will probably back it up with
> hundreds of examples. But on average a DBA will be paid more. Think
> about it, the database is the core component of an organisation's
> systems. If it goes down the organisation can and will lose money,
> fast. When a developer stuffs up it's most often classed as a "bug"
> and logged in a system somewhere to be looked at sometime.
> Organisations have a heavy reliance on good DBAs to keep their
systems
> up and running. Developers do not typically have this same level of
> responsibility which in turn means they don't have the same
negotiating
> power when it comes to salaries. Responsibility = Money.

This is how it should be, but is lessening. More as a result of management fads than any real logical reason.

>
> Fact: DBAs are often required to clean up the mess made by
developers.
>
> The application is performing badly - who gets the blame? The DBA.
> "There must be something wrong with the database!" More often than
not
> you will find the cause to be poorly written application code. The
DBA
> has to identify this code and often come up with the solution to fix
> it. This means the DBA often requires and has programming
experience.
> Don't think if you become a DBA that you will never code. I promise
> you will. Whether it be simply fixing up developers' coding errors,
> writing scripts, creating reports, building small management apps,
> there will be many opportunities to develop code as a DBA. Often the
> DBA will have an influential role in a team of developers providing
> guidance and assistance to develop optimised code. I have seen too
> many cases where the inclusion of a good DBA in early product
> development could have saved an application.

Ah, so you also see what we all see that management doesn't: Project leaders develop without DBA input, and that is a bad thing. Worse, few learn from the error.

>
> Fact: A career spans many many years.
>
> So long in fact that you could spend 20 years being a developer and
> then the next 20 being a DBA. Don't worry yourself over which one is
> right choice for now. If you start with one you can always switch to
> the other. Do what you think you will enjoy the most right now.
Find
> out what motivates you and then see which fits the best.
>
> I personally think a development role is suited better to your more
> "creative" type of person, whereas DBAs are required to be much more
> structured and organised - it is their job to make sure everything is
> in line, running smoothly. This may sound uninteresting but as a DBA
> you have a BIG responsibility. You are often the person designing
and
> managing things like disaster recovery plans for an large
> organisation's systems. You will diagnose and solve complex
> performance issues. You will implement security and auditing
features.
> The list goes on.
>
> If you haven't worked it out yet I am a DBA and I think it is a very
> rewarding career, for the right person.
>
> Good luck in your choice. Don't lose sleep over it though. I
started
> as a developer!
>
> Paul

I think your post is one of the best I've seen on the subject, my quibbles are minor, "in 20 years it won't mean a thing" as my dad used to say... 40 years ago.

jg

--
@home.com is bogus.
http://www.hp.com/hpinfo/execteam/fiorina/index.html (the day before
this hit the media, I had jokingly said "well, we should get Carly in
here" as someone was complaining about a ridiculous procedure for
updating some hp firmware.)