1) To the person who makes the hiring decision, make it clear that the person sucks up more money than they make the company. Make it a pure business decision.

2) Make it easy - very few people enjoy firing people. It is not only confrontational, but it often means admitting you were wrong in hiring in the first place. Give your boss as much of an emotional out as possible.

3) Have the meeting where you solidly and without malice make your case. If your boss isn't going to fire the guy right then and there, but until X, Y, or Z are completed then your boss is going to pussy out. Institutional inertia will set in. Say "I appreciate that you're in a tight spot with this project. What can we do to make this work." When it doesn't work, have a follow up meeting that puts the decision not to fire back in your bosses line of sight, and show that, indeed, it's continuing to not work out. Do NOT say "I told you so." You'll just make your boss resistant.

4) Once the problematic developer is gone, have a follow up discussion that shows it was the right call. Again, don't say I told you so. Say "Thanks for taking care of that. I know it was tough, but it's really working out"

Your job is to make your boss look good by kicking this person to the curb. You're approaching your boss and assisting them in making an informed decision.

Of course, if you're just trying to get someone fired out of spite, that's trickier.

The vast majority of my job in a management capacity is to translate from geek to suit and back again. The guy who owns my company, my direct boss, is not technically minded. The man has fantastic ideas, but couldn't write a lick of code or install a server to save his life.

The company is lucky to have someone like me. Many do not. And in the absence of an interpreter, you bet your ass that closing a lot of tickets in the bug tracker will mean dick when it comes to convincing your boss who doesn't read the bug tracker to not fire you. And frankly, pulling out the metrics to show that you're valuable is exactly the kind of strategic bragging you're arguing against.

You can fire a developer who is leading in resolutions and completed requirements. It happens every day. The job is not just to make sure that you're working your butt off, but that your boss knows it. Help them to make informed decisions. It may suck, but you know what, that's life.

I make the hiring decisions at my company. I check to see if people can solve complex problems. I don't care what language you know. You can learn PHP in a couple of hours. Sure, your first 5.000 SLOC are going to look like whatever language you know best, but right out of college your first 5.000 SLOC are going to suck anyway.

Learning a bunch of languages has the advantage that you learn what concepts are universal to programming and what are just entrenched in the language, but what really matters is learning to think algorithmically, no matter how many languages you know, be it one or one thousand.

It sounds like you've already made your decision about which school you're attending, you just want some assurance that this education won't be wasted. Let me assure you that it won't.

In my experience code reviews trap errors all the time. Second sets of eyes catch stuff like "You forgot to set the status property there" or "that's an off by one error in that loop".

Most commercial code is written with an iterative design/implement cycle. This causes code paths to grow rapidly. A programmer writing the code is constantly updating his mental model of all code paths. A developer coming in on feature complete code has to build his mental model from scratch - he's going to catch code paths and exceptional cases that grew up in development.

In my experience, a solid, robust test suite can automate the edit/run/check cycle while in development, and is great at catching regressions in the future. But short of true waterfall development, where you have an exceptionally rigid spec, it's really really tough to make sure you're test suite catches every code path - especially since modern dev practices (objects/exceptions) create implicit rather than implicit routes through your code.

This is my experience, however. Maybe I'm not working at a high end enough shop that every dev is unlikely to make these kinds of basic-but-potentially-shippable errors. But that's the beauty of a well thought out dev process - those of us less talented can be more likely to produce something of quality.

In my shop, there is no formal code review process. But informally, we all have to maintain this stuff, and there aren't enough of us that everyone gets one nice, clearly demarcated area of responsibility. So in that principle, there is a strong informal process.

In the course of designing a piece of software, or subsystem there is a lot of "Okay, here is my approach. See any pitfalls?" During implementation, there is a lot of over the shoulder "could you take this over?". And once a piece of code is ready to be merged into trunk, a fresh pair of eyes are pulled over, and the code is looked over.

It's a lightweight process, code gets checked numerous times, and we don't run into cases where you suddenly have to review several thousands of lines of code. This has caught numerous bugs, time and time again, and catches the kinds of bugs that user level testing can be the worst at finding - corner cases and intermittent issues.

Wii games seem to be played almost exclusively by little kids, old ladies, and drunk college guys who spent too much goddamn money on a giant ass fucking TV instead of paying student loans, and feel constantly entitled.

This is why WiiBeerPong (or whatever it's called now) was brilliant in its identification of a market niche.

You also don't need a lot of people to agree to fault Nintendo for a class action lawsuit. A lawyer just needs a couple of guys and the reasonable belief that he'll get paid, and he can stir up a lawsuit on behalf of everyone who broke something without their consent.

I worked many moons ago as a tech support agent for BellSouth Internet - of course, my actual employer was ClientLogic, who no longer exists.

The tech support client was different from all the other kinds of phone support that operated in the facility. The others had at most one app - generally a DOS DB driver app for taking orders. and you'd telnet in, and run it. There was no account for accessing the system, and the departments were small enough that employees used the same cubicle day in day out.

The contract with BellSouth required that a number of applications be opened. Each one had a login. They varied by which kind of service you provided - DSL support, Dial Up support, or the various forms of advanced support. Also managing all those windows was terrible on Windows (hah). In the absence of virtual desktops managing as many as 20 mandatory apps got insane.

And,of course, the number of employees exceeded the number of allocated cubicles. So as soon as you stood up, the next shift was grabbing your cubicle, logging out, logging back in, and starting up those apps.

At first, it was standard operating procedure to walk in, go to one of the various machines hanging around, sign into the phone system, which was also the time tracker, log out so that you weren't taking calls on the machine, and let the next guy clock in, while you hunted around for a cubicle, and brought the machine up. But BLS was the only client who had this issue, and a manager was brought in from another department and removed the machine.

All hell broke loose. I was promoted at that point, and effectively, if not officially, had my own cubicle. I was logged into the system all the time, so I didn't have to get into the various fights about the issue, although several people either quit or were fired.

Over a year after leaving, I got a moderately fat check in the mail from the class action lawsuit which had occurred unbeknownst to me. And damn right. I had to arrive early and setup a computer as required by the client in the contract. ClientLogic got more money per call taken from BLS than from other clients because of the additional requirements the techs had to follow - but I don't get paid for doing the actual leg work?

From TFA:

VDPAU is an X extension, and anyone can implement it. It's a competitor to the XvBA extension being developed by AMD, only it exists now, with hardware support, and is derived from an existing technology that has been tested on other OSes.