[COFF] Re: UNIX and its users - new or old

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 7176 bytes --]

Dan, I suspect that we are more in agreement than you might recognize.
 Your *Guide vs. Guild* is spot on.  I don't have a problem asking
questions, and as you know, I answer many newbie questions WRT SIMH,
PiDP-x, and the like, as well as ask questions about stuff I am not
familiar with.   I have had an issue with a questioneer when the reply to
the question is: "*Here is how to learn the answer* " (*i.e*.*, teach the
questioneer how to find the solution),* but if said party is unwilling to
do the background work (or the suggested work from the answer) - but just
wants to be spoon-fed for that particular issue so they can move on,
instead of* learning how to solve* it and hopefully the next issue
themselves.

Someone asking a question is fine with me.   And answer from me, or you may
offer a small reminder of *here is how to learn*.   Asking -- "*Folks, I
can't be the first person that ran into this ... what can I read'/where can
I learn/is there a tutorial/book, etc. that explains/has an example on how
to do X*" is a perfectly fine question (we get them on simh all the time as
an example).   Even "*I'm stuck, and I'm getting this result when I try ...*"
 So *h**ow you ask* your question helps, of course, that is, please try to
demonstrate that you have done some work already but are currently running
into a dead end.

That said, as you point out, *how you answer* is just as important.   RTFM
or see-figure-one are not ok answers - tempting as they may seem to be.
 But I think it is ok to say: "*If you look here ... read this
book/document, you should be able to figure it out*"  is a fair reply and
not acting like the "Guild" -- that, to me, is guiding.    But if the same
user just asked the same question on a different list when they were
pointed to on how to find that answer, that is not the proper answer.  The
trick for the OP is to try to do your homework and show how/why you are
stuck - what don't you understand - so you can be guided and demonstrate
you actually want to learn.

WRT to respect each other and look at each other as peers.  Amen.

For all my joking, I think it's great that you, Branden, et al. have taken
the reins from folks like me and are keeping alive the ideas and techniques
we started years before. I thank you both (and the others out there I have
not directly recognized) for your efforts, and I think you two both do
learn and look to lists like COFF and TUHS as amazing resources where you
can both learn and contribute (as a peer).  Note I learn from both lists
all the time.   But I do reserve the right to sometimes ask as a master,
passing on knowledge (like why ignoring/denigrating Fortran is at your
peril).  I did try to do it humorously, and I'm even happier that Branden
caught my probably bad/poor taste - Kung Fu joke.

Respectfully,
Clem
ᐧ

On Wed, Jun 14, 2023 at 9:34 AM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Jun 13, 2023 at 1:03 PM Clem Cole <clemc@ccc.com> wrote:
> > On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson <
> g.branden.robinson@gmail.com> wrote:
> >> The BSD advocates I knew back in the day suggested that this was my
> fault for not locating and apprenticing myself to such a master;
> >> the guild mentality was, and in some ways still is, powerful there.
> >
> > This is a fair point and is actually true of almost any system or, for
> that matter social setting, if you have a guide it's a lot easier to know
> what to do or fool people into thinking you do; Liza Doolittle style.
>
> Forgive me, Clem, but I'm going to push back on this a little bit. The
> TL;DR of my position is, "guides, yes; guilds, no."
>
> I agree with the idea that having a friendly guide to help one
> acclimate to a system is really useful: provided that guide is
> actually friendly and helpful. I find that the interaction works best
> when people regard each other as peers, with one imparting specific
> knowledge to the other to fill in gaps in the latter's experience. I
> find it works very poorly when one side is arrogant and belittling
> towards the other. I believe that the "guild" mentality encourages the
> latter behavior, with an "in-group" that demands unearned respect.
> Mutual respect works much better.
>
> Moreover, adoption of this guild model (really, the mentality) with
> partitioning people into groups of "apprentices", "journeymen" and
> "masters" has allowed for the rise of charlatans and cranks across the
> industry. Consider people like Robert Martin: he's become known as a
> "master software craftsman", has published many books that sell well,
> and speaks at conferences across the industry. And yet, near as I can
> tell, he hasn't actually written all that much software; certainly not
> much that is publicly available. What is there shows that he is a
> middling programmer at best; certainly not worthy of the accolades
> heaped on him.
>
> Same with people like Allen Hollub, who's biggest claim to fame seems
> to be writing a book on compilers that is mostly material regurgitated
> from the Dragon Book (but in poorly-written C), and who infamously
> rails against things like issue trackers (seriously: tell me you've
> never worked on a big project without telling me that you've never
> worked on a big project). Then there's the rest of the agile
> influencer cult; mostly more of the same.
>
> >> To bang an old drum of mine, while Unix culture pats itself on the back
> for economizing keystrokes with an ad hoc compression scheme for every
> >> name in sight, it too often overlooks what discarded in pursuit of this
> form of minimality: clarity, lack of ambiguity, and ease of acquisition by
> newcomers.
> >
> > Again fair - which is why I think losing things like the old UNIX (I
> think bwk originated) 'learn system' from the stock releases is a little
> sad.   I used to tell newcomers - to spend an AM with learn and go through
> the files/more files/vi scripts and then come back to me, and I'll try to
> help you.
>
> There is a qualitative difference here. Being willing to mentor and
> (importantly) providing access to learning materials is very different
> from being disdainful for those who don't already "have a clue". Being
> friendly and helpful is also qualitatively different from demanding
> groveling behavior from the "apprentice" caste before they can be
> allowed some scraps from the table. I argue that the "guild" mentality
> leads to the latter.
>
> > My line was that UNIX always had a more difficult learning curve than,
> say GUI based systems (or even some of the old DEC ones likes TOPS or VMS),
> but once you learned the tools and ideas, it was much simpler to use - made
> more sense (to me certainly). [Teach someone to fish, vs. give them one
> idea].
> >
> > But as you point out, that only works if you have someone(s) to ask.
>
> ...and that person is not a jerk to you for daring to ask a question
> they don't already know the answer to. That, I think, is the
> fundamental difference that G. Branden was trying to highlight.
>
>         - Dan C.
>

[-- Attachment #2: Type: text/html, Size: 9854 bytes --]