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.