I gave my notice at a certain IT department in late October 1999 as I had a new job waiting in January. I wasn't working on anything Y2K, my documentation was up to date and I did a good handover but the (contract) project manager appealed to management to keep me on "just in case" of something. I took December as holiday (as there was a "use it or lose it" policy and that same PM had stopped me using it during the summer, leaving me 5 weeks to burn.

January 4th I was back at the office. I chatted to my colleagues, made some tea, browsed the internet and swivelled my chair left, then right. I repeated that for 4 weeks. Occasionally some managers not from the IT department would ask what I was doing these days and I'd tell them. I didn't sabotage anything except that PM's contract.

My contract doing Unix and storage work on an SAP project was due to end in May, but the full time guy who they ran ragged with unpaid overtime and 24x7 on call gave notice in April to become a consultant making 3x what they paid him. He was in the process of training a couple underlings pulled from the Engineering division's Unix team but they were pretty green when he gave notice.

The project lead told the powers that be they had to extend my contract as I was the only one who really knew the system, and when they came to me I could smell their desperation so I scored another $30/hr for a three month extension.

After this was done, the two full time guys came to me and basically told me they didn't want me touching anything unless they specifically asked me. The way they looked at things, they were going to have to manage everything once I'm gone and they'd rather screw up now when they can be more easily forgiven. I was treated as a resource to answer their questions, nothing more. So I spent the entire summer browsing the web or hacking Linux (a few patches still remain in the source from that time) and they went from having a few questions a day at first to basically ignoring me the last month and a half. I took a week off to travel to Europe in August and they didn't even notice I was gone.

Easiest money I ever made.

It's nice to work with good people.

They were right! Get yourself up to speed, do not let the wizard do their magic - but ask them, learn from them, and hopefully they no longer need to ask for help during the last month. Yes, easy money for the wizard, but their role is as a teacher and an insurance, and both are worth every penny!

Fire somebody, but keep them for a month to train their replacement. Possibly, a cheaper, offshore, replacement.

Ah, you obviously attended the Wipro school of manglement !

:p

Yes, of course, no way that training could go wrong?

The alternative, I've discovered, is not to train them but let another of the client's suppliers train them instead. Or, as it turned out, the other supplier's contractor. It became obvious that the data we received had similar mistakes in it every few months as a new lot were rotated in on their 6 month visas and decided to rework their predecessor's code that they didn't understand.

Worse than that. I once had colleagues who were being made redundant for not accepting relocation. They found that the replacements they were training were on a higher pay grade.

Similar to

"They give the promotion you were hoping for to outsider, then ask you to train them"

Theres a 'Dilbert' to that effect somewhere.

Whenever you fire someone who has privileged access to *anything* of importance, you always revoke the access immediately and ideally put the person on gardening leave for the duration of their notice period. It's simply due diligence and is for their protection as much as yours.

I have sadly been in this position myself - not the being fired part, but being pulled into HR to be informed my that my boss was about to be dismissed. It wasn't for reasons of performance or anything, the company had been bought out and the new parent company decided they didn't need two IT managers.

Anyway, I was told that my boss would be called into a meeting with HR, and whilst he was there I was to disable every account he had, change any shared passwords (ie, admin account passwords) and make sure that he no access to any systems whatsoever. It can sound harsh, but you've simply got to do it - no matter how much you may think you can trust that person.

Many years ago (early 90s), I was working with a codebase written in assembler (6502 for those who are interested).

The primary author of the original code was brilliant [1] but the comments were utterly useless.

A typical line might look like:

BNE ; not zero, go to label.

There was no comment on just what meaning the item being tested for zero actually had.

Fortunately, the labels had a tiny bit of meaning so we were able to work out what the code did, but it took several months.

[1] Brilliant in the sense that the code he wrote was excellent in functionality. My personal view is the person was not a particularly good software engineer. As the article noted, assembly needs proper comments to make sense of it.

I would like to point out, for the record, the main difference between "assembler" and "machine code".

Machine code is the actual, byte-for-byte code that a machine executes, and very rarely contains comments (it has been known, but it's generally a waste of space, except when symbol names are left in to aid debugging).

Assembler is a way of representing this code, normally by symbolic name for each machine instruction, but normally includes the concepts of named variables, labels, named functions and subroutines, and often macros expanded at assemble time. And, of course, comments.

You take assembler source, pass it through an assembler which strips out all comments, and does all the clever variable substitution, macro expansion (if present) and label and variable resolution, and produces an object file which is the machine code corresponding to the source, but which may not be complete because externally referenced subroutines and functions may yet to be included. You then submit this to a loader, linker or link editor that resolves and includes any references to library or other object files, which then spits out the machine code that the system actually executes.

It is possible to write machine code directly, but it's very rarely done, even by very low level programmers (or as exercises for students!) About the only people who really handcraft machine code are those who deal with tiny embedded systems with very little memory, but even then it is normal to write assembler code, and then use an assembler (often on a different platform to the one being targeted for the code) to do the machine code generation.

Modern IDEs often blur the distinction between macro processor, compiler, assembler, and loader, but even in the most integrated development environment, I would expect these steps to still be present.

If anybody remembers the C compilers for early Bell releases of UNIX, you could see the different stages explicitly, (the compiler could call the assembler and linker directly, but you could get it to spit out the code that was submitted to the assembler with the -s flag), and you had control of how the resultant objects were linked together. And of course, the original C++ compilers were just front ends to the C compiler, so went C++ -> C -> assembler -> linker -> executable machine code object.

> Dick changed all the comments in the code. Sure, they all still looked OK to the casual observer but bore no resemblance to what the code actually did.

Ahhhh. Otherwise known as "version 2"

The amount of time I used to spend believing the comments, rather than the code. A working practice I have been completely cured of for many, many, years.

It seems to me that most of the time that bug fixes, tweaks, modifications or any other changes are made few people see fit to alter the comments to reflect what was done. Or why it was done.

At best you might get a passive-aggressive: # fix for bug report 93315 which is neither helpful (or often correct).

"The amount of time I used to spend believing the comments, rather than the code. A working practice I have been completely cured of for many, many, years."

For anything written in human-readable code, yes this is true. Assembler however is essentially* unreadable without comments.

*Within any realistic timeframe

Surely, all that was needed was to go back in the version control system, and pull the earlier versions that still had meaningful comments, and then delta the non-comment changes to the latest version, just to get the more recent code changes.

What do you mean, "what version control?"...

"delta the non-comment changes to the latest version"

With boxes of cards?

Ah, OK. I missed the "go back to the 1970's".

In the early 1980s I did work for an organization that kept the original card decks for all programs that were written, but they also had a disk based online card image library.

But SCCS goes back to 1972, so it is not so far fetched to suppose that there may have been a version control system available.

"The amount of time I used to spend believing the comments, rather than the code."

You need to allow for the possibility that the comment tells what the code should have been but isn't.

That has to be what he meant. Its either that or another case of malicious comment abuse like in the article , which cant be that common!

The code also had to be as small as possible so many tricks were used to reduce bloat

But sometimes reduced bloat and "clean" programming caused more problems than it solved.

Back when I was an analyst/programmer on DEC VAX at the local college we had a simple game, written by one of my predecessors, set up as part of the new student inductions as many of them hadn't used a computer before. It was noted from the monthly logs that this one game was causing more page faults than everything else put together. I got the job of trying to reduce this, which turned out to be quite simple.

The program was very well written and, as was considered "good programming", an operation that was carried out twice per iteration was called as a subroutine. The trouble was that the subroutine was only about 3 lines of actual code and the overhead of calling it was sufficient for the VAX to page fault every time, twice per iteration, every few seconds, with a lot of students...

The answer? Just in-line the operation, twice, the code fit nicely into one page, everybody happy.

This makes me very glad I got into programming after this kind of thing stopped being necessary for most software. Having to make code worse to make it work feels bad to me.

And the moral of the story? "When you fire someone get them out of the door immediately!"

Pay people what they're worth, I'd have thought

Yeah but sometimes people really do need to be let go; regardless of how 'good' they are at their jobs. Like many others here, I've been in a team with somebody who was very good at the technical aspects of the job, but completely impossible to work with. Refused to comment code, didn't attend stand-ups because he thought they were a waste of time, refused to work with the integration team because "if they're too stupid to understand my stuff, that's not my problem", and lastly was personally thoroughly obnoxious in word, deed and frankly, smell.

Finally management did the necessary, and had a 5-minute meeting with him on Friday at 11am including the classic line: "We appreciate you might think it's impossible for us to do this without you, but as of Monday, we're going to try."

Back in the dark ages I worked in the support and development teams for a then well known and widely used Database product.

The product in question had been originally written as an in-house tool by a large corporation's IT department, bought by a systems vendor, source converted onto a different platform, and subsequently licensed by the company I worked for and source converted once more time into the native assembly code for the Mainframe it then ran on.

So, the main core components of the product, the code modules that interpreted DML commands at run time, were all still the doubly source converted code that had been delevloped, engnahced, patched, bodged and battered. The comments for the remaining Ur-code were the original early '70's era assembler code, and parts of it (the hashing algorithm was once such) were sufficiently sacrosanct that they just had "don't even think about trying to change this" comments around them.

The Schema compiler still generated '70's era assembler data constructs for the run-time tables, which were run through the same source code converter in order to spit out the final loadable objects.

I am being deliverately obscure here because the product is still in use. Meaning that code I wrote in the '80's is still being used somewhere, which is terrifying in tself.

Damn, I wish they paid performance royalties!

The product in question had been originally written as an in-house tool by a large corporation's IT department.>

I've worked on many systems that have been written by in-house tools!

OTOH, when version control goes thru a few outsourcerers, I found all code I had written on one site for the departments main activity had the comments removed when I looked at it a decade or so later. Why, no idea. The original team kept a full change history of who, when, why and what.

Why, no idea

"Our" fairly large and reasonably innovative at the time project got transferred to India for "maintainance".

Our site were to be the 3'rd line support. However, those indian capital wankers kept toying with the code, breaking it, then whining to everyone up the coporate "value chain" about how smart they were to find all these bugs, followed by more whining when instructed by developers "to put it back to how it was and stop tinkering, that will fix it!", quite soon, we were instructed to just fix all of their breakage - a.k.a. put it all back to how it was, except for those parts we missed.

This pissed everyone royally off so, in the end we gave the Indians what they were angling for: The full ownership of the entire code base, except, all the comments were replaced with numeric codes, referencing text strings, so the precompiler cold do translation of all of those the strings for proper Localisation and the local team could read the comments in their native language.

Or should have, because, along the way, the comment-string database somehow got lost in ClearCase and since it was not our teams product to support anymore .... nothing could be done about finding it.

Eventually, the "Splat" on The Bottom Line made the codebase come back. But, the team is gone, the code has been sucked into Rational Rose RT and turned to gibberish, and all the comment strings are still lost in ClearCase.

I've been in both situations, in theory.

I've had redundancies due to firms relocating where I've known for months that I was going, generally I've managed to come out of these quite well (the last one got up to the £500/day level to retain my services). I've also had one where I was escorted to the door after retrieving my personal property, although in truth I was surprised it had taken them that long - my role had gone* so I knew redundancy beckoned and if I'd wanted to lay any traps I had plenty of time to do so.

I can see that if someone feels badly treated they want to extract revenge but it's a dangerous path to tread and, to my mind, unprofessional.

*It hadn't really but I was a victim of manoeuvring by others and was paid off with enough to be happy, especially as I had a better job within a couple of weeks.

Used to work in the CAD industry in Cambridge. It's a very small and incestuous industry, so eventually everyone gets to work with everyone else. There's a tacit gentleman's agreement not to enforce non-compete clauses as decreasing mobility decreases innovation. Overall, ignoring non-compete clauses is a good thing for the industry.

Anyway... one of my good friends decided to leave for a rival company across town. He was fully expecting to be put on 'garden leave' and have a few weeks of dossing around before starting his new job. Unfortunately, the conversation with his manager went something like this:

[Friend] I'm leaving and going to work for [redacted].

[Manager] That's fine. Just finish your project before you go.

[Fr] Err, you do know they're a competing company?

[Mgr] I know that. Just finish your project before you go.

[Fr] Aren't you going to put me on 'garden leave'?

[Mgr] That won't be necessary. Just finish your project before you go.

Instead of relaxing on gardening leave, he spent his notice period frantically trying to finish his project. He was well p1553d off!

More fool him. He should have done his contracted minimum and left it 90% finished.

Ah the Cambridge IT Mafia. Back in the day I swear nearly every IT company had at least a few people who had worked with each other at a previous company at some stage.

there was a similar thing in the West Midlands, with a lot of firms formed out of ACT (who themselves fell out of Apricot I believe ?)

At one point, there were 3 separate companies in the same building that had formed from ACT - LLS (became WMS) who I worked for a company doing Windows CE, and a third doing process management.

> He was well p1553d off!

so, mission accomplished.

At least people aren't subject to a systemd message I encountered recently.

systemd: worker not accepting requests - worker killed

This is why HR should never be allowed near the sharp end of IT. It might give them ideas.

I find it pretty sad that Humans have been reduced to status of "resource" as it is.

and HR have made that their nameplate

First place I worked at, they employed a French developer as a contractor to develop a standalone system. When he left and I was asked to extend the functionality, I discovered he had used French to name everything and bizarrely wrote all his comments in Spanish! All I can think is that it was some elaborate attempt to get his contract extended, but thankfully we had a lady in accounts who was French and could also just about interpret his Spanish comments.

I am posting this anonymously, for reasons that will become obvious.

In the early 1980s I was working for a large engineering firm in the North West of England. Sadly the firm, the office block, and the heavy industrial engineering buildings are no more, but I don't think my efforts were part of this. During my time, I was System Programmer on a brand new VAX 11/780, then hot off the shelf which we kicked off with a massive 456MB of RAM (a nod to the original story of having to make your code compact). Like the original story, much of what we did was coded in Macro32 Assembler (or machine code). I became very adept at system internals and how to use and write system service calls.

I was also the go to person to laise with the mainframe boys who worked out of the midlands. I had experience of HASP. JES, IEBGENR and all the fun tools we accessed via punch cards. I got on well with the midland computing team.

All was well, until my boss who was a great leader to work for, was replaced by someone we will call the Ginger Bearded Giant (GBG). He was a right bastard. If he could do something to upset you, he would. Just for the sheer hell of it. He and I did not see eye-to-eye, so the time came when I handed in my notice to move jobs across town.

I was given an exit interview, during which the HR person asked me why I turned down the plumb jib to become a system programmer with the mainframe team, after all it was a great promotion and a big pay increase. I was struck dumb. I knew nothing of this, and said so. HR told me that GBG had spoken to me, showed me the transfer request and that I had turned it down. HR pulled out my file and showed me the document where I had signed that I turned it down. The trouble was, that wasnt my signature. Not even close. GBG had forged my refusal to take a plum job at a huge salary hike.

So, out comes the BOFH grin (though this was BSPFH). It was too late for me to take the job, but not too late to have a little fun and revenge. I used my last week coding a timebomb that I placed right at the heart of SYSLIB, the VAX/VMS System Library at the heart of the operating system. A week after I lkeft, the code kicked in. Next Monday. GBG logged in and asked for his directory. ANd the system said "No". So he tried again, and the system said, "I told you before, No". So then he asked to get the current work list for teh engineering team and the system said "Sorry, GBG, but I am unable to do this". It had over 30 different ways of not doing what he wanted. In fact, the only command that would work was logout. Eveything else, and I do mean everything, redirected to the program that say No.

He called my young apprentice over, who looked at this and laughed. He called the System Manager over, who also laughed. System Manager logged in, and hey - everything works. GBG logs on and it all falls apart. So they go to System Managers terminal and try - it works for System Manager, but not for GBG. This goes on for a week. They called Digital (DEC) in. They look at and laugh, and conclude that what ever was done, its smarter than they are. They couldnt figure it out at all.

The fix was quite simple, and I was surprised later when I met up with my apprentice (who by now was a leading light in database technology) that no one spotted it. Simply save all of GBG's files somewhere (which System Manger could have done in his sleep), delete his account. recreated it and restore the files. But no, they didn't do that. They nuked the whole damn operating system and reloaded from tapes.

I was asked to come back, on a contract, at extra ordinarily high rates, to fix it. But of course, I denied everything. I even managed not to laugh on the phone. Being able to fix it would have been tantamount to admitting liability, so I used plausible deniability as the way out. After all, it worked for a week when I wasn't there, so it couldn't have been me.

And the moral - if you are going to piss off a competent sysprog you had better be prepared to walk him/her off site immediately they hand in their notice.

With evidence of the forgery the easier and better fix might have been to replace the GBG.

Maybe I spent some of the HR-mandated punishment service to do really useful stuff like updating the Site Operations Manual. Like maybe every six months there is a to be live UPS failover test, to make sure that everything is spickety-spank and running extra smmmothly?

"The code also had to be as small as possible so many tricks were used to reduce bloat, something maybe we have lost nowadays."

I didnt work on minicomputers in the 70's , but i saw what was possible on 8 bit home machines in the 80s with 3mhz and 64k ram

The documentary about how those 2 guys created the game "Elite" whithin the hardware constraints is amazing.

"a good nights work - I saved a byte!"

In the late 1990's I did some work for a satcom company that was build a new and innovative (at least when the company was set up) system that would allow handheld terminals to operate around the world (this is just before mobile phone roaming agreements started to be established). The company was burning through its start-up budget like mad, so they someone in senior management decided that the best way of saving money was to get rid of all of the contractors.

This decision was not really thought through since there were two issues that they had not considered. Firstly, at least two-thirds of the company were contractors, often with highly specialised knowledge that they did not have in-house. Secondly, some of the contractors had long-term contracts (I personally knew one who had just signed a 2 year contract extension on very good terms), and hence did not appreciate the 1 weeks notice they were given, generally in violation of the T&Cs of their contracts. Of course this company threatened to turn the lawyers on anyone who dared complain to the courts about "breach of contract".

In addition the company did not bother to ask anyone to perform a handover and knowledge transfer to the in-house staff, but simply assumed that that would happen. Given what had just happened to the contractors, they were not in a good mood and simply did not do anything they were not explicitly asked to do. Which meant that, the Monday after the contractors had all left, the company found that it needed to be doing some highly technical and deeply specialised work, but had no-one left who knew what to do, or how to do it. A series of frantic phone calls to the former contractors elicited precisely no co-operation at any level, or for any price.

About one year later, the company went bankrupt.