In a number of fields I have found that people who think they are good generally think that because they've never met anyone who is good. And as a result they are really bad. Because no matter how much talent they have, they simply aren't going to figure out on their own enough to be better than people who have exposure to the wider world.

About the "group shop" issue. I'm in a team of under 10 people. (How big the team is depends on how you count it - for instance I mostly do reporting these days, so I'm not part of the core team.) Is that a group shop in your eyes? Yet every member of this group is at least decent by my standards, and my standards are pretty high.

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.

--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

That fits in with my experience. It is very difficult to judge your own skill accurately unless you have sufficient exposure to other programmers. For years I worked either solo or with one other developer, and all along I thought I was a damn good perl programmer. Mostly because I was the only perl programmer I knew that understood globs and tie.

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.

That's certainly true, about bad habits, tilly. Ego is another issue that can be poisonous. My personal experience is that the need to solve problems on multiple levels does more good -- by a large measure -- than the bad habits do harm, and I'll comment more about ego down below.

My definition of greatness (or 'senior programmer' status) is based far more on one's ability to gauge what parts of a problem are worthy of more applied brilliance than others. That does not appear to be yours, though. You seem more concerned with ability to work to an API defined by a team and write elegantly maintainable code. These are admirable traits in my book also, but (honestly) I've never worked much in group development environments. I am, I suppose, much more a rough-and-ready programmer with lots of odious habits. ;-]

As for your 'group shop', if we turn it around, how many kids are you (collectively) mentoring? We all know that you can generally write code faster than you can explain menial coding tasks suitable for learning experiences. If you're not supporting some, you're making my point: that small-to-medium groups cannot support mentorship opportunities, and big ones are not worthy learning environments. I heartily agree with another responder who said that many bigger shops have dead-end programmers who can't shine a dog's @ss. One of the reasons I rarely get in to larger shops is that those are the ones who get chosen to give interviews. ;-]

Be that as it may, I don't disagree with anything you've said, but I stand on my case that anyone sharp enough to survive the hot seat is capable of learning to code defensibly and in a shared environment. The ego is the sticking point. They can, but will they? It took me a lot of years to learn humility. I never wore my ego on my shirt, but it was definitely riding on my shorts. I "knew" I could solve anything in programming, given tools and time. Now, at least I know that not all problems are made of bits and neither are all solutions. :D

I never really had a mentor, because I was a better coder and analyst than anyone I worked with, but I did have some good (non-programming) teachers who were proud to point me towards the prize rather than the competition. I guess that's the real key in integrating a team member: is the achievement worth more to him than the race?

Now, I'm getting to the point in my career where the young guys are definitely better coders than I am. Here in Austin, they grow up speaking C at the breakfast table and C++ at tea. (Perl, of course, takes up Saturday afternoons out in the garage). However, I'm still valuable because of that early seminal training in recognizing the prize. It isn't really about how much syntax you can crunch before noon, but rather how much closer you get to release by 5.

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

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.

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.

--
And-httpd, $2,000 security guarantee
James Antill

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.