From mboxrd@z Thu Jan  1 00:00:00 1970
From: ron@ronnatalie.com (Ron Natalie)
Date: Sun, 1 Jan 2017 08:11:56 -0500
Subject: [TUHS] Unix stories
In-Reply-To: <20170101050011.GQ5983@mcvoy.com>
References: <20170101050011.GQ5983@mcvoy.com>
Message-ID: <02e201d26430$a111ecc0$e335c640$@ronnatalie.com>


> That way I could go build and test that kernel and get ahead of the bugs.
> If I could fix up their bugs before the rest of the team saw it, then I
wouldn't get blamed for them.

Ugh.   I had a programmer who was sent over from the other side of our
company to help out.   The guy was a complete dolt and broke more than he
fixed.    Mostly, he never really caught on to how dynamic memory worked in
C and was always trashing the malloc areas.  So I just backed out every
change he made (at least we had source code control going at that point, one
of the first things I insisted happen when I took over).     Finally, I was
on my way in to fire him when I found he had quit an hour previously (fine,
I love it when that works out).    Unfortunately, he checked in all his
"work in progress" which didn't even compile.   Backed all that out.

Several years later I get a hold of a tool called Purify which finds memory
leaks (among other things) In your code.    I find a piece of code written
by one our better programmers that predate the source code control system
that's leaking memory.   This can't be.    Look through the edit history and
there is one edit, my former programmer.   He's deleted the free() call in
the routine without explanation.   Obviously, he had corrupted the malloced
area one day, and it crashed in the subsequent free in this routine, so he
just deleted it.

Bad programmers can hurt you for a good long time after they leave.    The
only other guy I had to fire at least had done absolutely nothing over his
tenure, so we were unaffected in the long run.