Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #211981 > unrolled thread

The shambolic self-taught programmer?

Back to article view | Back to alt.folklore.computers

Contents

  The shambolic self-taught programmer? Gareth Evans <headstone255@yahoo.com> - 2020-06-17 11:34 +0100
    Re: The shambolic self-taught programmer? Dallas <dallas@texas.usa> - 2020-06-17 06:48 -0500
      Re: The shambolic self-taught programmer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-17 21:18 +0000
        Re: The shambolic self-taught programmer? J. Clarke <jclarke.873638@gmail.com> - 2020-06-17 19:32 -0400
          Re: The shambolic self-taught programmer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-18 14:45 +0000
            Re: The shambolic self-taught programmer? J. Clarke <jclarke.873638@gmail.com> - 2020-06-18 18:01 -0400
              Re: The shambolic self-taught programmer? Dallas <dallas@texas.usa> - 2020-06-18 17:21 -0500
                Re: The shambolic self-taught programmer? Peter Flass <peter_flass@yahoo.com> - 2020-06-19 10:03 -0700
                  Re: The shambolic self-taught programmer? J. Clarke <jclarke.873638@gmail.com> - 2020-06-19 17:22 -0400
          Re: The shambolic self-taught programmer? Peter Flass <peter_flass@yahoo.com> - 2020-06-18 11:18 -0700
            Re: The shambolic self-taught programmer? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-18 20:30 +0000
              Re: The shambolic self-taught programmer? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-06-18 22:56 +0100
                Re: The shambolic self-taught programmer? Andreas Eder <a_eder_muc@web.de> - 2020-06-20 13:00 +0200
                  Re: The shambolic self-taught programmer? J. Clarke <jclarke.873638@gmail.com> - 2020-06-20 15:01 -0400
                    Re: The shambolic self-taught programmer? John Levine <johnl@taugh.com> - 2020-06-20 20:02 +0000
                      Re: The shambolic self-taught programmer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-20 20:32 +0000
                    Re: The shambolic self-taught programmer? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-06-20 21:34 +0100
              Re: The shambolic self-taught programmer? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-18 22:23 +0000
    Re: The shambolic self-taught programmer? mentificium@gmail.com - 2020-06-17 07:21 -0700
      Re: The shambolic self-taught programmer? JimP <solosam90@gmail.com> - 2020-06-17 12:39 -0500
    Re: The shambolic self-taught programmer? Peter Flass <peter_flass@yahoo.com> - 2020-06-18 11:17 -0700
      Re: The shambolic self-taught programmer? Dallas <dallas@texas.usa> - 2020-06-18 13:39 -0500
        Re: The shambolic self-taught programmer? "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-06-19 07:48 +0000

Page 1 of 2  [1] 2  Next page →

#211981 — The shambolic self-taught programmer?

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!

[toc] | [next] | [standalone]

#211982

On 6/17/2020 5:34 AM, Gareth Evans wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#211986

On Wed, 2020-06-17, Dallas wrote:
...
(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.
...
> #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   .

[toc] | [prev] | [next] | [standalone]

#211987

On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:

>On Wed, 2020-06-17, Dallas wrote:
>...
>(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.
>...
>> #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.  

[toc] | [prev] | [next] | [standalone]

#211988

On Wed, 2020-06-17, J  Clarke wrote:
> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
> wrote:
>
>>On Wed, 2020-06-17, Dallas wrote:
>>...
>>(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.
>>...
>>> #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   .

[toc] | [prev] | [next] | [standalone]

#211999

On 18 Jun 2020 14:45:30 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:

>On Wed, 2020-06-17, J  Clarke wrote:
>> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>> wrote:
>>
>>>On Wed, 2020-06-17, Dallas wrote:
>>>...
>>>(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.
>>>...
>>>> #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.

[toc] | [prev] | [next] | [standalone]

#212000

On 6/18/2020 5:01 PM, J. Clarke wrote:
> On 18 Jun 2020 14:45:30 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
> wrote:
> 
>> On Wed, 2020-06-17, J  Clarke wrote:
>>> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>>> wrote:
>>>
>>>> On Wed, 2020-06-17, Dallas wrote:
>>>> ...
>>>> (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.
>>>> ...
>>>>> #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.

[toc] | [prev] | [next] | [standalone]

#212003

Dallas <dallas@texas.usa> wrote:
> On 6/18/2020 5:01 PM, J. Clarke wrote:
>> On 18 Jun 2020 14:45:30 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>> wrote:
>> 
>>> On Wed, 2020-06-17, J  Clarke wrote:
>>>> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>>>> wrote:
>>>> 
>>>>> On Wed, 2020-06-17, Dallas wrote:
>>>>> ...
>>>>> (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.
>>>>> ...
>>>>>> #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

[toc] | [prev] | [next] | [standalone]

#212004

On Fri, 19 Jun 2020 10:03:53 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

>Dallas <dallas@texas.usa> wrote:
>> On 6/18/2020 5:01 PM, J. Clarke wrote:
>>> On 18 Jun 2020 14:45:30 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>>> wrote:
>>> 
>>>> On Wed, 2020-06-17, J  Clarke wrote:
>>>>> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>>>>> wrote:
>>>>> 
>>>>>> On Wed, 2020-06-17, Dallas wrote:
>>>>>> ...
>>>>>> (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.
>>>>>> ...
>>>>>>> #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.

[toc] | [prev] | [next] | [standalone]

#211990

J. Clarke <jclarke.873638@gmail.com> wrote:
> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
> wrote:
> 
>> On Wed, 2020-06-17, Dallas wrote:
>> ...
>> (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.
>> ...
>>> #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

[toc] | [prev] | [next] | [standalone]

#211997

On 2020-06-18, Peter Flass <peter_flass@yahoo.com> wrote:

> J. Clarke <jclarke.873638@gmail.com> wrote:
>
>> On 17 Jun 2020 21:18:49 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
>> wrote:
>> 
>>> On Wed, 2020-06-17, Dallas wrote:
>>> ...
>>> (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.
>>> ...
>>>> #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.
\ /  <cgibbs@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.

[toc] | [prev] | [next] | [standalone]

#211998

On 18 Jun 2020 20:30:37 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> On 2020-06-18, Peter Flass <peter_flass@yahoo.com> wrote:
> 
> > 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/

[toc] | [prev] | [next] | [standalone]

#212005

On Do 18 Jun 2020 at 22:56, Ahem A Rivet's Shot <steveo@eircom.net> wrote:

> 	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

[toc] | [prev] | [next] | [standalone]

#212008

On Sat, 20 Jun 2020 13:00:03 +0200, Andreas Eder <a_eder_muc@web.de>
wrote:

>On Do 18 Jun 2020 at 22:56, Ahem A Rivet's Shot <steveo@eircom.net> wrote:
>
>> 	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.

[toc] | [prev] | [next] | [standalone]

#212011

In article <o6nsefhibeteqeiukjpvqqacch8fhnff38@4ax.com>,
J. Clarke  <jclarke.873638@gmail.com> wrote:
>>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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#212012

On Sat, 2020-06-20, John Levine wrote:
> In article <o6nsefhibeteqeiukjpvqqacch8fhnff38@4ax.com>,
> J. Clarke  <jclarke.873638@gmail.com> wrote:
>>>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.

> It's not really comparable.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#212013

On Sat, 20 Jun 2020 15:01:59 -0400
J. Clarke <jclarke.873638@gmail.com> wrote:

> 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/

[toc] | [prev] | [next] | [standalone]

#212001

On Thu, 2020-06-18, Charlie Gibbs wrote:
> On 2020-06-18, Peter Flass <peter_flass@yahoo.com> wrote:
...
>> 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   .

[toc] | [prev] | [next] | [standalone]

#211984

On Wednesday, June 17, 2020 at 3:35:20 AM UTC-7, Gareth Evans wrote:
> [...] 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.

[toc] | [prev] | [next] | [standalone]

#211985

On Wed, 17 Jun 2020 07:21:35 -0700 (PDT), mentificium@gmail.com wrote:
>On Wednesday, June 17, 2020 at 3:35:20 AM UTC-7, Gareth Evans wrote:
>> [...] 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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web