Comment in code read 'Dear future me, sorry I wrote this' WHO, ME? Regrets? We've had a few. And so have many readers of The Register, who we try to help by getting their stories of workplace mistakes off their chests every Friday in a reader-contributed column we call "Who, Me?" This week, meet a reader who asked to be Regomized as "Johnny," who told us he was once hired as a Visual …
During uni, me and my coding partner were having a similar issue. We traced the problem to a specific line of code.
In desperation we erased the line and re-typed it from the book, and the error magically disapeared.
Our only explananation, to this day is that some non-visible character logdged itself somewhere, somehow, the firts time we wrote the line.
In my first job after university, a hateful one writing RPG/2 in a batch environment (after using PL/1, APL and C at university) I had a problem with the behaviour of some code that I just cold not tie down.
Although I can't remember what the code did, or exactly what the symptoms was, I was embarrassed to have it pointed out (by the most prudish of old-school data analysts who regarded any other languages than RPG and COBOL as being abominations) that I had a letter O rather than a numeral 0 in one of the character field tests. I blame the poor font and a fabric ink ribbon that needed changing on the band printer that printed out the diagnostics for the lack of visibility of the problem.
Did not stick that job for more than a year.
Not just travel typewriters, my dad brought home an ancient 1950s Remington from the office, when they upgraded to those new fangled electric golfball typewriters, it cast iron and weighed a ton, so definitely wasn't a travel model. That lacked both a 1 and a zero, 'l' and 'O' were considered close enough. That didn't matter for me as a child learning to bash the very heavy keys against a warn out ribbon.
I was very annoyed a few years later when home computer magazine started printing listings, and not all of them thought to use a font where 1 and l, 0 and O where indistinguishable.
This post has been deleted by its author
I cannot believe that in 2026 we are still suffering (almost) the same problem. Today I tried to create an account and password for an ISP that shall remain nameless. Their form let me paste the generated password from bitwarden for the first copy, but flat out refused to let me paste it into the second copy. I had to manually retype the 16char random string into the second field, but it kept failing validation. Turns out one password had a lower case L and the other had a capital I and in the font they'd chosen they both look like a simple vertical line. Aaah!
So is it just my PC, or does Windows 11 think it's helping by converting tabs into characters when I paste them into a terminal window?
Just tried it again. I pulled up my working .bat file in Notepad and copied a line with tabs. When I put it in a terminal window it added ".cache" and ".eclipse" (without the quotes) to the line where two of the tab's were.
It made updating these .bats bit of a pain before I noticed what was happening.
Happened twice in C++, just printing something before fixed a "bug" and a couple of times in Vb.net: software was inherited, pretty big classes everywhere, so since the bug was there but no way to understand what the problem was I just took a couple of chunky functions and moved them at the beginning of the file. Bug gone.
Had one of those once a while ago. Launching a published application via a batch file on Tarantella. App mostly worked, but the help system didn't. Worked fine if launched from a desktop session, but not as a published application.
Added some error tracing to the batch file to echo various bits of the application state during launch and the error went away. After removing all the tracing, it came back.
I can only conclude that echoing something made a subtle change to the environment that made the help system work. Couldn't track it down, so eventually just echoed a single character during launch along with a comment that although this looked stupid, please don't delete it.
Many years ago, a coworker had an intermittent bug.
A signal handler had been set up but would not reliably fire.
The reason is that his code was expecting the signal before the OS (Linux1.x as I recall) had properly registered it.
The fix was to add fflush() immediately after the signal init code which yields the time slot to the kernel which can then do the necessary steps to actually set up the handler.
When I was teaching C++ a student came to me because his code wasn't working and the lab assistant couldn't find the bug. Turns out the student had written:
if(char == '\\' then { //check for \
etc.
Well the \ at the end of the line deleted the following newline making the next line a comment. This caused errors on the second following line causing confusion.
When I was a student, back in the middle to late 1960s, I had an assignment in a (Dijkstra forgive me) FORTRAN class where a FORMAT statement would not compile for some reason.
Now this was back in the days of keypunches and tab cards (no fancy screen editors), where programming involved writing the code out on a coding sheet1, trotting down to the keypunch room, and transcribing the written text onto cards (and, in my case, producing vast number of mispunched cards since there was no way to correct a typo other than starting over again).
I looked at the card and could see no error -- one of the first things I looked for was typing F0RMAT -- I even read the Hollerith code to make sure (one of those now useless skills I picked up on the punchcard era2) -- but no dice.
I had others, including the professor, look at both the card and the printout to no avail.
I finally repunched the card -- using the duplicate function of the keypunch -- resubmitted the deck and the thing ran perfectly.
It was a trick to which I had to resort on a couple of occasions early on in my mainframe days.
The ways of IBM big iron were sometimes mysterious.
_______________
1 To some extent, I miss those days, since you really had to think about what you were coding in detail and I suspect it made me a better programmer as a result. I quickly learned to leave a few blank lines between statement on the coding sheet so I could insert things I'd forgottenrather than having to rewrite the whole darned page.
2 I also used to be able to read five level Baudot and eight level ASCII paper tape from my days at a COMSAT earth station but that's a tale for another time.
At uni I was doing a course on basic programming, so I'd had to write a small program in C. It was mostly working, when I modified a comment, after which, the program *never* worked again. Obviously I tried removing the comment, and re-writing that line, but nothing ever seemed to work.
I just faked the results I was expecting to see, and printed it all out. I guess the professor never bothered testing the program, so I got good marks for the module.
Never tried programming in C since.
I had something the other way round. Someone had been given the task of making a database dump available and had done so - the problem was that it hadn't occurred to him to make it usable!
I wrote some frankenmonster code to parse this monstrosity data into a format that a data scientist could use that took hours and hours to run on HPC. I dreaded the next team meeting as what I'd written was so horrid. My colleague just looked at the problem I'd solved and just said "I'm sorry you had to write this".
Eventually, the team behind the data started providing sane dumps and my work of the devil is still living in Bitbucket somewhere...
I know your pain,
Wrote a beautiful hierarchical data structure that parsed beautifully for sane statistical tools (like R)... And the client said... "Can you output that as a flat CSV file"?
Sure was a pain getting the repeated measures to come out sanely...
They eventually did migrate from SPSS to R, much to my joy.
Had the great misfortune of having to document some legacy C++ code as part of a compliance procedure. The background was that a 'domain expert' ie not dev, in the company had managed to get hold of Borland C++ Builder and managed to spin his code into a £14M+ business line. The code itself was not difficult, just *long* eg one function 2000+ lines long. The best part was some hard coded, PII (Personally Identifiable Information); the sort of stuff beloved my identity thieves. It included: name, address, dates at said address, and salary details. I pointed out that you couldn't simply delete this info as it was permanently in the git history. Not sure if they ever passed their compliance audit.
I once had to code something in MicroSoft Visual C++ for Windows. Now, I did have some knowledge of objective C, but not of any of the then 'newfangled' Object-Oriented stuff, or programming for Windows. In addition, I was not then and never have been a trained 'proper' computer programmer. Well it was not a happy time for me, but I eventually got the things sort of working. Fortunately there were no actual customers as such to support or I would have been in trouble. I well remember being on hold to the MicroSoft 'Help'* line for ages, and after describing what I was trying to code being told that Visual Basic would have been a better choice of language.
'Why use C++?' I hear your cry. Well, one of my colleagues wanted to steal, sorry borrow the installation discs so that he could have it at home for free (those were the days when that sort of thing happened a lot, although I didn't).
You win some, you lose some, and still the World turns.
* Technically they were MS Help, but they were of no actual help to me at the time.
> eg one function 2000+ lines long.
First paid job, worked with C code. The UI stuff was ok, but The Function that processed ALL the data (running up and down graphs percolating values - and no, it wasn't an LLM) was one looong monster.
Eventually resorted to formatting it so that braces were vertically aligned and each block indented in one from there, do I could print it out (thank Ghod for fanfold, so it was all one continuous sheet), laid it out one evening across all the desks in the office and used a metre rule (multiple times per brace pair) with a packet of coloured felt tips: green* blocks aggregate, red blocks store back, blue blocks build backtrace etc etc.
This left a lasting impression and to this day, braces are vertically aligned, blick contents one space (not tab!) indented and I use "mark column" along with "find matching brace" all the time...
* recall of colours used unlikely to be accurate!
We are both having bad speeling days:
>> This left a lasting impression and to this day, braces are vertically aligned, blick contents one space (not tab!) indented and I use "mark column" along with "find matching brace" all the time...
Yes, "blick" should be "block".
OTOH
> but one space intended and block content don't mix in my brain
One space *indented*, not "intended"!
So if the opening brace happens to be at line 8, column 11, it will be the only thing on that line (except perhaps a comment). The contents of that block, within the braces, are indented to start at line 9, column 12. The closing brace will then be at column 11, whatever line it happens to reach, and be the only thing on that line (bar a comment).
Oh, if you are trying to figure out if column 11 is a possible column for a brace to end up in, it was chosen randomly for this example.
I tend to have a dent in my intended expression to indent.
What I meant is, since those 80 columns I worked with last millennia, indenting with two spaces is minimum. With 40 columns I'd agree, one space is enough, but 40 columns was the 6502/6510 era, when I was 10 to 14 years old, and such style had not reached me yet.
I don't remember if it was Nicklaus Wirth of Edsger Dijkstra who said that no function should be longer than one page, so that you could see the whole thing at a glance. I once worked with a guy who did not use subroutines - just COPY and PASTE. His code would span many pages and was impossible to follow.
If you don't know what an ORM is for, and why you need one, then you probably don't. Personally, I don't like hand-crafting SQL and having to continuously refer to the database scheme because someone 20 years ago decided on some dumb convention and then abandoned it half-way through implementing it, or got a pair of columns the wrong way round.
I inherited a PCI enumeration function that was nearly 6000 lines long.
I broke it down into a lot of smaller, well defined functions with proper error checking, minimal parameter passing rather than whole structures (yes I know that it makes for longer assembler code, but it cuts down on data exposure), no globals (except for a table containing the pointer entry for each PCI root), fully commented, etc.
Nearly 2 decades later, at another company, I had to work on certifying a PCI software component. To my shock/surprise, it was my old code, complete with my name still at the head of the code change history! I was dreading such old code being pulled apart for very detailed testing of the requirements, but pleasantly surprised that no errors were shown up by that testing. And nobody commented on my name being at the top of the file history.
I had to think carefully if my 20+ year old code and me being part of the certification team would cause "independence problems", but the DER was happy that I pointed it out, and happy enough that I was a different person to the one who wrote it.
I did some PCI work some 20 years back, adding Chip & PIN payments to a system. I remember three really good things about it compared with so many projects:
1) well documented, sensible requirements
2) thorough, published, functional test suites
3) engaged, supportive, client and vendor staff, keen to make the project a success.
The code was finally retired after about a decade when they replaced the entire system - don't recall them ever finding a bug in it :-)
Compare that with the "oh yeah, we can just repurpose that unused field in the API to hold something completely unrelated" that I've had recently, along with "so when you said (in writing, no less) do this, you actually meant do something else entirely" :-(
Like you, I inherited a PCI enumeration function for an embedded system that needed to ensure that the expected devices were present. This was on a LynxOS box that talked to a network connected host.
The problem was that there were no error checks. None. Nada.
Failed enumeration and init simply bailed out with no indication different from a successful init.
So if the enumeration and init failed, the host would simply receive an error message that the device | was trying to connect to did not exist. Not very useful when I am trying to guide the system builders a couple of time zones away.
I added a status word to the function and as each stage of the enumeration went and was OK, I cleared the relevant bit in the status. A status result of 0 (as is common) was a successful enumeration and init of the various bits we expected to find.
That status word was sent back to the host; if the init failed, I could state precisely what had failed by looking at the first non-zero bit in the status. Not difficult but hardly the first time I have seen lazy code. Without an error code there was no way of knowing if everything was OK short of the entire box not doing anything.
It ended up being used in the production code.
No. Plausible deniability has it uses.
Just ensure the code is © Hans Schultz.
(Of course no one expects or believes system admins can write code and they usually obliges by not… except when they have pressing need.)
I have somehow managed to create a stored procedure in SQL that cannot be reopened once created. I rescued the code by querying the schema in order to migrate to another server .
Despite examining the code for ... something .. anything .. it all seemed fine and ran Create Procedure on the new server , aaaaand it happened again .
The error is "Syntax error in TextHeader of StoredProcedure 'usp_name' " if anyone curious
I worked with one developer who absolutely hated using hyphens or underscores in identifiers because he swore it made them harder to read. His joy on learning that square brackets let him do almost anything in SQL Server was unbounded... much like the hatred of anyone who had to maintain his :poop:
I wrote the Amstrad CPC arcade conversion of Ghouls n Ghosts for my sins.
The game contained chest sprites that would pop up out of the ground and when shot would reveal a weapon or a magician that would turn you into a duck or an old man.
Each sprite was associated with a structure that contained its position, animation #, and some flags such as 'I am a bullet', 'I am solid' and 'I am deadly'. For some reason that I could not determine this flag was being set to 'I am deadly' maybe 1% of the time. There was a mad deadline to get the game master to the disk duplicators, so I bodged the chest logic so that it would constantly reset the 'I am deadly' flag.
Am amazed no-one has spotted this since. In my defence we had no source level debugging. At some point I may revisit this in an emulator with CPU level debugging to see if I can finally fix it.
Back in the distant past - around the turn of the century - I was writing some Perl to add functionality into an e-commerce program. Hit an issue where it would fail on one specific line, however the line itself was perfectly fine - no errors, no dodgy logic, no hidden characters, no speeling mistokes, nothing wrong on earlier lines. It was just a mystery as to why it was failing.
I put put in a debug line above it (thereby moving it down a line) to dump the variables it was using to see if there was something off there (there wasn't) - and then it started to work! Baffled, I removed the debug line and it failed again. I put it back and it works. I commented out the debug line and it still worked.
I must have hit some super-obscure, edge-case bug in the Perl parser and that line was just at the right spot to trigger it.
Sounds like a timing issue to me. I see such things in powershell too, even in the current 7.x version. I use $null = Read-Host "Pause: Press ENTER to continue or hit CTRL+C" quite often for debugging. However, if you hit CTRL+C powershell quite often executes one more line, on some systems up to three lines, which is problematic for obvious reasons. It is timing dependend. If the lines below are functions or cmdlets it won't reproduce. But a simple $i++ or $b=$a/2+4 makes it beyond CTRL+C...
That sounds almost like my most glorious contribution to OSS to date. Back in the mid-2000s or so, I was finding that some Perl RPM packages were completely uninstallable (short of --nodeps) because they had some very random-looking requirements that seemed like Perl modules, but weren't. I traced it down to multi-line comments in which one of the lines started with the Perl keyword use, just as part of a sentence, and then the dependency parser assumed the next word was a module name, so you'd end up with a lot of RPMs requiring something to provide 'Perl::the' or just 'the', and sometimes other words that might follow 'use' in a sentence. I submitted a patch that checked for the various ways of opening a multi-line comment in Perl, and if it found one, skipped everything until the appropriate comment-closer. Shortly after that, they completely overhauled the Perl part of the RPM builder, but for a little while, my code was doing some good for the world at large, and I was quite chuffed when one of the Fedora/Red Hat high-and-mighties called it 'a clueful patch' on the mailing list message about it.
I've had effects like that which I put down to faulty ram. Old cheap ram cards sometimes didn't have parity (they always reported they were working when they may not have been) so a faulty bit wouldn't be detected. Moving it down a line, especially with a comment that wouldn't execute, shifts the issue so it doesn't cause a problem.
My second year at uni involved writing a Cobol program on a mainframe. So green-light terminals and dot-matrix printers were our only interface - no fancy IDE's. (I did miss out on the punch cards, though). And the number of compile-and-test runs was limited, of course.
I still dread the all-night debugging session we had the night before we had to hand in our program. Compilation was failing with lots of errors that didn't make sense (to us, at least). And a compile failure meant no debugging run.
After poring over the print-outs for hours, one of my fellow students noticed that a "01" on a line looked slightly odd - perhaps it was mistyped as "O1" with the letter 'O' instead of a zero?
He rushed to the datacenter around 2 AM in the morning (about three miles away on bike - no remote connections, this was 1984), all terminals were busy because we weren't the only ones struggling with this assignment. Eventually he got a chance to fix the error - the program compiled without any errors. He managed to run a couple of tests even though we were over quota on our account - it was quickly spotted that the system only checked your quota at login and didn't kick you off even though you were broke.
I do not recall if it worked as intended (most likely it didn't), but I did pass my second year exam.
Never in the 42 years since then have I opened my textbook on Cobol programming, nor done any of it.
That's familiar. That and the ever annoying straying into the column 73-80 territory that woe betide you would cause compilation and linking errors. And when you wrote a substantial bit of COBOL, you had to check every single line (and the line editor column field) to make sure you were not accurate. Back in those days the error message was not that particularly descriptive, so yes, at some point it became routine to a) check column 73-80 and also column 8-12 just for good measure (because).
And like you, I never opened my COBOL textbooks again after I left the poly (and ironically lent them to someone at the local uni because their text books were shite and ours made a lot more sense).
In the management procedures of laptops in my company is 13 year old code that I wrote before we were managing with MDM. It's been so persistent, it's still there. In bash. Not Python.
It has been super robust and fills a gap that MDM cannot fill.
I leave the company next week....
I'm proud of the code, but somewhat fearful of the future :-)
I used to work for a Uni, doing tech support. As part of our student facing website, we had a system where students could request that their MySQL password be reset. You know the drill. Click on the link, answer a couple of questions and then enter a new password.
I was walking through the lab one day, and a student stopped me. He was looking partly offended, and partly confused. I asked what happened, and he said he'd recieved a wierd error. He showed me the error, which said "Get back, thickyhead." I apologised to the student, and explained that the phrase was an in joke withing the team, and not meant offensively, and that I would talk to the page developer, and get the error removed.
I advised the student to give it a couple of hours, and retry the operation. The student seemed happy with that.
I spoke to the developer, who explained that several things had failed that caused the error (the site emailed him with the technical details of any errors), and that he would both fix the failiures, and replace the error with something a bit more appropriate.
I once wrote some test software for an automated test of security administration software (SeOS, if anyone remembers). It created a user with a specific recognisable name (rabbit) did some things with that user and then deleted it. Years later, after I changed departments, I got a call from someone who had an audit report that that specific user was present on production systems. I explained, that someone must have tested in production, and that the test was probably rudely (-9) interrupted before it could clean-up. Still funny how rabbits popped up there.
About 30 years ago, we encountered a Heisenbug[*] in a COBOL program. If we put a diagnostic display in the code before the errant statement, the bug went away. Remove the display and bug returned. We found that any dummy statement would stop the bug from occurring, so one was left in the code. Given the same codebase is still running today, I imagine the same shim is still in there.
[*] A bug that disappears or alters its behaviour when one attempts to probe or isolate it.
No, no, a Schrödinbug is one that may or may not be present in working software - but you're not sure until you have a look.
It's where you have this nagging feeling that you _may_ have inserted a bug in some code that (inevitably) is now running successfully in production. But you go and rummage around on the dev systems anyway, just to be sure. This opens the box, as it were, and you collapse the bug waveform. Either you find there wasn't a bug after all, or you uncover a coding horror lurking where it has no reason to be. Naturally, if your search discovered a bug, the previously working production code immediately starts failing - thereby also showcasing 'spooky action at a distance'.
I think Schröding-bug would have been a better name, but it just isn't what popular culture chose. In that sense, it is similar to the use of the phrase "quantum leap" to describe a big change, when a QL is in fact the smallest possible change permitted by the Laws of Nature. It's annoying to those of us who know, but on balance it is probably for the best that everyone isn't forced to learn quantum theory before being allowed to enter adult society.
People who get hung up on "quantum leap" are looking at it from the wrong perspective. The whole point of quantum levels is that changes in such systems are not continuous as had been previously thought. So yes, it's the smallest possible change. But the point is that it is a shift to a whole new level, not a small incremental change. If you have a hydrogen atom at -13.6eV you can't bump it up to -12eV, you have to go all the way to -3.4eV for the second level. So the analogy is fine.
I once did a y2K fix on some code where I could have fixed it PROPERLY but that would have impacted a whole load of other stuff some of which was out of my jurisdiction, code wise. So I had to do a moby hack and do a temporary fix with minimum change. This worked, but in the words of Susan Ivanova, "There's always a boom tomorrow".
So I worked out when the code was going to fail catastrophically, and I left that as a comment in the code, together with a comment on how it could have been fixed properly.
Ending with the words "Hopefully by then this will not be my problem!"
As things went, the company went into liquidation and so it became nobody else's problem. I would have hated to be pulled out of retirement to fix it had they still been going.
Not C#, but Delphi has a distressing quirk where local boolean variables aren't initialized to a consistent value, so on one execution it could be false, and on another true depending on what garbage happens to be in that memory address at the time. Caught me out more times back in the day than I care to admit.
"Works on my machine!"
Fine. I'll just take that production system offline and do whatever it takes to figure out the bug. You can set up another system if you want to keep production going.
What I cannot do, and what no-one can do, is fix a bug that does not happen on a system that I'm allowed to touch.
Oh, and it absolutely is the job of the tester to produce a repro case, since otherwise their reports are just hearsay.
My very last day on site after many years -
I'd been body shopped in originally. Then left the body shop. Then got taken on as an employee. Then been prematurely retired. Then, in unforeseen circumstances, gone back on contract. Then left again. Then had a vendor contract and ended that contract doing some hand-holding while the site went through an upgrade. The go-live was the first working day after the contract ended but as the guys there were old mates stayed on that day.
On go live an SQL statement failed. I looked at it. I remembered writing it it back in the body shop days. It replaced a non-SQL bit of code what I'd also written back then so the logic behind it was one of the oldest things I did there. It brought together stock levels for two different types of product that had stock levels determined in different ways. I couldn't see how it ever worked but it had, in practice, worked for years. Somebody else said that they couldn't see anything wrong with it. I fixed it and the fix worked.
It was a few years before I came across the explanation. It was a complex statement that involved nulls and the definition about nulls is a little ambiguous. The new version of the product changed the way it navigated the ambiguity.
I was moving an old MUD to a new server. When started up on the new server, the output to the user was completely garbled. Ok, fine, full recompile from source - same problem! Hmm. Full recompile from source on the old server - worked fine. Hmmmmm. Time for proper debugging.
I eventually found that someone decades ago had used strcopy to shift characters in a string by having the source and destination strings overlapped. This is a no-no, but worked for years... until I moved it to a machine that did the copy starting at the other end of the string.
...don't. I'm sorry I even wrote it now."
Probably my favourite. It's in the manpage for a quick and dirty "Serve absolutely anything - binary, text, the output of an executable - anything - wrapped in HTTP over an arbitrary network port" tool.
IIRC I wrote it because I was trying to get a file into a really early Windows95 VM by abusing the fact that IE4 or whatever ancient version it was would treat anything that arrived as a result of an HTTP request as a file if it didn't know what else to do with it and try just offer to write it to disk, thus neatly side stepping the fact that I didn't have scp or nfs or anything sensible to move files around with.
When I started work, a senior coder on my team explained that you should always "code and comment as if your code will be maintained by a psychopath who knows where you live". It was a good rule to live by.
Sometimes I'd return to the scene of the crime (a customer that I'd written something for five years earlier) and be responsible to maintain or update things. I quickly learned that my memory would not save me, so I'd damned well better document my assumptions.
I've lost count of the number of developers who told me I was being ridiculous, and we didn't need to document things to that level, because they were obvious. Years later, those same developers also invariably ended up spending days, or weeks, trying to reverse engineer their own undocumented code. They often not only had no idea what it was doing, they had no idea what it was supposed to be doing, because they didn't remember, it was polymorphic, multiply inherited, reflected, replicated, and god knows what else, and the only comment would be something like "// I am not sure if we need this, but too scared to delete.".
Here's a collection of comments I've found in production code bases over the years:
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
/* This is O(scary), but seems quick enough in practice. */
//Dear future me. Please forgive me.
//I can't even begin to express how sorry I am.
// TODO: Fix this. Fix what?
// If you're reading this, that means you have been put in charge of my previous project.
// I am so, so sorry for you. God speed.
// no comments for you
// it was hard to write
// so it should be hard to read
And, my favourite, a 13,000 line C++ source file that was rejected by a checkin validation script because there were no header comments to any of the hundred or so functions in the file. The code added the following header comment to every one of the hundreds of functions to get it past the validation script:
// As you can see, I comment the code
I wrote a bit of code for work that (I think, from memory) called a poorly (or not at all) documented library function with a lot of parameters. If I called it exactly like the example, it worked; if I changed anything, it didn't. My comment above the function call was something along the lines of:
Don't change this next part unless you really, really understand how it works. (I don't.) Here be dragons.
Back in my very first professional assignment, I was a Jr. member of a team that was doing an Operational Test and Evaluation (OTE) suite for the Us Military (Army...IIRC. I was working on the second shift prepping our code to identify differences between what the code from several well-heeled Defense Contractors produced against what the "standard" said it should be producing. (The project was battlefield asset location -- this was waaay before GPS was a gleam in its developers' eye.) Our code was to compare the output from these Contractors' solutions in real time...we were the referee, as it were to define whch of these solutions was the most accurate.
A demo was scheduled for all the Contractors' wares at 0700. Sharp. Full military brass in attendance; never seen so much scrambled eggs in one place live. The sun was coming up and the Law of Demos was raising its ugly head...for us in particular. We had test suites to verify that our code was working correctly, and sure enough, it wasn't. The code was running on the Hewlett-Packard equivalent of a PDP-11 (an HP 26-sumpinornother) that was basically filled to the brim (64K address space; overlays were supported, but they weren't fast enough to do the real-time monitoring and evaluation for 5 separates sets of inputs).
Our team was huddled in our trailer (this was, of course, a field project) trying like hell to debug our code. At T-1hr, 30mins, we found what we think was the bug. But we couldn't fix it correctly. See, the code was in HP assembler, and we had long exhausted the assembler's symbol table space. (Back in the day, that was a thing.) So the "fix" had to be written without adding any symbols. And it had to be small. This meant PC-relative coding (i.e. using *+2 kinds of constructs. The fix required a loop, with two conditional exits at the bottom of the loop. I managed to draw the short straw, and ended up coding this abomination in 4 assembler statements. It just fit...and because the Coding Gods were smiling on us...actually worked! It passed the verification suites, as well as some we cobbled up to verify the conditional exits. With 15 minutes to spare, we submitted our code to the Powers that Be for the Demo...then went home to go to bed.
Word was that our OTE code worked properly throughout the Demo.
Fast forward several months, and I'm now back at the home office, readying for my next assignment. I received our code back from the field, and went to go print up the block of code cobbled up under sleep-deprived pressure, to post on my cubicle wall. I hand wrote on that printout the words: "Don't ever write code like this again!" Later that day, our resident Alpha Geek came in to offer congrats, and saw the code on the wall. He looked at it for a rather long while, then turned around with a big smile and, as he left the cube, said, "Good comment".
Many moons ago I fiddled with, if memory serves me right, Assembler for Z380 to drive an LCD and some, replacing the Z80 in an appliance of some sort. At one point I was taken of that unfinished project and Tom took it over. One day, at pub'o'clock, he told me that he had flushed all my code and started from scratch. At first, of course, that tickled my ego, but after a moment or two considering what I had done so far, I could only think: good riddance! Thank you, Tom.
robot land, I wrote a simple macro for drilling any number of holes on any diameter of circle (fairly common thing.. think bolts around a porthole).
Get the call a couple of years later... seems there is a problem with said macro... setter has produced a pile of scrap ..... and I noticed his inputs to the macro where way off.
Goto my macro code in the robot.
First line
; ToDo : validate the inputs to catch any stupid values
Blah blah blah
etc etc
Oopsie..... where can I hide the blame for this failure......
In my first job out of uni in '93, I started out as a Configuration and Release Manager for a major telecom company. Basically, I wrote and maintained ksh scripts for our build process - developed on Unix, read all the PRs/CRs (problem reports / change requests) out of our homegrown system, parse out the version info, check out all the code from SCCS, ftp it to the Tandem platform, build it, burn it to 9-track tape, and install on the test machine. about 12 hours start to finish.
We were on Unix servers, and the homegrown pr/cr system was ok but it used a gui front-end. Luckily, all the files were simply stored it text files named with the prcr#. I ended up writing a script for myself that would get the data from a terminal. It was faster, and you do do it from the lab where there wasn't a gui. After about a year of that, I moved into the testing team because I really liked testing. We still used the prcr script because we needed to look things up often. I made a few updates to it along the way, and I had learned to put comments in and a version history at the top.
1999 rolled around and I was lured away to the promise of the internet startup bubble, and we all know how that ended. Several companies and 15 years later, I was tracked down via email by someone who still worked at my first company. He asked me if I remembered writing the prcr script. Someone there was wanting to make some changes to it, and wanted to know if I was ok with that since I was the author.
While that was amusing, it was also frightening that 20+ years later a) they were still using that pr/cr system and b) my script hadn't been updated since then. It wasn't even stored in source control.
I of course gave them the go-ahead to change whatever they wanted.
Years ago, I handed the task of figuring why a port of sendmail to OS/2 would occasionally send multiple copies of an email. Since I was new to the code the first thing I did was turn on all compiler warnings and fixed them one at a time. Eventually I got to a complaint that a function call had three variables and the function wanted four. The fourth variable was an optional variable for the number of emails to send. Adding '1' to the function call fixed the problem.
Until now, I never thought to check if the bug was in the original sendmail source or if a coworker created the bug.
A while ago (I forget which side of the millennium), we had a Heisenbug that I traced to an Win32 API function (I forget which) that had an uninitialised variable; my fix was to call a dummy function that declared and zero'd a suitably-sized array on the stack and then returned.
I still feel dirty.
Saying it again as I like my little coding story. I don't regret it, wasn't my fault 2 "friends" got expelled from college for it, I warned them.
Was doing my computer course and we were learning Pascal. For some reason they'd never bothered to teach us writing to files. When I came across how to do this in a really good Pascal book I got from the college library. I started to play, then found more on it in the actual Pascal help file in the editor we used.
I realised that when we'd turned the PCs on in the computer room, they'd start on C:. You'd change to T: and type login.exe
Then you'd put in your user name and password then type win for Windows 3.11 for Work Groups. I had noticed people would forget and type login.exe on C: and would leave their assignments on the root of C:. So I created a login.exe in Pascal that displayed the same (although I never worked out how to hide the password as you'd type) as the official login.exe. It would then save the user name and password to a file called assignment.wpd (using WordPerfect at the time). I tried it, it was very simple, it worked!
I stuck it on a few of the PCs in the lab to see what it could pick up. Being totally clueless that I'd written a sniffer program. I told the 3 mates "Don't abuse it. If you get caught with it, you know nothing".
Checked it one day and it had picked someone up with password "masterofpuppets". Logged in as them. I was happy I'd made something that worked. Then logged out and that was it. Told them I just wanted to see it working in the real world. Its not to be abused.
One day I was skipping college and those 3 idiots got caught with it, although other stuff was on one of their floppies abusing the lecturers as one of the "mates" was immature. The rule was, if you'd been spotted pressing the reset button on the PCs, you were up to something. So they got pulled up on that. Found with the sniffer program and the other abusive stuff. Was mainly the abusive material that got two of them expelled and one suspended for the sniffer program. They were questioned but thankfully no one cracked. Told "The code for the program was quite good who made it?". It wasn't good, it was basic and most of it taken from the help file. Lucky for me that didn't make them crack.
Had a big meeting in the hall about how serious it was as that the police could have been called (I think they didn't as they realised how shit their computer security was).
A couple of years later. My cousin and I were mailing floppy disks to each other (it was the 90s). One floppy disk at a time, full of interesting things. He'd got hold of 2600 magazines if I remember right (although not been able to find the article since, so may have been from another mag), which had a piece on Pascal and a basic cipher. So I added that to the login program to scramble the assignment.wpd file, so if they found that, it would look like junk. I never deployed it this time though, although did give it to my cousin who wanted to use it at Leeds Uni, never found out if he ever did.
Sadly, I cut up all the old floppies some years later when CDs became a big thing so I lost all the code. Been trying to recreate it recently for the nostalgia.
