If it's not strictly a bug fix, feature flags are a good way to go. Keep a standard of adding any reasonably sized addition behind a feature flag. That way it's easy to turn on/off your new button, or swap between two methods of doing something.

If it's testable, have a code review and release process built around difference testing. Reviewers have to sign off on the externally visible differences in the code's effect. Release engineers can close bugs based on expected diffs and reject releases in the face of un-expected ones. These can be simple diffs of database files, or more complicated screenshot difference analysis. Either way, you have someone other than the dev having to click a checkbox that the change makes sense.

Companies will hire depending on who they are looking for. There is some stigma about the trade schools sometimes, and a CS degree will get you to other jobs aswell. While it is a flame-war-able debate, I'd argue on the side of a CS degree over the tradeschools. Trade schools are good, as I work with several people who came from those degrees. But there is a divide on knowelege. Trade school degrees like FullSail give a good overview of the game aspects of programming and design, but they lack some of the more fundemental courses of Computer Science and Mathmatics (like compilers, languages and automata, operating systems, parallel programming, etc.) The CS degrees on the other hand lack a lot of the hands on programming courses focused on game specific technology like Graphics, AI, and Design. Really, the best bet would be trying to get the best of both worlds.

Also, let them know that the pay is lower for the hours worked when compared to other computer programming positions out there in the world. They have to be motivated to make games or they are going to burn out fast. And, yes, the ones who actually want to make games should already be making them. If you start making games/programming when you get into the industry you are 10-15 years behind the people of the same age who were actually motivated to work in their free time.

Point them at good side resources. What are they interested in? Send them to Wii/PSP/PS2/PS3 homebrew sites to learn to hack away on real hardware. Send them to modding communities to make HalfLife 2 mods, or Quake maps, or Starcraft 2 maps. Send them to places like http://www.gamedev.net/ http://aigamedev.com/ http://www.gamasutra.com/ or other high profile programming forums.

Encourage them to do ACM programming contests or topcoder.com programming contests. Get them to learn to solve problems, debug programs, and use source control. Get them to explore stuff other than programming; having a good understanding of art, music, or some other set of game related tallents helps out the team flow.

Even after doing a tonne of programming on the side since forever ago, I still don't feel like I learned enough before becoming a dev. And after two shipped titles, I can say you still have to learn on the way. Technology changes too quickly to ever stop learning. Getting to the goal of being a game developer isn't the end of the road.

It really was beautiful. This looks to be for games what Avatar was for 3d movies. Unlike the active shutter 3D demos, this one seemed to suffer far less drawbacks. Including, not having to wear expensive shutter glasses.
The effect actually adds a lot to the perception of the game world in most cases, though there are obviously the instances where it seems like a gimic. But even as a gimic, it makes the 3d world feel all that more real.
And the 3D camera is rather impressive too.

THAT sir, was the first thing I thought of when i read this headline. I remember that car having an EMP gun that it used to catch cars as well.

Nasa HAS tried this.
http://en.wikipedia.org/wiki/Electrodynamic_tether
You can generate electricity as you move around the earth. Being in orbit, you are going fast enough to make worthwhile magnetic flux, and you are free of air resistance that would keep you from deploying the tether if you were lower in the atmosphere.

Today, now that even game consoles have gone multicore,

That doesn't help things. In fact, it makes them worse. Concurency causes lots of issues that each have their own solutions. One simple one is double buffering all the data. This puts all your threads a frame behind, but it means that you get to use more CPU since every thread has data in its input buffer instead of waiting on other threads.

Notice the lack of "sleep(9000)" statements ? So that's what, 20 usec worth of code ? Take input, spawn bullet, play sound and draw the goddamned frame already! If that takes you 200 msec to process, then your game is really running at 5 fps with a shit ton of interpolated frames in-between, and you should probably go back to writing Joomla plugins.

Doesn't work like that either. spawn_bullet may have to be deferred because of threading. The graphics for the bullet may not get updated untill next frame, as i stated above, double buffered frames delay output by a frame.

All of these delays are in the name of effecient use of the hardware. It isn't intentional that killzone has 12 frames of delay, so much as using the hardware to push the best graphics means sacrificing in burst rate for throughput on the CPU.

1) Input is often sampled only once per frame. That is why quake at 120fps feels more responsive, the time between you pressing a button and the game noticing you pressed the button is reduced.

2) Input and actions are often determined on a per-frame basis. Meaning the fastest delay you can get is a single frame. Consoles tend to have games that run at a target frame rate (30, 24, 60) that determines how much visual flavor the game can have (60hz leaves less time to draw and update stuff than 30hz). So, at 30Hz, the fastest you can hope to see an action is 1 frame after the game detects it. That amounts to 33ms-66ms depending on your timing of the press in relation to the frame processing (we are asynchronous to the technology after all).

3) After a game renders a frame, it is usually buffered, so it has to swap and display the buffer. With V-Sync (consoles tend to v-sync automatically) that means it has to wait the 16ms for a 60Hz screen to refresh. But it only attempts to swap once a frame, introducing an aditional frames worth of delay in the display.

This is where the 99ms minimum response for a 30FPS game came from. 48ms for a 60FPS game.

Then you have to take into account that because of threading and networking, there are often more buffers in the game that only swap once a frame. This can introduce additional frames worth of delays as developers attempt to use the hardware to its limits.