b********n
发帖数: 38600 | 1 I would probably just do a shitty job of training them. I wouldn't want to
get sued for damaging company stuff.
I'm pretty sure the guy before me sabotaged everything. Documents would
NEVER have dates in the file names; I think he removed all of them just to
make things difficult. Versions were also a mess. There would be things like
version 1, "final", "final revision 2", "100%". Of course, none of the
files have dates on them, so you can't tell which order they are. Another
brilliant thing he did was have files located on 3 different servers, and it
wasn't immediately clear which copy was the working copy. Suppose we have a
project consisting of a house, a car, and a yard. The working (most recent)
copy of the house might be on server #2, the car is #1, and the yard is on
#3. The catch is that all 3 servers have plan sets for all 3 locations. That
means you have a total of 9 drawing sets, of which 3 are up to date. The
other 6 are obsolete. If you didn't carefully inspect every single drawing,
you might put an engineering stamp on a drawing that is obsolete, and that
opens the door to huge legal problems if the thing fucks up and someone gets
hurt. Another hilarious and awesome thing he did was related to file
sorting. What he would do is create 1 giant folder containing a bunch of
different files, create shortcuts to each file, and then sort the shortcuts
into folders. That means all of the sorting was shortcuts. If you ever
wanted to fuck everything up, all you had to do was delete the folder
structure containing the shortcuts. All of the files are still in the same
place, but all of the sorting is gone. Oh, and did I mention these files
didn't have fucking dates in the file names? It took months to fix that
fucking thing. | y********l
发帖数: 3970 | 2 这个被解雇的人不一定是在要被解雇时才这样干。估计正是因为他一向都是这样干的，
所以公司要解雇他。 | b********n
发帖数: 38600 | 3 因为在他之前被解雇的人也是这么干的
【在 y********l 的大作中提到】
: 这个被解雇的人不一定是在要被解雇时才这样干。估计正是因为他一向都是这样干的，
: 所以公司要解雇他。
| b********n
发帖数: 38600 | 4 Agreed! I hate to admit it, but I've seen some absolutely brilliant moves by
computer programmers who where laid off who before doing so put what I call
a "time bomb" in their programs. I got stuck "inheriting" their code and
had to figure it out and it took months and months to do so. Learned a lot
in the process though! Time bombs are not computer bugs or viruses or
anything like that which could get you in big trouble.... but this is what
they did:
1. Write all your code in complicated ways that work well but are a total bi
*ch to figure out or decipher if you weren't the original programmer.
Almost all my code works brilliantly but all my Gen Y co-workers (fresh out
of school who think they are somehow instantly better than I am with 30+
years experience).... whine and complain they can't understand the code. I
use a lot of Boolean operators, as I'm good with logic... and more recently
started using macros more.
It helps that as a SAS programmer I can use "old" methods and styles of
coding that are no longer taught, which you can't find help for on the
internet or in most books... but work as well as they ever did. And every
time I try to teach one of the new sprouts how to do what I do, they are not
interested because they have some new fangled method they think is better
just because it's new... and they assume I'm too old and don't know what I'm
doing. Their disrespect for my experience in the end helps me, not them.
2. Use a lot of macros, which are much harder to debug. I resisted this for
years, until I figured out how helpful it could be to keep someone else from
screwing with your programs if you are required to keep them in a "shared"
area.
I know this sounds paranoid, but I know people have messed with my code I
was required to store on a shared drive. So now I backup my most important
code on my C drive and whenever I have trouble running something I know
should work, I check to see if someone (can never tell who) changed part of
"my" code so it doesn't work or is wrong. When that happens I just replace
it with my backup. Seen that multiple times, unfortunately.
3. Imbed in a macro a reference to another macro in a file that was in your
personal files that you know they will delete as soon as you leave or that
you delete on your way out the door.
4. For all your big programs write a 2nd program that looks mostly the same
but has macros with a chunk of code removed from the middle of it. On your
way out the door, replace the code you "trained" your replacement out with
the code with the chunks missing.
Unless the person they hire is an absolute genius it is darn near impossible
to debug and figure out what went wrong. Your replacement may take MONTHS
to figure it out... or more likely will NEVER be able to figure it out. |
|
