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: 7655 of alt.hackers
From: (Nathan Waddoups)
Newsgroups: alt.folklore.computers,alt.hackers
Subject: Re: Hacker FAQ (please comment and help fix)
Date: 14 Apr 1995 08:12:57 GMT
Organization: Northwest Nexus Inc.
Lines: 227
Approved: by just another 'hacker'
Message-ID: 3mlaq9$
Status: RO

It's been interesting to see the management<->hacker interactions
in the FAQ and the ensuing debate...

As someone fortunate enough to work at a company that is full of hackers
and very good hacker-managers, I'd like throw in some comments of my own... (Tommy Usher) writes:
>In article <>,
>Bernie Cosell <> wrote:
>>In article <3lucq9$1b7@mangrove.Intran.Xerox.COM>, Peter
Seebach writes:
>>} Enclosed is a very rough draft of a much needed document.
The goal for
>>} this document is that it be something you can hand your manager
and say
>>} "see?  there are other people like me".
>>I dunno.  This whole FAQ feels a bit misguided to me.  I think a
>>lot of this "I'm a hacker" stuff is vastly overrated.
I wonder if
>>our profession wouldn't be a LOT better off if the best of us
>>started thinking of ourselves as professional engineers rather than
>>of misunderstood artists.

>I disagree.  I have been in situations where such a document might have
>actually helped.  And I think we would be better off if more in management
>realized that programming, as well as other forms of engineering, ARE
>ultimately forms of creative thinking, and as such cannot be easily reduced
>to something that can be managed without real effort.

I agree, but there is something to be said for posting a 'how do I deal with
silly managers and coworkers' FAQ as a companion document, though.

>Expecting anyone doing
>creative work to simply jump through hoops on command is idiocy, but
sadly a
>very common idiocy.

No question about it.  While my personal situation is excellent, we're
working closely with a company with a radically different management
style, one which would undoubtedly cause many of the best engineers here
to seek worse elsewhere (or not to try to get here in the first place).

I mean, it's really sad what management can do to stifle productivity.

Allow me to snip a previous argument and its rebuttal, perhaps changing
the original meaning somewhat, but making what I feel is an important point:

>> [and it is amazing: if you take a step backfrom the FAQ, it
>>reads more like a FAQ on how to take care of a rare, fragile tropical
>>fish than it does a top-shelf engineer].

> Good engineers are creative.  Creative
>people are often, shall we say, eccentric.  Eccentric people are,
by nature,
>sometimes hard to manage.

If I may interrupt (of course I can, it's the usenet), there's a parallel
path of reasoning: good engineers often (and often with good reason) see
management as a necessary evil, something that impedes their progress more
than it should.  This can make them difficult to manage.

>And companies that recognize this, and even nuture
>it, are often more successful than those that try more traditional forms of

Agreed 100%.

[snippage, and on to a new point of contention]

>>}	circumvent security measures, but this is not malicious;
they just
>>}	do it when the security is in their way, or because they're
>>Indeed, and generally with NO regard for the repercussions or
>>of subverting the security.

Let's not confuse being a 'hacker' with being immature.


>>I disagree [having seen *TONS* of code produced by hackers over
>>[and even having been considered one to some extent, this back before
>>some of you were born].].  The key qualities, I think for
>>jobs are:
>>   1) the job can be done by ONE person

>You are somewhat correct here.  Of course, this is as much function of the
>quality and personalities of the other programmers, as anything.  Quite
>frankly, we don't work well with people who are faking it.	I know, I have
>been there.

I work directly with at least a dozen people whom I feel have the 'hacker'
essence, and indirectly with a couple dozen more.  The project I'm on has
plenty o' people bumping elbows as they crank out and debug code.

People who are 'faking it' are for the most part working on peripheral
areas of the system, so the rest of us can cooperate more efficiently.
Managed well, hackers CAN work together, and quite well.

[skipping the documentation and sysadmin bits, as I don't have much to say]

About deadlines and challenges: trust me, we've got way too many of each
over here.  Again, let's not confuse the 'hacker' with the 'immature.'

>>Another aspect is that hackers aren't good at *finishing* things,
>>which makes their propensity NOT to adhere to those dull-as-dust
>>software engineering procedures and guidelines more of a problem:
>>they'll get bored when the hard stuff [according to THEIR metric,
>>not yours] is done and as for actually finishing it and fully
>>debugging it?  that's for the drones...

You've been dealing with workers who have got problems that go beyond the
'hacker' issue.  Seeing a product finished and ready for public
consumption is only difficult if the engineers don't take pride in their
work.  A hacker with a shred of maturity and pride in his/her work will
polish the UI until a child (even an adult) can use it with no problem.

>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
>accurately.   And to expect otherwise is a waste.

I just started a debate a coupleof days ago with our big cheese in QA
about this very issue.	We'll see how it turns out.  I'll be surprised if
I have to run another half-hour test case again.

>>} 1.2:	My hacker won't call me by my title, and doesn't seem
to respect
>>}	me at all.
>>} A:	Your hacker doesn't respect your title.  Hackers don't
believe that
>>}	management is "above" engineering; they believe
that management
>>}	is doing one job, and engineering is doing another.
They may well
>>}	frequently talk as if management are beneath them, but this is
>>}	really quite fair; your question implies that you talk as if
>>}	engineering is beneath you.  Treat your hacker as an equal, and
>>}	she will probably treat you as an equal - quite a compliment!

Here (did I mention that the company is ConnectSoft?), people don't have
titles.  I mean, everyone has a title on their business card, but that's
as far as it goes.  First name basis, period.

>>ROTFL.	Hackers believe, apparently, the the money that pays
>>their salary comes bubbling up from a hole in the ground, and so
>>contracts, sales, customers, marketing plans, etc, are all just
>>nonsense getting in the way of the true artiste plying their

The money that pays our salaries here comes from the sale of the fruits
of our labor.  The marketing teams certainly deserve appreciation for
the work they do to help the stuff sell, yes.  Ditto for the folks that
find us the contracts.	They do their job, we do ours.	How come they
deserve to be treated differently?

They don't.  They aren't.  Everyone is part of the same larger team, and
everyone treats everyone else like a teammate.

>>} Section 2: Productivity.
>>} 2.0:	My hacker plays video games on company time.

Personally, I think that's bad.  Plenty of people here have Descent
installed on their hard drivers, but to my knowledge nobody would be lame
enough to put 'played games' on their timesheet.  I'm running telnet from
my development station, but I clocked out almost an hour ago...

Using company hardware to blow of steam is one thing, but billing
(stealing?) the company for that time is quite another.

>>} 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.

2.3.1: My manager is constantly messing with my code.

	a: did s/he fix any bugs?

That's not for the manager to decide, period.

	Yeah, right...

>Again, it is clear that your definition of professional conduct involves a
>lot of bowing and scraping, a lot of ego stroking, and a lot of

There's a guy here who feels that way about professional conduct.  He's
the only one in the building that wears a suit when the clients aren't
here.  He had a windowed office until a couple of weeks ago.
Productivity counts, appearances don't.

>>}	Be prepared for an argument; your hacker is a rational entity,
>>}	and presumably had reasons.  Don't jump on them too quickly;
>>}	they may turn out to be good reasons.
>>Hee hee hee.

If you treat your employees with that kind of attitude, it's no wonder
they treat you with the same respect.  If you feel that they have nothing
to say that is worth listening to, how can you be surprised if they feel
that way about you?  Hacker vs. drone has nothing to do with that
phenomenon.  It's human nature.

This is getting silly.

Look around you.  Any hackers left?  You've probably managed a few in the
past.  They all left, right?  They work here now.  They put in 60 hour weeks
and they get a huge amount of work done.

ConnectSoft has double in size since I started, less than a year ago.
We occupy two full buildings and have client references ranging from
Aldus to V-Graph, with UPS, MCI, Microsoft, IBM, and Nordstrom in between.

>>*I'd* never hire a hacker.

Cool.  Good employees are hard to find, and WE're always looking for more.
 Want to see Opcode's MAX software ported to Windows? Send your vote to me
 or	 We're going to send the petition in to Opcode....

Parent Parent gone

Child Child Child

Back to index