Sam Trenholme's webpage
This article was posted to the Usenet group alt.hackers in 1995; any technical information is probably outdated.

Re: Hacker FAQ (please comment and help fix)


Article: 7675 of alt.hackers
From: heikki@lsd.ping.dk (Heikki Levanto)
Newsgroups: alt.folklore.computers,alt.hackers
Subject: Re: Hacker FAQ (please comment and help fix)
Distribution: world
Message-ID: 950416.232511.4Y5.rusnews.w164w@lsd.ping.dk
Date: Sun, 16 Apr 1995 23:39:43 +0200
Approved: Of course not
Organization: LSD - Levanto Software Development
X-Newsreader: rusnews v1.12a
X-Posting-Software: UUPC/extended 1.12j inews (25May94 18:03)
Lines: 62
Status: RO

Just some small comments to the management discussion:

>>No, the average hacker is not going to take well to
>>spending hours doing data entry to determine if the program is working
>>correctly, assuming, quite correctly I feel, that this is better
done by
>>someone talented in mindless drudgery, and who is capable of
reporting error
>>saccurately.   And to expect otherwise is a waste.

Considering myself somewhat of the hackish nature, let me
share here a hackish solution to the boring testing phase.
May it serve as the ObHack for this post.

1) generalise it enough to make it interesting
2) Let the machine do the hard work

In practice I have gained quite some respect from my bosses
by adding a test machine interface to an application, so
that with suitable command line switches (that a mere user
would never try to use anyway) the program can build its
own record/playback macros, with automatic comparision to
expected output etc. A test run from the papers used to take
a day and a half, now it takes an hour, during which I can
play games. If a stupid manager asks what I'm doing, I can
always explain that I am running a two-day test in an hour,
and that this (playing games) is the most effective way to
do it ;-)

As a side effect, we have caught half a dozen of bugs in
"ready-to-be-shipped" versions, once missing a deadline, but
with great approval from the management when we explained
what it would have meant if we had shipped that thing out...



>>>} 2.3:        My hacker is constantly doing things unrelated to
her job
>>>}     responsibilities.
>>>}
>>>} A:  Do they need to be done?
>>>
>>>That's not for the hacker to decide.  Period.  The question of what
>>>"needs" to be done and what resources should be devoted
to it are
>>>management decisions, not idle I'm-amusing-myself decisions.
>
> Yeah, us hacker ain't smart enuf to make those kinda decisions.  Bullsh!t.
> It it needs to be done, and I'm in a position to do it, I probably will.
> If it slows my work on my end of the project, I'll stay an extra hour
> that day.

I think this is a sign of the hacker showing more
responsibility than the management. When a customer calls
at a time when nobody else is around (when management has
already gone home), and has a pressing (preferably
technical) problem, then the hacker may well solve that
problem here and now, in less time than it would take to ask
the managers permission. And get the customer off the hook
tonight, instead of next week when someone has taken the
time ot decide if this thing is our problem or not. What
kind of company will not benefit from that?

Heikki Levanto
LSD - Levanto Software Development
(owned and run by I, Me, and Myself alone)



Parent gone Parent

Child

Back to index