Nearly every developer is a diamond in the rough in some way; rarely is a new employee a perfect fit for the job, even when their resume says so.  I think this happens for a few reasons:

1. Resumes (and sometimes even blaring overconfidence) exaggerate most candidates' skills.  Most often, it's because they knew how to pull every handle and turn every knob at their last job, so they must be an expert... when, in fact, they were just experts at their last job.
2. Your job opening is almost never the same as their last job.  Unless you're hiring laterally from another department or absconding an employee from a direct competitor (who has the same platform and build process as you), your job will have unique requirements and being productive in that job will require implicit knowledge of how your company or department operates.
3. "Perfect" is a subjective mix of wisdom, efficiency, insight, overall productivity, communication, and socialization.  It's impossible to be Perfect on Day One, if not Year One.

Recognizing this, I try to keep an open mind when hiring new staff (which I've been doing tirelessly for the past two months).  There are really only a few traits I key-in on:

1. Appropriate level of knowledge for the platform.  I've been hiring for a .NET developer with a modest SQL background.  I don't particularly care if their experience is in C# or VB[.NET], I just care that they've had solid experience with the framework itself, which is an immense geography of 2500+ classes and tens of thousands of functions, so in particular the parts that we use most (data and IO).  I check mostly for awareness and a keen sense of what's-what (like the difference between Inherits and Implements).
2. Good programming.  Beyond linecoding, being a good programmer means that you know how to back up, consider the bigger picture, and write what needs to be written (and nothing more).  God bless those uber-efficient linecoders who can churn spec into code for months on end, but you need three architects to keep them on track (which we don't have).  This one is harder to sniff out, but not impossible.
3. Raison d'être.  Some developers only write software to cash a paycheck. Ironically, most of them don't seem to realize that they're being outmoded by newer, faster, smarter developers who are eager for their paycheck.  Continuous improvement isn't just a corporate thing, it's a career thing.  I take it as a sign that anyone who hasn't flexed themselves in the past 3 years thinks they know all they need to know, and I don't hire those people.

All of this preamble was a build-up for my soapbox on Professional Development™.  It is far too easy for developers to stagnate, and they usually don't know they're a dinosaur until they're being "let go" in favor of newer/younger blood that has three times the depth in current technology and can't find a job.  Likewise, I'm there are many companies looking to expand their Lotus Notes & CORBA integration project from 1997 and want to see more "web 2.0" in it.  The reality is that those companies are mired in the 10-year-old mentality because they didn't help (or push) their developers into staying current.

At MLSPIN, I've been instituting the best policies I've ever learned working for various software companies, large and small, or heard of through online sources:

1. Conducive environment.  This is the hardest, since it takes a lot of money and there's only so much you can do with the facility.  My developers work in a bullpen (less than ideal), but have plenty of space and new ergonomic chairs.
2. Productive equipment.  Each developer has a real HP workstation, with a quad-Xeon processor (room for a second), 4GB of RAM, 15K rpm SAS drives in RAID 5, and an ATi FireGL video card (because they're better at 2D than nVidia).  Each also has two 20" flat-panel monitors and their choice of keyboard & mouse.  We run Visual Studio 2008, and each developer has a copy of Photoshop Elements and SnagIt.  I also have a 5-seat license of MSDN, so we can tinker when we're planning new stuff.
3. Progressive training.  In addition to the modern cachet of books, we provide $2500 in tuition/certification reimbursement, pay the certification exam fee for any passing score, and offer merit bonuses for accomplishing their certification goals.  I'm also committed to having two "superstar" training weeks each year.

The first training session this year was held in January and featured the inimitable Bill Vaughn.  Aside from being one of the founding fathers of ODBC and grandfather to ADO, Bill has the most comprehensive knowledge on programming against databases in Microsoft technology that I've ever even heard of.  Buy his books, they make you smarter.  In a week's time, Bill was able to convey as many nuances to the technology as I've learned in a decade of hands-on work, and I still learned new tricks.  He's very personable, doesn't believe in stupid questions, and knows how to mentor.  We liked him so much, we've now got him on retainer.

I still haven't decided who to have out for the August-ish session, so if you have any suggestions, drop me a line.

So, that's my pitch.  If you are a professional developer, do whatever you need to to stay current, and if your company doesn't support that, leave.  If you're a company who doesn't believe in training your resources, send me your developers' resumes.

-Matt

Michael Wurzer posted (over at the FBS Blog) his commentary on the ever-roiling hype around map-based searching in MLSes and for real estate consumers, borne out of Real Tech LLC's implementation of polygon-based mapping for John L Scott.

Whenever I ask our client base what features they'd like to see added to our service, map-based searching (MBS, for short) inevitably takes one of the top three positions.  However, when pushed with the 5 Whys, virtually no one can get past "because xyz does it!"

I have closely followed the various online mapping options since they became financially accessible and widely accepted (roughly 3 years ago). However, based on numerous seminars and conversations with end customers -- as well as top people at the mapping vendors -- the reality is that mapping hasn't either A) matured sufficiently for, or, B) proven its value in, our market.

As I've pointed out on in several RE forums, I'm skeptical at best of the merit of broad, location-based searching. I personally believe the value is in context-based geography, such as "maximum distance to x school, y office building, and z office building". The problem is then the processing power (and licensed software) required to provide those results in a sub-second period... not an easy trick when you have to scale to thousands of searches per hour.

At last year's Connect SF, I had the opportunity to discuss at length the issues surrounding MBS with Microsoft's Live (nee Virtual Earth) Maps team.  Out of those conversations, Microsoft added off-map drive-time calculation for points (which Google also implemented mere days later).  Unfortunately, the reality of having to load several hundred candidate points and perform the calculations against their servers still proved too latent an exercise to be useful.

The average real estate consumer -- the should-be target of these features -- simply does not rank the featureset nearly as relevant as price, bed/bath count, and square footage... especially when beginning their search, which is how most of these tools approach the visitor.  In fact, I think most consumers will sacrifice location in return for a house that otherwise meets every need.

This year, we will add interactive mapping to the Favorites feature of our service, only because it will include multi-point route optimization (for planning drive-by tours and showings).  To me, this is the extent that the technology has provided value to the consumer.

I would much rather let the big corporate vendors spend millions figuring out what works, then implement those features for a few thousand dollars in a quarter of the time.