Re: 20 years of experience, versus one year of experience repeated 20 times (Bradley Stone)

Yes, Jim. There is a middle ground as with anything. There is even
further left and right of the spectrum.

Simple black and white examples usually get the point across better. Flow
either way from there as much as you like and you'll find more than just a
middle ground. But no one wants to read about that. :)

Brad
www.bvstools.com


On Wed, May 8, 2013 at 2:23 PM, Horn, Jim <jim.horn@xxxxxxxxxxxxxx> wrote:

Isn't there some middle ground here.

Certainly there is some value to continuity. To change at intervals. Do
you really want everyone to use the latest technique every time they do
something? Do you want to be debugging the latest technique when the
author is gone and you're the one there?

Some of you seem to be experts at many things. Could be that's a bit like
hiring a concert pianist to fix your guitar. He might get it done, might
even enjoy it, but may not give you the bang for the buck you are looking
for, and will the job stand the test of time. Maybe a person who has been
fixing guitars for 20 years and has "seen everything" will do the job you
want.

Many of us on this list may have erp systems that are still working after
30 years (with updates of course). They probably lasted because they were
fundamentally sound and consistent no matter what techniques they used. I
certainly wouldn't write them that way now, but they used the simplest most
consistent technique at the time to get the job done.

Don't start jumping. I'm not suggesting we use more indicators than we
need to, or use goto's and tag's, or go back to tweaking arrays rather than
using string operators. I love using new techniques I can understand. We
just need to remember they are tools we use to our jobs, they are not ends
in themselves.

Jim

message: 1
date: Wed, 8 May 2013 12:33:20 -0500
from: Bradley Stone <bvstone@xxxxxxxxx>
subject: Re: 20 years of experience, versus one year of experience
repeated 20 times

What you've described is the difference between a "programmer" and a
"coder".

Programmers love what they do, try to better themselves, know when and
where to apply those techniques, etc.

Coders write code, fix code and coast to retirement. Throw something new
at them and they'll fight about "if it ain't broke" and "well, if you use
xyz then YOU have to support it".

It's the difference when given a task between: "We should be able to do

xyz

to solve the problem" vs "Ugh.. then we'll HAVE to do xyz and that will
take a lot of time..."

My .02 adjusted for diabolical and invisible inflation.

Brad
www.bvstools.com

***********************************************************************
The information transmitted is intended solely for the individual or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of or taking action in reliance upon this information by
persons or entities other than the intended recipient is prohibited.
If you have received this email in error please contact the sender and
delete the material from any computer. As a recipient of this email,
you are responsible for screening its contents and the contents of any
attachments for the presence of viruses. No liability is accepted for
any damages caused by any virus transmitted by this email.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.