Paris Sinclair said:
A good programmer always should be using whatever resources they have
available to them. I'm definately of the Thomas Edison school of thought
on the subject of, things that are written down somewhere don't need to
be memorized. As a result, I spend a lot of time being cozy with
perldoc. So a test that required me to forgo reference materials
wouldn't accurately be testing my programming skill, because I never
work in isolation. Indeed, knowing when you need to RTFM is an important
skill for those of us not blessed with an indexed photographic memory.
Here, here! This is exactly the reason why O'Reilly et. al. are in
business: it's not possible to remember everything you need to know. Thus
authors write books, and in turn we users purchase and treasure them. For
example: how many people know all the various Java API's? Is it even
It may simply be that humans are non-standard, skilled humans are more
non-standard than average humans, and most programmers desired for jobs
are skilled humans. Now, if we add the other data point, that the people
hiring said skilled humans are not skilled in the area of the people
they are hiring and, therefore, desire a standard or metric to measure
them by, then we can easily come to the conclusion that it is quite
impossible to achieve a test that is going to be considered ideal by
very many of the involved parties.
It's very interesting you bring this up. I'm reading "Software
Craftsmanship" right now, and it talks a lot about how software
development is not well suited for "licensing" programmers. In engineering
you have best practices and known data about materials. In software,
things get much more amorphous. How do you define a "good" program, or a
"good" programmer? There are many more factors at play than say, knowing
the tensile strength of a steel beam or the propagation speed of an
electron in a substance.

Mr. McBreen makes the case for bring back the idea of "craftsmanship",
where experts teach newcomers the tricks & skills of the trade. He
compares it to apprenticeships, which I think is a very interesting
comparison. Software is so new that we have not yet figured out all the
development "best practices", unlike say, mechanical engineering. So why
not take what we have learned and pass down that knowledge to others so we
can all progress?

Getting back to the subject of jobs... It seems to me that what it really
comes down to is recommendations: if a developer you know & trust
recommends someone for a job, you have a pretty good idea this 3rd-party
is qualified. Why else would I put my job and reputation on the line for
someone else unless I trusted and respected their work?

This is why I've decided to become a more active _contributer_ in the perl
community. It's the perfect way to gain a better reputation, and continue
to better yourself at the same time. (This assumes some level of skill in
the first place ;-) The icing on the cake is that I am contributing back
to the community that helped me get where I am. Thanks for listening to my

Drew Taylor * Web app development & consulting
drew@drewtaylor.com * Site implementation & hosting
www.drewtaylor.com * perl/mod_perl/DBI/mysql/postgres

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2022 Grokbase