Suppose that you are running a software company. What are the elements that your new developers' training program, that you will not let a developer touch your code without completing it, would contain?
The answer can consist of books, articles, presentations, blog posts, videos or other resources. Better available and linkable online. One resource per answer please.
A definete book I would make sure they read is Code Complete 2nd Edition.
Scot Hanselman has a list of 6 books http://www.hanselman.com/blog/SixEssentialLanguageAgnosticProgrammingBooks.aspx
Timur
Do I understand correctly that you are talking about "teaching" non in-house knowledge to newly hired software developers? (As opposed to things that are related to your particular company) Why would you hire them in the first place if you don't feel they are trained or competent enough?
I mean, why would you hire someone who hasn't read Code Complete or something similar anyway?
I would definitely contain google's guide to writing testable code:
http://googletesting.blogspot.com/2008/11/guide-to-writing-testable-code.html
and the great clean code talks videos:
http://googletesting.blogspot.com/2008/11/clean-code-talks-unit-testing.html http://googletesting.blogspot.com/2008/11/clean-code-talks-dependency-injection.html http://googletesting.blogspot.com/2008/11/clean-code-talks-global-state-and.html http://googletesting.blogspot.com/2008/12/by-miko-hevery-google-tech-talks.html
I agree with not hiring people that fit the qualifications needed for the job meaning that the only knowledge they should have to be formally taught is the in-house specific technologies or architecture or etc. Once they know the in-house knowledge get them working on bug fixes in their own development branches so that they can learn the code-base while being productive and contributing to the workload.
If you are looking for additional areas to check them on you can focus on OO code design, security (varies based on your application type), unicode and internationalization, designing for usability. There are probably additional areas you can check but all of this should be handled in the interview.
"How Open Source Projects Survive Poisonous People" by the core Subversion guys. I'd also point them to whatever you read that made you start using the methodology trend you are currently using. e.g. if you're company is big on automated unit+coverage testing (which you should be), what experiences made you that way, and what were you reading that made you realize how awesome they were.
The obvious expectation is that the people you're hiring are familiar with the language you're using, and know how and why you want to use SCM and dev/test/prod at a bare minimum.
No training program.
Work product/code/design reviews.
Formal indoctrination seems to me to be a bad idea. Do your hiring correctly and have mentoring set up and have good process. A formal training program is a good idea, but will most likely degenerate into something useless and crappy.
On Addition to the Scott Hanselman's list of books mentioned by Timur I would also recommend the 'Foundations of Programming' e-book by Karl Seguin :
http://codebetter.com/files/folders/codebetter_downloads/entry179694.aspx
And than probably for Continuous Education here are some books recommended by Howard :
http://blogs.conchango.com/howardvanrooijen/archive/2008/03/05/continuous-education.aspx
Jomit
At the minimum I would ensure that they understand the software development process that the team uses.
I usually do this in a hands-on manner by getting the new hire to do a small feature that takes them through the whole development process, but that is very specific to our internal process, and not necessarily applicable depending on the actual process being used.
Actual, complete technical training program for our newest developer:
In fairness, she's extremely bright, talented, outgoing, and experienced. I wouldn't recommend this method for the average trainee ... but this is definitely the sort of person I want on my team!