Questions like these are the whole reason the Software Carpentry project exists.

For the last 14 years, we've been teaching scientists and engineers basic software development skills: version control, testing, how to modularize code, and so on. All our materials are freely available under a Creative Commons license, and we run a couple of dozen free two-day workshops every year to help people get started.

Based on that, I think the best starting point is probably Robert Glass's excellent (short) book Facts and Fallacies of Software Engineering: its evidence-based approach is a good way to convince scientists that what we're telling them about good programming practices is more than just opinion.
As for specific practices, the two that people are most willing to adopt are version control and unit testing; once those are in place, they can tackle the kind of systematic refactoring that Michael Feathers describes in Working Effectively With Legacy Code.
I no longer recommend The Pragmatic Programmer (lots of exhortation, hard for novices to put into practice), and I think McConnell's Code Complete is too much to start with (though it's a great thing to give them six months or a year in, once they've mastered the basics).

I would also highly recommend Paul Dubois' excellent paper "Maintaining Correctness in Scientific Programs" (Computing in Science & Engineering, May-June 2005), which describes a "defense in depth" approach that combines a dozen different practices in a logical, coherent way.

Questions like these are the whole reason the Software Carpentry project exists.

For the last 14 years, we've been teaching scientists and engineers basic software development skills: version control, testing, how to modularize code, and so on. All our materials are freely available under a Creative Commons license, and we run a couple of dozen free two-day workshops every year to help people get started.

Based on that, I think the best starting point is probably Robert Glass's excellent (short) book Facts and Fallacies of Software Engineering: its evidence-based approach is a good way to convince scientists that what we're telling them about good programming practices is more than just opinion.
As for specific practices, the two that people are most willing to adopt are version control and unit testing; once those are in place, they can tackle the kind of systematic refactoring that Michael Feathers describes in Working Effectively With Legacy Code.
I no longer recommend The Pragmatic Programmer (lots of exhortation, hard for novices to put into practice), and I think McConnell's Code Complete is too much to start with (though it's a great thing to give them six months or a year in, once they've mastered the basics).

I would also highly recommend Paul Dubois' excellent paper "Maintaining Correctness in Scientific Programs" (Computing in Science & Engineering, May-June 2005), which describes a "defense in depth" approach that combines a dozen different practices in a logical, coherent way.

Questions like these are the whole reason the Software Carpentry project exists. For the last 14 years, we've been teaching scientists and engineers basic software development skills: version control, testing, how to modularize code, and so on. All our materials are freely available under a Creative Commons license, and we run a couple of dozen free two-day workshops every year to help people get started. Based on that, I think the best starting point is probably Robert Glass's excellent (short) book Facts and Fallacies of Software Engineering: its evidence-based approach is a good way to convince scientists that what we're telling them about good programming practices is more than just opinion. As for specific practices, the two that people are most willing to adopt are version control and unit testing; once those are in place, they can tackle the kind of systematic refactoring that Michael Feathers describes in Working Effectively With Legacy Code. I no longer recommend The Pragmatic Programmer (lots of exhortation, hard for novices to put into practice), and I think McConnell's Code Complete is too much to start with (though it's a great thing to give them six months or a year in, once they've mastered the basics). I would also highly recommend Paul Dubois' excellent paper "Maintaining Correctness in Scientific Programs" (Computing in Science & Engineering, May-June 2005), which describes a "defense in depth" approach that combines a dozen different practices in a logical, coherent way.

Questions like these are the whole reason the Software Carpentry project exists.

For the last 14 years, we've been teaching scientists and engineers basic software development skills: version control, testing, how to modularize code, and so on. All our materials are freely available under a Creative Commons license, and we run a couple of dozen free two-day workshops every year to help people get started.

Based on that, I think the best starting point is probably Robert Glass's excellent (short) book Facts and Fallacies of Software Engineering: its evidence-based approach is a good way to convince scientists that what we're telling them about good programming practices is more than just opinion.
As for specific practices, the two that people are most willing to adopt are version control and unit testing; once those are in place, they can tackle the kind of systematic refactoring that Michael Feathers describes in Working Effectively With Legacy Code.
I no longer recommend The Pragmatic Programmer (lots of exhortation, hard for novices to put into practice), and I think McConnell's Code Complete is too much to start with (though it's a great thing to give them six months or a year in, once they've mastered the basics).

I would also highly recommend Paul Dubois' excellent paper "Maintaining Correctness in Scientific Programs" (Computing in Science & Engineering, May-June 2005), which describes a "defense in depth" approach that combines a dozen different practices in a logical, coherent way.