|
That may be the case, Greg.
The challenge is expectations. I agree none of this is hard. Have
you ever been chewed out for solving a problem in XML production through
programming? Sounds unreal, yes? As to the skills required, a common
complaint is “that’s too tedious”. Another was “that’s
too old fashioned” making reference to inspecting the file.
We have raised a generation that cannot fathom a box that can be opened and
inspected (I think of them as Mac People but that’s my prejudice) and all
too often, they are being managed by a generation that considered programming
tasks beyond them. XML sits in a not too hot not too cold zone
where it is believed costs can be cut by hiring less than competent and then enforcing
the notion that all you need to do is tag across levels of upper management
which sanction actions. Companies like that eventually kill a
customer in our business. You get what you pay for. len From: Greg Hunt
[mailto:greg@firmansyah.com] It sounds like your
recruitment process is picking people based on substrings of their resume,
resulting in your "guru". None of these technologies are
extremely hard and my preference is always to look for people based on
personality (curiosity, openness, technical orientation) and then work out what
taxonomic box to put them in later. On Fri, Mar 9, 2012 at 5:39 AM, Len Bullard <Len.Bullard@ses-i.com> wrote: I agree, John. And a very productive one.
Note to Len:
Writing and debugging XSLT *is* programming. Anyone who _______________________________________________________________________ |