Discussion:
The shambolic self-taught programmer?
Add Reply
Gareth Evans
2020-06-17 10:34:33 UTC
Reply
Permalink
Many times have I been called in when the local
"expert" is leaving a company, only to find a
complete unstructured mess created by a
self-taught programmer who had grasped the
lowest level notion of instructions executing
one after another, but had no concept of
structures, nor that the main cost of software
is not the original creation but the subsequent
maintenance phase.

Be cautious when interviewing because someone
who claims 3 years' experience may ony have
a single day's experience which they have
then repeated a further 1094 times.
(3 * 365 - 1 !!!!!)

I particularly have in mind a CORAL system
on a Perkin Elmer 8/32 where there were 94
procedures in a single file with no comments,
and no indentation and where there was a mixture
of block structures and GOTOs. This was in 1984

... and the manager complained that the
departed supremo could nail down a problem
in only a few minutes, so why can't you?

Another case in 1988, when it was held by the
non-professional world that only schoolchildren
were programming geniuses and the son of the
owner had been tasked with producing the
company's first computerised product and had
done it all in hex machine code to be entered
manually and laboriously into the SOFTY
proprietary PROM programmer!
Dallas
2020-06-17 11:48:38 UTC
Reply
Permalink
Post by Gareth Evans
Many times have I been called in when the local
"expert" is leaving a company, only to find a
complete unstructured mess created by a
self-taught programmer who had grasped the
lowest level notion of instructions executing
one after another, but had no concept of
structures, nor that the main cost of software
is not the original creation but the subsequent
maintenance phase.
Be cautious when interviewing because someone
who claims 3 years' experience may ony have
a single day's experience which they have
then repeated a further 1094 times.
(3 * 365 - 1  !!!!!)
I particularly have in mind a CORAL system
on a Perkin Elmer 8/32 where there were 94
procedures in a single file with no comments,
and no indentation and where there was a mixture
of block structures and GOTOs. This was in 1984
... and the manager complained that the
departed supremo could nail down a problem
in only a  few minutes, so why can't you?
Another case in 1988, when it was held by the
non-professional world that only schoolchildren
were programming geniuses and the son of the
owner had been tasked with producing the
company's first computerised product and had
done it all in hex machine code to be entered
manually and laboriously into the SOFTY
proprietary PROM programmer!
That brought two memories to my mind from my first years
of professional programming just after university (1973)

#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.

#2 a boss of mine who programmed in hex machine code because
he thought that gave him job security

Notes on each:

#1 - this was actually a workable arrangement

#2 - one of the best days of my life was when I was able to eventually tell
that boss I had found another job within that company in another city
Jorgen Grahn
2020-06-17 21:18:49 UTC
Reply
Permalink
On Wed, 2020-06-17, Dallas wrote:
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.

Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
J. Clarke
2020-06-17 23:32:43 UTC
Reply
Permalink
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Jorgen Grahn
2020-06-18 14:45:30 UTC
Reply
Permalink
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Probably because he noticed he can get away with it ...

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
J. Clarke
2020-06-18 22:01:35 UTC
Reply
Permalink
Post by Jorgen Grahn
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Probably because he noticed he can get away with it ...
Eventually I'm going to clean up one too many of those and have a
discussion with the boss about it.
Dallas
2020-06-18 22:21:34 UTC
Reply
Permalink
Post by J. Clarke
Post by Jorgen Grahn
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Probably because he noticed he can get away with it ...
Eventually I'm going to clean up one too many of those and have a
discussion with the boss about it.
We are small enough that the "boss" actually looks at our individual contributions, and I look at hers.
Peter Flass
2020-06-19 17:03:53 UTC
Reply
Permalink
Post by Dallas
Post by J. Clarke
Post by Jorgen Grahn
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Probably because he noticed he can get away with it ...
Eventually I'm going to clean up one too many of those and have a
discussion with the boss about it.
We are small enough that the "boss" actually looks at our individual
contributions, and I look at hers.
That’s the best way. When I was boss I instituted code reviews where
everybody looked over everyone else’s code.
--
Pete
J. Clarke
2020-06-19 21:22:07 UTC
Reply
Permalink
On Fri, 19 Jun 2020 10:03:53 -0700, Peter Flass
Post by Peter Flass
Post by Dallas
Post by J. Clarke
Post by Jorgen Grahn
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Probably because he noticed he can get away with it ...
Eventually I'm going to clean up one too many of those and have a
discussion with the boss about it.
We are small enough that the "boss" actually looks at our individual
contributions, and I look at hers.
That’s the best way. When I was boss I instituted code reviews where
everybody looked over everyone else’s code.
We don't quite do it that way--we do have code reviews though and if
it's something major it gets looked at by more than one other person.
My old boss was great--she could do anything I could do, backwards in
high heels. The new one is coming from a different direction and in
the long run it's going to be beneficial I think--she isn't an
experienced programmer but she has a vast store of business knowledge,
she's willing to learn, she's smart, a quick study, and a
self-starter.
Peter Flass
2020-06-18 18:18:55 UTC
Reply
Permalink
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Error recovery makes up large amount of production code, and it’s usually
not “fun” to write.
--
Pete
Charlie Gibbs
2020-06-18 20:30:37 UTC
Reply
Permalink
Post by Peter Flass
Post by J. Clarke
Post by Dallas
...
(1973)
Post by Dallas
#1 a programmer who had a reputation of slinging out code
quickly that actually worked, but whose code had to then
be taken by other programmers and made suitable for
incorporation into the product for reasons of maintainability.
...
Post by Dallas
#1 - this was actually a workable arrangement
Not quite unlike the practice of code reviews, popular today.
Although I hope the imbalance is rare. Maybe that first guy should
just have been brought in to generate design ideas.
I have encountered a similar situation. Give the guy a calculation to
solve and he'll produce code that solves it. But he just plain could
not grasp concepts like "Production code must not halt on any
anticipated error"--he'd merrily test for an error condition and crash
the program instead of making the extra effort to make it recover.
Error recovery makes up large amount of production code, and it’s usually
not “fun” to write.
Indeed. But when a system falls over due to an unhandled error,
it's usually not "fun" to get it back up again either. Anyone
who skimps on error handling should be forced to participate in
said recovery. (It's a variation on "eating your own dog food".)
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <***@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Ahem A Rivet's Shot
2020-06-18 21:56:04 UTC
Reply
Permalink
On 18 Jun 2020 20:30:37 GMT
Post by Charlie Gibbs
Post by Peter Flass
Error recovery makes up large amount of production code, and it’s
usually not “fun” to write.
Indeed. But when a system falls over due to an unhandled error,
it's usually not "fun" to get it back up again either. Anyone
who skimps on error handling should be forced to participate in
said recovery. (It's a variation on "eating your own dog food".)
There is a design approach where crashing out or being killed is
considered the normal exit and crash recovery using checkpointed state is
the normal start up procedure. It makes for very robust systems even under
difficult conditions.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Andreas Eder
2020-06-20 11:00:03 UTC
Reply
Permalink
Post by Ahem A Rivet's Shot
There is a design approach where crashing out or being killed is
considered the normal exit and crash recovery using checkpointed state is
the normal start up procedure. It makes for very robust systems even under
difficult conditions.
That us what I have seen in a lot or Erlang code.

'Andreas
J. Clarke
2020-06-20 19:01:59 UTC
Reply
Permalink
Post by Andreas Eder
Post by Ahem A Rivet's Shot
There is a design approach where crashing out or being killed is
considered the normal exit and crash recovery using checkpointed state is
the normal start up procedure. It makes for very robust systems even under
difficult conditions.
That us what I have seen in a lot or Erlang code.
Being killed is fine.

But crashing out on a production job means that the bills that were
supposed to be paid at 2 AM aren't paid and won't be paid until
somebody fixes the production job.
John Levine
2020-06-20 20:02:44 UTC
Reply
Permalink
Post by J. Clarke
Post by Andreas Eder
That us what I have seen in a lot or Erlang code.
Being killed is fine.
But crashing out on a production job means that the bills that were
supposed to be paid at 2 AM aren't paid and won't be paid until
somebody fixes the production job.
Erlang is typically used in telephony where the cost of a crash is
more likely to be a dropped call. It's not really comparable.
--
Regards,
John Levine, ***@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Jorgen Grahn
2020-06-20 20:32:24 UTC
Reply
Permalink
Post by John Levine
Post by J. Clarke
Post by Andreas Eder
That us what I have seen in a lot or Erlang code.
Being killed is fine.
But crashing out on a production job means that the bills that were
supposed to be paid at 2 AM aren't paid and won't be paid until
somebody fixes the production job.
Erlang is typically used in telephony where the cost of a crash is
more likely to be a dropped call.
That was the original use, but I believe it's also used for web and
stuff nowadays. Luckily (for Erlang) there are lots of cases where
it's ok to drop a single user session ("call") and let the user try
again.
Post by John Levine
It's not really comparable.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ahem A Rivet's Shot
2020-06-20 20:34:20 UTC
Reply
Permalink
On Sat, 20 Jun 2020 15:01:59 -0400
Post by J. Clarke
Being killed is fine.
But crashing out on a production job means that the bills that were
supposed to be paid at 2 AM aren't paid and won't be paid until
somebody fixes the production job.
Suppose that the production job simply restarts after the crash
picking up state from the checkpoint and carries on without manual
intervention. Now if the crash was due to resource starvation or a
scribbler or any number of causes the job will finish, if the crash was
down to poor handling of bad data or similar then it will crash again and
again and again - it could be coded to skip the transaction that crashed it
in that case.

That's how this design philosophy works.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Jorgen Grahn
2020-06-18 22:23:33 UTC
Reply
Permalink
...
Post by Charlie Gibbs
Post by Peter Flass
Error recovery makes up large amount of production code, and it’s usually
not “fun” to write.
Indeed. But when a system falls over due to an unhandled error,
it's usually not "fun" to get it back up again either. Anyone
who skimps on error handling should be forced to participate in
said recovery. (It's a variation on "eating your own dog food".)
I strongly believe all programmers should participate. You don't know
your code until you've seen it fail horribly ...

I once worked in a place where we outsourced maintenance. We
wrote the new features, tested and shipped them, and then another
organization did maintenance and support. These other programmers,
who were also young and bright, got all the practical experience.

/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
m***@gmail.com
2020-06-17 14:21:35 UTC
Reply
Permalink
[...] the main cost of software
is not the original creation but the subsequent
maintenance phase. [...]
AI Mind Maintainer is potentially the Job of the Future.

http://ai.neocities.org/maintainer.html -- care and feeding of AI Minds.
JimP
2020-06-17 17:39:03 UTC
Reply
Permalink
Post by m***@gmail.com
[...] the main cost of software
is not the original creation but the subsequent
maintenance phase. [...]
AI Mind Maintainer is potentially the Job of the Future.
http://ai.neocities.org/maintainer.html -- care and feeding of AI Minds.
At one job interview the interviewer tried to tell me that only
programmers under age 25 could write software.

I was able to pin the idiot into telling me that at age 26, too old.

So I said, when do they lose all ability ?

He claimed when they turn 26. So I said, the day they go from age 25
to age 26 ? He claimed yes, I pointed out that made no sense.

He didn't hire me, but then I would likely have laughed myself to
death at his other 'gems of wisdom'.
--
Jim
Peter Flass
2020-06-18 18:17:10 UTC
Reply
Permalink
Post by Gareth Evans
Many times have I been called in when the local
"expert" is leaving a company, only to find a
complete unstructured mess created by a
self-taught programmer who had grasped the
lowest level notion of instructions executing
one after another, but had no concept of
structures, nor that the main cost of software
is not the original creation but the subsequent
maintenance phase.
Be cautious when interviewing because someone
who claims 3 years' experience may ony have
a single day's experience which they have
then repeated a further 1094 times.
(3 * 365 - 1 !!!!!)
I particularly have in mind a CORAL system
on a Perkin Elmer 8/32 where there were 94
procedures in a single file with no comments,
and no indentation and where there was a mixture
of block structures and GOTOs. This was in 1984
We used to call this kind of program “job security.”

When storage was limited programmers often omitted or abbreviated comments
to save space.

Ai I tried to figure out the logic of code like this, the first thing I’d
do is add comments.
Post by Gareth Evans
... and the manager complained that the
departed supremo could nail down a problem
in only a few minutes, so why can't you?
Another case in 1988, when it was held by the
non-professional world that only schoolchildren
were programming geniuses and the son of the
owner had been tasked with producing the
company's first computerised product and had
done it all in hex machine code to be entered
manually and laboriously into the SOFTY
proprietary PROM programmer!
--
Pete
Dallas
2020-06-18 18:39:34 UTC
Reply
Permalink
Post by Peter Flass
. . .I particularly have in mind a CORAL system
on a Perkin Elmer 8/32 where there were 94
procedures in a single file with no comments,
and no indentation and where there was a mixture
of block structures and GOTOs. This was in 1984
We used to call this kind of program “job security.”
When storage was limited programmers often omitted or abbreviated comments
to save space.
Ai I tried to figure out the logic of code like this, the first thing I’d
do is add comments.
Here's some commentary for that spaghetti code


Kerr-Mudd,John
2020-06-19 07:48:17 UTC
Reply
Permalink
Post by Dallas
. . .I particularly have in mind a CORAL system
on a Perkin Elmer 8/32 where there were 94
procedures in a single file with no comments,
and no indentation and where there was a mixture
of block structures and GOTOs. This was in 1984
We used to call this kind of program “job security.”
When storage was limited programmers often omitted or abbreviated
comments to save space.
Ai I tried to figure out the logic of code like this, the first thing
I’d do is add comments.
Here's some commentary for that spaghetti code
http://youtu.be/6bOI-VY1Wpw
FFS
--
Bah, and indeed, Humbug.
Loading...