Link Details

Being an expert in something can work for or against you, though. Where I work, expertise is not something you hire unless it's core to the business (DBA's, *nix Admins, developers skilled in a core business function, etc.), where ANY other IT project that will require expert knowledge to deploy will generally be contracted out. If you're a contractor, that's great, but if you're looking for a full-time job at that company, good luck to you.

Also, how does having an expertise in a framework, language, or tool, relate to the trend of adopting Agile principles, which include pair programming, Scrum, XP, etc.? From what I've seen of these Agile methods, they take an approach that teams get work done, not individuals. Teams share responsibilities, share coding, share expertise, so that they can all strive to be on a level playing field. Hiring an expert doesn't necessarily fit this model, IMO, unless it's secondary to their interpersonal skills, ability to learn new tools/languages, and be a team player.

Mashups, where you integrate a variety of technologies into one system tend to be a disaster in terms of maintenance. Stick with one technology -- stop switching around you language/framework because you have to write three lines instead of two to get something done. Learn how to write clean, object-oriented code in your chosen language, and how to handle security/persistence/rpc/ui, etc.. before you move on to the next flavor of the week.