Re: Hacker FAQ (please comment and help fix)

Article: 7649 of alt.hackers
From: hacker@ns.secis.com (Tommy Usher)
Newsgroups: alt.folklore.computers,alt.hackers
Subject: Re: Hacker FAQ (please comment and help fix)
Date: 13 Apr 1995 15:03:19 GMT
Organization: SouthEast Information Sys
Lines: 533
Approved: Yes! But not by Bernie!
Message-ID: 3mjefn$rgi@news.cais.com
NNTP-Posting-Host: ns.secis.com
Status: RO

In article <D6y5IL.EGK@world.std.com>,
Bernie Cosell <bernie@fantasyfarm.com> 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.  Expecting anyone doing
creative work to simply jump through hoops on command is idiocy, but sadly a
very common idiocy.

>I almost think our craft would be better served be a FAQ for hackers
>giving them a hint about how to exist in and be a useful part of the
>real world, rather than a FAQ for employers on how to tolerate the
>bunch [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].

First off, you presume that hackers would care.  You want to have your cake
and eat it.  You want the creativity and dedication of the hacker, but in an
easily manageable, bureaucracy-friendly package.  As though this were a
simple matter of telling a hacker the facts of life.  Again, you raise this
idea of 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.  And companies that recognize this, and even nuture
it, are often more successful than those that try more traditional forms of
managagement.

>NB: I've removed alt.hackers from the newsgroups.  I have no interest
>in exerting even the minimal effort to forge an approval (I assume
>that alt.hackers is still the no-moderator moderated list it used
>to be), and I suspect that few in that newsgroup will much want to
>see what I have to say, anyway....

I put it back, and boy was that forgery exhausting.  To be honest, I really
have to wonder if you know how to forge such a thing.  But that is not really
the issue.  No, maybe some there would not appreciate your view, but they,
perhaps more than any others, have a right to comment.

>} Section 0: Basic understanding.
>}
>} 0.0:	Won't my hacker break into my computer and steal my trade
secrets?
>}
>} A:	No.  Hackers aren't, contrary to media reporting, the
people who
>}	break into computers.  Those are crackers.  Hackers are people who
>}	enjoy playing with computers.  Your hacker may occasionally
>}	circumvent security measures, but this is not malicious; they just
>}	do it when the security is in their way, or because they're curious.
>
>Indeed, and generally with NO regard for the repercussions or ramifications
>of subverting the security.

Actually, probably more so, and with a better perception of the realities
involved, than the system administrator.  A hacker has no desire to wipe out
his creation by a careless violation of security, but he also often recognizes
the silliness of some systems excesses.

>} 0.1:	Was it a good idea to hire a hacker?
>}
>} A:	It depends on the job.	A hacker can be dramatically more
effective
>}	than a non-hacker at a job, or dramatically less effective.  Jobs
>}	where hackers are particularly good are:
>}		Systems administration
>}		Programming
>}		Design
>
>I disagree [having seen *TONS* of code produced by hackers over theyears
>[and even having been considered one to some extent, this back before
>some of you were born].].  The key qualities, I think for hacker-suitable
>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.

>   2) you don't particularly care if it is ever properly documented, really
>	  quite finished, if it really does exactly what you wanted it to do or
>	  if anyone else can effectively work on it.

Here you are completely off the mark.  Of course, the first depends on your
definition of "properly documented."	If you don't have a sense
of humor, no
you probably won't appreciate the documentation a hacker might produce.  If
you are looking for dry technical prose, you probably won't get it.  If you
want something that is actually fun to read, AND which explains what is going
on, then that is another matter.  Getting the job finished?  Is ANY program
ever REALLY finished?  Shipped, yes.  But there is always room for
improvement.  In most cases, the program may well exceed specifications.  And
the question of others working on it, is amusing.  You hire a hacker because
he is a superior programmer, but then you want something that any drone could
crank out, that is so simple that any idiot can fix it, and that is so poorly
designed that it is a waste of memory and resources?  Do I detect a
contradiction here?

>As for systems administration, again I disagree: in a proper world
>where security must be taken account of and things have to be paid
>for (and so accounting and access controls have to be dealt with),
>hackers aren't great about maintaining paperwork, adhering to
>adminstrative procedures, honoring the chain of command, etc., I'm not
>convinced a hacker is going to be a good choice for my sys admin.  [if
>you only focus on things like amazing sendmail hacks and stuff like that,
>then yes, but it is the dull stuff done well that really makes for the
>well-run system].

In another words, he is not going to produce reams of useless reports that
serve only to stroke the ego of someone who requires it, but hasn't the
foggiest idea what it really means?  He isn't going to follow mindless
procedures that are not well thought out, but were put in place because
they are the latest thing in management theory?  He not going to let
bureaucracy get in the way of the job?	In short, he is not going to bow to
the whims of some former programmer, who really hated programming, and who
couldn't wait to get into management.  Or worse, the whims of someone who
doesn't even know how to turn the computer on, but is convinced he knows how
to manage programmers.

>}	The good news is, if you get a hacker on something he particularly
>}	likes, you will freqently see performance on the order of five
>}	to ten times what a "normal" worker would produce.
This is not
>}	consistant, and you shouldn't expect to see it all the time, but
>}	it will happen.  This is most visible on particularly difficult
>}	tasks.

>Actually, only on particularly difficult tasks that happen to amuse
>the hacker.  And even if you have a deadline staring you in the
>face, if the hacker takes a fancy to square dancing or optimizing
>some loop in some other project's code, _your_ project may well go
>down the tubes [and since hackers aren't good about design,
>planning, design reviews, etc, there's no way to supplement the
>situation: you're basically screwed until the hacker, out of the
>goodness of their heart, feels like turning their attention back to
>your petty matter].

Actually, you go a bit too far in your stereotype of the hacker.  Most of us
are well aware of deadlines, and will work to meet them.  In fact, we may well
view the deadline as a particularly difficult challenge that amuses us.  And
as I have oft quoted, "Designers make designs, hackers make
programs."  In
another words, the hacker won't waste his time on flowcharts and such, but
will do his work at the computer.  He will produce the code without producing
200 pages of documentation explaining how he plans to produce the code, first.
Actually, I suspect you speak from experience, probably as a result of having
some hacker irritated enough to let you stew in your own juices.

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

Again, you are wrong.  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 errors
accurately.   And to expect otherwise is a waste.  I know from personal
experience, it is easy to miss bugs, perhaps because you subconsciously work
around some possible problem.  Or because you know that the number in a
given field is expected to be below a certain value, you never enter a larger
one by mistake.  Or you never enter a longer name than the field is designed
to hold.  Or you tend to use the same values, over and over, which means you
may well miss a common value that can crash your program.  (This last one, I
have specific knowledge of.)

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

No, we just don't believe it buys respect for people who don't deserve it.  I
bet you are in management, aren't you?	And I bet you really couldn't wait to
get away from coding.  Right?

>} Section 2: Productivity.
>}
>} 2.0:	My hacker plays video games on company time.
>}
>} A:	Hackers, writers, and painters all need some amount of time to
>}	spend "percolating" - doing something else to let their
>}	subconscious work on a problem.  Your hacker is probably
>}	stuck on something difficult.  Don't worry about it.
>
>Translation: hackers refuse to be reasonably managed and refuse to
>consider themselves professionals.	Rather, [again] just misunderstood
>artists forced to tolerate this ugly workaday world in deference to
>rent and food.

In another words, we are creative people, who don't fit some suit's
pigeonhole.  In another words, we sometimes need to take a break, and let
our subconscious work.	If you cannot relate to this, it just confirms my
theory.  You may have been a programmer, but you hated it, and have since
moved to management.


>} 2.1:	But it's been two weeks since I saw anything!
>}
>} A:	Your hacker is working, alone probably, on a big project,
and just
>}	started, right?  She's probably trying to figure it all out in
>}	advance.  Ask her how it's going; if she starts a lot of sentances,
>}	but interrupts them all with "no, wait..." or "drat,
that won't
>}	work", it's going well.
>
>Right, and as the deadline approaches and your customer starts threatening
>penalties for the deliverable not being ready on time, you can only
>pray that your unmanageable, uncommunicative hacker is:
>  a) actually working on the problem you need solved,

Most likely.

>  b) is actually nearing some sort of closure

Probably more so than you realize.  And may well make it if you don't do
something stupid, like adding more programmers.

>  c) has any prayer of getting it done ever, much less on time.

Again, do you have the good sense to let them?

>  d) gives any shit at all about your business and the interests of your
>	 company and your client, rather than assumes that you pay their
>	 salary out of awe of their talent and prowess and so view anything
>	 they deign to actually *DO* as being gravy.

Actually, like was said earlier, such an attitude indicates that you look
down on your programmers.  Is this REALLY reasonable?  Yes, YOU pay THEIR
salaries.  Why?  Becuase you, quite frankly, are too untalented to do their
jobs.  You want a very one-sided relationship.	You want them to see you as
the salary, but don't really need them.  You take the view of the man who
just about destroyed Atari.  He had worked in textiles, and said of the
programmers, "Damn it, they are just towel designers!"  He had
the mistaken
view that ANYONE can program given sufficient training.
>
>} 2.2:	Isn't this damaging to productivity?
>}
>} A:	No.  Your hacker needs to recreate and think about things in
>}	many ways.  He will be more productive with this recreation than
>}	without it.  Your hacker enjoys working; don't worry about things
>}	getting done reasonably well and quickly.
>
>The problem here is the definition of "working".	Hackers don't
>enjoy "working", they enjoy doing whatever suits their fancy
at the
>moment.  If that's redoing the file manager because compiles are
>going too slow, rather than working on the actualy project at
>hand... well tough [and even more fun: you won't even have a way to
>*KNOW* that your precious hacker is off in the weeds, since
>documentation, schedules, plans, reviews, etc, are all the sops of
>the drones, not the stuff to waste the time of the _real_ wizard].


While at times, a hacker may become distracted by another problem, or attack
some other area of the code, that is not of immediate concern, if you don't
panic, you may find that the ultimate impact is positive.  For example, one
one project, I was bothered for some time, by a piece of code I had not
written.  It was a conversion routine from ASCII to floating point, and it
played a major role in the program.  The code in question, was supplied by
the company we had purchased the compiler from, and seemed quite bloated and
slow to me.  But the offical attitude was, it works, don't touch it.  Well,
one afternoon, I couldn't stand it any longer.	In about an hour, I had a
brand new routine, which I quickly tested and linked into my program.  In my
rush to finish, I missed a couple of minor bugs, otherwise no one would have
noticed.  The tester caught them the next day, and was rather puzzled that
code that had worked fine seemed suddenly buggy.  When I found out, I fixed
the error, that took about five minutes, and explained to my immediate
supervisor what happened.  He was a bit put off, more because he felt caught
between me, and upper management.  But the new code worked fine, was faster,
took up less memory, and gave me a certain satisfaction which had been
lacking.
>
>} 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.

See the above.	The problem with what you say is, management usually knows
little or nothing about programming, but they refuse to admit this.  They
insist that they know how to do things better, when if they did, they would
be doing them, rather than hiring programmers.	It is this insecurity which
manifests itself in a need for control that leads to problems.	Perhaps if
you actually tried listening to the hacker, rather than making the demand
that they bow and scrape at your feet, accepting your every word as holy
writ, you might not have this problem.

>} ..  Very few hackers can resist solving a
>}	problem when they can solve it, and no one else is solving it.
>}	For that matter, is your hacker getting her job done?
>
>As you've said *yourself*, there's no way to know: you've offered an
>apologetic for unprofessional conduct, misuse of corporate resources,
>sloppy time management.  I sure hope you didn't put the hacker on an
>important project for your business, because if that rock climbing
>trip comes up you're down the tubes...

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 bureaucratic
poppycock.

>} 3.1:	My hacker did something bad, and I want to punish him.
>}
>} A:	Don't.	30 years of psychological research has shown that
>}	punishment has no desirable long-term effects.	Your hacker
>}	is not a lab rat.  If you don't like something your hacker is
>}	doing, express your concerns.  Explain what it is that bothers
>}	you about the behavior.
>
>Hee hee hee...

Yea, I bet punishment is your favorite part of management.

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

And I bet you can't handle disagreements from those who you are really not
in a position to disagree with.

>}	Don't be afraid to apologize if you're wrong.  If your hacker
>}	admits to having been wrong, don't demand an apology; so far
>}	as the hacker is concerned, admitting to being wrong *is* an
>}	apology, most likely.
>
>Great: an not even a crumb to the notion that management might be
>entitled to more professional conduct.  Just turn 'em loose and
>pray that they won't sell your business down the river again on the
>NEXT project as they get entranced with putting improvements into
>mazewar instead of actually finishing up the auditing and security
>package thow dullards over in accounting keep nagging about...

In another words, "Management is always right, no matter how clueless they
are."  You know, it isn't the hackers that are going to sell the company
down the river...

>} 4.1:	I can't get an estimate out of my hacker.
>}
>} A:	Your hacker hasn't figured out how hard the problem is yet.
>}	Unlike most workers, hackers will try very hard to refuse to
>}	give an estimate until they know for sure that they understand
>}	the problem.  This may include solving it.
>
>Unlike most workers, hackers will not bow at all to the notion that
>there is anyone in the universe even an iota smarter than they are
>[and this even from pretenders-to-the-title who are barely more than
>incompetent, but *FANCY* themselves "hackers"].  Thus, they
conduct their
>"work" in such a way that it is impossible for:
>  a) anyone to make sure they are working on the right problem

Which you are, of course, convinced that they are not.	After all, you know
quite well tha they are actually evil, unprofessional types, just looking
to steal the company blind while actually porting Pac-Man to run on the
company Cray.  So you, of course, are completely justified in maintaining
excessively tight and repressive control of their every move.

>  b) make sure their proposed solution will actually fit within
>	 the constraints of the project and the business considerations
>	 around it.

Again, if you showed a bit more trust, you might come to realize that people
often live down to your expectations.  Much of this is, in some cases, going
to end up as self-fulfilling prophecy.

>  c) to realize that the project cannot rationally be done within its
>	 constraints [either inherently or because of the "particularly
>	 elegant" way thehacker chooses to solve the problem] and so
>	 some other approach may be required [change the scope of the
>	 project, change the schedule, change the staffing, who knows..]

This is where we find that ignorance is a very dangerous thing....but more
in the next section.

>}	No good engineer goes beyond 95% certainty.  Most hackers are
>}	good engineers.
>
>IMO this isn't true.  Hackers are notoriously bad at providing
>design and documentation; they are notoriously bad at _finishing_
>things [i.e., doing the dull parts once the
>little-bit-in-the-middle that caught their fancy has been wrestled
>into submission]; they are notoriously bad at working on projects
>larger than one-person [since they communicate and plan so poorly,
>anything that cannot be done via a "turn in loose for six months
>and *pray* that what you get at the end bears some resemblance to
>what you need" project is a bad choice to put a hacker on].; they
>are notoriously bad at making the real-world tradeoffs that have to
>be made when things like money, customers, schedules, contractual
>requirements and such intrude on their artistic endeavours.

You know, this problem arises from an error on the part of management.	And
that is the belief, born of desire, that creativity can be doled out in
a measureable form.  That one can predict, with absolute certainty, exactly
how long a project will take.  As in, "Yes sir, we can write the operating
system to these specifications in exactly 3 months 14 days 12 hours 27 minutes
and 19 seconds."  Or perhaps you prefer the man/hour.  First, you
erroneously
demand an estimate, while pressuring for a short time.	Then, when you reach
the completely imaginary finish date, you go ballistic because the estimate
was completely erroneous.  Having followed typical management philosophy,
"We
never make mistakes, so we never learn from them," you demand a NEW
estimate,
with even more pressure to keep it short.  This goes on until the project is
finished.  And then, surprise, surprise, you wonder why the hacker gets very
angry when you ask for an estimate on the NEXT project?  This is why I prefer
a flat rate for a job.	That way there is no accusations of stalling in
order to earn more money.  Which is some cases, is quite removed from the
truth.	In some cases, I am trying as hard as possible to finish, so I can
get away from some clueless luser who knows nothing about programming.

>} ..   If you say you will not try to hold him to
>}	the estimate (and mean it!) you are much more likely to get
>}	an approximate estimate.  The estimate may sound very high
>}	or very low; it may be very high or very low.  Still, it's
>}	an estimate, and you get what you ask for.
>
>A clear betrayal of the fact that you haven't the beginning of a
>clue of what estimates/plans/designs/etc are all about and what
>purpose they serve.  The position that ones schedule, ones
>availability to [perhaps] work on something else, that OTHER groups
>might ahve to coordinate with your work, etc, etc...  are all
>anathema, spell the death of "art" and are certainly not the
>concern of the "hacker" is one that makes clear [to me,
at least],
>that *I'd* never hire a hacker.

Wrong.	The hacker knows exactly what the true value of an estimate is, and
acts accordingly.  In another words, the emperor has no clothes.  The
estimate is a meaningless piece bureaucracy that gives management something
to do.	And on behalf of hackers everywhere, let me be the first to thank
you for the promise not to hire us, since we would most certainly not want
to work for the likes of you.  Quite frankly, some have the ability to
reach a symbiotic and productive relationship with a hacker.  You clearly
wouldn't.

>Not only do I find this misunderstood-artist/adolescent's grasp of
>where their paycheck comes from  view of the world NOT persuasive
>to me.  But I think it is a VERY bad sign that our profession/craft
>has not grown beyond this in the 30 years since these notions were
>first being shaped at MIT [at TMRC and RLE and later the AI-Lab] and
>at SRI.  It is a terrible shame that the most creative, talented and
>capable among us find it SO hard to be disciplined.  That they find
>it so hard to conduct themselves a way that their employer and the
>profession can benefit from their expertise, insight and wisdom rather
>than their product being little more than another not-quite-debugged,
>under-documented program that no one else on the staff is willing
>to mess with [what?  Adhere to a company's programming standards and
>have that interfere with true expression?  Outrageous...].

You know, you are like the L.A. District Attorney's office.  You really don't
have a clue.   You have this bizarre belief that creativity can be
disciplined.  That, again, you can have your cake and eat it too.  That
you can reap the benefits of the hacker's creativity while offering nothing
except a paltry paycheck in return.  That the hacker should be so grateful
to you for this check, that when he is not cranking out code, he is bowing
and scraping at your feet.

>I know that for me [and I wish for more hackers, but obvioulsy it is a
>futile wish] there was a magical day when I realized:
>  1) programming is mostly just a waste of time.  The interesting
>	 part is the planning and problem solving.  A properly analyzed and
>	 designed system can be implemented by MUCH less talented personnel
>	 than it took to get the design right in the first place.  [and so
>	 personnel who view "programs" as their product, rather
than designs,
>	 plans, schedules, etc, are _automatically_ lower in the intellectual
>	 food chain [regardless of their opinion of themselves

In another words, you were a lousy programmer.	Or perhaps your really hated
it.  Or most likely, both.  You probably chose programming because, hey,
that was where the money was.  But you found that a)you were not that good,
b)your really wanted to go into management.

>  2) Working in the world of ideas and plans and designs, rather than
>	 lines of baroque code, gives the hacker a multiplier: the hacker can
>	 have the fun of doing the "really hard stuff" and then
have an *army*
>	 of those lesser-folk work away on making it come to pass [meanwhile
>	 the hacker can be working on something _else_ interesting].  It is
>	 an amazing thing to see a large team build something that NO ONE on
>	 the team really quite understood [except you!] and have it all end
>	 up working _better_ than anyone would have guessed.  [and with the
>	 hacker-in-charge having not written a single line of code!  JUst
>	 doing all that boring stuff: design reviews, meetings, schedules,
>	 frontloaded documentation, etc].

You don't get it don you?  Hackers don't want an army of lesser-folk messing
with their creation.  First off, while we may look down on those who are
less intelligent, less talented, and generally incompetent, we only do so
when they presume to tell us how to do our jobs.  We do not share YOUR lust
for power.  We simply want to be left alone, and allowed to do our work.

>  3) That dealing with real-world constraints makes problems HARDER [and
>	 so arguably more interesting to the "true hacker"],
rather than
>	 the ivory-tower disdain of mere reality.   That a program that is
>	 a polished jewel of intellectual purity is a waste of disk space if
>	 it doesn't meet the customer's needs and requirements.

Yes, this is true.  But again, this is not really the issue.  The question
comes down to, the hacker wants to do it right, management just want's
something finished, no matter how poor it really is.  A hacker realizes that
no program is ever perfect, and if we have a major fault, it is that.  We
don't always want to let go, because WE know how bad it really is.  When I
look at some of the garbage being sold, I wish that a few more hackers had
their way.

>	--->>>    Too many people; too few sheep    <<<---

Now why doesn't this surprise me?

--
+----------------------------------------------------------------------------+
| Tommy Usher  No Frills Software | Lubarsky's Law of Cybernetic Entomology: |
| hacker@ns.secis.com		  | There's always one more bug.	     |
+----------------------------------------------------------------------------+

Child Child Child Child Child Child Child Child Child Child Child Child Child

Back to index