14 Jun
2023
14 Jun
'23
9:39 p.m.
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(a)gmail.com> wrote:
On Tue, Jun 13, 2023 at 1:03 PM Clem Cole
<clemc(a)ccc.com> wrote:
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.
On Mon, Jun 12, 2023 at 7:50 PM G. Branden
Robinson <
g.branden.robinson(a)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 > 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.