Several things in a developer's e-mail just didn't sound right (they reported problems explicitly checking mouse click coordinates to display a custom control context menu).  Reviewing the code with the developer in their cube, I pointed out Windows Forms features that made much of their code unecessary, suggested a couple strategies to try to address some legitimate issues associated with their feature, and bookmarked relevant sections in the developer's copy of Chris Sell's "Windows Forms 2.0 Programming", that I had insisted we buy (along with Löwy's "Programming .Net Components, 2nd ed.") for everyone in the department. The developer's response: "Do I really have to read all this?  Its almost working, and we've got a schedule to keep."

My job has included interviewing potential new hires at my last three companies, and the one quality I'm always desperate to find, is evidence of sincere PASSION for software engineering. Staffing with passionate developers eliminates situations like the one above, while dealing with "corporate" developers just makes you want to poke your eyes out with a sharp stick on a daily basis -- or makes you want to poke THEIR eyes out, which apparently violates some sort of HR policy.

The "corporate" developer has little interest in software engineering, beyond what's required to check their currently-assigned feature off of their "To Do" list, and they're not about to spend time attending local .Net user group meetings, or catching up on the latest development books, or monitoring dev. community RSS feeds.  Their code usually shows little evidence of any attempt at refactoring, reflects ignorance of features explicitly designed into the dev. platform to address common usage scenarios, ignores obvious opportunities to employ common design or architecture patterns, and sometimes seems specifically designed to make it as difficult as possible for anyone else ever to understand, maintain, debug, or extend, their particular "contribution" to the code base.  Obviously, you can't hire someone purely on the basis of passion, but passionate developers tend to quickly pick up whatever they need to know, and understand it at a much less superficial level.  Passionate developers also care deeply about the quality of the code and architecture that they are inflicting on their co-workers. Some of them may secretly even... blog.

Beware, however, of the passionate highly-skilled developer who seems obsessed with finding fault with Microsoft's recommended approach to almost anything.  These are the developers whose code will have no relationship to anything found in any standard Windows development reference, ensuring confusion for every experienced Windows developer who joins the project in each new dev. cycle, and eliminating any chance of a clean migration path as Windows dev. technologies continue to evolve.  These developers are always able to provide low-level technical justification for their choices that is hard to argue with, but they never seem to be able to demonstrate any real problems with the simpler (usually higher-level), expected approach, that a target end user would actually care about -- or even be able to detect.

Developer passion and complacency are equally contagious, so be sure that your hiring, and FIRING, decisions leave no doubt as to the kind of engineering department you're trying to build.