From: Eric Lee Green Date: 2001-10-26T14:11:49+09:00 Subject: [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 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 once, > 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:eric@badtux.org Web: http://www.badtux.org You do not save freedom by destroying freedom