(no subject)

[ihateemo.livejournal.com]

50+ Ways a Manager can get Employees to Quit

See how many are applicable to YOUR place of work!

Comments

[jecook]

Excellent link. ::adds to memories::

[spacebird.livejournal.com]

A coworker and I picked out 8 immediately that are PERFECTLY in line with our manager.

[darkblade1.livejournal.com]

That list works. I can also rattle off about 7-8.

I got hit with the .25 of a day because I had an appointment (doctor).

[wignersfriend.livejournal.com]

17-18

I need out of the Real Estate industry. =(

[the-s-guy.livejournal.com]

I dunno. Most of them are variations of:

1) Incompetence
2) Being an Asshole
3) Inconsistency
4) Stupidity

[mouser.livejournal.com]

True.

Now how many of those do you deal with?

(Reading the list, I realized I was doing one of them. I stopped about two minutes ago.)

[the-s-guy.livejournal.com]

Eh, a couple. Not too many. I've had veteran managers replaced with dipshits, but there was really no indication that the upper levels gave a crap about our performance either way. There were some good people where were very _rarely_ asked if they wanted anything more, but it did occasionally happen.

We had policies imposed without consultation, but you get that in large shops. Some lunatic executive passed a clean desk policy, but it wasn't our direct management's idea and it quietly died because the brass never visited. We had to fill out separate timesheets on up to five different applications because five separate executives had demanded the in-house programmers write something new instead of just adding a function to the original, very quick-n-easy timesheet app.

Our access to Google *was* cut off, so that's a definite one. Not because it was a timewaster, but because the caching operations could allow employees to access blacklisted sites. Stupid, really.

Some of the meetings we were dragged off to were one-way only. A couple of the mandatory courses we were sent on were content-free. And there were plenty of stupid projects from the upper levels. But overall it wasn't too bad, at least initially. What killed the team in the end was bad hiring and weeding policies, not bad management.

[jon787.livejournal.com]

See my company is just firing all of us after we ship the product. What I need is a 50 fun things to do to the project to make it blow up after we leave.

[the-s-guy.livejournal.com]

PRODUCT DEATH:

Simple lockup timebomb.

Authentication process with a bug in it so the product can't actually be authenticated, or won't accept the correct codes.

Subtle incompatibility with any hardware it wasn't developed on.

Requirement for a very specific set of common userland libraries which are not shipped with with product and the docs don't mention this.

Requirement to type in "Have a cookie" every 30 days' runtime.

Processing algorithm which uses a date-based seed plus a constant so that after a certain date the total wraps around 32-bit space and causes multiple error cascades.

Database cleanup processes which require the presence of certain test records to work properly - records which get wiped before the product is released to the customer.

Have the install process for the product install the patched version of the library only if a certain undocumented process is followed during the install - which could be as subtle as entering a particular subset of registration data or a pattern of tapping the Shift key certain ways during some screens.


PROJECT DEATH:
Encrypt all source code, or spaghettify it, or both, such that when the product breaks shortly after the programmers are let go, and the company needs to hire someone to patch it, only the original team will be able to make head or tail of it.

Tweak the compiler defaults before leaving, and place structures in the code which will only choke on the new settings. Make sure all existing documentation on the compiler settings reflects the broken ones.

Have the build process pull a critical component from a workstation, laptop or other non-backed-up machine, and then wipe that machine before leaving. Alternatively, swap in a different version of the component. Sneaky is basing a significant part of the programming on a unique patched version of the component, and then replacing it with the standard version.

An even eviller variation is to have the component pulled from a location which IS backed up - but have a process in place whereby that location contains a patched version of the component at all times EXCEPT when the backup process is running. Have the process which performs the redirection or swap dependent on the existence of your userID on the corporate HR DB.

Fail to document tiny little things which "any good developer should know", but without which the entire codebase is rendered useless.

Use unoriginal libraries or code which have extensive legal baggage, ie you stole them from Microsoft or SCO thinks it owns them. When you're fired, send an anonymous email to Microsoft or SCO. You may or may not also want to send one to the company lawyers and perhaps another to Digg.

If the product is designed to be used on workstations, have it perform a background disk scan for porn 30 days after installation, create a collage of the most likely graphics it finds, and use that as the splash screen. Or have it randomly change the desktop wallpaper to that image with a chance of 1/50 every time it runs. Make the pornhound code sit in a module which is easily replaceable. Have very subtle code check for the alteration of either that module or the modules which call it, and if any alteration occurs switch the app into All Porn, All The Time mode.

Warning: some of these options may be detrimental to your career :)

[ihateemo.livejournal.com]

This is the single greatest post I have seen in this community.

Which leads me to believe that you've done this before..... ;)

[jon787.livejournal.com]

How about using undocumented capabilities of the processor? Or even better, ignoring the processor documentation and doing stuff it says not to.

[the-s-guy.livejournal.com]

No, merely collected anecdotes from those who have seen such things done, often more by accident or incompetence than malice :)

[squigit.livejournal.com]

Its all about the timebomb. It just has to do a couple obscure things, like remove chunks of text out of word documents that start with L on the third day of the month. The sort of thing that will take them forver to notice, much less associate with your program. I was asked by a former boss to program a demo one (love my job somtimes) to prove a point to management.