Speaking of which
I've decided it was time for my PFY to branch
into utility coding. He's spent the last year
baby sitting my stuff, and reviewing my code,
occasionally commenting and offering some
suggestions.
He is an odd mix of lots of book learning, combined
with an incredible level of naivety.
While he's coded "professionally" in Perl for a
couple of years, and he got my sample interview program
without any problem, there was no way I would have
hired him into the group as a database programmer.
So I decided it was time to ratchet his skills up
a notch.
I got a spec for utility to implement some select /
bypass logic against a flat file. Extract out fields,
drop stuff that match any of the bypass rules, then
keep stuff that matched any of the select rules.
It had to be runnable by people in our production group.
Take command line arguments, create logs / reports,
sanity check the arguments and the data.
Pretty straight forward. I had it coded in about a
1/2 hour. I assigned it to him as well, not telling
him I already coded it.
After about 3 hours he had a "working" program. Anytime
it encounters a problem (bad argument, file open failure,
etc), it would spit out a message that said: "Error" and
then printing the generic help text.
I was VERY emphatic about creating very explicit error
messages at that point. I asked him if he wanted to take
midnight support calls from the production group as we
ground to a halt because they typoed a file name and he
didn't tell them which one.
He missed the logging / reporting piece of the spec, and the
fact he needed to handle multiple select and bypass statements.
I read the code, slowly, and pointed out a couple of possible
errors, clarified the spec for him, and told him to go code
some more.
He came back the next day and I saw that he had cut&pasted a
bit of my old code into his script, and he left a chunk of dead
code in it.
Me: Do you know what the goal is?
Him: Um - To have a working program as quickly as possible.
Me: Nope. The goal for you to write a program, me to
review it and guide you. To tune our communication, to make
sure we understand each other. To learn from each other.
After we consider it complete, then to review the one I already
wrote, and determine which one should go into production.
Him: Oh. You wrote it already? OK.
I then went over his code, found a couple of ideas to steal
for mine, and made sure he knew that I liked the ideas and
was going to implement them in my code.
We've done 3 back and forth passes so far. He's got some
loops within loops that annoy me (should be factored out),
and a lots of useless copying of variables around (pulls
hash entries into scalars), but it seems workable.