[COFF] UNIX and its users - new or old

[Dan Cross]

On Tue, Jun 13, 2023 at 1:03 PM Clem Cole <clemc at ccc.com> wrote:
> On Mon, Jun 12, 2023 at 7:50 PM G. Branden Robinson <g.branden.robinson at 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.