> ACT I: SHOULD'VE SHOT MYSELF THEN
Identifying characteristics of a programmer: Flat forehead,
from banging head against wall and smacking self in head.
I am a contract software engineer by trade. This is familiar
territory for me.
> one of the endemic problems with this job is that my bosses want quick
> wins for free. perhaps the most important lesson i've learned in the
> last eight months has been that you never show a marketer a piece of
> software that works unless you're willing to put it into production
> immediately.
Not necessarily so. day-glow blinking orange text on screen should
read DEMO-ONLY, NOT FUNCTIONAL, NOT FOR RELEASE or some other collection
of statements to the effect that this will self destruct in fifteen to
thirty seconds. Add obvious bugs, block needed functions with "NOT
AVAILABLE / NOT COMPLETE". Use of 2+2=5 errors is too subtle.
> the contractor is a pleasant and charming young Indian woman named
> Anitha, who's about seven months pregnant. we hired her through a
> local agency rather suddenly, because at the time, following a series
> of domino-effect system failures, my VP was very hot to add staff.
WARNING: Pregnancy is a high priority schedule. It can not be
pre-empted by deadlines, corporate mergers, or edicts from the president
of the corporation or the United States of America. Substantial risk
exists of personal re-prioritization after pregnancy terminates.
Historical precedents may be found dating back to neolithic times. Animal
models of such events also exist. Any manager engaging a pregnant woman
for critical path assignments without regard to pregnancy schedule is a
totally ignorant and inconsiderate boob with an IQ of a sub-moron!
Civilization, Humanity itself, depends upon pregnancy being least
inconvenient. Hence, a pregnant lady engaged in a path critical task
should have an understudy at the very least. Repeat: Pregnancy is the
Highest Priority Schedule! (Chant after me...)
That said, we must not discriminate beyond the obvious. Women who
have more money and proven intellectual capacity, tend to have brighter
children who may then further improve our society. Hence, we should not
unduly deprive them or make them feel unwelcome. Happy pregnant women are
sometimes associated with increased maternal and paternal instincts that
may mute some turf wars, etc. and provide employees with improved morale,
hope, sense of what life is REALLY all about, etc. (This may, however,
not be what some demented bosses want...)
> not wanting to miss the window of potential spending authority, my
> immediate boss brought Anitha in on a semi-permanent arrangement.
> her objective is to create a stable version of the two prototypes
> which can be rolled out to all the other newspapers in the company.
"Semi-Permanent"... what is the time frame? Plan for two months
leave, consider part time telecommuting as an option. Mother-infant bond
is more valuable to the society in the long run than your product.
> i accept my share of the responsibility for not staying on top of what
> Anitha was doing, but in extenuation, there are half a dozen other
> projects which i'm supposed to be mentoring, not to mention the code
> of my own -- which the elves and faeries have so far steadfastly refused
> to write overnight. i let Anitha choose her own direction as a way of
> letting her get familiar with the existing code, and the product
> requirements.
Management Error: direct-line supervisor over-tasked.
Safe Option: blame contractor when task fails. (Do not use too
often.)
I have been in Anitha's position several times, not getting enough
information to even figure out what to start working on, and not being
able to see direct line manager to determine this! Heck, I have been
given masses of code where NO ONE knows which end is up. Sometimes I
manage to pull it off, sometimes I got thrown out the door, politely.
Rarely is it possible to know a priori that management is critically
over-tasked.
Probable best course: Raise a stink that you are not given enough
information. Write memos to direct line supervisor stating that you
believe you should work on item XYZ because of A, B, and C; PLEASE inform
me if you do not consider this the optimal course. Make it clear.
If boss mumbles, write him a memo detailing his mumbles, and asking if
this represents a formal change in course, etc. You are seeking clarity.
If boss is unclear, go to second line and state that your direct boss
appears to be OVER-TASKED, has not enough TIME (not incompetent or
unclear,) and you need clear direction on how to proceed. (I should have
done this several times...)
When nothing is clear, I just simply state in a memo that I have
completed what could be done, and rather than waste your money sitting
doing nothing, I am going home. I will call you tomorrow to see if you
have something specific and valuable for me to do. If you do not have
something specific on this project, perhaps I can be of service on another
project while you resolve this one. If you do not have something clear
for me to do, I will consider other work options. (I have done this at
times. I have not been fired over it yet; even though I expected it. It
has always cleared the air to the extent that the air could be cleared.
Which is to say, sometimes not at all; but often adequately. I often
state I have other part-time options available, so that scheduled part
time work is a viable option.)
By the time you entered the door, a significant amount of human
capital and time has been invested in the selection and tasking process.
You are one of the most valuable resources that has been brought in,
probably earning more than your bosses boss. In most cases, your
statement that you can not determine what has to be done will be met as an
important red flag warning that a project is in trouble. Sometimes, that
is the most valuable function you can render to them.
This philosophy is, however, contrary to my first mentor's statement
that if it is their problem, you may sit waiting for instructions, and
they owe you a minimum of eight hours billing. That may well be. However,
if they do not task you with something doable, you can not be judged as
competent, and will be dismissed sooner or later. Better clear the air.
Remember, fear is the mind killer. If you fear you will be fired, your
performance will almost invariably decline to the point where you should
be fired. So either clear the air, or quit.
On the other hand, if you can find other valuable work that may
reflect favorably upon you, do not hesitate to embark upon it while you
wait for clarification of your status. Suggest it if you can, but do not
hesitate to use your own initiative if you can justify the benefits of
doing B instead of A. I kind of joke that I often do not do what I am
asked to do, but that my clients are very satisfied with what I have done.
That is in part because I seek out things to do, and tend to create more
generally applicable solutions than those I am tasked to create. And
quite often, that alternate task is what I get the credit for. Often, that
alternate task is laying there because it is too important to write off,
and too difficult (so they think,) for their regular people to handle.
> that resulted in a major, but necessary, change of direction. Anitha
> started to re-examine the code to see which, if either, prototype
> could be expanded to suit everyone's needs. i mentally wrote off a
> couple more hours each day to checking her progress and reinforcing
> the things i consider positive.
>
> then my boss found out about it.
>
> he's a nice guy, and in his defense, he's not trying to make my life
> as much of a screaming hell as he is, but he doesn't have any
> background in technology development. he knows he's supposed to be
> in control of the department, but doesn't exactly know how to do that.
> when i can keep him happy enough to stay out the way and let me run
> the development wing, things are fine. unfortunately, this issue made
> enough noise that he felt he had to make his presence felt. the
> result was roughly like a senior administrator of a hospital going
> into the operating room to "take charge".
Brook's Law: Adding people to a project that is late will make it
even later.
(Brooks: "The Mythical Man Month." An absolute must read for managers.
I give it as a gift to managers who's projects have screwed up.)
> technically, as director of the department, he has the right to tell
> people what to do and where to go, and the higher the mileage and body
> count, the better. he brought John, the guy who wrote the original
> product description, into the office from 300 miles away, then
> declared that there would be a conference call with the other coder,
> in Montana, to get everything squared away.
>
> the hidden agenda for the exercise was to make the guy in Montana
> accept the blame for writing a piece of code which couldn't be
> expanded indefinitely. that got nowhere.. he's had far too much
> experience dealing with the principles to accept that kind of loss of
> face, and i didn't have the stomach to really grill him. we all
> repeated our default positions, got nothing whatsoever accomplished,
> and went away unsatisfied.
Right. Though you may have helped educate your manager.
> i feel like i've abandoned her. at very least, i haven't
> communicated what i want well enough or clearly enough, yet.. she's
> not excited about what she's doing, and that's my fault. i'm the
> only one in the company with both the information and the authority to
> give her a job she's enthusiastic about, and if she doesn't have that,
> i've failed as her project leader.
A sense of excitement is not necessary. What is necessary, is a
string of small victories. I always try to end the day with some small
victory, some small feeling that I got this or that done and done well.
With that kind of small victory, I have kept people working for years on a
part time project without paying them... It was a start-up, and pancaked
about 3/4 down the runway... but we had our fun, and all remained on
friendly terms after the wreak.
Not all projects work out. Not all people try to do things they are
good at. If you succeed too often, you are not trying big enough tasks.
We must continue to learn, and to work at keeping our icons well
delineated on the mental screens of those using our functions. That
includes figuratively blinking our icons when we know our functions should
be used for the task at hand, even though we may not have been brought in
for it.
[EMAIL PROTECTED] ------------------ [EMAIL PROTECTED]
----------------------- IMAGINEERING --------------------------
----------------- Every mouse click, a Vote -------------------
---------- Do they vote For, or Against your pages? -----------
----- What people want: http://www.mall-net.com/se_report/ ----
---------------------------------------------------------------
--- Have you analyzed your viewer's footprints in the logs? ---
--- Webmaster's Resources: http://www.mall-net.com/webcons/ ---
--- Web Imagineering -- Architecture to Programming CGI-BIN ---
---------------------------------------------------------------
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
