I wouldn't use it that way deliberately, but if programming is ever going to become a profession in the true sense, then it behoves those in charge to treat it as such.
In the law, you have different levels of lawyers. In the english system, the barristers present the case, solicitors deal with the run of the mill problems. If a solicitor finds himself presented with a problem -- contract or area of the law where the case law is vague or indicisive, then s/he feels no qualms about making a consultation with a barrister or other specialist in order to clarify things.
Your average GP becomes a specialist in general practice, dealing with the wide range of average complaints and conditions, but feels no shame in making a referal to a consultant for brain surgury or eye surgury or any other specialist fields.
Yet we expect every programer to be able to handle every thing after one 3 or 4 year course, and the ethos that exists in most software houses and shops I've worked in is one that discourages people from putting their hands up and saying "I'm not sure I understand what this bit of code is doing".
As always, the analogies aren't exact, but if you asked a brain surgeon to limit himself to those procedures that could be performed by an intern, or the eye surgeon to only use stitches that could be removed/replicated by a staff nurse, then medicine would be in a pretty poor state.
I think the same is true for software. Dumbing every piece of code down to the level that the a recent CompSci graduate or Teach Yourself Perl reader can understand and modify just throws away so much. I strongly believe that the coder charged with maintaining a piece of code should be at least as experienced and capable as the person who wrote it, if not more so.
I've worked in shops that segregated the production of new code from the maintainance of existing code, on both sides of the fence. I've also worked in a place where code is code, new or legacy. Where all code is initially written by whomever is available to do the job, but the first pass is always reviewed by one of the senior staff, and those senior people always make themselves available for consultation by anyone else who's unsure of how to tackle a particular problem -- including other senior people. The latter was hugely more productive than the former.
The ethos of the place was not disimilar to PM in some respects. Anyone felt free to simply call out a question to whomever was within earshot, and anyone who had an idea for a solution would pass their ideas back. No one felt scared that their idea would be laughed at or that they would be set upon for expressing it. The result was that the final solution was (as is often the case with the more interesting problems here at PM) a combination derived from several peoples input and rapidly refined by the group.
I remember hitting a problem late one Friday night when everyone one else had gone. I took the problem home with me and worked on it most of the weekend but still hadn't got a good solution by Monday morning. Within an hour of being back at work, I had described the problem aloud and between half a dozen people, a really good solution had been arrived at.
I had been taken on for my expertise in the particular field we were working on, but I never learnt more, faster than when working in that environment.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
Hooray!
Wanted!