Re: Exceptional Rails Developer

On Friday 02 October 2009 05:10:06 am Eleanor McHugh wrote:
> The best teacher of "the right way" is experience, and experience
> mostly comes from doing things the wrong way and then having to clear
> up the mess at some appreciable cost to yourself.

That is true for the species in general. It is not true for the individual.

For example, we, as a species, have enough experience to know that shooting 
yourself in the foot will probably hurt, and may even require that foot to be 
amputated. It would be ridiculous to expect every individual to do that.

Having to clear up the mess is helpful, except for the situation where you 
don't realize what a mess you're in.

> I suspect most of
> the problems big companies have (and not just with coders) is that
> when a person works on one small problem and then passes their output
> along to a coworker in an equally myopic position, the producers of
> mess are rarely if ever penalised.

That is a large part of it. And having responsibility for the mess would mean 
someone would try that much harder to avoid the mess in the first place.

But the key word there is "avoid".

> > Some of these people are the people who will grow up to use Visual
> > Basic, and
> > enable "on error resume next".
>
> I guess you probably don't approve of rescue nil in ruby either lol

In production? Nope.

In development? Be careful, because it might survive till production. I'd much 
rather replace the troublesome code with an explicit stub than have something 
that half-works, maybe, this time.

It's actually something I'm starting to dislike about shell scripting:

#!/bin/sh
source config/variables.
rm -rf ./$BACKUP_DIR
cp -a $FILES ./$BACKUP_DIR
...

Obivously, BACKUP_DIR is assumed to be defined in config/variables. But if that 
file doesn't exist, "source" will raise an error -- but the next line will 
proceed. If the file does exist, but doesn't define BACKUP_DIR, the result is 
the same -- in either case, BACKUP_DIR will be expanded to an empty string, 
resulting in:

rm -rf ./

It's a contrived example, but not too far off from reality. And I don't think 
anyone should have to see their files go away to learn to do proper error 
checking in their shell scripts. It can be as easy as adding a && to the end 
of each line except the last -- and there's probably some even easier flag to 
set...

Same with Perl and "use strict; use warnings;" -- I had to learn that those 
exist first before I could use them properly. If I was only to learn from 
experience, I'd probably have written years worth of programs in which 
misspelling a variable didn't raise an error, but instead gave me a null 
value.