> if that type of prject fell into my lap, I'd do my best
> to work at it so they wouldn't have to hire
> someone else, except to do my old job.

That attitude would doom you in my office.
The 1st thing we do with programmers who embed
themselves into a project is pair them off with
another, do a knowledge transfer, and fire them.

There is no project that is a lifetime deal.
Every project needs to be coded in such a fashion
that ongoing activity is handled by a customer
support person.

This is at least a 7 person project:

Executive face to the client - major bigwigs - 10%

Project manager / business analyst, Full time for
6 months, 30% after that.

DBA - initial 50% for 2 months, 5% from then on.
But since we also need a DBA in general, this
is a "global" position across many projects.

PL/SQL coder - initially 100% for 2-4 months,
then maybe 10%. They better be useful elsewhere,
or they get layed off. Or we just use a consultant
to start off with. And I really don't like PL/SQL,
but of we 'save' the current code, we are stuck with
it. If I do it from scratch, the PL/SQL would be a
very small part of the project.

Perl / Unix systems person. Initial file setups,
automations, out of database processing. Me.
75% for 2 months, then 5% if that.

Technical Coordinator, QC, production. Full time.

When the project goes in production, the only
full time person would be the TC.

And then we redeploy the others.

Anybody who plays 'tick' gets fired.

Anybody who doesn't understand table driven
logic gets fired.

Projects (from the coder's point of view) have
a finite lifespan. People who can can do
what I need them to do are far too valuable
to waste on a single project. They
cost way too much, and can provide far more
value, by assigning them to the next project.

The size of the systems I work in require
100% of the coder's attention at first,
for several months. There is NO concept
of juggling multiple tasks such as these
at the same time. The database is 1/2 billion
records. And an update can take 2 days or 3
months, depending on the skill of the coder.

And the 2 days coder would NOT be layed off, but
the 3 month one should be fired by the 2nd week.

And at least 3 people work as a team, closely.
The business analyst, the coder, and the production
person have a goal of getting the business rules
right, coding, and handing off to production.

And there should be NO lead coder. The business
analyst needs to be comfortable the task can be
handled by at least 1 other person. If not,
it is specced poorly, or requires too much on
the coder side, or the hardware is wrong.

We have at least 2 other people in my company
who are better coders than me (and I'm f'ing
GOOD!), and I hope to bring a couple more along
within the next year or 2. I just hired a
brilliant 'kid' as a sysadmin, and we did
NOT skimp on pay, even though we could since
he is young. Any of these people could do
my job, given a bit of time to learn the
specific project. I just dropped the one
I spent the last 6 months on in someone else's
lap, to pick up the new one. And this makes
ALL of us more valuable.

The core knowledge gained doing these types
of projects is very valuable, it is called
institutional knowledge. A SINGLE person
can never be allowed to hold the company
hostage based on that. But when multiple
people know this, they can form a strong
project team for more money making projects,
since assigning people without this experience
is a horrible crapshoot, leading to project
failures and lawsuits.

From a personal career objective, if you
can't be fired you can't be promoted. And
in my case promotion does not mean to
management slime.

Not sure if you were talking about me or Norm though.

I've seen people attempt to update huge data sets
in simple SQL updates, watch it fail after 3 days,
allocate more rollback space, watch it fail in a week,
etc.

The next step is to realize how to do it in PL/SQL,
as opposed to SQL, but then you get into other issues,
which could allow a single update to go for weeks.

Then you realize how to partition and parallelize your
logic, focus your efforts, tune your SQL to not use any
tmp space, balance your commits, allocate more memory for
the particular transaction, etc, etc, etc, and you are
down to 2 days.

While the idiot is still adding rollback segments,
and blaming the hardware or the database, and asking to
triple the budget because the machine is too "small".

And then, someone says: But that is not an idiot, that
is someone merely not trained in that environment. He
is a smart, well valued person, who merely needs a little
time to get up to speed.

No. Unacceptable. That is why we pay trainees dirt and
experienced people gold. And a trainee sucks down an
experienced person's time, which means they should be
paying us for the priviledge. Go pay Oracle $100,000
and spend 2 years on their equipment. That is why some
careers have internships that treat the trainees like
slaves, and for good reason.

Your value is based on your value. Not some fuzzy
measurement of how you will be in a year, it is how much
value you have right now. What do you bring to the table,
what projects can you pull off right now, and how is it
related to MY industry?!?! Not the industry you came
from.

And no, again, knowledge in one product may or may NOT
translate to another. I've seen some people here "council"
the approach that one database is just like another, and that
potential employers should allow for that in their
hiring decisions.

This is ONLY true is you take a lowest common denominator
approach in your usage of it. Which makes sense for
portable coding, but SUCKS for project specific performance
issues, which can KILL a project and close the company.

And no again, to if someone knows 8 languages, they will
pick up a ninth without a problem. Bullshit. If you know
8 Latin based languages, what the hell makes you think you
will pick up Chinese?

Procedural assembler VS procedural BASIC VS COBOL
VS Perl VS OO Perl VS C VS C++ VS Scheme VS LISP
VS Java VS Java Script VS Bourne Shell VS C Shell VS
TCL VS VB 3/4/5/6 VS C # VS every goddamn library
in the world VS SQL VS PL/SQL VS Transact SQL VS
PostgreSQL SQL VS MySQL VS OLTP VS ODS VS Data
warehouse VS JCL VS PL/1 VSMVS VS Unix VS Linux
VS VMS VX Solaris VS M$ WinX VS Apple VS AIX VS
HPUX VS OS/390 VS (I think you get the point).

You may THINK you really know about 1/10 of the above list,
and knowing that 1/10 will dramatically influence how
to go about dealing with the other 9/10s. Make a
career bet, and always take responsibility for
maintaining a forward focus on the next career. It
will NOT stay the same in 10 years.

We sell "solutions", not technology.

We are primarily a print company, ie: junk mail.
Also, statement printing. BIG PRINTERS.
LOTS OF THEM. Football fields worth.

That is 90% of the business.

Then we have the merge/purge / data warehousing
side, the "boutique". Print customers want us
to handle their dirty data, which then feeds
more print jobs.

So we choose the appropriate technology to
do the job, not the other way around.

If THEY chose, it would be on a time and materials
basis, with no end point in sight.

If I was in your position, I would attempt to
price the 1st project in new technology so
I could afford to hire the expert, and do
joint work to enable knowledge transfer. But
you might actually price it much lower, to get
the business in a new area, which then adds to
your corp experience, which can then bid on a wider
variety of projects.

Nonononononono.

I love my Perl.
I like my fake OO Perl.
I love my SQL.
I accept PL/SQL.
I like Java.

I despise Bryce.

I mean that where ever possible, rules should be
abstracted to simple files or tables that drive
the logic, which then allows non-coders adapt
the behaviour of the code based on these driver
tables.

And this seems to be a rare coding trait, which
I encourage in my co-workers.

Or beat into, as needed.