It's not really the work environment that matters. The people I really consider good programmers work in very small groups. However, the work group isn't everything. With Perlmonks and other online things, even a lone programmer can learn a lot from senior people. Indeed, I went out of my way to meet other people doing Perl so I could have someone to talk to. Don't be satisfied with what you find at work: check out a Perl Mongers group, read as much as you can online, try out new things, and so on.

As a counter-example, I've met a lot of really bad programmers in big shops. These are the sorts of people I would never hire. Really big companies have seats to fill and they take what they can get. Often, even though the company is large, they work in very small groups that don't talk to each other. I'm constantly surprised how compartmentalized a big company can be. Given a relatively senior bad programmer training the new hires can have the same disasterous results as the lone programmer who never talks to anyone.

The trick, no matter the work situation, is to talk to as many people as you can, or at least read the answers other people give to problems. You'll quickly figure out, for instance, about strict, warnings, and PERL vs. Perl.

We have a part to do in this too. The Perl community can be very unforgiving (and I'm not talking about Perlmonks necessarily, which happens to be on the more friendly side). The hapless newbie comes in looking for help and reassurance, but is often immediately attacked for lack of strictures, etc. We want people to get better, but we tend not to nice enough that they want to listen to us.

A few years ago I realized that I was an ok perl coder, but a horrible engineer. I wrote clever and unmaintainable code, and not a single test case. I then adopted the policy of being maintainable instead of clever.

My most recent awakening came from taking part in discussions on perlmonks. I have learned more from answering questions here than I have from many of the books on my shelf.

I am somewhat puzzled where you're getting your impression of my priorities from. For one thing, they're off by quite a bit. For instance while I'd hope that a junior program could code to an API and standard that someone else has developed, I'd never judge a senior programmer on that skill. Instead I'd want them to be good at things like inventing APIs that I'd want to use. The ability to work with someone else's API is like the ability to walk and chew gum - I'd take it for granted.

About what you value in "great programmers", I'm unsure what you mean by "applied brilliance". Largely that's because there are plenty of things that I consider routine that others consider to be brilliance. Why I like functional programming is a good example. I have no idea what your standards are.

However, no matter what your standards are, I sincerely believe that you are mistaken to focus on what are probably just flashy hacks. In every field that I know of, when you talk to the best people, they stress the importance of getting the fundamentals right. That holds true whether you're talking about playing a musical instrument, playing a sport, or even an intellectual discipline such as mathematics. (See The path to mastery for a story from mathematics.) And, believe it or not, I've encountered the same attitude from the best programmers that I've seen.

For instance take the best-known example of a truly flashy "mad genius" programmer in the Perl world. That would be TheDamian. Can we agree that he really is a great programmer? Now go look at the most widely recommended book that he has written. That would be Perl Best Practices. What is it? It is a detailed analysis of apparent minutiae, like whether you should format code with the + signs before or after a line break if you had to break the line. (The answer to that one in Perl is on the next line, BTW.)

The fact that he was willing to put a tremendous amount of energy into considering issues like this, and that the resulting book is valued highly by so many top-notch programmers, speaks volumes to me about what is important in programming. Namely that fundamentals count. You might not always start by learning fundamentals, but somewhere along the way you need to pick them up. And then you layer knowledge on top of that. Some day as you take the natural approach to a problem you'll see blank stares from people who do not have the background to understand what you're doing. While that can be fun, you get there by getting the fundamentals right.

I wouldn't disagree with anything you've said about the fundamental disciplines of programming. The only thing I'd re-stress is that "getting" the big picture is the most important skill of all.

Don Wilde
"There's more than one level to any answer."

Both theory and experience lead me to believe that people who learned in the small company environment will have a bunch of really, really bad habits that they will never realize are bad habits because they have never worked with anyone who could set them straight.

I'm not sure, it seems unlikely to me that you can get a great programer from a single great mentor. I think a programer who could become great has to look outside their local environment Netnews, books, blogs now and "community websites" for different opinions/approaches, and think about them.

In fact, I'd say that one of the major points of greatness is "one size doesn't fit all" / "everyone or everything is wrong some of the time" and you can't learn that from a single mentor, almost by definition.

You can't logically disprove, A is necessary by arguing that A is not sufficient.

Of course just dealing with one great mentor won't make you a great programmer. And good mentors know that, and encourage people to get exposure to additional outside experiences.

But that doesn't invalidate what I said. Which is that if you've never had exposure to someone who is good, then you've never had a necessary reality check that you need to really get the learning process going.