It is definitely the spoiler tag. It would have been really cool if it were actually blue.

Wow. Interesting question with many, many possible answers. Here are my top things:

• Find out what motivates each individual, everyone is different.
• Make sure to mark small successes. One thing that motivates many is creating something that has value. Show the folks that what they have done has value.
• Celebrate failure. Trust that the folks will try to do well, and applaud effort. Note: This doesn't mean you should tolerate lack of effort; see next.
• Weed out those who are not capable or do not put in the effort. The best way to do this is to have significant contact with the teams. Get to know them, and know what they are doing day-to-day.
• Read up on the Agile Manifesto and Agile Principles. I'm not going to say, "Do agile." However, knowing something about the history and reasons behind the Manifesto and Principles will give significant insight into what developers have seen as problematic and as potential solutions.

Same thing, different term. I would tend to think of URL Routing as being a little more specifically calling for a dynamic, programatic solution, but these days that would almost be a distinction without a difference.

The "big bucks" are in writing something small that takes off huge. That is, joining or starting a new company that hits the big time. This can be done in any language, but Ruby/Rails was and arguably still is one of the more popular ones. There are also PHP and Python, which have their own frameworks that can make it easy to get a web site or service up and running.

That said, there are also big bucks in "enterprise" development, where Java and C# are the main languages in use. So, for job safety and pretty decent salaries, those are pretty strong.

The problem is... you are best off not focusing on where things are now, but trying to get a handle on where they will be. The problem is that predicting that is and always has been pretty tough. So, the smart money says, get some experience with as many different programming paradigms as possible. That is, learn procedural, object-oriented, functional, and whatever else you can.

Then, when the time comes, you can pick whatever holds the "big bucks" title at the time, pick it up quickly, and get in the rat race with the rest of us.

When you say small team, I'm assuming fewer than 6 developers. In that case, I would suggest introducing it by pairing, one at a time with each developer over the course of several features/enhancements/whatever units of work you have. Demonstrate to each one the benefits and pitfalls by directly working with them on their day-to-day efforts.

So that's my "mechanics" answer. What about the "hearts and minds" piece? Likely the biggest risk to adoption is that people start to think TDD is slow. This is even worse in your case because you can't "TDD" legacy code. The code is already there. You can make sure you write tests for the legacy code before you write any new code. Then you can use TDD for the new code. What this means, however, is that you're initially going to be "slowing down" even more than using TDD normally would.

How do you fight this? Don't talk about TDD as being about speed. Talk about it in terms of safety and design. Talk about the reduction of stress involved with making future changes because of the "safety net" that the test suite provides. (Note: I am assuming you will have a build that runs all tests on every check-in/commit/push to the code repository. I am also assuming you are using version control.) Talk about how writing the tests first ensures that your design is minimal and aids in getting the design to be as flexible as possible.

There are whole books on this, so I'll end by recommending one you may have seen since you mention Michael Feathers: Working Effectively with Legacy Code.

/u/14d2025 mentioned the Dreyfus Model. That identifies a set of categories, but is not without detractors. Of course, there is no One True Way to determine this. If there were, interviews would be much more cut and dry.

That said, here's another way to look at it. If you are a "Senior Programmer" then you should be a source of information for others as opposed to a sink. That doesn't mean you know everything or aren't still learning (even from the more "junior" folks). It just means that, on average, you can provide more information than you need. A slightly different take would be that your focus becomes less just about you and your tasks and more about others and the project/program/company as a whole.

Also, you are definitely right that you are unlikely to "master" programming. That would be a bit like trying to be a "master" at medicine. I was speaking to an honest-to-goodness brain surgeon a few weeks ago. This is a highly regarded professional in his field. However, he readily admitted that there are plenty of things outside his area of expertise even when it comes to the (biological and chemical) workings of the brain.

• Quick edit to add: You are experienced enough to run a development team, manage a project or company when one of two things is true. Either you convince someone to let you, or you are confident enough to try it and accept the consequences of failing. Most folks that I have talked to that run companies have more failures in their past than successes.