On Sat, 2026-03-28 at 02:41 -0400, Steve Litt wrote:
> Peter Duffy said on Fri, 27 Mar 2026 12:26:24 +0000
>
> > I used "diligent" rather than "careful" (although the latter is
> > clearly
> > a subset of the former). In my definition (probably not the
> > standard
> > one), "diligent" means being conscientious and honourable enough to
> > go
> > the extra mile - or even 100 miles - to ensure that something is
> > done
> > properly, rather than just botched. And - if it is temporarily need
> > to
> > botch something to fix a critical problem, having the humility to
> > admit
> > to it, placing warnings and caveats in place, and
> > revisiting/improving
> > the situation at the first opportunity.
>
> We could debate the benefits and costs of adherence to this degree of
> diligence, but the fact is that a lot of bad code gets written,
> damaging society and the programming profession. 

Absolutely agree. 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. So that
if they believed that a program or system wasn't yet fit to be rolled
out and needed further testing, management would respect their views
and comply with their wishes. (As opposed to: "What part of: 'it's
going to be rolled out tomorrow' don't you understand?")

Anecdote. Round about 1997, I was helping to set up an ISP from
scratch. I was initially tasked with setting up the authentication
system. Another guy was given the job of writing the signup system. He
had joined as a project manager, but had unfortunately let it slip that
he had some experience in coding in perl, and at that point, the signup
facility was seen as a trivial challenge. The deadline for the rollout
was approaching, and this guy was under increasing pressure to deliver.
Finally the day came. 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. Finally, it was acknowledged
that his code just wasn't going to work, and he was fired. (I'm still
amazed that he didn't take the company to a tribunal, on the basis that
his job description didn't include software development.)

Then - given that I was setting up the authentication system, and had
considerable experience with perl - the entire mess was dropped in my
lap! A glance at the existing "code" was sufficient to show that it was
hopeless - it wasn't even logical, and could never have worked in a
month of Sundays. (A lot of it was experimental, as the users were
buying subscriptions independently, and our system had to interface
with a system of account codes which had to be matched with users
trying to sign up online.) I knew that I'd need to go back to research,
specification and design. I told management that I'd do it in a month.
They didn't like it a bit - it was effectively going to mean putting
back the advertised startup date. However, to my amazement - accepted
my terms: the only time in my career when that happened. (The general
manager was an experienced software developer himself, and I think that
made the difference.) 

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 and logging, so
that I could see the progress of the code virtually line by line. We
fired the starting pistol. The signup system ran for about 5 minutes,
then something went wrong: because of the logging, I was able to
diagnose and fix the problem and get the system up again in less than a
minute. This time it functioned correctly for about 30 minutes - then
another problem: again fixed in about a minute. (The problems were
always caused by misunderstandings about the working of the upstream
subscription system, which was completely undocumented.) The lengths in
between the glitches gradually increased, until 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 . . . )

(Just quickly - an associated recollection. We had two signup servers,
and a few weeks later, one failed - think it was a faulty memory stick.
We started dismantling it - then were told that the MD was on his way.
We all dropped tools and almost literally stood to attention for his
entry (he was a peer of the realm). He congratulated us warmly on an
excellent job of getting the systems up and running: he then noticed my
expression, and asked why I was looking rather less than delighted. I
told him that one of the signup servers was literally in bits in the
next room. He gave us full permission to get back to work immediately!)

> At some time in the
> future you, a diligent programmer, might find yourself hamstrung by
> actual laws requiring you to jump through all sorts of hoops (or pay
> lots of bribes) to be allowed to ply your trade.
>

Do lawyers, doctors, accountants etc. see having to work within the
guidelines and conditions imposed by their governing bodies? I don't
know - maybe they do, at least occasionally (e.g. when they're summoned
for re-training to update their skills and knowledge). But they
probably don't view it as a problem when they look at their bank
balances or routinely get paid for working overtime!

> Safe languages save programmer diligence for things like better
> algorithms, better analysis, better interactions with users and
> specifiers, etc. And they prevent a lot of nasty code by programmers
> pretending to be diligent, or programmers not even bothering.
>

I suppose one of my problems is that I hate being prevented from
knowing things. One of the reasons that I prefer linux to windows is
that linux allows me to know what's going on underneath the hood. (I'm
sure that that goes for most, if not all, linux users.) The idea of a
programming language that does things on my behalf, without my wanting
them to be done, to keep me safe, unsettles me. (Same goes for the
"system" in my car which turns on the lights in broad daylight.)

> And what in the world do you have against Rust? Yeah, it's harder to
> get it to compile, but once it compiles it's probably going to do
> exactly what you intended. Safely.

As far as I know, I've not expressed an opinion about rust. If I have
inadvertently done so, I shouldn't have, and I apologise. I don't know
enough about it to express an opinion. I've heard and read other
opinions, but before I commented, I'd want to read up on the language
and try it for myself (this is high on my to-do list). 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. And the people of the world rely on
the linux kernel to a degree that most of them, outside the IT
industry, have not the slightest inkling. (I always wonder how many
people are under the impression that the internet core and services run
on windows, and that if they go down, M$ will gallop to the rescue.
Hah!)

>
> Steve Litt
>
> http://444domains.com
> _______________________________________________
> 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