Re: [PLUG] Revision Control for the Rest of Us

[Rich Kulawiec <rsk@gsp.org>]

On Sun, Nov 19, 2017 at 12:45:22PM -0500, Keith C. Perry wrote:
> While it's important to innovate and keep striving to make tools better.
> Much of what is new is not new- it's a repackage spin on what someone else
> things is a "better" way to accomplish a task.  

That's often true.  It also seems to be often true in the last decade
or so that new things are being invented by people who didn't bother to
learn the old things and to understand, in depth, why they were designed
and built as they were.  In some situations, this has led to rather a
lot of time and effort being invested in something that's new and shiny
and fine -- as far as it goes -- but is partially-to-mostly superfluous.
Or worse, is a really poor attempt to replace something that doesn't
need replacing, just some updating and extension.  This often seems to
happen out of hubris: some developers just can't bring themselves to
use/adapt/improve existing work and insist on starting over because
they want to.  This serves their egos well but the community poorly.

This has in turn resulted in an environment with way too many projects
and way too few really good ones.  Which is understandable: there are
only so many clueful brains and so many hours available.  And -- going
back to the ego thing -- it's much more glamorous to have your name on
a project than to be one of a thousand nearly-anonymous contributors
who've each submitted a bug report or a documentation improvement or
a typo correction.  But the latter is how the heavy lifting gets done:
tedious, nearly-invisible, grunt work like that slowly raises the quality
level of any project.

So yeah, many eyeballs make deep bugs shallow, but I worry that the ratio
of eyeballs to bugs has been decreasing in the last decade and that
the bill for that is coming due.  I hope I'm wrong.

[ slight change of topic ]

I've maintained for a long time that everyone should make it a point, once
a year, to read all the man pages in section 1 of the manual.  (And if
an admin, section 8 as well.)  It's not necessary to memorize them
or even to try.  Just maintaining a passing familiarity with what's
already there may be enough to jog one's memory when trying to accomplish
various tasks and perhaps alleviate the need to "invent" something whose
functionality has already been part of the system since v7.

And as a complement to that, I think we should all make it a point to
try to keep a peripheral awareness of the myriad extant software projects
out there.  This is a much harder task: there's a lot of them, they're
scattered, they're all in different states of maturity/maintenance,
and if they're outside our usual interests, we're not likely to see them.
But I still think it's worth making an effort.  My practice is to take
note of projects mentioned by other people and take a few minutes to
read/bookmark their home page, to read their README, and/or to
browse through examples/screenshots.  This *still* isn't even close
to enough to keep up, but it beats ignoring them all entirely.  And all
of you -- whether you realize it or not -- are helping with me,
so I thank you for that.

---rsk
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug