Sorry for the delay in following this up. Comments inline below. I've
tried to prune down to shorten, and hope I haven't messed up contexts.

On Sun, 2026-03-29 at 16:41 -0400, Steve Litt wrote:
> Peter Duffy said on Sun, 29 Mar 2026 15:07:21 +0100
> > I'd argue that what I'd like to see - a kind of
> > "guild" for IT workers, regulating both skills/experience and
> > remuneration/working conditions - could potentially raise both the
> > general quality of the code, and the status of the programmers.
>
> If such a thing existed in the early/mid 1980's, I'd have never been
> able to become a professional programmer. I didn't have an "Uncle
> George" in the union (whoops, I mean guild).

I didn't say it would be easy to set up something like that up. I do
think it would be necessary to scrap most of the paradigms which were
used to set up historical guilds and organisations like the British
Medical Association and the Law Society. The new paradigm would need to
take into account the fact that the vast majority of IT people are
autodidacts and polymaths, who have gone into IT simply for the sheer
joy of striving to produce order out of chaos, and detecting an itch
and deciding to scratch it (and doing whatever it takes to do so). The
other side of that coin is that many developers don't derive much (if
any) income from the software that they develop, and have to work in
other contexts. So at least initially, membership of an IT "guild"
would need to be based on skills and abilities, rather than on income.

Maybe what's needed is a web of trust - but certifying
skills/experience rather than identity. Guild certifies someone in a
particular field/subfield, and at a particular level of
skill/experience. Certified person can then extend their certification
to someone else - who would then have the same certification and
benefits accruing from it, and can in turn extend it to someone else.
But each time the certification was extended, the onus would be on each
link in the chain to maintain the standards and quality, and any
deviation would threaten the accreditation of everyone in the chain.
The technical/practical basis for something like that is probably
already in place: X.509 v3 allows custom extensions to be included in
digital certificates.

>
> Today we have hundreds of "certs". How well do they correlate to
> performance? Not well at all. But they sure do make money for the
> guys handing out the certs and the guys with the money to buy one.
>
> Hey, I have nothing against unions. During the Great Depression, my
> aunts worked in a sweatshop and came home barfing paint every night.
> That factory sorely needed a union.
>
> But there has to be something available for us guys who don't have an
> "in" with the guild, so we don't need to spend 4 years and six
> figures on a college education just to do something most often done
> well by musicians and bicycle riders.

Totally agree. Old ideas about guilds and professional organisations
would need to be changed (or completely discarded) to reflect the needs
of members of the IT community.


>
> Do you REALLY think management would listen more to a guild
> programmer
> than today's regular programmer?
>

Not at first. It would all depend on whether the "guild" was found to
be workable, and the degree to which it was found to improve the
current situation, from the points of view of both IT people and IT
users. If that was the case, it would hopefully start to feed back into
the respect in which the IT people were held.

>
> Perl is the poster child for mistake encouraging languages. I
> understand that in 1997 Ruby, Lua and Python were basically unknown,
> so for high productivity your choices were Perl, Perl or Perl, but
> it's a nasty language for doing anything beyond a little file
> manipulation. I know this because I used it professionally around the
> time you're discussing.
>

I got to like perl a lot. For at least 20 years of my IT career, I
wrote perl code on a daily basis - including some fairly large-scale
projects (by which I mean upwards of about 5000 lines of code. Biggest
was probably one to document a vast and completely-undocumented
relational database by analysing a body of code which used it, looking
for JOIN definitions and arranging the tables in a hierarchy based on
them: it eventually output .dot files for input into graphviz. The
resulting PDF would probably have been legible printed at about A1
size, and looked like something out of a very bad psychedelic trip. But
it was accurate, and was used by developers for several years.)  

IMHO, perl is a great language - provided that one only uses a subset
of its capabilities. In my case, I aim at writing perl which looks as
much like C as possible, which means avoiding a lot of the shortcuts
and "syntactic sugar" which were built into it. By personal preference,
I avoid the "(statement) if (condition)" syntax - I stick with "if
(condition) { (statement) }" (I've had too much experience of reading
perl code written by others, and finding conditions at the end of long
lines, which totally screwed up my understanding of what the code did).
I also avoid "unless" like the plague. One of the features which I
**do** use and love is the ability to construct complex data structures
of nested anonymous hashes and arrays. I'm also very fond of the way
that perl does object-orientation. One of my criteria has always been
to write programs which, if I read them several years later, I can
still understand what they do. The other day, I was reading and (more
or less) understanding a perl module I wrote about 10 years ago - so
that box seems to have been ticked.

I came across two books by Damian Conway which I found very useful:
"Object-Oriented Perl" (also a wonderful introduction to basic perl,
clarifying many things which seem to be obfuscated in the early
O'Reilly perl books), and "Perl best practices". Highly recommended.
He's one of the most lucid writers on programming that I've yet come
across.

> > The signup system immediately fell over, and the
> > author hadn't a clue what was wrong or how to fix it. I can still
> > remember his look of petrified panic, as he stared at the code,
> > with the MD literally breathing down his neck.
>
> My analysis: The guy was an idiot. Even with Perl, there are ways of
> building for modularity, modification and debugging, as your story
> reveals later. What kind of fool wouldn't build individually testable
> modules?

He wasn't a programmer and had never claimed to be one. He had joined
the company as a project manager: in the job interview, he'd let it
slip that he'd tried his hand at writing a bit of perl, and
unfortunately that had been noted. Then there was the fact that the
complexity and criticality of the signup system had been massively
underestimated. The two came together: disaster, and the poor guy was
the obvious scapegoat. One could argue that he should have turned the
assignment down. But it was sold to him as a trivial task - and hubris
and wish to "prove himself as a programmer" probably did the rest.

>
>
> > The day came when my signup system was going to be tested. Even
> > now, I
> > start to shake when I think about it. One of the defensive things
> > that
> > I'd done was to incorporate paranoid error checking
>
> Can I assume that "use strict" was part of that paranoid error
> checking? Without "use strict", Perl is a monster.
>
I can't remember. Almost certainly so. There have been times when I've
deliberately decided to avoid "use strict" because it got in the way of
what I was trying to achieve - but I don't think that was one of them.

> > within a couple of
> > days, it was working without a hitch: after that, it continued to
> > run
> > virtually without changes for the rest of the time that I was with
> > the
> > company - about 8 years. (It was a long time before I stopped
> > worrying
> > about it . . . )
>
> You were smart about it, which is why you're on DNG: A belief in
> modularity, DIY, maintainability, modifiablity and tight error
> control.
> Which is the point you're making.
>
At the time, it felt more like desperation and dread - which I guess
focus the mind wonderfully.

> Let me ask you this, however: How did you break into the programming
> profession in the first place, and would you have been able to do it
> if you had a guild hurdle to get over?
>

Potentially long story - I'll endeavour to keep it brief. First
intention (from about 5 years old) was to go into chemistry, but that
was scuppered by total failure at maths in secondary school. Went into
music instead (had played the piano since very young) and eventually
came out of music college with a mediocre degree, and spent about 10
years trying to scrape a living from music (eventually playing piano in
restaurants for 7 years).

At a certain point during that time, I bought a Sinclair QL - still not
sure why - and found I could talk to it. I discovered that I appeared
to have a knack both for programming and understanding the underlying
structure and theory of computers (and no one could have been more
astonished). Several months later, I was admitted onto a 4-year part-
time computer course at Bradford University, for people coming from
other disciplines and leading to an M.Sc. in computer studies: I
graduated in 1991. Whilst still on the course, I got a job with an IBM
business partner, eventually managing and supporting mainframes all
over the UK. Then came the job helping to set up the ISP (Supanet) and
managing the authentication/signup systems for several years. Then came
managing several hundred linux workstations used by developers writing
STB embedded software. Finally, I spent 8 years managing an enormous
MySQL database used by a recruitment agency specialising in healthcare
posts and staff. Then retirement! I still write perl . . .

The Uni course was superb - it was mostly taught by ex-industry
professionals rather than academics. It including modules on
programming (pascal, C and assembly languages), systems analysis,
hardware, operating systems, IKBS, and a particularly good one on
databases, taught by a colleague of Codd and Date (the relational
database had been invented quite recently, and aspects of it were still
research fields). The Uni computer was a VAX 8650 running Ultrix (they
later upgraded to an Ultrasparc running Solaris). Unix was love at
first sight. I bought and used several secondhand copies of various
unixes for PCs. Then linux appeared and I didn't look back.

I'd like to think that I would have been able to join the hypothetical
"guild" - but as I said abover, I'm clear that a new paradigm would be
needed for such an organisation aimed at IT - and that would include
specifying entry routes and credentials.

(BTW I did eventually get to grips with maths - key was discovering
that it was actually enjoyable - and retook the exam I'd flunked at
school: this time, passed with top grade. I now work through maths
exercises as a kind of hobby.)

>
> > My only current concern is that it's planned for rust code to be
> > included in the linux kernel. I'm worried that the language is very
> > new (for a programming language) and the compiler and libraries
> > probably still contain significant errors and anomalies.
>
> Ah, that clarifies things. Daily I run into Rust fanboiz and Rust
> haters, and wonder how the hell do they arrive at such extreme
> opinions.
>
> My understanding, and I hope it's an accurate one, is that any kernel
> migration to Rust will be a program at a time, with lots of attention
> paid to any bugs or exploits that might pop up.
>
> A wholesale conversion from C to Rust or any other language would be
> stupid in 2026, and I hope that's not what happens. As far as the
> kernel, I'd hope they start by writing new drivers in Rust, so
> they're not fixing what works. I'd hope the transition would be slow,
> and could be stopped and backed out of if it turns out to be unduly
> problematic.
>

I agree absolutely with that, and I fervently hope that it proves to be
correct. There is an awful lot riding on the linux kernel. I'm sure
that Linus had no idea of the scale of the millstone (or albatross)
which he was hanging around his own neck, and I still wonder how he
manages to cope with it.

>
> _______________________________________________
> Dng mailing list
> Dng@???
> Manage your subscription:
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> Archive: https://lists.dyne.org/lurker/list/dng.en.html