If you fire someone, don't let them hang around a month to finish code With The Great Resignation upon us, depending on which survey you read, we present a reminder that when a programmer has to go… just let them go. Or face whatever form their vengeance might take. Welcome to Who, Me? We go back to the 1970s for today's tale, courtesy of a reader Regomised as "Thomas". Thomas was working for a …
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.
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!
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.
In those circumstances, you look up the procedures in the office manual that were last updated around 1995 for when the company was going for ISO9000 and then train people on those.
Yours is not to question why; if manglement wanted the procedures changed then surely they would have done so and they can't blame you for training people on the approved procedures in place.
The problem with ISO9000 is that it doesn't stipulate anything in the doucment is actually TESTED
As I once commented in the 1990s, "You can write an ISO9000 document detailing how to fly a 747 into Angel Falls or the World Trade Centre. It doesn't mean it's a good idea or that anyone will test it"
Except that someone went ahead and bloody well did
The problem with ISO9000 is that it doesn't stipulate anything in the doucment is actually TESTED
Actually, it does. There's a whole audit process to ensure that the procedures as written are being followed, and if not, to update either the written or practised procedure - or both - until the two are in synch.
If your employer wasn't doing this, that's on them.
ISO9000 is all about process, and you're right - that process includes testing and verification that procedures are being followed. It can document pretty much any process, not just software or shop floors.
I think of it as more of an ideal state where tests are indeed producing results that can be used to feed back changes to the process, improving it, reducing errors, and hopefully improving productivity along the way. But that is the ideal world. In practice, most organizations document their "ISO9000 process", stick it on a shelf some where, and don't keep it up to date nor follow it properly, because it was never more than a checkmark on some management beancounter's list of "requirements."
Thing with this is that it's such a waste of time.
A former employer suddenly had to get certification, because a major worldwide supplier demanded it.
Cue months of wasted time.
Then every year or so, a BSI bod would come in an 'audit' us against the said document.
One week before.... "can someone update the documentation".
Cue 10 people spending the entire week doing their respective departments updates.
The auditor was an anal retentive, but there was never a big list of issues.
As far as the supplier was concerned, it was proof of the company being properly run etc.
I can tell you now.... it proves nothing, but earn some people big bucks, for very little real use.
Well, there's more to it than that. Management is supposed to be reviewing shit regularly and updating procs all the time, as necessary.
So maybe someone in management was faking a paper trail for that, or maybe the auditor just logged a whole slew of non-compliances for them that no one thought you needed to know about. (Bet you didn't get to see the actual audit report, did you?)
If you do it like you describe, then yes, it's a significant cost for no real benefit.. But that's not how it's designed to be used. Like programming tools, there are good and bad ways to use management tools too.
While working in Australia many decades ago, I encountered an outfit that had a paid position called Process Rationalizer whose job was, after the fact, to go in and create all the documentation establishing that the developers had followed procedure--whether or not they had. I once told a QA bigwig about this without naming names, and he went apoplectic, insisting that I expose the perpetrators of such a heinous violation of the true purpose of standards of practice.
I suspect that it makes very little difference in the long run. I was made redundant last year when 3/4s of the test team was outsourced to the big W. I diligently did all the handover sessions with the new bods, braindumps of product and system knowledge that were so comprehensive they extended my leaving date by a month to get them all done. Caught up with a former colleague 6 months later and only one of those people is still on the project. The rest have been replaced with fresh bums on seats and no knowledge.
I was let go from a tech support position with a large US software house many years ago as they moved much of the support function to India. I worked my month notice "knowledge-sharing" with my "replacements" but the day I finally walked out the door for the last time, they were still sending me the most basic of support cases as they either didn't understand, or didn't want to understand, how to troubleshoot user issues. The fact that they all wanted to be programmers and thought of tech support merely as a foot in the door may have had something to do with it. Not surprisingly, the company in question developed a reputation for providing execrable technical support. Not that they cared very much, I imagine. They had something of a monopoly in their market.
How on EARTH have people got brainwashed into thinking tech support is the route to programming? If you want to be a programmer, enter programming, not not-programming.
I wanna be a surgeon, I know, I'll clean hospital toilets. It's "working in healthcare", what's the problem?
Sheesh!
For a very long time support was the main route to a programming job. I was told this repeatedly by recruiters when I started 25 years ago, and they were right. In fact, the vast majority of software devs/engs I know that started in that era all got their foot in the door via tech support.
So much of todays code is generic / commoditised web code, or just plain boilerplate. The threshold for being a productive enough dev (to warrant employment) is therefore generally quite low. But this wasn’t true 25 years ago - code and programming techniques were a lot more specific to the use case. You were pretty much useless until you became familiar with the product & code base, irrespective of your programming skills. An initial 6-18 months in support was the way you got up to speed while not being a huge burden on everyone else.
It was also the case that code was seen as much more valuable and sacrosanct than it is today. Companies didn’t want any old fool fiddling with their code, and your time in support was a way of demonstrating your diligence, competence and trustworthiness before you were released into the wild!
@J.G.Harston, depends on how people look at their career path forward. The CEO of Walmart started as the simplest worker in high school. Usually, tech support managers will not want to hire overqualified candidates exactly because of this, but sometimes they can't help themselves. I've worked with a few who gave awesome support and it was bittersweet to hear when they found something else in the company.
Well, as a Someone who rose through the ranks from service desk to Systems Architect. I have always said that every junior programmer should spend at least 6 months in the service desk just to experience the HELL bad code can put the support people through!
I thought it might make them code and debug more responsibly. But I'm probably mistaken!
You're not wrong. A company I used to work for did this. Engineering had to spend a week on the support floor with the support desk and listen into calls, and try to resolve calls on the fly. It was not pretty, and I wonder how many engineers actually learned to respect support, or learned to code better.
That said, my own experiences in tech support for many years, and then also as a developer whose ultimate customers were the IT departments of some large organisations, made me vow to improve my code such that it was easier to use, debug, and figure out than the crap I had the distinct displeasure of having to work with.
Microsoft did that, a lot.
After seventeen hours straight being on the phone with several Indian consultants for an Exchange 2010 issue, I got transferred to a guy in Dallas who really knew his stuff. Took him six hours of rebuilding my Exchange files to sort out my issues (including the ones introduced by the other engineers.) Last part of the call he told me he was the last Dallas staffer. The rest of the Exchange group had been let go after training their replacements in Mumbai. He was due to clock out five months earlier, but they kept extending his contract a month at a time. He knew the systems inside out and the Indian call center guys kept referring the tough cases to him.
He confided that this was his last month come what may as he had a new job lined up. Stupidly, the re-engagement employment contract they had him sign had no notification clause. They came to him on the last day of the month long contract with a new one for him to sign. At the end of his contract, he could just walk away and he the intention to do just that on the last day.
A brilliant engineer sacrificed for Microsoft's bottom line.
PS. The quality of the Indian call-centers has improved dramatically since then and I'm not slamming them as individuals. However, at that time in history, their skills were remarkably underdeveloped.
TBF to the guys in Mumbai Exchange was a pile of shit early on. Cant say how it is now but I worked at one place that had a support contract and they'd spend 3 days sending me MSDN numbers to read and try to fix the database corruption that seemed to occur fairly regularly. On one occasion the last resort DB repair program could fix the DB even after a dozen runs or so but I'd discovered the Exchange API by then and used that to basically read out message after message and put them into a new DB and then renamed that to the old DB name and rebooted the system and the corruption was gone. The VB code I wrote was about 30 times faster than the MS db cleaning engine and seemed to get all the existing messages out - Exchange just would just leave corrupted bits of data in the DB from time to time and then fall over them, and sometimes their repair program would too.
And the best thing was I discovered I had access to everyone's mail. Not that I read (many of) them but I learned that security has to be put in at the start and not added on later.
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.
> It can sound harsh, but you've simply got to do it - no matter how much you may think you can trust that person.
I always position it as it protecting that person too.
If someone does something on the system shortly after you've been dismissed, you don't really want there to be any question about it might have been you (if nothing else, you want to be sure you won't be scapegoated).
It protects both sides, which is far less harsh (though still won't feel that way when they come out of the office to find themselves locked out).
"I always position it as it protecting that person too."
It absolutely does protect that person. There are always crafty people looking for someone upon whom to pin their misdeeds, someone just let go would make a perfect fall guy. Example, as a lad I was part-time working the cash register (and sandwiches) at a restaurant. After I started, one of the cooks started stealing from the drawer, but only on the nights I worked. I found out on the night they set up the surveillance to catch him.... "Hey, go take a break."
I've been the person being called in to an unexpected meeting with HR - got the call on Sunday evening, the meeting was on Monday at 9:00. I dictated a list of systems and passwords that I insisted be changed, to protect myself. She said they had it all covered, but they had missed several.
I did that when I was made redundant once with a company I really loved working for. Gave them the list of creds that they had to change.
The last company I was made redundant from also did the 'oh, but you'll have to work out your notice' thing, so I spent my time documenting stuff and making sure the colleagues in question knew. I cleared down my workstation publicly did so so I couldn't be accused of having taken any of their code (not that I wanted to... I was done with that software and never wanted to see it again), and on the last day I emailed my manager telling him what was done, what wasn't, and could he please verify that everything was terminated because as far as I was concerned, we were done and over.
Never heard anything back from anyone, other than someone calling me about how something worked and me saying "sorry, I don't work there anymore, I cannot help you".
I've heard of people trying to do the same to people who voluntarily resign. Just a quick reminder that doing this is pointless and stupid. If someone is quitting they will obviously know before you do and if you have a regular habit of escorting quitters out the same way you kick out fired people then you can guarantee they already know how you will behave. Save yourself some organisational memory and don't burn that bridge. If someone tells you they are quitting then lock them out on their last day not before.
If someone tells you they are quitting then lock them out on their last day not before.
Most organisations are narcisstic to some degree. And, narcissists does not handle rejection very well.
The higher the level of group-narcissim is, the more the organisation will try to take revenge over being failed by the quitters!
Its best to lock their accounts a day or two before.
I've seen far too many occurrences where critical processes were running as a standard user. Telling the person who quit their last few days are coffee and consulting still leaves on good terms
During my first IT tour of duty at NHS I pointed out how poor security was when engineers left. No passwords were ever changed etc. So when my contract came to an end they gave me gardening leave for the last week to try to "prove a point". I didn't care, got a week off but paid and they still fucked up.
This is over 10 years ago when the iPod Touch was a thing. It was the only Apple product I'd ever own (sold later when I realised how locked down Apple was). Due to a bug Apple didn't want to fix, their version of Outlook allowed exchange e-mail access to mailboxes where you required a cert that was only installed on official NHS hardware. It sent a signal or something back to exchange to fool it into believing the cert was there. So I was able to get all my NHS e-mails on the Touch because they refused, as I was only a contractor, to give me a Blackberry. Anyway. After I left, for well over a month, my Touch was still getting e-mails into my NHS inbox. I asked a tech who I knew who was still working there why my account hadn't been disabled. Her reply was "I told help desk the day you left to disable your account. They are useless and clearly haven't done it". She couldn't as you had to follow "process". I'd gotten bored of seeing the e-mails come in so just deleted the mailbox off the Touch in the end before they'd even disabled the account.
Once you've gotten access, or a right according to your role, you never lose it in a lot of companies. After a bit switching around, since you are the multi-talent, you have access to everything. Even when you should not according to your current role. Including your example of a different role in a different company :D.
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 <label>; 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.
Not quite. The first iteration ignored errors for unknown labels, but would step through the code correctly, so when the labels were seen they would be correctly set.
The second iteration did the exact same thing, but didn't ignore missing labels because now they'd all be known.
It would be executed when you did CALL or USR.
It's my guilty pleasure today, though I usually use ObjAsm as it's less farting around. ;)
For added farting around, including machine code into TRS-80 BASIC was even more fun. Probably the most efficient way, assuming the code was shorter than the 250 or so characters available to a string variable, was to put the hex or decimal into BASIC data statements, locate the LET statement that assigned the string of spaces or whatever, and POKE the values directly into the source code. Next, back in edit mode, delete the code that put the m/c into the string along with the DATA statements and SAVE the program which now contains a LET statement with a weird looking string assignment that usually won't even LIST properly because it likely contains control codes interpreted by the LIST display parser. IIRC you could create up to 10 m/c USR calls if all you needed were some short, separate routines. Also, it was quite easy to add to BASIC, either by being clever and intercepting the syntax error call, or, if not using a DOS, tapping into the DOS BASIC extended commands which, without DOS booted, just had a jump instruction the SN ERROR routine
Some years prior to that, we had Heathkit (remember them?) educational boards when I was teaching electronics.
The only way to program them was to input the actual opcodes using a hex keypad (most were based around the 6800 series parts IIRC). The location of the code had to be reachable via the reset vector.
So:
Do a flowchart (maybe).
Write the assembly code.
Hand assemble the code (in those halcyon days the opcodes were listed in the datasheet).
Set an address, load a byte. Repeat at next memory location until done.
Point the reset vector at the start of your code.
Not something I would do today but it certainly gives insight into just how a microprocessor actually operates.
A favourite saying from the time: "The processor will execute the code, not the comments which may not actually do what you wanted it to do".
Icon cos ancient history.
A Open University courses in the 1980s taught computing using HEKTOR (acronym now forgotten). First we coded by hand - pure assembler, calculating jumps, etc. Then progressed to a very simple assembler and so eventually on to a C compiler & linker. I used some of that knowledge when I had a chip whose floating point multiply took umpteen clock cycles to multiply by 10 - I did 3 left shifts then added the original twice, much faster
Ah that brought back memories. I worked on a system in the mid 80's (just it was incredibly obsolete then..) which was an X ray thickness gauge for steelmills. Real time, multitasking code written in assembler. The gauges were sold around the world and if anything went wrong with the code, we would (try and) figure out what was happening remotely and create a patch. All the debugging was by telephone/telex ( :) who remembers that) and then a patch was sent out via telex which was keyed in an empty part of EEPROM. Then 0xFF was overwritten into the EEPROM at the appropriate place to jump to the patch.
Most challenging job I ever had....
The worst one I had was a manufacturer of industrial process controllers and monitoring equipment who was (bizarrely) wedded to the 80186 processor (the one that NOBODY else used!). The assembler and all the other tools were horrible, and getting any kind of stable performance out of this gear was near to impossible.
I stuck at it for about 10 months, and then went and got a very much more lucrative job writing C for another manufacturer of industrial monitoring gear. The first company collapsed shortly after I left, and the new concern I was at bought all their product range and patents.....
I left the second job on the day they asked me to migrate the 80186 code to later a Intel processor.....
Anon - because these guys are used to control Nuclear Reactors!
Comments are always contentious. I did have a bit of a battle with someone who was trying to use me as the excuse why his bit of the system wasnt working when all the bits he'd asked me to do were. He changed the rules so basically comments had to be so detailed someone who had never programmed could follow it. So 300 lines of device driver became so large it wouldnt assemble on the machine he thought I had to assemble on. But of course I could cross assemble it elsewhere and copy the object file over et voila. It was around this time I realised he'd spent two years there being paid a fortune to code something without actually knowing how to code but somehow he'd decided to make me the fall guy - even though I could have actually helped him if he hadn't tried shitting on me - the thing he was trying to code could be achieve by basically cutting and pasting the data from a large document into the DB and putting it in the right drop-down lists at the right time. However he chose to fire me while I was away at my mothers funeral and I was told not to come back to the office or contact anyone in the company or legal action would be taken!! He managed another year before the Director finally sussed out his childhood friend was just a con artist and sued his balls off!
"About the only people who really handcraft machine code are those who deal with tiny embedded systems with very little memory"
Far and away the most common use of programming in machine code without an assembler is vulnerability analysis and exploit creation. Engineers writing software you want to run invariably use an assembler. When you're writing code from scratch -- as opposed to gluing together bits that are already in some region of memory -- there is nothing you can do in machine code that you cannot do with an assembler, provided the assembler supports the entire instruction set. Unlike in high-level languages, the mapping between mnemonics and machine code is 1-1 and (normally) unaffected by surrounding code, so every valid instruction encoding is available. If the assembler is missing support for some instructions or encodings, or one wishes to create an *invalid* encoding for some reason, those still can be defined manually without needing to write the whole program in machine code. Even in embedded applications, writing software in raw binary form would always be considered deliberate obfuscation and extremely poor practice.
Patches to assembler-generated code were typically done in machine language.
On rare occasions I would 'patch' on the fly a COBOL program with a bug after it had run for a couple hours then failed. After figuring out a patch, I would restart from the last checkpoint, set 'stop on address' switches on the 360/40, then set data and address switches to push the patch into memory, hit the "STORE" button, and pray. Actually worked more than once.
This would normally take place at 2am, after I was woken by Ops when my weekly Hospital Billing program failed. It had to complete in order for the next daily to run.
Good times.
The last time I wrote actual machine code, I hand assembled the machine code into position to replace the first part of PCDOS (yes, IBM's) critical interrupt handler. The space is small enough so I needed to be crafty and make something small but effective.
For those of you asking why on earth I would need to do this, it involved an unmanned PC sat in a cupboard talking to VTAM area on mainframe to grab information. The link would occasionally fail, leading to an "Abort, Retry, Ignore".
Every time I gave a training course in LotusScript or VBA, the last day I had a session on commenting your code.
I tried to drill in my students' head the fact that you do not write a comment that repeats what the code is saying. Anyone who can read code does not need a comment like "Test for zero".
I tried to show them that code commenting is "If there is no label, then <something> ".
Of course, I have no idea how successful I've been, but I've tried.
TBF there isnt room for gravel filled emergency off ramps in most cities so soft road furniture it is. I say soft as in my old village one house got pissed off with pissed teenagers coming over the 16thC humback bridge too fast and taking out their garden wall so managed to get some cat iron bollards to defend it and all it achieved was it launched a car over the wall into their living room!
Or as somebody else put it, "Don't put up road-signs that say 'keep going straight'."
On the other hand, a road sign which is effectively telling you to "keep going straight on", something like "Edinburgh 115 miles" is useful because now you know you don't need to keep looking for your exit every time you come to another junction.
Sometimes in assembler, undocumented crazy-looking stuff is merely slang for that machine type, and if you're not in the know, it doesn't make sense, but just works.
We never used the jump instruction, ex. "JP <label>" on our CDC 6600-series supercomputer. We used a compare-registers-and-jump-if-equal instruction on register B0 (B0 was was permanently wired with the value zero) instead. Ex., "EQ B0,B0 <label>" . If you left the register specification out, the COMPASS assembler would assume B0, so we'd simply use, "EQ <label>".
Why? Because it executed faster than the JP instruction.
Similarly bizarre-seeming was that we'd use a Program Stop ("PS") instruction as the first instruction of a subroutine, and at the end of the subroutine, jump back (using "EQ <label>") to that PS instruction.
Why? Because the 6600-series had plenty of registers, but no hardware stack. The subroutine call mechanism would, by design, self-modify the code, stuffing a Return Jump instruction into the first word of a subroutine. The PS instruction was a word of all zeroes.
There were some old info you could get on how to implement really useful machine code side effects to do things that weren't in the least bit obvious from the assembler. I've been looking for them recently but either my googlefoo is going to hell or they have been lost like tears in the rain. I found a few bits of really weird stuff in device drivers and when I used to step through code to find out how to get past the need for dongles or bits not in the normal parts of floppy disks.
"but I do recall being tickled by seeing XOR AX, AX to set it to zero."
IIRC Zaks Z80 assembly book had a table showing the clock count and byte count for each instruction. Very helpful for optimising for either speed or code size and determining the correct balance.
Yes, LDIR and LDDR. If you're partially overwriting the source with the destination, make sure you use either incrementing or decrementing as appropriate! Useful for loading tape based games into a system upgraded to use disks (TRS-80) or microdrives (Sinclair) as the OS extensions were sitting where the games expected to run from. Dump to disk or microdrive with a prepended loader to load it high then block move it to correct location, killing the DOS extensions, then jump to the original entry point :-)
Ahh, Those were the golden times: ONE book for the CPU, another book for the Peripherals.
Each book amounted to about 120 pages or so. One could read the documention for an entire system on the train.
Todays CPU are a 1200 page volume for the version 1.0 CPU, then six more with the Errata's and descriptions of variants, then one more tome for each on-board peripheral or bus, and each of those books have erratas, but, those mostly come as PDF's and are left to "the user" to discover.
Each of these replies is getting closer and closer in spirit to the story of Mel, a Real Programmer…
> 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
For people like me who program in assembler every day, it's no less readable than any other language.
But comments are important in every language. The purpose of the comment before every block of code is to tell the reader exactly what that block of code is supposed to do. Then they can compare it with what the block of code actually does and see how badly you fucked it up.
If you don't comment properly then anybody (including you five years later) who needs to debug or modify your code can see what it does, but has to guess whether that is the correct operation or not.
The other purpose of comments is to add irony, sarcasm, jokes, artistry and personal touches to programs which are otherwise rather boring text documents.
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?"...
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.
Your original cards might have been on the limits of readability before they went into storage - that's why there were card duplicators. Providing they'd been run through the interpretor you could always go through a card at a time and look for comments by Mk 1 eyeball.
Post-its are so yesterday.
Proper tickets are the way.
Better yet use thermal paper and they will auto-destruct
Or the bug database is upgraded following a corporate mandate, say moving from TFS to Azure DevOps.
Over our product's lifetime we've changed database 3 times. Even though the previous DB contents were migrated, all comments referencing old bug reports are now meaningless.
# fix for bug report 93315 http://localhost/projectnumber1/filecurentlybeingred#BR93315
is sometime the best way to do it - and its sort of bidirectional too in the sense you can hop from the place where the bug fix is defined to the code if you grep and or ASP a lot.
I think it was in the 70s, I was working with the source code to RT-11. (I was writing device drivers for lab data acquisition.) Whoever wrote that OS had the habit of a (sometimes) starting with a long comment - a quote from literature or poetry - at the head of each section - the essence of which hinted at the intent of the code.
I deepened my appreciation of literature... even now I remember "The Blue Guitar".
(Guess that isn't very common these days. Pint for anyone still doing that!)
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 kind of thing can still be necessary.
I like using recursive functions, whenever possible. It seems quite elegant to me, but I have learned that said elegance comes at a price.
For example, if you need to search and replace a given character in a string of characters (for export to csv reasons, for example), if you have to write your own s&r function for whatever reason, you'd better be sure that the original string isn't too long and that there aren't too many occurences.
Otherwise, your code will crash with a memory overflow error due to the amount of instances of the recursive function.
In that case, there's no choice but to deal with a loop function and handle everything in one instance.
It's a bummer, but it works.
I have only written recursive code ones - and that was to kill a process tree in Linux.
There so you execute stop on the parent so no more processes launched or reaped, deal with children, then kill the parent with SIGTERM (nice way) or SIGKILL (if needed). The "deal with children" is exactly the same but on a search for process with that have that as parent ID, so you can see how you just recurse the main routine on each child, then grandchild, etc, all the way down....
But knowing how the stack works I put a check in that if it recursed down more than X levels it would return instead of deeper recursion to avoid that process-corrupting (ideally segment violating) result.
I was once asked to write and document a well written recursive function to be used as an example for students to explain the concepts and code required.
I chose to write a recursive flood fill algorithm, which was technically very elegant, but suffered exactly the problems you allude to with regard to the stack.
I coded a version in BBC Basic (be careful with those global variables! although I also wrote it in the Acorn Pascal system for the BBC Micro), and being a relatively slow system (but fast for a Basic), and working on the actual drawn screen rather than a hidden frame buffer, it was fascinating to watch it go through the motions. I made it colour each pixel with one colour as it recursed down, and a different colour as it climbed out.
It used to fail with stack problems for relatively simple shapes more than a certain size. It actually worked better on complex shapes (because these gave it more chances to climb back out of the recursion).
I found that by controlling the argument passing in arrays, rather than using true nested function calls, I could get it to work on larger shapes without exhausting available memory, but this was not the point, as it was meant to demonstrate recursive functions.
In the good old days it was a rapid test of a 'computer scientist' vs a programmer.
CS courses seemed to love recursive functions as the ultimate elegance which could easily fit on a blackboard - so seemed to teach recursion as the cleverest thing a computer scientist could do.
Unfortunately computer scientists program imaginary computers with infinite memory (and are probably spherical and only operate in a vacuum).
Now I'm going to get nightmares tonight.
If products X & Y & Z were sold together as product A they had a different price than the total of prices when told separately. What's more X had a serial number which would become the serial number of A when it was sold as part of A. There could also be product B which was X & Y but not Z but also inherited the X serial number so A could be B & Z.
Products with serial numbers had a table individual rows for each item and stock levels were the counts of those which were unsold. Other products just had a stock level on the main product table maintained by dead reckoning and reset at stock takes.
The subtleties of this were only communicated to me shortly before go-live when I though the code was finished. The resulting hastily constructed recursive BOM with two limbs for the different cases worked but was clearly categorised as DO NOT TOUCH, even after I left and after I came back. Fortunately the whole pile of bits approach became redundant and could be removed from the codebase.
You could always use Scheme, which guarantees tail call optimisation (specifically so you can write that sort of recursive code functional programmers etc find so elegant...)
A C compiler can do it too but you're not /guaranteed/ it'll do it, so not something you'd want to rely on in production.
If a Lisp system hasn't got tail call optimisation these days it's not a real Lisp.
In C you can get (the effect of) single function tail recursion with a simple loop, but the multifunction form is a swine. I've seen some horrible trampoline code written just to get that effect. I suspect this is because it makes debugging interesting - "A calls B calls C calls D so why does my stack show A calling D directly and what were B & C's arguments?"
I applied my "C16 don't recurse" knowledge recently to powershell. The simple $variable = get-childitem -recurse caused powershell or go above 12 GB RAM usage on an 16 GB system just because the directory had so many files and folders. OK, then use my old "walk/iterate instead of recurse" knowledge from 30+ years ago and made it a live-walk through the tree with the old depth-counter + index method. Faster and way less memory hungry.
Shirley that was what macros were for? People used to complain about pointers in C, I wrote some code which was basically tables of ops managing tables of lists managing tables of selectable options and staring at rows of asterixes did my head in so I just put a few defines into a header and the whole thing became a doddle.The thing about coding is there is always a way to make your life a lot easier if you just take the time to ensure your arse is properly scratched!
Oh, the "functionitis" sickness I see from quite some coders! It is insane...
Typical example is: Program consists of five functions, which are defined. And then at the end those five functions are called ONCE in order. No nesting or other funny stuff. Usually those who write that style don't know about global, local or any scope of variables at all and wonder why it does not work, and have to put weird extra code into their functions to make it work.
Then I come along, clean that nonsense up and suddenly the code is half of the original size or lessn actually readable and faster!
Now imagine that with a large code base.
That's not always a problem. If the functions are designed properly, it still provides a system that's easier to update or modify. For the same reason that people write scripts that call system binaries instead of taking all the code for them and building a program with all of that included, there's a case for implementing a few basic functions and having a chain of calls in main.
If they're just doing it because they were told about the benefits of functions without understanding why, then I get your point. If they really did implement self-contained operations and then had a basic function to call each one, then I'm not sure it's an issue.
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."
Ah yes, they are everywhere, you can't escape them. They're officially known as 'The Insufferable IT-Twat', a Jungian archetype that Jung never got round to describing, because he was lucky enough to die before it emerged.
Insufferable IT-Twat <abbrev: IT-Twat>
(psychology, philosophy, psychoanalysis, Jungian analysis)
Definition & key features:
Jungian archetype of the insufferable, self-identified IT "genius" which first emerged in the mid 1990s.
Its prevalence grew rapidly, and by the mid 2000s it enjoyed a ubiquitous presence in IT departments across the globe. Key identifiers are: a grating personality which can range in intensity from mildly annoying to infuriating; extreme pedantry; inflated sense of own technical abilities; passive-aggressive interpersonal style; obstructive behaviour; strong unwillingness to help with anything, ever; dismissive of co-workers abilities, suggestions or opinions; dismissive of everyone else's opinions; patronising; rude; shows eagerness to sabotage colleagues; unwilling to train co-workers; highly deficient in self-awareness; lacks normal adult social skills; thinks everybody but him is an idiot; talks loudly so everybody can hear how clever he is; displays indigence at the suggestion that another individual could perform any part of his job; feels excessive and unwarranted confidence that the company could never cope without him; invariably a man.
Social and interpersonal impact:
The 'The Insufferable IT-Twat' has a significant impact on behaviour of those around him.
Responses are remarkably consistent across different cultures, companies, genders and ages. These are centred on the following themes: a desire to shout and swear at the IT-Twat; strong and often uncontrollable urge to strike him physically; an extreme aversion to being in his company or close proximity; strong feelings of dislike invariably felt toward him which may verge on mild hatred and/or disgust; strong ideation and frequent fantasising regarding IT-Twat being fired; shared experiences of extreme joy and schadenfreude if he does get sacked; joyful and sarcastic waving as he leaves the building for the last time; induces an irresistible urge for team to shout ‘don’t let the door hit you on the way out!’
Agreed - sometimes the boot is the best option.
Many moons ago I was IT admin in an engineering department of a big company. One of the project engineers was an absolute social turd - OK at his actual job, but delighted in antagonising others for the sole purpose of mocking and humiliating them to 'prove' his knowledge superiority. Women were a favourite target, so I was firmly in his sights until I out-argued him numerous times with witnesses (to the point where he would walk away when I arrived, which regularly let me run interference when he picked on the office admin girls).
I will add that our managers were decent and would normally have dealt with people like that pretty swiftly, but this guy was also an ethnic minority, VERY well versed in discrimination law (to the point of exploiting it for profit as a significant second income stream by suing people and businesses regularly), and played the race/discrimination card at the drop of a hat. So there was a certain amount of extra caution, and Mr Obnoxious clearly believed he was Teflon.
Until one evening my boss discreetly approached me as I was wrapping up for the day and quietly asked how long it would take to lock Mr Obnoxious out of certain key systems. "About 30 seconds, why?" I replied. "Please do it now - he's about to have a meeting he won't be coming back from. He'll probably win an unfair dismissal claim, but HR have said it's worth it to be rid of him..."
Shortly after, I left the building with a big grin on my face. Rumour had it the meeting was 'interesting, and loud' ;)
I agree.
The actual moral of the story is, when you have somebody who is really dedicated and goes the extra mile and puts in a lot of overtime for the benefit of the company, reward them for it.
Not: screw them over, fire them, and get them out the door before they can take revenge.
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!
If it isn't the same product, I certainly worked on one that followed the same path. When I was handed the task, it struck me that by learning SFL to support it I might be making a serious percentage increase in the number of active (or indeed breathing) practitioners of the art.
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, part of the handover was a localisation project. That was done totally By The Book: All strings, "all" of course meanbing also 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 localisation database somehow got lost inside of ClearCase and since it was not our teams product to support anymore, indeed ther was no more funding .... nothing could be done about finding it.
Eventually, the "Splat" on The Bottom Line from India made the codebase come back. But, the team is gone, the rest of the code has been sucked into Rational Rose RT and turned to gibberish, and all the comment strings remain 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.
Made redundant with the rest of my team, but supposed to work the notice period & we trust you will act professionally & not broadcast this to the staff outside of IT.
That lasted about 20 minutes as the IT Director (Who was there for the firing) told a higher up at our branch & it was around the place like wildfire!
A friend was made redundant from her marketing job. In the process she became well educated on UK employment laws. She then set herself up as an HR redundancy expert for down-sizing companies - many of whom were somewhat unsure of their legal positions.
As she said - her job as an employee with each company was perpetually to be the last one out of the door who switched off the lights.
"It hadn't really but I was a victim of manoeuvring by others [...]"
I gradually drew back - allowing some youngsters to believe they were achieving their career aims of usurping my role. IMHO they could not do the technical job properly as correcting their misdiagnoses was often needed - but it opened the door for my early retirement.
@GlenP “I've also had one where I was escorted to the door after retrieving my personal property”
At least you were able to retrieve your property.
I got the full bums rush when made redundant at one company. It was a small company of 9 people, and I was one of 4 programmers, two of which were also directors. I had been at the company a year and a half and there was no indication that the company was having financial problems so the redundance came out of the blue.
Middle of the week just before lunch one of the directors came over and asked me to follow him into the office. Entering the office, I saw there were two people the other director sitting at the desk and standing Infront of the desk the office secretary. I took the position indicated next to the secretary and we where then told that the company had to make cost cuts and regretfully the both of us were redundant.
That we would be paid to the end of the month and a month’s notice along with in the secretary’s case her state statutory redundancy and we now had to vacate the premises.
I went to go back through the door I came in saying I had to get my belongings. The director who called me in, jumped Infront of me and said I can’t return to the office and our belongings had been bagged up and can be picked up from reception on the way out. He then guided us both out through another door past reception picking up our belongings and out the front doors. Then without saying a word, he went back into the building.
This whole process took no more than 5 minutes from me leaving my desk to the two of us standing in the carpark staring at each with that look on our faces of what the hell just happened.
I was at a customers, about 20 years ago. We'd just finished seeing up a new accounts system using Windows server running Terminal Services, with minimal spec desktop PCs as clients. It was our first TS site, and something of a test.
I'd finished what I'd been on site doing, and was chatting with the office girls when they got a call for all staff to come to the warehouse for a meeting. (only place big enough for them all.) I said my goodbyes and went back to the office. Where I learned that the meeting had been to announce that the client had gone bust and everybody was being let go.
My boss was not happy as he thought I should have hung around, learned what was going on, and grabbed as much of the kit we'd just installed as possible, since it hadn't yet been paid for.
In the end, after much wrangling with the administrators, we got most of the hardware back, although we lost all the time-and-materials from installing networking throughout the building.
This was based on a "not yours until its paid for" clause on the back of the invoice.
Which hadn't been there when it was originally issued...
"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."
Never mind professionalism; this is a good way to end up in prison. There are plenty of ways to get revenge on a bad ex-employer that don't entail breaking the law or even putting yourself at risk of being charged. Whether you want to keep that kind of hatred with you for the time required to do so is a personal matter. For me, being fired was the best thing I could possibly have hoped for; I was working for people who were both technically and professionally horrible and being rid of them was strictly good for me. I thought long and hard about how best to get revenge and then finally realised that being the people they are is worse than any punishment I could deliver. Even trying to obliterate their teams by hiring people away made little sense; why would I want to hire people who are happy working for them (or are so weak they feel they have no alternative to get a living)? But there was never the slightest possibility I would sabotage anything or do deliberately shoddy work, no matter how angry I was before or after. If you're angry enough to wreck your own life to spite someone else, remove yourself from that person's influence. Even if you can't find other income for 2 years, that will do you far less harm than 2 years in prison.
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!
It's one of the downsides of working in an incestuous industry like IT in Cambridge. Sooner or later he would want to move on again. At which point his prospective new boss would ask around what he was like. "He pushed pretty hard to get his old projects to a good state before he left oldjob." is a much better thing to hear than "That git! You should have seen the pile of crap he left behind when he quit oldjob. Took us months to sort out."
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.
"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."
Absolutely. In 40 years (FSVO) in Cambridge I have only worked where I already knew someone, except the first when I was assigned to a project by an external partner. And I've employed someone I'd worked with before to start work less than 36 hours after his CV landed on my desk.
> 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.
Early '90s, worked as GIS tech in St. Petersburg (sunny place with beaches and pubs). There were 4 or 5 GIS shops in the area and when one got a large contract (i.e. map all utilities of St. Louis), they'd hire a bunch of folks for contract duration and then let us go. Could quickly find a job at another shop. Or course, with large pool of trained cart/digi-techs, wages stayed low.
Still, gave me my first exposure to SunOS and then Solaris so moved on after a couple years. Still have my rapidograph pens!
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.
At a place where I was working as a contractor back in the '80s, there was a particularly inflexible, unhelpful and downright rude contractor who finally pushed things too far and got canned. I was asked to finish what he was working on, which was all written in assembler.
I guess nobody in the manglement had actually looked at the source he was producing. The canned contractor hailed from Poland...and I'm sure you can imagine what I found when I opened his project files...
Not only had he written all of his comments in Polish, he'd also applied his mother tongue to all the variables, labels and function/subroutine names! Maybe today, google translate would have given me some way to use what he'd written so far, but with no other Poles on the staff and no other way to add some meaning to the source, the only option was to start again from scratch.
Maybe he was trying to bake some job security into the code, but instead, all he did was get himself added to the "never to be employed again" blacklist!
It is indeed surprisingly good for code commented in Chinese, as I also found out when I wanted to modify the firmware for a Chinese RF signal generator that I'd purchased.
The only disappointment was that instead of the translated comments adding any value, they were all comments of the type that explain what the line of code (which I can already read) does, not WHY it does it.
Many decades ago I worked on porting Swiss interbank gateway software to other UNIX variants, it was written by German speakers who did their best to comment in English, but there were a few spelling mistakes. So I submitted the corrections upstream with a polite note that about the correct English spelling, but they wouldn't accept the change, so each new version came back with the every one of the many dozen instances of error trapping code sectioned off with comments reading "########## DESASTER ##########"
I got lumbered with updating a Fortran software suite which had originally been written by a Portuguese placement student, more because I'd done more work with Fortran than anyone else rather than because I knew the field (although the updates required were functionally comparatively simple). He'd effectively written everything in Portuguese except the menu prompts and error messages, so you can imagine what it was like trying to make sense of all those variable and function names abbreviated to fit Fortran's six-character limit, even with sensible and consistent comments.
Fortunately there was a Portuguese-English dictionary in the library and with a bit of guesswork from what I could remember of schoolboy French and Latin, I got the job done in three weeks. Then as I was demonstrating the end results to the department who owned it, a lecturer popped up and corrected one of my translation explanations. She'd been away for the previous month buying a house in Portugal and teaching an evening class in computing at a local college, in preparation for a phased retirement in the sun. I think my expression gave away my feelings; I was lucky I was so stunned I couldn't even swear.
As I have posted elsewhere. A customer had - at some time in the past - an official naming system that reduced all Assembler code labels to "A1", "B1", "AA1", "AB1" , "AB2" etc. We had to make sure the one remaining program with this notation worked ok with a major system upgrade. Fortunately the existing
binary ran ok.
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.
If it was indeed a 11/780 and not some later vaxen then something isn't quite right. Around 1983/84 I was playing with a 11/782 (effectively two 780 processors working in master slave mode) and the memory maxed out at I think 12MB supporting around 100 concurrent users.
It's been the best part of thirty years since I was anywhere near a VAX so this may just be complete senility induced fantasy, but I have a recollection that 456Mb was the capacity of one of the larger DEC hard discs. Certainly no VAX11 could support that amount of physical RAM.
One of my PDP11s can run 4.2BSD off a 456Meg DEC RA81, perhaps that's the drive you remember? Mine says it was made in October of '82.
Interestingly, I also have a copy of the RA81's baby brother, the 124 meg RA80, which was released in January of '82 ... For many years, this was the single largest percentage leap in size between successive generations of HDD capacity on a given model/type of drive.
I think fraud legally would be if GBG profited from the forgery or if the company demonstrably lost by it. Evidently someone else got the job, and presumably that wasn't GBG himself... It's ditty work anyway, but maybe not unusual in business or not something that the company would fuss over.
"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!"
The same requirements to be able to hand-optimise code was present in the late 90s/early 00s too - my first embedded systems job saw me working on devices with 8KB of program memory and 512 bytes of SRAM, and I recall there being a week in 1999 where I did nothing but rewrite the existing code to claw back as much space as possible so that I could continue adding all the remaining functionality. I think my personal best for that week was finding 8 bytes in one day...
After that I worked on another device with 1KB of program memory and 32 bytes of register space (you'll note I don't say how much SRAM it had, because it didn't have any - the only volatile storage there was were those registers.). That was fun, especially trying to learn all of the limitations of the C compiler provided specifically for that device, and how to write code so that, say, you could perform a fairly simple calculation without the result being complete garbage due to the way the compiler failed spectacularly to translate said calculation into the correct sequence of opcodes and intermediate result saves. Had I been asked to work on that project from the start I'd have been writing the whole firmware in assembler and not even considered C, but as it was inherited from someone who'd not survived an earlier round of redundancies I was stuck polishing a turd.
On the subject of this article, the only time I've not been kept on to work through my notice period when made redundant was when the company I worked for announced on Friday morning that it was about to go into administration, leaving us with little more to do besides packing up our personal items before heading to the pub. At the other places I've worked, where people have been made redundant whilst the company itself remained active, the only people who got to go on gardening leave were manglement, and the occasional grunt-level if their notice period had been initiated by them wanting to leave. I've also seen people escorted out of the building if they were being dismissed vs made redundant, but that's a slightly different scenario...
Otherwise, if it was the company deciding our positions were now redundant, we'd still be expected to show up every day, with full access to all company resources, and work just like nothing had happened. For my first company I did this, perhaps partly because I didn't know any better, but also because I genuinely did like the place, the work and the people I'd been working with, and because they'd treated us all fairly during the redundancy process, which left me feeling like I had a personal obligation to leave behind the minimum amount of mess. With the second company, the nature of the redundancy process left a somewhat less pleasant taste in my mouth, so strangely enough I felt somewhat less obliged to do anything beyond the bare minimum re project handover, and ended up spending most of my months notice period just sat in the office taking advantage of the company software licences to brush up on my Delphi and Paintshop skills...
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.
"A series of frantic phone calls to the former contractors elicited precisely no co-operation at any level, or for any price."
Unless the contractors were already in contract elsewhere that's not very professional. The professional approach is "Don't get mad, get even. But payment upfront this time."
"Unless the contractors were already in contract elsewhere that's not very professional. The professional approach is "Don't get mad, get even. But payment upfront this time.""
If you leave the job on someone else's initiative, your new full-time job is to find another job. But personally, I would realize that even if it is cash upfront, the odds of contracting with a company like this being beneficial and lucrative are low. You already know that the company, in this case, won't honor T&Cs, so engaging with them for *any* reason is dangerous for you and could lead to more legal entanglements than you want to deal with -- they're already floundering and desperate, so why put yourself in their crosshairs voluntarily? They've just given you about the most trouble-free excuse to leave from what is obviously a bad situation with less than ethical folks. Seriously, in this situation you should see all sorts of red lights and klaxons going off, so smile, demure, and run like hell for the exit.
Don't wrestle with the pig -- you'll only get dirty and the pig will enjoy it.
If I had just signed a 2 year contract, and made plans based upon that assumed income, such as paying rent and bills for the next two years, and the company decided to terminate that contract, with no good cause, then not only would I blacklist that company, and tell everyone I know about what they had done, and publicly warn about them to others in the industry, but I would be talking to anyone else who had been put in the same boat about a class-action prosecution to recoup the remaining 23 months of pay.
The nature of freelancing is more complex than this although it's too often lost sight of, including by HMRC. Basically the engaging company is trying to balance a variable (holiday, sick leave, parental leave, training etc) staff availability against a variable workload. This can be done by recruiting more permanent staff that would be required to ensure the mismatched peaks and troughs are covered. However this also risks having under-employed staff from time to time and also risks the costs associated with making staff redundant. OTOH not having sufficient staff at the time of peak demand risks missed business opportunities. The role of contract businesses - emphasise businesses - is to ease that balancing by taking some of that risk themselves*. For a price, of course.
It's provision of services on the basis of T&Cs very different to those of employees which is the USP of a freelancer vs a permanent member of staff** for any given role. Although there may be a 24 month contract in place it will almost certainly make provision for early termination and this should be allowed for as a possibility. It's one of the things built into the rates as is time spent on the bench - the standard greeting of the agent is "Are you available?" and if the answer is "Yes" that availability is a cost to the freelancer.***
So no, don't assume two years means two years. Don't go round blacklisting companies. Don't prosecute them. You'll only damage your own professional reputation. If you're freelance it's part of the business you chose and whatever you do don't build financial expectations on it without a fall-back fund. And don't go freelance without understanding this. If they've made a mistake getting rid of their skills base regard it as an enhanced business opportunity.
* This, in my view, is what makes them businesses and what HMRC & IR35 overlook. They are taking on business risks, they're businesses and should be taxed as businesses even if they only have one principal.
** This is no excuse for trying to run a business with free-lance staff only. A business needs employees to provide continuity.
*** These are two of several factors the permie might fail to take into account when looking at freelance rates. The freelancer should not so fail.
You can't count on a guaranteed job in any case, but in the situation described, it seems that the terms in the contract for termination weren't even followed. If you have contracted long enough that they give you a two-year contract, there's likely some restriction on how a termination might go (E.G. how long you get a notice or any early termination payments). Most long-term contracts don't allow the employer to terminate at will. Unless the person describing this situation was lying or failing to understand the contracts, the company did fail to meet those obligations.
In that specific case, you can see why someone wouldn't want to go back and would blacklist the company. If they don't follow the terms related to termination, it's easy for them to fail to follow other terms as well, such as the requirement to pay the contractor. Their violation of the contract is already a legal issue, but even if it doesn't seem worth it to bring a case, that's not a good sign for future connections. Therefore, in a case like this, I don't agree that people treated in this way should refrain from blacklisting or even suing those companies.
On one point, we absolutely agree though: "whatever you do don't build financial expectations on it without a fall-back fund". This is important for everyone, not just contractors. Even employees who have more employment rights can end up in a situation where they get fired at short notice without any more payments, and it's a situation where savings may be needed to cushion the consequences. Contractors are more likely to have that happen, but anyone can. After the economic chaos caused by the pandemic, I think a lot of people have learned this. Unfortunately, many learned firsthand by having it happen to them.
Exactly this. Presumably the termination clause was negotiated, and if there was an early termination fee or some other penalty there it is because the contractor wanted it enough to give up a higher hourly rate or something else of value. A counterparty that makes a habit of failing to honour its contracts should be penalised by the other contractors in the market: not necessarily out of some moral principle but because the only thing those contractors can be assured of getting out of their contracts is whatever cash they already have in hand. That makes it more expensive for the counterparty to do business, as it should.
If the corollary is to always demand only the highest hourly rate and never negotiate for anything else, that isn't necessarily wrong but it does preclude a contractor from getting what he or she might really consider the ideal compensation, even if the counterparty is willing to honour the terms and has a track record of doing so. Distrust costs everyone money, which is why we have civil enforcement of contracts to begin with. Unfortunately in most "developed" countries, that enforcement has become so expensive and time-consuming as to be of little value to anyone, which means it's a rational contractor who demands maximum cash in advance and manages everything else without benefit of any other contract terms. The disconnect with IR35 is that the government still acts as if it's providing useful civil enforcement but really isn't. As Doctor Syntax has correctly pointed out, who is taking the risks makes all the difference. It's supposed to be both parties according to the negotiated terms; in reality it's always the contractor.
It still doesn't give a good reason to blacklist the company. If the client has breached terms of the contract with regards to notice or payment then that's generally an easy one to take them to court over.
If they haven't breached the terms then what's the problem. As has been implied elsewhere a contract is only as good as the notice period
It's unfortunate that this is not as rare as it should be...
I used to work for a firm in Southern England, (as a Permy, but had recently handed in my resignation although not for reasons related to the following story, but due to deciding to move to another country). The firm was a big multi-branch behemoth and we were the engineering section of the firm, which also had very large manufacturing divisions. We, the Engineers, all worked in a big open plan office, probably 500 people all in all, with probably 2/3 of those contractors of one type or another.
Suddenly in a November, we got a new Boss for our section, who had come from one of the Manufacturing Divisions of the firm. Considering that he was well known for considering Engineers as being an expensive and useless overhead, I can only imagine he wasn't too pleased to be taking over the Engineering Department. Still after implementing a few stupid internal rules (no use of headphones in an open plan office of 500 people, no more than 3 people at the coffee machine at the same time, etc.), he waited for Christmas to really go to town. On the last day of the year every contractor received a pink slip telling them they were out of a job and not to come back in the new year.
I had 2 weeks left of work in the new year, and walking into that office and finding it almost insanely empty was awful. The managers who had fought tooth and nail against having the contractors kicked, had basically given up, and sh&t really hit the fan over the following weeks. I'm glad I got out when I did.
In the end about half of the Contractors got rehired, now at twice their previous salary, so the company didnt actually save any money, all of their customers got super annoyed as everything was delivered late and at a much reduced quality, and the company almost folded (ended up getting bought out or propped up if I remember correctly). All of the good managers left, and the total firm is now about a quarter of the size it was when I was there. I have no idea what happened to that idiot boss though, I sincerely hope he got kicked out on his a$$, but he probably got promoted until he got a golden parachute.
Still just goes to show, promoting someone to manage something that they hate, is more than a little stupid...
I worked alongside a contractor. Nice bloke, knew his stuff, but the company decided they could do without him. They told him he'd be going, and a month later they said 'right, that's it mate, thanks but it's time to go'.
He looked at them blankly and told them they'd not informed him in writing, as per his contract. So they had to pay him for another month ... at £60/hour. In 1989.
Like many of the posters here, I was on the opposite side, being the new programmer. The old programmer hadn't really been terminated, but rather had a nervous breakdown and didn't show up for works for over an month. Finally to get some severance money, the bosses forced him to come a few days into the office to help transition.
He just sat on a chair and the only non monosyllabic answer he gave was "I don't know". Sigh.
Hashaha, thats me right now. While I was gone on a long sick-leave the big-brains decided to re-re-re-re-organise the never-working PLM system. In My Opnion, simply to carpet over another structural failure.
Everything that I worked with, stuff that is now needed for licensing & compliance, has become hidden somewhere, and, one of the many documented failures with this piece of rotten garbage PLM system is that "document search" never quite worked. The moronic option of Slapping everything into folders on a shared disk would have worked better, at least those are searchable!!
It sounds like they want to redo everything to fix "the issue", they first wanted me to do it, but, I quit :)
I'm sure my productivity went through the roof in the 3 months before I resigned. I wanted to leave my ex-colleagues in the best possible position to survive without me... Going on 6 months since I gave notice, still nobody sitting in my old chair ;-{ I'm still getting a question now and again, and am happy to give advice! I miss that office!
"The code also had to be as small as possible so many tricks were used to reduce bloat, something maybe we have lost nowadays."
Maybe?
Not maybe ...
Difinitely lost.
Not only that, far too many times full of incorrectly commented code.
And not only incorrectly commented code: how much unfixed code has been piling up for years ie: won't fix code because it produced a harmless warning, did not affect enough people or because the kernel version was soon to be EOL'd?
As I have commented before: "... it's just dirt/grime being piled up and festering in some dark corner ...", much of it originated in the sloppy coding practises Torvalds bitched about last year.
https://www.theregister.com/2021/06/26/linux_kernel_contributor_from_huawei/
Healthy code = lean code with no warnings.
There's no two ways about it.
O.
I agree, but in the real world there's never any time to do what we might see as essential maintenance but the boss doesn't because no-one above him is kicking his door down about it. To him it's far more important that we spend our time modifying everything to use the new corporate colours...
Hmmm.
Microsoft still haven't fixed a stupid but that means when you use a custom recycle bin icon it doesn't automatically change on deleting/emptying. You have to manually edit teh registry to put a ,0 at the end of the icon path*
*The Windows registry seems like a very strange place to me. There are so many entries that take extra bits like that, that don't seem to serve any purpose, but I'm guessing are left over from some planned functionality that was never implemented.
*The Windows registry seems like a very strange place to me. There are so many entries that take extra bits ...
Seems?
Strange place?
You may want to look again, deeper down and then re-evaluate your understanding of the term strange.
The MS-Windows Registry is nothing but a developer sanctioned virus running inside the OS, constantly changing and going deeper and deeper into the host with every iteration and as a result, progressively putting an end to the possibility of knowing/controlling what is going on inside your box as it becomes more and more obscure.
And yes, it may also be sloppy coding but first and foremost it is a virus.
O.
The windows registry was an in-departmental utility(?) that was not supposed to see the light of day, but some how got out of the bottle, all departments used it, and we are stuck with it... I can't find the interview now, perhaps it was here on El Reg, but the search function here is as useful as an one legged man in an ass kicking contest, sorry El Reg, but it's true... ya got some work to do there... or you got some work due there... do I sound like a teacher?
Voice from another age here. We knew that any code was difficult to follow if it became lengthy, So we spent ages writing with things called pens on a thing called paper to design and document smaller and smaller modules until they were nugget size. Some rooms were walled with whiteboard and had assembler/machine code in screeds and cartouche flow-chart snippets.
In-line documentation is like having architectural plans in each room on a room by room basis. "This room is a meeting room for up to six people with a projector." and so on. I'm worried that the lack of skills in top-down design, lack of understanding the whole and undercurrents and lack of practice of creating a whole (sub)system picture has an even worse impact when people become unfamiliar with reading specifications and rush off to play with toys.
PS We need a grey-beard icon.
Well, today those walls are replaced by at least one 43" 3840x2160 monitor with OS-zoom level set to 100% to make actual use of those extra pixels available. Maybe some have more than one of this type.
This gives you so much actual working space that you don't need to plaster the walls any more, which was needed when you coded with 80x24 (or less) characters on screen. Or on punch...
Mind you... I was leaving voluntarily in the midst of a big departmental reorganisation. Hence it was exceeding difficult to work out *who* I should be handing stuff over too. So I spent my notice period diligently documenting everything I could think of in as much detail as I could and making sure it was all stored in the appropriate database (which my colleagues perhaps didn't use as much as they might have).
A couple of months later I received a query from an outsourcer who was looking for a contractor with a skill set uncannily like my own. It didn't take long to establish that, yes, they had been given the role of picking up where I left off. Conversation on the role and requirements soon established that not only had they not been pointed at my documentation, they had no idea such a body of documentation existed at all. I told them where to find it. After all one has professional pride.
It was probably as well I told them where to find the documentation, because my former employer vetoed my return as a contractor. This was the first of a number of clues that the frustrating working environment that had motivated my departure was most probably because I was coming last in a game of internal politics I had no idea I was playing!
It was probably as well I told them where to find the documentation ...
You should have sold it to them for a nice, round albeit affordable sum.
After all it was not their fault and it would have eventually be paid for by your ex-employer.
Happens that "professional life" is absolutely full of assholes, a great many actually proud of being assholes.
Now, if one of them could not be bothered to do their job right ...
Why should you bail them out free of charge?
O.
I think the suggestion was to sell only the information needed to find it. A directory path that, on the company's own systems, leads to what they could have found wouldn't be proprietary because it wouldn't work anywhere else.
That said, I wouldn't recommend doing it. From the sound of it, by that point they thought there was a chance of getting paid to work on the code again, and haggling over existing work wouldn't be likely to earn their approval. Even without that, I wouldn't pay someone for telling me where to find their docs when I could just search more to find them.
I was think more along the lines of just acting as a consultant to the outsourcers
The company doesn't see JimC on site (assuming the outsourcing is done on-site) nor as a name on any roster list. If anything they just see the name of JimC's consulting company - which shouldn't look anything like JimC - as providing consulting services to the outsourcers but it shouldn't really be any of their business. The costs just go on the bill with the outsourcer's mark-up and everybody's happy.
I think in practice if a contractor were found to be having any kind of working relationship with someone the client had specifically vetoed then things would be exceedingly difficult. Hard to believe it would be worth the risk. After all to be irreplaceable is very unprofessional.
I was working for a company in the dot-com bubble era - the company was growing slowly but steadily in the previous years, they went for a IPO, got the money and spent them in a new HQ building and buying another company to replace their AS/400 ERP with a Windows one (getting a truly bad product, as we warned and they discovered after not listening to us). So they hired an ex-IBM executive to fire the most expensive developers to cut expenses. When it was my turn - and I had to know indirectly because they mismanaged it so badly I had to ask if the voices about my layoff were true - they give me three months to finish my current tasks and probably hand off the projects - so they hoped.
Just they had "forgotten" to renew my contract - basically I was working on a "gentlemen agreement" since my previous boss left months before and HR never approved my new contract which I discussed with the old boss and was never approved by the new one - it had an early termination fee. So I just told them "alright, goodbye" on the spot. Turned off my PC and exited the building. Soon some customer called me to consult on those applications - one even bought the source code of one to let me keep on working on it.
With IT development decapitated, IPO money burned into silly acquisitions, they went bankrupt two years after, and shares became toilet paper.
A long, long time ago, I worked for a big computer company. It decided to close a factory in Belgium. Production shifted to France and software development/support got moved to New Hampshire. The USians were very unhappy when they loaded the tapes from the Belgian factory. All of the software - OS, libraries, compiler, utilities - was written in assembler. Which was to be expected because that's how things were done back then. But all of the source code was commented in Flemish (Dutch).
One a contractor was treated like shit when they asked him to leave for petty reasons but he needed the money so asked if he could finish the day. They said yes, which they shouldn't of, but all he did was take stuff they'd probably never notice was missing. Their own fault for letting him back to his desk.
Another was from Kevin Mitnick's book. Apparently an arrogant network engineer was fired in front of quite a few people in a meeting by the CEO. Not many people liked him so, if I remember right, they weren't sorry to see him go. However the management allowed him, after firing him in front of people, back to his desk to see out the day.
That evening, after he was long gone and his building access disabled and account locked, all the main servers rebooted and wiped themselves. They pretty much knew it was him but had no evidence to prove it as the timed script had been wiped with the servers.
A customer wanted his legacy programs carried forward to a new OS on a fairly compatible new mainframe. One program had us scratching our heads. At some point a manager had mandated a "tidy" assembler code labelling system. A top module's jump labels were "A1", "A2", etc - then the next module was "B1" etc Within a module the next layer labels went "AA1", "AB1". Not a single label had any human meaning. Can't remember if the variables followed the same convention - probably they did. Fortunately the program didn't need recompiling or modification - the existing binary ran ok.
Its taken me years to beat the finer points of having meaningful labels in the code to the rest of our programmers
Call "101";
means bugger all
Call "Rotate_B_Axis_to+42"; rotate table to next position and set new datum
can be read by all and understood (and changed if need be.. cursed customers changing spec 1/2 way through a job)
Only ever had to be escorted off site once.... handed notice in and was going to work the 2 weeks until manglement told me that the monthly earned bonus that was paid up in full in December only applied to people employed in december.. if you left earlier in the year you lost the lot.
Needless to say I was quite annoyed.
So the deputy mangler sent me home on gardening leave, was'nt alllowed to access the computers while clearing out my desk....... oh well... it was a better paid job I went to and made the lost bonus in a month
An organization that features "unachievable deadlines set by managers that lacked a proper grasp on the challenges involved" is a toxic waste site, and should be shunned by anyone with a gram of self-respect, until said organization either gains a clue or collapses from the accumulated incompetence.
Your skills, your time, your self-worth, are too valuable for you to collude in your employer's abuse of you. Run, do not walk, to find a job with a better employer. (If you really need the money that badly, set a limit on how long you'll tolerate those conditions, and stick to it.)
There have been two times where I took revenge on a company for mistreating me, though I chose to go a more ethically sound way.
In the first example, it was my first serious job out of college working for a contracting company. Not only was my pay routinely late, but come tax time I found out my employer had been pocketing the tax withholdings from my pay. Being young and stupid I let them give me a tax form for a contractor, and basically ended up paying taxes twice on the promise that they would reimburse me for the money that should have been paid to the tax man. They never did, so I reported the accountant for the company to said tax man. No idea what ever became of that, but knowingly giving employees falsified tax documents is likely not the sort of thing that would be looked kindly upon.
In another example, I got back at the same company more than once. I was doing hardware repairs for a now defunct retailer, and due to a combination of laziness and incompetence on the part of the company execs I was the one who ended up dealing with the OEM most of the time and had a pretty good understanding of the terms of their contract. So, when the company decided they were going to try to violate that contract I tipped off the OEM who was very nonplussed. Amusingly, they had a previously arranged "friendly" visit to the OEM's campus to be given a tour, and instead they were all ushered into a conference room and confronted about their plans to violate the terms of the contract. Then, later, when the company decided to fire me after my supervisor started taking out his romantic frustrations with his fiancé on me, I tipped off the OEM to a lot of other things I knew about. Strangely enough, not long after that, every time I was in one of the stores for this retailer, they never seemed to get new products for the OEM. I was working at a special "store" that only did hardware repairs for all the other stores, and I bumped into one of my former coworkers who told me that they had closed down that store and made everyone there go work in one of the customer-facing stores. Things went downhill pretty quickly after that for the retailer. I don't presume to think I was directly responsible for the business ultimately going under, but I do like to think I played a not-insignificant part in that downfall.
Over the years, I've know many who've been let go. The company never limited anything and even encouraged the employee to continue using the company premises to look for a new job (as well as a job search workshop). Taking out some impulsive revenge would just follow this person around the industry. And everything is backed up anyway.
Perhaps the comments were good but cunningly displaced from where they should be.
Or perhaps Dick had s peculiar comment style that he thought was normal.
For instance, say what a line of assembler does... a space and a line below the actual code. That would confuse me.
a bit different to this one.
I gave my notice, and was promptly trained on some new software systems during that final two weeks.
My new employer reaped the benefits of that training, as it was a large part of what I was being brought in to learn and do.
A bit odd, that.
First, they didn't fire me, I quit. Second, I was hacked off with them because I'd been treated as a dogsbody, passed over for promotions, always got the smallest pay rise and eventually, after a long talk with another guy in the department, who told me - as I suspected - the big cheese of the entire site had it in for me, Idecided to go elsewhere. I landed a prime job with much better pay and prospects, and back to my preferred career as a CG artist. They wanted me to start ASAP but understood I had to give notice.
It was when I was drafting my notice that I remembered I'd not taken much of my leave; I'd recently divorced so I didn't want to spend time moping about on my own, so I had 16 days left. After a bit of checking and double checking, I confirmed I could use these days as part of my notice, so I'd only actually be working at my old place for 4 days.
The department head wasn't too pleased. "I don't think you can do this", he said. "I don't think you can stop me", I replied. He then scurried off for a talk with the HR bods, who confirmed I was in the right and they were up the proverbial creek without the legendary paddle. He then offered to buy back some of my leave entitlement, so I could at least get a new bod started on the right path. I told him there wasn't a truck big enough for the money I'd want in return. "Not very team spirited", was one of the things said to me about it. "Well, you buggers didn't do me any favours these past few years, so why should I do anything in return?"
Not saying the name of the firm, but they had a 3 letter name with an A at the start, an N at the end and an O in the middle.
Took a week of my leave enjoying the sunny weather with my new GF, then started at my new job and never regretted a moment.
Oh my god this happened to me EXACTLY and they were so mean, not even people who found new jobs instead of waiting to be redundant had a leaving party. There were managers retiring with like, 40 years service, a whole career in IT and nothing just today is my last day on their last day. It was like the soul was ripped from loyal people as they were harvested then discarded as husks after serving their purpose.
I must admit to using extensive comments, especially in Javacscript (... in Javascript, I specifically have like "} // End catch" or "} // End if(x>y)" or the like at the end of some larger sections of code, since the design of Javascript seems to encourage like "foo{ ..{..{..{..}..}..}", and it's a PITA to track how far down the nested {}s you are.) I strongly prefer Python, one of the many reasons being how a block of code has to be indented the same amount, so you can see in an instant where an if, else, catch, etc. block ends.
Occasionally a comment's really not necessary but as much as one can say good code is self-documenting, I also do like having enough comments to be able to know at some high level at least what a piece of code is doing just by looking at the comments near it. Both for me having to work on code much later, and if it's handed off to another programmer.
Man, that's a nasty trick changing out all the comments in some assembly code! Just for those who don't know, to even print (in this case) 15 characters of of text onto screen you end up with something like (they use pnemonics like LDA, JNE, etc. but in plain text):
load address a into register 1
load address b into register 2
load from address at register a into register c
write what is in register c to address pointed to by b
increment a
increment b
subtract 15 from a, put result in c
jump if not zero (register c, and the address the "load address a into register 1" is at) -- to jump to top of code if c is not zero.)
With a pointing to a block of text and b to screen memory (for a screen in text mode), just to print 15 characters onto a screen!
You were unlikely to have multiply and divide instructions, and you'd need some extra code to add or subtract if you expected values larger than what a single word would hold of course. This may have been in a library, or just inline in the code if you weren't going to use it much -- and without comments who knows which is the case.
So yeah without comments you would be royally screwed.
I must say, if I were being laid off, I would NOT go through and sabotage the comments or code. But, I could definitely see doing the bare minimum, taking any saved up leave, and not worrying about if the transfer goes smoothly or not, if the management were dicks about it. If the management was nice about it, I'd probably be nice and professional about it and try to ensure a smooth transfer.
Got laid off once (2009), was one of the 'lucky few'* (including our then manager) that had been selected to be 'at risk'. (we're sure they selected those they needed most to go since those were the ones to go). During the next 3 weeks before we were given the final decision that we were going I think I vaguely turned up for about 2/3 of the time, almost no work getting done and our manager (again, one of those slated to go) couldn't have cared less.
* this statement means more than it first seems - see below
On the date we were destined to go it had alresdy been decided that once we were officially redundant all we needed to do was hand in our official laptop + charger + mobile (POS really) + it's charger and we were free.
What didn't go so well was the fact that one of the people slated to go (who had worked out how much he was going to get and had mapped out 2 years of travelling etc) was then told he wasn't going and that he needed to get back to work asap. I ended up about 3 months later getting the contract to go back there to work on a rollout (they hadn't shitted on me really so I went). Strangely enough I met up with about 5 or 6 others who'd been let go who were also contracting for the rollout.
I did spend some time at the branch that the guy that hadn't been allowed to leave was still stationned at - the other rollout contractors moaned that the onsite guy was very un-cooperative, when I saw who it was I quietly enlightened them as to a small bit of recent history and none of them complained any more. In another twist, one of the guys at another branch that'[d been allwed to leave was back 3 days a week on more money than he was before working full time, basically doing the same job he'd been doing before he left.
Rollout finished (and this time I was very glad to go, the project managers for the rollout were total assholes, and we managed to get through about a dozen of them before the rollout was complete). I was the last of the original batch that had been let go that were still there, some had left, others had been shown the door (to be fair those shown the door had mostly deserved it because of their attitude).
Roll forward to my next but one contract that was a local(ish) ISP that had been bought out by a multi-national software giant and they needed 'Corporatising' (as well as removing the old redundant IT kit from the estate). Strangely enough I found the guy heading up my batch of contractors was none other than the guy I'd been working for (he was the co-ordinator, not the boss) when I was full-time at the previous place. Didn't need to interview - he saw my name and said Yes without needing to think too hard about it (nice when this happens).
Turns out that they'd shat on him as well and the place had gone to the dogs after we all left - he was good at 'mitigating' SLA breaches so they invoked an almost never before used clause burried deep in the small print to dump him (the 'We don't like you so you're gone' clause). I also met a number of other former colleagues at that contract (not necessarily in the IT area either) who'd jumped ship when the writing on the wall started to reveal itself.
Of course, someone, someone with a white beard, might actually have commented assembler back in the '60s, but by the time the '70s came around the code would have changed so much that the comments would make no sense whatsoever.
/* Add one to the index into heaven. */
*--hell;
It's a wise manager who immediately calls security on any terminated employee to show them the door, and it's not just software.
A manager I knew at a car dealership, which closed, locked out all of it's mechanics for fear that one of them would take their revenge on a customer car, or nick some of the more expensive garage tools.
The mechanics arrived one Friday to discover all the doors locked, and they were allowed in one at a time (under escort) to retrieve their tool lockers and overalls. Everyone got their stuff, and all the money that was due to them, but nobody got the chance for "revenge".
The manager kind of regretted having to do all that. He knew most of the mechanics were good guys, but it would only take one to cause immense reputational and potentially legal damage.
A phone system that kept its user database passwords in plain text so you could just use Chrome to change the "password" field to "text" and it would reveal that persons password. That person, 99% of the time used the same password for the phone system as their Windows login.
Reported this but as they do, was ignored "Its not an issue. Only admins have access". I pointed out some admins go rogue. Made no difference, I was still ignored.
Said phone system allowed you, with a simple button, to export the whole user database with their passwords. I may have done this before I left. Because the login page for this phone system was open to the world and its dog (for ease of use) you could, from any hotel room, cafe, holiday home etc access it. So I may or may not have accessed it after I was long gone and after my account was locked. I may or may not have then logged into said phone system with the accounts contained in the exported user list. I may or may not have known a person who had admin access once logged in to said phone system who was an idiot and rude. So I may or may not have used their account to snoop around. Just to prove a point I then changed the Chief Execs numbers to redirect to somewhere else using that persons admin account. I never saved these changes so no harm was done & the phone and numbers were never actually redirected.
I connected via a VPN, then in a VM and in that VM it was connected to the VPN again but from yet another country all on WIFI that was not my own. I may or may not have done this over a few weeks, sometimes waiting a few months to see if anyone was bothering to look at logs and wonder why this admin was logging in from these foreign countries & hopefully change their password which was as bad as "Wednesday10". I never caused any harm, never deleted any data or redirected any phones. I was so tempted to but didn't. Eventually that login stopped working, I knew someone still there who said they wiped the server and started a fresh because they thought all their problems might be fixed by building a new server (the hosting company). Their problems WERE NOT caused by my logins, I can assure you of that. The phone problems were always an issue while I was still employed and continued on the new server that I had no access to.
I just wonder, to this day if the real reason for building a new server was because they'd spotted that admin logging in from foreign countries and assumed they'd be compromised. But I very much doubt it.
A couple of years past and they finally lost the contract due to the same on going phone issues. The new provider? Same system, same on going phone issues.
I'm back in New Zealand now anyway, so far far away from them every grabbing me for my minor, pointless and harmless breach that I warned them could happen one day with that shitty phone system.
So, we were shedding staff left right and center and I was planning on retiring early so I put up my hand and Nope!
I tried really hard, I had had a few months of no real work. I was a technical trainer but no courses. I spent time learning all the new stuff that the move from copper TDM telco to VoIP was bringing, well you never know.
In the end I managed to get 5 months more with only 1 days training delivery plus they sent me to Munich to learn the new products ?????. Sweet, paid holiday and a chance to say Hi! and Bye! to all my old German friends.
Such Fun!
No redundancy but no work, happy bunny.
The only "last day sabotage" I ever did was to type up a Word document containing nothing but mis-spelled words on my boss's laptop while he was out at lunch, and added the lot to his dictionary.
That was pretty mild, really; considering the "19-day week" I had to work to finish a job which subsequently sat untouched on a desk for the best part of a fortnight, and the nightly decision whether to catch the bus home and stay dry, walk home and have the fire lit for an hour or walk home and have something to eat.
I remember years ago, a big bank clearing firm got a Chinese contractor in to do some deep code in assembler for early ATM machines. The firm then proceeded to dick over the contractor in terms of payment.
When he left the code all worked beautifully and, as per the contract, was fully commented.
Only trouble was the comments were in an obscure Chinese dialect the required programmers to spend an awful lot of time at a certain greengrocers getting them to translate the comments.
I designed a machine control system and it operated most of the machines in the company. A certain other person thought he could do it and I had saved over £3000 on one machine in 1977. I was told to do the same on other machines. However, due to a market change they made me redundant so I put a Christmas day stop in all the machines programmes. I left in the May. I happened to see one of the lorry drivers in the town I had moved to and he told me that when they came back from the Christmas break in January, not one of the machines would run on the computer. They then spent days removing the kit on all the machines and had to run them manually. This caused many die breaks and the costs would have paid my salary for another 5 years. I had a lovely laugh. The company went broke and was bought out before that!
Back in the days (1970) when code was on punched cards and the language of choice FORTRAN.
My predecessor change all variable names to x, xx, xxx. You get the drift.
The code still worked so could not be accused of sabotage.
I privately admired his guts for avenging a perceived wrong.
Was working for a sizeable international financial company (in the UK) had been there for 9.5 years, 7.5 as an IBM i RPGLE dev on a big legacy application. Only 2 of us, so we had a lot of unique and barely documented knowledge.
Both of us made redundant with 6 months notice along with most other UK based IT when the company decided to move as much IT as possible out of the UK and into India, Poland, and Hong Kong. Not outsourced, just overseas in the same company.
Then insult to injury, had to train our replacements. And document as much as we could. I think I myself wrote about 700 pages of pure knowledge dump. So much I bet they couldn't find anything (can't see the forest for the trees and all)
But we did it properly. No bombs left behind, everything as proper as we could manage in the time.
I do feel bad for the replacement people, having to pick up after such a short handover for such a complex system (parts of which were 30 years old at that time)
And the final insult before leaving, was getting my 10 years service gift and presentation on my very last day with the company. My boss was very apologetic, telling me about it by saying "I'm not sure if this is actually a joke but..." and telling me how the presentation script he was supposed to read said to say "here's to another 10 years"
And then there was the delayed action insult - my redundancy package never arrived because the person handing it missed that I was on an unusual type of contract and didn't file the right paperwork, and no-one flagged that it hadn't been done. Had to flag it myself once it was late and go back in to go through the paperwork, but I did get it eventually 2 months late.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
