Let's see... some good answers have already covered a few on my list:
Be professional - a no brainer anyway, but avoid, at all costs, judgement calls about your potential problem employee. If you really need to vent, ask your boss for the opportunity to talk through the issue, don't ever let his problem or your problem impact how you interact with your team.
Be direct - give work, expectations and deadlines. Involve him as much as you would any other employee and stay willing to listen to ideas - but make sure you are impeccably direct. I think one the tricks with problem people is that it's easy to say "do X task by Y date" but there's another set of elements of how you want the work to be done - how much bragging? how much testing? how much is due diligence vs. over engineering?
- Sadly, this will also have to include being direct about his behavior (dress code, watching non-work videos, off color humor) - as his day to day manager it is not just your right, it is your duty to help the rest of the team survive this guy, and that means setting the expectations point blank.
- Being direct also means calling him on bad behavior when it's happening. You are actually in a good position as you already know some of his problems, so you can be on alert when he repeats previous problems. The best time to halt a behavior is when it's happening.
- And - being direct also means giving feedback on work - when you review his code (which you should do with some regularity) and find that you'll need to throw out 50% of it, then his job needs to change from writing new code to fixing code to meet your expectations. Not your minimum expectations, either, the expectations you have for everyone. And that doesn't mean a delay in deadlines - if this is something that should have been done right the first time, then he needs to do the work and keep on schedule.
Keep records - Personally, I like the giving tasking via in person conversation, since it (usually) reduces tension and improves shared understanding. But there's no harm in leaving the meeting and following up with a friendly email reminder to everyone. The best part is that once it goes through email, it goes through whatever corporate email scrutiny and backup processes you have, which means it's part of a more legal record.
Remember - you own team health as well as the technical solution - A lot of the behaviors you've pointed out are problems that can be counter to a healthy happy team. One of the things to think about as you work on this problem is that you are not just the owner of the technical solution, but also the productivity of the team while they build the solution. It can often be hard when you think about going head to head with someone - as if the situation is innately adversarial. I've often made much better headway when I think of the problem behaviors as something that is hurting the whole team - then I can look for ways to change the context and isolate the problems so that I don't have to go head to head with someone - instead I can develop a team that is so healthy that it fights the "virus" in its midst. Probably my biggest guidance here is work on overall team trust - if the rest of the team trusts you (and vice versa) it will be very hard for the bad behaviors to get much play or to do your group much harm.
do have 1 on 1s - not just with your problem guy, but also with other people on the team. IMO, team meetings are for status that everyone needs to hear, and problem solving. 1 on 1s are for the things no one wants to get into in public - what's going well, what's going bad? What does a given employee want most of the job? What's missing? What's great? This is a good way to build a healthy team, and also a good way to address problems 1 on 1.
That's all the really good for all purposes advice. Here's the way more political and harsher underside of management:
Know the blame lines
What exactly is the direct chain of command that says whether this guy stays or goes in the company. In other words - who gets the blame for a problem person remaining a problem that the company is paying for? With the first line of technical leadership, you cannot automatically assume that the blame line involves you - for several of my first leadership situations, I was not the person who approved vacation time, raises, bonuses, employee evaluations or disciplinary action. Often on short technical projects that responsibility can fall on a bigger section manager and not on the day to day technical lead. Know this guy's blame line. Get to know at least 2 tiers of those individuals - develop a collaborative relationship where you are checking in about the more trivial day to day stuff, so you already have a point of trust if you need to bring in problems.
Learn the company's employee evaluation process
Most importantly - is it you that will be the frontline reviewer of this process? If not, who do you give feedback to, and why isn't it you? But also - what ratings and guidance has this guy received in the past? I'll bet ya that he's already gotten some pointed feedback about his behavior in the past, and most companies keep records on this. Get the records, know what he's been told.
One of the roughest parts of engineering management is that due to the speed of projects, there is sometimes no longevity of management, so a problem person can get bumped around between managers and each switch is a chance to revert to old behaviors. You don't have to keep this a secret - if you end up leading him, you can sit him down and say point blank - "I checked up on previous evaluations, and I know you're working on improving X, Y, and Z - I expect you'll keep working on those skills and behaviors on this project and I'm ready and willing to help you improve here." Obviously use your own words. What I just wrote makes you sound like you're impersonating a human being. :)
Talk to HR and learn about the process of how someone gets fired
Yes, this is truly a horrible process. There is no good way to fire someone for being incompetent. No matter what the process is, it will trump any other process in terms of horribleness.
The only thing worse than knowing about the company's termination process is NOT knowing. Not knowing will get you in plenty of trouble, knowing will let you prepare yourself in case you have to go there.
A legally minded company will have a very formal process and your HR should be prepared to coach you. This does NOT mean that you should step up ready to fire the guy - this means that you should know what it takes. There are often some truly bizarre (to a sane person) nuances to how this works, and forewarned is forearmed.
Keep your own records
You do NOT owe your employee every thought that crosses your mind.
Keeping records in general is a good idea, because it lets you remember the good (and bad) stuff that EVERYONE on the team does - so when it's time for the fun part of management - setting bonuses and other cool rewards - you can do more than give a generic gift. One of the best things ever is having your management give you a bonus and a note that specifically calls out some of the awesome contributions you made to the team... I guarantee that employees remember the cool note much longer than they remember how much money the company forked over.
And, sadly, having records of issues for a problem employee is often part of the firing process. It's also part of the sanity-keeping process. The human mind likes to forget pain and suffering. It's very easy at review time to conveniently forget just how many issues have come up, and when you do have to have a painful conversation, it's worse if you are not grounded in some details of specific issues and patterns.
Use your management chain
When I was an individual contributor, I was happy to stay as far away from management as possible. Once I became a manager, I realized how invaluable a good working relationship with management can be. Of course it totally depends upon the competence of your management - but often higher levels of management are composed of people with plenty of tricks in their tool kits. They know the culture and they know the biggest red buttons in the company - so they are in a good position to give you help. Also - if you are sharing your grief on a regular basis, they know where you stand in case of any political hijinks.
Do not assume that no sign of trouble means no trouble
I could be completely washed up, because this is just one snap shot in time.
But what you describe is a series of very defensive behaviors that seem to be coming from someone who has some serious problems with work behavior. The fact that you have been promoted and he hasn't tells me that your management is smart enough to realize the issues on some level.
Most disciplinary action is taken in private one on one sessions. Calling someone out in public rarely does any good - and when it comes to the very serious "shape up or ship out" discussions, they are ALWAYS in private. Which means that no one who is NOT in the direct management chain should be privy to these.
This is my biggest rational for most of the other advice -- it sounds to me like not only do you have a guy with some problems, but that you have decent enough management that problem-fixing may already be underway, and mostly what you need to do is establish how you fit in to the problem-fixing cycle and then continue the activities as needed.
The final hopeful finish
It's not unusual for people to change radically when dealing with a manager from dealing with a peer. All my cautionary advice may be pointless as it very well could be that this guy will be sweet as pie when you take the lead role as you have now suddenly become "The Boss". Different people deal very differently with authority - for signs of how this guy is programmed, check out how his current boss deals with him.
In fact - one of the best tricks is to watch other managers. I'd bet money that his current management does some stuff great and some stuff absolutely badly. Look for the good tricks, and keep and eye open to blind spots in your current management hierarchy - be ready to try new things but also be aware of what works and therefore doesn't need to be fixed. :)