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

[Reverend Green]

Imho grammar is at least a important as math. If a person speaks like an illiterate rube, chances are he'll program like one too.

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

[Immerman]

Other way around - mathematics is a strict subset of logic, which also applies to realms well outside mathematics.

Re:Learn math

[arth1]

There is no problem finding good mathematicians that knows jack shit about logic

Name one.

Re:Learn math

[Z00L00K]

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

Back to basics

[Calydor]

Indentation and comments.

Stopping for a moment to ask yourself if you NEED to load a 50 MB library for two lines of code.

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.

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.

Humilty, but you can't teach that

[petes_PoV]

we have a vast number of self-taught programmers who have never been taught "best practices"

Arrrrgh! The worst sort.

These people tend to be rank amateurs. But with the "experience" that makes them think they are actually professionals. Almost none of them are. And most never will be.

Most people, even people who make a living from programming, are much worse at it than they think they are. They are impatient, they are hit-and-miss, most can't think clearly and an unfortunate number share in the twin misconceptions that "if it compiles cleanly, it works" and that testing is merely a stage that comes between coding and release to production (and is not there to fix problems, merely to tick boxes).

Personally I would focus this workshop on the cost of the errors made - and target it at the senior people there. Drum it home that "good" software - best practices is not about how many million lines of code you can write in a day, nor about how complex you can make an algorithm. It is about being able to hand your work off to others and the ease with which they can understand what it does.