Ask Slashdot: How Would You Teach 'Best Practices' For Programmers?

An anonymous reader writes: I've been asked to put together a half-day workshop whose title is "Thinking Like a Programmer." The idea behind this is that within my institution (a university), we have a vast number of self-taught programmers who have never been taught "best practices" or anything about software engineering. This workshop's intention is to address this lack of formal training.

The question is, what should be covered in this workshop? If you have an idea -- that also has an example of best practice -- please share!
It's really two questions -- what "thinking like a programmer" topics should be covered, but also what examples should be used to illustrate best practices for the material. So leave your best thoughts in the comments.

How would you teach best practices for programmers?

Comments

Learn math

[Master5000]

There is no way around it. Never seen a great developer without strong analytical skills.

Re:Learn math

[PolygamousRanchKid]

I think a combination of the "Wizard of Oz" approach and Cognitive Behavior Theory would be very effective here.

Never seen a great developer without strong analytical skills.

I've never seen great developer, or actually, someone who thinks that he is a great developer, who didn't look, smell and act like one.

Do not shave your neck any more.

Stuff yourself with unhealthy junk food; preferably, while working at your keyboard.

Think that you are a super-genius and all your colleagues are idiots. Convince yourself that your code never has any bugs, and the problem must be somewhere else.

Showers and baths? Forget it. The whole world is in a drought, and you need to save water.

Get yourself into meaningless arguments about trivial things like vi vs. emacs. Refuse to stop arguing, even when everyone else has left the room.

In short, you don't need to be a great developer! Just play one on TV!

Re:Learn math

[Z00L00K]

Always break down the problem into small parts that are easy to manage and test.

Electric shocks

[raynet]

The most efficient way to teach best practices is to give the programmer electric shocks for every error, and more for bugs caught in testing. For approved commits you may award them with treats.

Re:Back to basics

[Strider-]

Oh hell no. So-called “self-documenting code” isn’t. You can write the most comprehensible, clear code in the history of mankind, and that’s still not good enough.

The issue is that your code only documents what the code is doing, not what it is supposed to be doing. You wouldn’t believe how many subtle issues I’ve come across over the decades where on the face of it everything should have been good, but in reality the code was behaving slightly differently than what was intended.

Re:Back to basics

[JaredOfEuropa]

The issue is that your code only documents what the code is doing, not what it is supposed to be doing

Mod this up. I aim to document my intent, i.e. what the code is supposed to do. Not only does this help catch bugs within a procedure, but it also forces me to think a little bit about the purpose of each method or function. It helps catch bugs or inconsistencies in the software architecture as well.