Phoenix.pm: Programmer-standardized testing - was Parameter p

[Bill Nash]

On Wed, 4 Dec 2002, Scott Walters wrote:

> Most industries have a readily understood, easily observed product.
> Production can be quantified. Because of the technical yet abstract
> nature of code, a staff of hundreds of developers can get away with doing nothing
> for years, asuming no one blows the whistle - not in every case, of course,
> but it does happen. I'll grant you that this is human nature - I maintain
> that the scale can be larger in some cases in IT/CS ;)

	This is amplified by the decade-past tendency of people to fear
their technology, and to take an "Emperor's New Clothes" stance towards
its management. Most managers will nod their heads and agree about most
things the technologically advantaged will say, rather than bite the
bullet and admit they don't understand. I know a couple very capable
project managers than can absolutely destroy cunning technologists who
pull these stunts, without needing to understand the technology involved.

> > Thousands of totally unqualified individuals receive degrees every year that
> > should never be allowed to professionally practice in whatever field they
> > have chosen.  Will another test somehow succeed where the evaluation of an
> > educational institution has failed?

	I've got a project in the works that will convince you of this. =)

> Be it myth or fact, Java markets itself as reducing the frequency of this
> problem. Perl has so many syntaxisms and idioms, and "dialects of Perl" as
> Larry Wall puts it, that it is difficult to know enough of the language to
> understand the work of otehrs. Perl has a deserved reputation for being unreadable.
> If people use only the features that directly correspond that features in
> Java (for instance), there would be a common dialect, but at the expense of
> the expressiveness of Perl. Some times other people really do write code
> with ignorant choice of idiom and feature, but with Perl it is often just
> unfamiliar dialects.

	Like any other language, exposure only increases understanding.
Perl offers such a diverse experience, as well as an excellent insight
into how people learn, or teach themselves.

> This problem is above and beyond ego associated with one's own code, and
> the too often valid suspicion of other people's code.

	That's the other edge of Perl's diversity. I oftenfind myself
wanting to look at code before I'll trust it, simply to have a better
understanding of how it works. It's human instinct to fear what you don't
understand. It's evolutionary to turn that fear into curiousity.

Unless you're working with explosives. Then it's Darwinism.

> Thanks. Like I said, employers hire a broad range of experience levels -
> some places are happy with a bunch of a budget programmers.
>
> Attitude has a lot more to do with your success than ability, in my experience,
> but that is a different topic. Many shops place "team player" as a virtue
> above ability. Others shops have other requirements.

	Being a team player often isn't enough. Bad managers and bad
hiring practices can take any team and drive it into the ground by
introducing inferior team members. The stronger members who point this out
are seen as counterproductive, even though they may be right.

- billn