We've got a guy in the office that merges the past over the present all the time. He's not quitting but I imagine if you were to try to break things this would be a good way to do it.

Got a offshore guy just like that. Constantly committing his whole project where most files are out of date and only the few he worked on are not.

There's no reason for him to commit javascript files he doesn't even work on the front end. It took me forever to figure out he wrote over my files the other day.

He must be using push --force in that case.. which seems like a bad practise.

What they're doing is something like branching off a very old version of master, making changes to file A then trying to merge into the latest version of master, which already has a load of changes to file A. They then resolve the conflict by picking "ours", thus ignoring all changes on origin/master in favour of their own old version of master. This doesn't require a --force.

I am curious - wouldn't your Version Control system catch this and warn him that "file xyz has changed since you last checked it out, ..." etc?

DVCS systems like Git and Mercurial will require you to merge, but if you use a GUI VCS frontend it's really easy to choose the "use my local stuff" button. Been there with some university projects groups. (These people also liked the "force push" method of merging.)

There is no warning.

    Pull
    cp * ../work
    cd ../work
    Work
    (cd ../src && pull)
    cp * ../src
    cd ../src
    Commit

#define volatile // this one is cool

Oh wow. This literally sent a shiver down my spine. Imagine debugging that.

Also love the randmoness based ones!

Will you explain what this would do?

Of course :)

Basically this removes the volatile keyword from your code and replaces it with... nothing.

If a variable is declared volatile, it disables compiler optimizations and signals the compiler that this variable can be modified at any time (e.g. by hardware or other threads). Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

That would also break the trick of declaring something `const volatile`. While that seems like a contradiction, I've heard of it being used to force the compiler to include a symbol in the final object file. In particular, I've seen it used to make a poor-man's plugin architecture.

Omitting volatile can lead to nasty concurrency bugs (e.g. if the optimizer optimizes spin locks away). In the worst case, such bugs are extremely hard to reproduce (and thus debug) but lead to deadlocks and/or crashes in case they do occur.

In C and C++, volatile is not intended and must not be used for synchronisation primitives, it is not a memory fence (so it does not force cache coherency and does not prevent operations reordering) and operations on volatile variables are not atomic. Its primary use case is memory-mapped IO (with a sub-use case of preventing eliding memory operations affected by inline assembly). If a lock is broken because `volatile` is disabled, it's probably incorrect in the first place.

All `volatile` does[0] is forbid elision of loads and stores.

[0] again in C or C++, Java and C# have completely different semantics

Thanks for clearing that up. I worked with threading a lot in C# hence my misconception that it could be used for spinlocks in C/C++ too.

While you are absolutely correct, you will find no shortage of experienced employees at large companies that will disagree. In fact, they will insist that the only purpose of volatile is a primitive for synchronization. I actually had a conversation where a developer insisted that by declaring a variable volatile all operations on it were atomic.

Of course at this same company a developer insisted that if you use the mongoDB client libraries in your software, your software can never have data consistency problems.

If those developers target Visual Studio exclusively, they are actually correct: https://msdn.microsoft.com/en-us/library/12a04hfd.aspx

From "How to write unmaintainable code" [0], here is a function declaration that changes signature based on how many times the header is #included:

    #ifndef DONE
    #ifdef TWICE
    void g(char* str);
    #define DONE
    #else // TWICE
    #ifdef ONCE
    void g(void* str);
    #define TWICE
    #else // ONCE
    void g(std::string str);
    #define ONCE
    #endif // ONCE
    #endif // TWICE
    #endif // DONE

Granted, it isn't one line long.

[0] https://www.thc.org/root/phun/unmaintain.html (Cert issue shows up on FF unfortunately)

If only we can get a rosettacode version of this in all languages. I bet trolls will coming out left and right. It would be pure evil.

Most languages don't have a purely textual and completely unsafe preprocessor running during the compilation process, so it would be quite hard.

You could do some real evil stuff with reflection though, such as messing with Java's IntegerCache: http://codegolf.stackexchange.com/a/28818

This is when the scriptkiddies start getting involved..

From the comments my favorite:

   #define i j

It gets debugged in a flash though.

Someone will lose some hair over this

  /* create memory leaks if compiled on April, 1st */
  #define free(x) if(strncmp(__DATE__, "Apr  1", 6) != 0) free(x)

The random ones are just pure evil.

Perhaps the most enlightening (and actually useful) purpose of this file is to dramatize the glaring weakness in the c/c++ macro system. A proper macro system would not make it so easy to do this, shall we say, "evil", stuff :)

The horror story that I heard was a disgruntled engineer silently replaced the source codes (C++ based) in the project with compiled binary object files and he kept the source codes on his local computer, not checking those in. He did this over an extended period of time to make sure this crept into the backup tapes as well. No one found out because each engineer owned a code module of their own. Then he resigned.

When his successor tried to debug and enhance the code base, the core files were basically all stripped binary object files...

That's insane.. He must have really hated his job.

and everyone else. Seriously. No sympathetic human being would do this without a deep-rooted hatred to everyone involved.

my theory is that in every case where this has ever happened, all of the saboteur's ex-coworkers afterward said "I'm not surprised in the slightest."

My god, i'm surprised that person didn't land up in court :/

Is that illegal though? Sure, if you can PROVE it is done on purpose then maybe, but assuming you cannot then is it? Because if it is then any misconfigured version control or any employee that doesn't do what is expected of them is also breaking the law.

Is it worth the risk to find out? Court ain't cheap, even if you win.

As an employee of a company that provides you a paycheck, you "owe" them your best effort. If you don't want to try, quit - but don't sabotage. That is juvenile and perhaps illegal and certainly unethical.

you "owe" them your best effort

Yeah, and the company "owes" you as high a salary as they can possibly afford...

this is why we have code. reviews. haha. Yeah...I'd file a criminal lawsuit on his ass though.

In the US, only the "State" can file a criminal lawsuit. Imagine trying to explain this crime to a county prosecutor!

A friend of mine did something similar, not that long ago.

His employer told him to complete a 1-year masters in computing at his expense, including a course on ethics, or see them in court. He chose the degree course.

That's almost benevolent on the part of the employer -- having more degrees can only be good for the person's employability, and it was most likely an enriching experience to boot. Oh well, i guess some people have larger hearts than i do! :)

Some people who aren't critical to the company just have to go and try to prove the company wrong.

This is so childish and stupid it aggravates me. It only proves that the engineer was probably not a valuable asset and he really proved the company point with these actions. Hopefully he was on a performance plan or something similar.

At companies where there have been poor code control practices I have maintained git repositories locally of various files in the system to avoid exactly this thing, and to find issues/when things have changed (this too often is because operations teams don't like to maintain their files properly, so I go out to web servers and pull down configuration files on a daily basis and check them in somewhere. Now I'm telling them when their files changed).

Regardless, I have to assume this is before git/svn/mercurial. At least I hope it is.

what happened as a result? im curious to know.

The CEO decided to just move on because it was a small company with less than 30 people. Litigation would take too much time and money.

The engineering team took a couple of months to figure out what that module did and rewrote from scratch.

I had a professor back in the university that changes all the variable names to beer names while at a job. It ended up not being a problem for the company as he was consistent with the names.

It is always a funny joke to say "commit this when you leave a job". But I always wondered if there are people that actually do this.

Although it could be funny and give a sense of revenge for some wrong (perceived or real) that the person leaving might have suffered, I don't think this would be a good idea. Contracts usually include liability for gross negligence or wilful misconduct.

Does anybody have a record of this actually happening at any company?

Worse. Depending on the jurisdiction, they may be able to get you arrested for hacking.

Not some - all* US jurisdictions.

From the Computer Fraud and Abuse Act (18 U.S. Code § 1030(5)(A)):

knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer

English isn't my first language, and I don't live in America so it's not like this matters to me, but now I'm curious. How is editing a source file you're meant to be editing "transmitting" anything?

The key is "without authorization". You're allowed to fix things and add features, but deliberate sabotage is arguably unauthorized. You might win in court, but as others said elsewhere, court is Too Expensive even if you win.

That, and I wouldn't be surprised if they didn't go after you for industrial espionage or something.

Except that you're entirely authorized to access the computer system.

Purpose or intent isn't defined in that particular law.

Do you have authorized access? Well, as an employee you do.

This isn't a criminal matter, it's a civil one, and no company is going to sue a saboteur unless they need an example made; they stand to gain nothing.

A company doesn't get to retroactively redefine what "authorized access" is as it suits them.

Obviously most of those fall easily under gross negligence.

However, I threatened to use this for the company I quit in 2010 and the threat was enough. We were negotiating and they thought a share of 100-0 in favor of the employer was ok. The law was 100 in favor of the employee. After threat we ended up at 50-50.

The problem with doing this, besides being incredibly unprofessional, is that it won't really affect the company much - besides reducing productivity for a little while - however it will annoy the hell out of your previous colleagues. Unless you're leaving because you fell out with your colleagues, I doubt it would have the desired effect.

Those who make liberal use of 'git bisect' can not be so easily trolled.

Oh I so desperately need a PHP equivalent right now.

PHP actually allows much less mischief here than C or, say, Python does. It doesn't let you redefine or delete functions, classes or constants, unlike C where macros can be abused for this, and Python where you can delete anything.

But you could hide all errors if you want to screw with people:

  error_reporting(0);
  set_ini('display_errors', '0');
  set_error_handler(function () { return TRUE; }, E_ALL | E_STRICT);
  set_exeception_handler(function ($ex) { });

Well yes of course you can, we're talking about PHP here.

http://php.net/runkit_function_rename

Something I wrote to amuse the junior front end developers here:

    document.write('Error: Script not found.');
    var node = document.currentScript;
    if (node.parentNode) { node.parentNode.removeChild(node); }

Pop that in a JS file called something like jQuery.min.js and add it to an HTML page with the usual <script src="/js/jQuery.min.js"></script>. It'll run when the page loads, add the line of text to the page, and then it'll remove it's own <script> tag so there's no reference to it in the DOM (in relatively modern browsers) if you view the source. It's easy to debug by watching the network traffic, but it caused a few scratched heads for a little while.

'View source' shows the HTML source, not the DOM, in both Firefox and Chrome. Maybe you're thinking of the developer console, or the Firefox 'View selection source' feature?

Why wouldn't you search for 'Script not found' in the source code..?

The point wasn't to leave people puzzling over it for hours. It was a bit of fun. But ... It'd be quite trivial to hide the string.

    var msg = ['E','r','r','o','r',':','S','c','r','i','p','t',' ','n','o','t',' ','f','o','u','n','d'];
    document.write(msg.join(''));

Base64 encode the string for added fun.

... and then caesar-cipher it so that the first guess won't easily find it? :D

I gave a talk at BlackHat many years ago about JS malware, and proposed obfuscating malicious JS like this:

- Treat JS code like 7-bit ASCII

- For each character, convert the bits into white space. 1= space, 0 = tab

- A = "1000001" = space tab tab tab tab tab space

- concat it all together, \n shows you are done

So you can represent JS code as just whitespace. Which means this is malicious code:

<script> //st4rt

//3nd

var html = document.body.innerHTML; var start = html.indexOf("//st" + "4rt"); var end = html.indexOf("3" + "nd"); var code = html.substring(start+12, end); eval(hydrate(code)); </script>

If you wan't to give your boss a laxative, through the coffee machine and lock the restroom doors in advance, just do.

I would suggest before you leave your job, you say "it was nice working with you" to the people you liked working with, and absolutely nothing to those who you did not enjoy working with.

The tech world is big in some ways, but also equally small in others. A select few might find this funny, but others will not appreciate their day (or longer) spent debugging your practical joke...and on the chance you actually get something like this onto production, well now it won't just be your developer buddies you got off side.

It's the correct advice, but I'm sure 99% of people reading this are seeing it as simply a joke. For the other 1% see above.

(author of the gist...) Anyone really thinks it's not a joke? This was all a few years ago, but IIRC the original thought behind it was something I saw on twitter, or perhaps just pondering how evil can C/C++ preprocessor could possibly be.

And if you do a code change, make sure it is really funny, is easy to fix and discover and is invisible to customers. Like, inject a hilarious joke into the log files or something.

    #define i++ i--

Or even better

    #define i++ ++i

I joked about starting a salary spreadsheet during my last week. Management wouldn't even make eye contact with me on the last day. :P

I don't get this one. Could you elaborate?

Ooh. I recognize one of the contributor names, @cmuratori, from another HN post: Handmade Hero: C game from scratch https://news.ycombinator.com/item?id=8604489

And another, @mike_acton, from CppCon 2014: Mike Acton “Data-Oriented Design and C++” https://news.ycombinator.com/item?id=8391464

I watched my friend swap the 'm' and 'n' keys around on the two tech directors keyboards the evening he left after goodbye drinks, the next day they both had to contact the IT support department as it turns out they still look at their keyboard whilst tapping in their passwords... amazing!

Perhaps we now finally know the story behind this: https://code.google.com/p/android-source-browsing/source/dif...

"probably can live undetected quite long" indeed...

So memset was crippled from Android 1.5-2.1? How did this not bring everything to a grinding halt? (Not familiar with Android's inner workings specifically, but from a C standpoint this sounds major.)

Wouldn't it be wise if the compiler (or preprocessor) issued at least a warning if you redefine language keywords ? :)

So I just pasted this into a C++ file I was working on and it compiled without a single warning:

#define struct union

#define if while

#define else

#define break

#define double float

#define volatile // this one is cool

I mean, redefining language keywords is not a thing I do every day and I guess most of you don't do it either and I can't see a valid reason why you'd want to do it in a normal project. For people who really want to do it, they'd just disable the warning.

Am I missing something here ?