To your point about using the hiring process to ensure quality code... I couldn't agree more!

However, in my experience I've found that in large corporations the HR department often has predefined channels for funneling all prospective talent into your group. And getting a truly talented candidate via these official channels is pretty rare. They just don't seem to attract the types of rock star developers that we all want. They seem to be a source of quantity, not quality.

I suppose it's obvious, but the best talent seems to come via referral... which makes total sense. I know I sure the hell wouldn't refer someone I thought was sub-par... if I did, what would that say about me.

Jeremy,

As far as limiting the sophistication of your development approaches to your teams skill set.  I am a firm believer in growing people.  (Now that doesn’t translate into driving new technology down people’s neck but slowly introducing new concepts in small digestible chunks) Everyone that has introduced agile practices should be able to attest to that statement.  Remember when the concepts of TDD and paired programming where first introduced.  Remember all the frustration and unwillingness to take on these practices. But slowly everyone came on board and realized the benefits but they did it corporately as one team.  I have found that as long as you introduce new concepts and practices into your development group as opportunistic possibility.  Organically they will self organize around the concept and determine as whole if the idea or technology is sustainable.  At that point through the spiking and peer pressure they will either excel or ask for additional training.   The complexity of the language or the suppleness of the architecture seems to be somewhat trivial as teams self organize.  At the same time these opportunistic possibilities will sometimes lead to developer turnover but 9 time out of 10 the developer that does leave has had problems in the past gelling with the team.

I agree that working in the corporate sector has its tradeoff’s but for those (like my self who still work for the man); there are partnerships you can establish with HR.  I use HR as an initial screening tool only then to invite the recruiters to take part in the development interview. After the development interview and an hour or so of QA from the recruiter grilling me on what OOP and TDD are, they eventually get it right and start to find qualified developers.  Again partnerships are the key here.  If you don’t you will find yourself muddling through hundreds of junior developers or old main frame developer’s resumes, that want to catch up to  the 21st century.

I know this is rather long winded but team development is something that I feel very passionate about.  Teams complete projects not glory minded developers!

It's interesting you hear someone say that they are sticking with smaller companies, I used to work for a smaller company that had the same problems. Most signs point to the director of applications not having a clue (an old VB4 developer that never grew up technology wise). I have since moved to a bigger company (3 IT to 30ish) and things still seem to be about the same. I have since gotten our group (3 programmers) to try DDD, TDD and I just set up Cruise Control for CI. The downside is since I am new to all these as well, I question if everything I am doing is right. I wish we had someone else with these interests just to have someone to bounce ideas off of, or a different point of view on how to implement these.

As for the hiring side of things, we just hired our 3rd developer who is technically weak. The problem being she is used to having business analyst telling her what/how to things, and no longer has that luxury. I used to work with her and knew this area would be one of her weaknesses, yet something we still need, yet I was overruled. Maybe she will catch on to some of the simplier concepts quickly, I just have a hard time teaching something I am still learning.

Jeremy, there seems to be some wounds about your former employee (which some years ago was a well respected company, but for some reason lost valuable talents). Why dont you share with us what happened? I'm specially interested as my company is an agile practitioner, and I love to know what _not_ to do in advance.

Sharp Tools for Sharp People

JavaScript, even more so than VB, has to be the Rodney Dangerfield of programming languages. I'm