Question: I've been told that I am to be a team lead of an upcoming project. I've not ever been team lead before but the responsibilities are what you would typically expect, with revolving door of 3 to 4 other developers through the 8 or 9 months it takes to complete the project.

My problem is this: one of the developers who will no doubt be working on this project will be a problem. He has more experience than me, has called me an idiot several times in the past, and has told me that he has taken this job because he is a natural leader. He has expected to be promoted to a leadership position with every new project (which has not happened to date), and even once told me that I was to report to him, even though the actual team lead was under no such illusion. Moreover, I've both observed and heard from others that he is extremely unprofessional (watches non-work videos at client sites - with no head phones, dresses unprofessionally, comes to work late, makes inappropriate jokes, etc.) He took or attempted to take credit for my work or insights multiple times while I worked with him as a peer. My current team lead told me that she threw out 1/2 of this guy's code once he left her project because the quality was no good. I could go on.

My fear is that this guy will actively work against me, because he will resent having to report to someone that he considers an inferior, especially since I have been given this opportunity before him. I've successfully dealt with this type of personality as a peer or even reporting to managers like this in the past. I've not dealt with, or ever thought about, having to deal with this type of character who is reporting to me. 

My question is: what kind of strategies can I use to effectively and professionally deal with this? Especially now, before it has become a problem, is there any way to cut it off before it gets out of hand etc. If anyone has a similar experience how did they deal with it?

Answer: 
I agree with Joel, all the answers are on the same frequency, everyone is giving suggestions as peers, not as managers.

Before dwelling in the human side of the problem, I think there's a meta-question you have to answer yourself.

As the leader of the team, your responsibility is for the team to deliver, on time, on budget.

The meta-question to be answered is, you wanna do it with this guy, let's name him Dick, or without him?

**You wanna make it with Dick**

This will make you sweat...

* You need to understand what motivates him
* Need to give him tasks suited to his skills
* You will understand what skills are missing, and coach him on those
* You will spend a lot of time arguing and positioning, which may damage your position as leader in the eyes of others.
* If it doesn't work at the end, the team will lose.
* If it does work at the end, your energy will be drained, but there's joy in helping someone be a little bit better.

If you have the time and the energy, take the path of the enlightenment, you are made from the battles you fight, not from the battles you win. Risk losing.

**You wanna make it without Dick**

This I call, damage control mode...

* You won't put Dick on the critical path
* Dick won't have sole ownership of any piece of the project
* The priority is to keep the guy busy and the project moving, not to keep him happy, not to keep you safe.
* You will need to prevent Dick from undermining the morale of the team:
	+ Recognize loud and clear the good performers.
	+ Make everyone to understand the deliverable of everybody.

Because life's too short to work with Dicks.

Only you know if it's worth it.

There is an alternative path if you have someone in your team who does get along with Dick, you may proxy through her.

My two cents.
most answers i see, i think, focus on the wrong problem.

i can't help but think that the OP is disillusioned, this is only half the story

leadership is hard, i can't help but wonder that if i was in the poster's shoes, the situation never would have evolved to the point that a peer disrespects me

developers don't "report" to the tech lead, they report to managers, "tech lead" (in the sense of the guy who knows the most on a team of 6 devs) doesn't get asigned on healthy team, a healthy team organically self-organizes and people naturally grow into ownership of functionality. that teams often don't self-organize is a culture problem at some bigcos for various off-topic reasons, see jurgen apello's writings (noop.nl) for further reading