Re: Hacker FAQ (please comment and help fix)

Article: 7664 of alt.hackers
From: seebs@solutions.solon.com (Peter Seebach)
Newsgroups: alt.folklore.computers,alt.hackers
Subject: Re: Hacker FAQ (please comment and help fix)
Date: 14 Apr 1995 22:55:20 -0500
Organization: Solutions Online
Lines: 371
Approved: seebs@solutions.solon.com
Message-ID: 3mng38$e3k@solutions.solon.com
NNTP-Posting-Host: solutions.solon.com
Status: RO

I'll just start by warning that, while I disagree with you strongly, I
*do* appreciate the criticism and commentary.

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.

Any competent engineer is an artist.  If people don't know this, that
engineer is a misunderstood artist.

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

A top-shelf engineer is rare (otherwise, it'd be a mid-shelf engineer),
and they are often fragile.

Hackers know a way in which they can be a useful part of the real world.
They know what is (so far as we know, although there's a sad lack of
testing) the *best* way for them to be useful.  This FAQ aims to explain
to people who have previously only worked with mediocre programmers who
don't enjoy their craft at all, how to get good milage out of a hacker.

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

Actually, they do, and it's back in there.  This is about the core of
hacking; what are we, anyway?

>Indeed, and generally with NO regard for the repercussions or ramifications
>of subverting the security.

Actually, I've never seen a hacker past college age do something insecure
without very careful contemplation.  However, as a group, they're more inclined
to care about real-world impact than whether or not it violates an
ill-considered set of "security policies" that aren't working.

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

You're not talking about the same hackers we are.  For reference, there are
three types:
1.  Crackers.
2.  Sloppy, but moderately fast, programmers.  This seems to be what you're
talking about.
3.  Fast, and moderately perfectionist, artist-type programmers.  This is
what I'm talking about, what TNHD is talking about, and what alt.hackers is
about.

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

Once again, I think you miss the point; administrative procedures don't
keep a system running.  A competent hacker will keep the system running
better than an incompetent administrative type.  A good hacker will also
keep careful notes, and have procedures for almost everything.  Once there's
a procedure to do it, you can automate it, and you don't have to waste
your time *doing* it anymore.  Which is what good hackers aspire to.

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

You are *definitely* talking about the wrong hackers here.  Hackers are
*obsessed* with design.  Let's take a moment to compare two programs,
performing the same task, one written by a hacker, one written by
a non-hacker.

The programs are both "more".  The hacker wrote BSD more.
The non-hacker
wrote MS-DOS more.  Let's compare:

Hacker version:
1.  Works as a filter.
2.  Works on named files.
3.  Lets you quit, page by pieces, page back, or call an editor.
4.  Is robust in the face of unexpected behavior.

Non-hacker version:
1.  Works only as a filter.
2.  Detects arguments, but aborts complaining there are too many of them.
3.  Quits only on interrupt; any other key, other than return, is ignored;
return moves you ahead a page.

Which of these do *you* think shows signs of design?

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

Fully testing is best suited to drones; however, I've had a user other
than me find a bug in one of my programs twice.  Once it was in a feature
I had just added at their request, but not tested yet.  The other time it
was a compiler bug.  (gcc-1.41 dumped core on return from main, but was
fine with exit().)

>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.  But I believe that my manager is a *coworker*.  He does the administrative
stuff; I do the technical stuff.  His money comes from the same place mine
does; customers.  I produce stuff that works, or I answer questions right,
or *neither* of us gets paid.

I respect my manager; he's a good manager.  He's not "above" me.
He's not
"below" me.  I don't respect Management; I respect a particular
manager, who
has shown signs of competence, not to mention professional ethics.

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

"Reasonably managed".  So, I suppose you'd say that we shoulda
stuck with
Multics?  Unix was developed from a video game, or so They tell us.  You
get innovative new technology by letting people play.  Quick trivia
question: Has lambda calculus been taught more effectively by Lisp books
or by LambdaMOO based muds?

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

Non-existant.  You cannot "manage" people.  You can work with them.
And
your hacker will be as communicative as you are.  I've never been late
on a deadline.  Unless, that is, my idiotic, non-communicative manager
kept changing priorities on me, and refused to give me a straight answer
when I asked which 40 hours a week he wanted done first.

>  a) actually working on the problem you need solved,
>  b) is actually nearing some sort of closure
>  c) has any prayer of getting it done ever, much less on time.
>  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.

This is silly.  I know damn well what I'm paid for.  And I go a fair ways
beyond it.  (I've read my job description recently, and about 60% of my
working hours are beyond it.)

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

No, they're not stuff to attract EL1TEZ! - but we're talking about
competent hackers here, not teenagers who think they're God in a
handbasket.

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

Look, if you want people at your job to wait around for a manger to come
back from lunch, idly staring at the downed system, you go right ahead.
The rest of us are professionals, and have work to do.  If that means
I do something that the sysadmin would do if he were even in town this
week, then that's what I do.

You do what needs to be done, and let God sort it out.

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

Where in here did you see any mention of unrelated trips?  We're talking
about, say, answering questions that have stumped the development team, or
getting the system back up.  Stuff that needs to be done before *anyone*
gets any work done.

>Great: an not even a crumb to the notion that management might be
>entitled to more professional conduct.

Management is entitled to professional conduct.  I hope you're not seriously
advocating punishment; as noted, 30 years of research have shown it reduces
performance dramatically, moreso in skilled labor.

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

I've never met a hacker who played around idly when behind schedule.  Now,
if they finish two weeks early, maybe.  :)

>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
>  b) make sure their proposed solution will actually fit within
>     the constraints of the project and the business considerations
>     around it.
>  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..]

I don't think you understand.  How precisely do you propose someone estimate
time to complete a project before they've got at least a sketchy design of
what it is?

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

Maybe, but I've confirmed with N competent engineers that you don't go beyond
95% certainty until you've *done it*.

I've met a lot of hackers who were good engineers.  I've met a lot of
incompetent engineers, but none of them were hackers.

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

You are completely and utterly missing the point, and I begin to think you
do so on purpose.  I know exactly what an estimate is for; not jack shit
until you can back it up with *some* idea of how you're doing the project.

I want the Grand Unified Field theory.	About how long do you think it'll
take you?

Now *ONCE YOU HAVE A DESIGN* you can give an estimate.	And most hackers
will.  But management types are notorious for asking for the estimate
before they've really described what they think the problem is.

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

I have yet to do anything nearly this bad.  I think I see who you're
talking about; I worked with one of them once.	Utterly impossible
to work with; spent most of his time on IRC, never produced useful code,
and filled his code with very poor imitations of parts of the standard
library.

But he wasn't a hacker.

>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

Bingo.	That's why hackers design stuff, then try to get you to hire a
drone that costs half as much to implement the triviality.

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

This is not always a bad idea.	However, I find that you get your best
milage by having the wizard go after the toughest code, also, and actually
put in the prototypes and skeleton funcs.  Otherwise, the drones misunderstand
the documentation ("Where's the any key?") and screw it up.

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

Right.	I think you're actually probably a competent hacker; you've just
met too many people who called themselves hackers to recognize the use
of the term.


I think you've identified what is probably *THE* biggest weakness in my
draft FAQ; it fails to help one distinguish between the hopeless egomaniacs
of the world and the hackers.

Does anyone have any suggestions for how you tell Ken Thompson from Bill
Gates, in the general case?

-s
--
Peter Seebach - seebs@solutions.solon.com  -- seebs@intran.xerox.com
C/Unix proto-wizard -- C/Unix questions? Send mail for help.
Moderator - alt.religion.kibology, comp.lang.c.moderated
Copyright 1995 Peter Seebach.  Not for distribution through Microsoft Network.

Child Child Child

Back to index