[lug] software engineering
nate at natetech.com
Wed Nov 15 01:19:29 MST 2006
Sean Reifschneider wrote:
> On Mon, Nov 13, 2006 at 04:39:08PM -0700, Evelyn Mitchell wrote:
>> An example of this that we've all encountered is using the phonetic
>> alphabet to read back a word that needs to be entered exactly as typed over
>> the phone. "aBcd" = "lower case a as in alpha, upper case b as in bob,
>> lower case charley, lower case d as in delta".
> I've trained myself to notice when I'm running particularly sensitive
> commands or in production environments and behave slightly differently in
> certain contexts. For example, if I'm doing a "rm -rf" or "rm *", I will
> almost always give the full path to the entity I'm trying to remove. "rm
> -rf /home/jafo/Maildir-spam/*".
Yeah, me too.
> For example of why, years ago I ran a production-test system that
> suddenly lost part of it's database files. I spent 36 hours, because of
> a snow-storm that blocked access to the necessary tapes from across town,
> recovering this system. The end result was that a user had typed
> "cd / home/username/test" followed by "rm -rf *". Note the space after the
> first slash after "cd"...
So you were taught by someone crashing the plane for you. Maybe there
is some value in a formalized apprenticeship or level process wherein
you would have instead been taught this technique more formally and
trained and tested on it before being cut loose with root privs? You
don't see many shops doing that -- yet.
> I often, when running on production systems, will stop myself where I'd
> normally hit enter on a command, and re-read it and really think about the
> consequences of running it, before hitting enter. This sort of "slowing
> down" of the process can really prevent errors.
Very much so. Similar to the thinking a pilot does before flying an
especially difficult instrument-only approach to an airport in bad
weather. You gain a sense of when something is more likely to kill you
and you think and behave in a more structured and consistent manner.
I won't reply to the other e-mail, but I like your correlation to
programming too -- tips and techniques to save your bacon like the
bracket idea. Nice.
How do we start to move toward a formal knowledge transfer process for
these types of behaviors in IT? More important, how do we change the
current motivations of both the workers and the bosses so that they WANT
that level of formality and discipline?
Nice examples, great discussion -- filled in a lot of holes for me to
some extent as to the "why" the less critical things simply never get
looked at or fixed.
More information about the LUG