[ruby-talk:23398] Re: Bruce Eckel's opinion of Ruby

On Thursday 25 October 2001 17:44, you wrote:
> On Fri, 26 Oct 2001, Eric Lee Green wrote:
> > On Thursday 25 October 2001 10:44, you wrote:
> > > Eric Lee Green <[e-mail]> writes:
> > > > Yeah, sometimes you must cope with people who are, uhm, less than
> > > > stellar, in order to get a product out. You assign them to all the
> > > > simple drudge tasks that even a moron should be able to do, and cross
> > > > your fingers that they won't screw it up, because it can take 6
> > > > months to get a good replacement (as vs yet another less-than-stellar
> > > > person) on board.
> > >
> > > And then you wonder why they aren't stellar...
> >
> > So I have no problem with anybody who has initiative and skills doing
> > anything on the task list (which, BTW, is publically posted and anybody
> > can choose any task off of it -- if they dare). But if you assign a
> > difficult task to a person and it turns out that you spend more of your
> > time helping this person do the task than it would have taken to do it
> > yourself, the conclusion as to what this person's NEXT task will be is
> > clear: something simpler. Sh*t needs to get done, and needs to be done in
> > a timely manner, and if he can't do it, he can't do it.
> >
> > This may make me sound like a jerk, but it's just business. We have
> > product to get out the door, and if a person is incapable of the
> > initiative or lacks the background to learn what he needs to know in
> > order to accomplish complex tasks 

> Considering this message arrived thrice, I wonder if you should be
> assigned simpler email tasks in the future.
>
> :)

My apology for the multiple post. I am in the process of moving and my 
outgoing mail server was set wrong, compounded by a bug in my mailer (kmail) 
when dealing with inability to contact mail server (it queues up another 
copy).

>
> Your points are all perfectly valid, but your terms are wrong.
> Let me summarize your calculations here:
> If time of 'one time cost of training employee + employee writing code' is
> greater than the time for Mr. Green to write the same code <i>once</i>,
> than the employee is "less than stellar" and should be fired and replaced.
> To put it another way, an employee is not up to par if he/she cannot,
> without any training in the local technology choices, documentation, and
> coding styles, accomplish a task *faster* than an engineer experienced in
> the local variances.

Uhm, no. The question is not how long it takes the employee to do the task, 
just that it gets done, and it gets done without significant inputs of MY 
time. I understand that most programmers are not as fast as I am. The point 
is that things are getting done that I don't have time to do myself. I may be 
good, but my fingers can fly only so fast. As long as the task is not in a 
critical path (and we hash that out in our design meetings when we add tasks 
to the GANTT chart, and in progress meetings where we decide who does what 
next via a consensus process that tends to put the fastest programmer onto 
the critical path nodes so that they no longer are so critical), it doesn't 
matter whether he takes two hours (which I'd take), or two weeks (which 
someone new to the language and the system might take) to do the task, it's 
still a task I don't have to do myself.  

As far as training in local technology choices, documentation, coding styles, 
etc., I'm a former teacher for cryin' out loud. Remember the first three 
letters of the word "assumption"? You just made a *LOT* of those.

The issue is that there are programmers who, regardless of training, lack the 
initiative and gumption to do complex tasks on their own without significant 
inputs from myself or my team members. 

> This is not teamwork, this is subcontracting.  You are not building a
> team, you are seeking a person with a perfect skill match to do something
> specific and go away. 

Oh poop, "ASSumption". I once recommended hiring a guy to write Python code 
who had never seen a line of Python code in his life because I could see that 
he had the right "mindset" and wide enough experience in other areas to do 
the job. He later went on to write the entire web interface for our product 
single-handedly -- in Python. My philosophy is that anybody can learn a 
language or a technology, but you can't teach mindset. Or as Coach John 
Wooden is alleged to have said about basketball, "you can't teach height" -- 
i.e., you can teach skills, but you can't teach physical makeup (or, in my 
experience, mental makeup). I can't turn an unimaginative person with no 
initiative into a dynamic contributor to a project team. Remember that task 
list? My ideal team member is someone who *ADDS* things to that task list, 
not someone that I have to assign tasks to. 

> A well built team requires time and energy to bring
> people to a union of minds, and has benefits above and beyond their line
> count for a one-off application.

Obviously. 

> And as I have no ending, I will make a little bow, and head to the pub.

Please do not spend too much time there, alcohol does not contribute to 
clarity of thought.

-- 
Eric Lee Green          GnuPG public key at http://badtux.org/eric/eric.gpg
           mailto:[e-mail]  Web: http://www.badtux.org
             You do not save freedom by destroying freedom