From: Todd Gillespie <toddg@...>
Date: 2001-10-27T00:26:33+09:00
Subject: [ruby-talk:23466] Re: Bruce Eckel's opinion of Ruby

On Fri, 26 Oct 2001, Eric Lee Green wrote:

> On Thursday 25 October 2001 17:44, you wrote:
> > 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.  

Let me quote your previous message:
"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."

So despite back-pedaling, I read this as evidence that you consider time
investment in help and training as only affecting the local project,
instead of amoritizing that cost across an employee's lengthy tenure.
It is this time-budgeting distinction that makes your 'team' most resemble
contracting rather than full-time employment.  Nothing wrong with that.

> 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.

All I see from you is a strong desire to avoid teaching.  If you have
formerly held the job title of 'teacher', hey, great.

> 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. 

Of course there are.  But I think that you are ardently opposed 
to recognizing the distinction between them and someone who can be a
valuable addition with training.

> > 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.

Cute.  Do you use ad hominum attacks in the office, as well?

The group has moved far from this topic.  Perhaps we should stop now.