Re: Conversion of data & associated logic from ISAM to RDB
- From: "Robert Jones" <rjones0@xxxxxxxxxxx>
- Date: 14 Apr 2007 16:43:45 -0700
On Apr 14, 1:46 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Alistair" <alist...@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1176480052.803028.87680@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 13 Apr, 11:58, "Pete Dashwood" <dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
"Alistair" <alist...@xxxxxxxxxxxxxxxxxxxxx> wrote in message
<snip>
So that still
leaves the PM at 300% more incompetent than the Programmer.
Just like someone being 300% more dead than another...
And YES, I was stirring it a bit, but I have noticed a certain
tendency on your part to blame programmers before managers for project
ills and skills shortages.
OK, let's finish this right here, once and for all.
I have been a programmer since 1965. I'm still a programmer. I posted
program code to this very forum yesterday (when was the last time you did,
Alistair?) and I am taking a break from writing more program code (on a
Saturday) to write this response. I intend to be a programmer as long as I
can see and use my fingers.
However, although programming is a passion for me, it is not the only "hat"
I wear. For almost two decades now I have been making a living out of
managing programmers and providing consultancy to corporations. So amongst
my other "hats"... manager, consultant, negotiator, mediator, conflict
resolver, trouble shooter, and project manager.
I am getting a bit tired of certain people here ALWAYS seeing the trouble as
being caused by management so, if I defend that point of view, it is
because of that. I don't like unbalanced assessments.
There ARE bad managers, just as there are crap programmers. Both varieties
make life tiresome for those of us who just want to do a job as well as we
know how, and get some satisfaction from it.
As for blaming either programmers or managers for the ills of a project, I
never do that. I don't blame anyone for anything. Ever.
I see no point in blame (by the same token, I see rehabilitation as
preferable to punishment... guess I'm a pinko Liberal :-)), and every
project or team I manage promotes a blame-free culture. I encourage
personal responsibility and try to see that people have enough empowerment
to exercise their discretion and take responsibility. Someone makes a bad
decision, they learn from it and move on. There can be no growth if all we
ever do is stay comfortable and do as we are told, without thought or
question, then gleefully point the finger at others when things go pear
shaped. (I have fired people for doing this, even though they were
technically "right" and quite convinced they could not be touched because
they had simply done as they were told, knowing full well the consequences
of doing so...). People screw up, they fix it.(Sometimes the rest of the
team help them fix it; I have never abandoned anyone on my team because they
screwed up. I have defended them (even when they were patently wrong,
sometimes) and ensured that whatever was made wrong was made right.). This
applies equally to managers and programmers.
NO-ONE works alone on my watch, including me. I keep the team informed of
what is going on politically and explain what I am doing about it. I listen
to suggestions and considerations and apply them if they make sense....I
work very hard to keep politics and paperwork off their backs so they can do
their job. (Funny thing, I never have trouble getting tech people to work
with me again, once they have done so... can't say the same about certain
managers.)
I've fought battles at senior management level and right through the gamut
of management. I know that Doc's "Corner Office Idiot" (actually, I love
that... :-)) is a reality, and I've dealt with them too. But, and this is
the important point, there are also people in corner offices who are doing
the very best they can. There are people who are the first to arrive and the
last to leave, dedicated company people who put heart and soul into their
jobs and are defined by the work they do. (No, I don't think this is
healthy, but I'm certainly not going to denigrate these people or tar them
with the same brush as COIs.)
When every programmer and staff member in the company is saintly and without
fault, when these perfect superior people are NEVER wrong and ALWAYS right,
THEN, I might agree they have the right to denigrate the people who manage
them (be they idiots or saints). In the meantime, criticism is fine and
natural but it should be fair and true, and preferably from a position of
seeking to improve, not seeking to destroy, humiliate, or belittle, for the
sake of destruction or to boost one's own ego. There is enough negativity
and frustration in everyday work without seizing on the opportunity to
generate more because some COI screwed up again.
All of us every day have to deal with management decisions that are not
perfect, sometimes downright stupid. It goes with the territory. You pick
your battles and win the ones you can; get stupid policies changed, don't
sit back and pontificate on how stupid THEY are and how clever WE are...
In the final analysis, I guess it is this US and THEM perception that really
irritates me. Especially when I can find myself in both camps...:-)
OK, that's all I really want to say on this... back to work. (I'm working
for this really hard *** who sets me impossible goals and makes me work
weekends if I don't achieve them... soon as I can, I'm going to quit working
for him and get a job with some much more understanding management...:-))
Pete.
I agree with you and with Alistair's response, though think that such
issues are often basically a system problem, for exmaple, take the
following items and stir them with a wooden spoon over a hot stove.
Customers always want/buy/can afford/justify to their shareholders
items/services that are the cheapest, most effective and speedily
available.
Employees want as much money as possible for as little effort as
possible in congenial surroundings.
Employers want as much work as possible for as little money as
possible in the cheapest facilities practical.
If you pay peanuts you get monkeys
If a million monkeys spent a thousand years bashing away on
typewriters, one might write the works of Shakespeare (some might say
that one did, only he didn't use a typewriter, I don't know what his
handwriting was like, but I work in the NHS).
Many programmers and probably analysts wrote most of their programs
online with two fingers. Managers paid them to do it like that. I
wrote much of mine like that too.
Employers and employees are often unwilling (can not afford) to invest
time and money in training to use software and equipment to best
advantage.
No one gets a job for life anymore and many didn't anyway.
Employers are mostly in no position to promise a job for life.
Restrictive practices and agreeing to inappropriate contract terms.
The need for employers and employees to protect and invest in
intellectual property and rights while still managing to do their jobs
effectively with several employees and employers.
Most software written on behalf of employers was not reviewed for a
possible conflict with software patents, which were in any case
legally disallowed for much of my career. Certainly not in my
personal experience in a variety of companies and government
organisations. When I have had to specify, write or amend a program
to provide some funtionality, I have never had to check if someone
else from another organisation had done something similar and patented
it, so that my work was in contravention. I can not begin to imagine
how much extra overhead and delay there would be if all organisations
had to make such checks.
Twiddling thumbs furiously.
Some of the programming and design standards I have seen.
Drinking at lunchtime.
Some of the progams and specifications that I have seen.
I have also seen some very well written specifications, programs and
user documentation.
Cultures of working long hours.
Getting a life
Office parties.
Perennial legislative changes necessitating software amendment.
Tax structures.
Political planning generally being subject to general election and
short-term public opinion constraints.
Alternatives to democracy have generally been much worse.
Voter apathy and political skulduggery.
Investing for the future in child and adult education.
That's probably enough of this rant, I am certainly not perfect myself
either. I have just enjoyed a very pleasant ride on my motorbike to
Symonds Yat in Gloucestershire, in fine good and warm weather. I
stopped on the way back to listen to the nightingales in a local
nature reserve.
(I tried posting this earlier but lost my connection, though it said
it was sent, but now can't see it in the list, though it might turn up
later. I have lately taken to saving posts separately while writing
them to protect myself from such problems and this one is very similar
to the other, though I think it is better for having had a little more
time spent on it.)
Robert
.
- Follow-Ups:
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Pete Dashwood
- Re: Conversion of data & associated logic from ISAM to RDB
- References:
- Conversion of data & associated logic from ISAM to RDB
- From: DaveM
- Re: Conversion of data & associated logic from ISAM to RDB
- From: DaveM
- Re: Conversion of data & associated logic from ISAM to RDB
- From:
- Re: Conversion of data & associated logic from ISAM to RDB
- From: DaveM
- Re: Conversion of data & associated logic from ISAM to RDB
- From:
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Pete Dashwood
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Alistair
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Pete Dashwood
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Alistair
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Pete Dashwood
- Conversion of data & associated logic from ISAM to RDB
- Prev by Date: Re: SORT DUPLICATES
- Next by Date: Re: Migrating ISAM to Relational Database
- Previous by thread: Re: Conversion of data & associated logic from ISAM to RDB
- Next by thread: Re: Conversion of data & associated logic from ISAM to RDB
- Index(es):