Live data from Hacker News

Times I've Messed Up as a Developer

medium.com

101–110 of 137 posts

Re: Times I've Messed Up as a Developer

#102

Fortune 500 company, Junior dev. Tried to log into our staging database, which has the same username, but different password than production. Tried 3 times, got the locked out error. Got frustrated, said I'd fix it after lunch, went out to eat, came back about 3 hours later after a doctor's appointment. My boss was waiting for me at the department door and I got sent back to his office for a stern talking to. I had l…

I agree with nieksand... badly designed system. It's better for companies to recognize these design flaws and fix them, rather than blame employees ignorant actions.

Re: Times I've Messed Up as a Developer

#103

Back in the early 90's I had 2 terminals up on my X windows console. One for local dev and another for a production server running a trading system for around 50 users. Naturally for production I was logged in as root. I typed rm -rf to clear out my dev folder only to figure out I just deleted the root folder and all sub folders on a production machine. I recalled a piece of advice a university friend had given me. "…

> Moral of the story - Don't let anyone give you access to production servers.

In my case, it was "Don't let anyone have you do testing/debugging on the production machine."

I was 18, first dev job, small mom-n-pop which developed insurance claims management software. Early 1990s, green screen VT100 terminals connected remotely via modems and dedicated phone lines.

Anyhow, something was wrong, I forget what, and to fix it I needed to debug using a real dataset. Between each run I had to clear out and rebuild a series of test "tables" (that's in quotes because the system was PICK, and the DB isn't exactly a SQL RDBMS), then copy the production tables to the test tables, and re-run.

Well - at one point I cleared the wrong table - cleared the production and not the test table.

Within seconds all the phones lit up in the office. I groaned (rather loudly), because I knew I just dun f'd up. The client was one of 3 or 4 that the company had, and the largest. Needless to say, for every minute they were down, they couldn't process claims, and were losing money.

Did I mention there weren't any backups? Not that backups weren't made, just that they were "end-of-day" backups, so the backup for that day's work (head's down manual entry of claims for processing) had not yet happened.

Fortunately for me, the table I deleted could be recreated (mostly) from two other still-intact tables. My manager and I worked thru the evening rebuilding the table as much as we could, and also pulled in data from the prior day's backup to make it as complete as possible. Even so, they still had to re-enter some data lost that wasn't recoverable by that method.

Did we set up a test server or do anything else that any sane company would do after that incident? Nope. Things just continued on in the same manner, and somehow I kept my job. Honestly, we should have been doing the testing in-house, but this was using an IBM RS6K box that at the client was much larger than what we had as a dev box (we were using the smallest version of that machine at the time, which was meant to be a single user desktop workstation as I later found out), so we couldn't fit the data onto the hard drive, even if it was possible to download it all via modem (it wasn't - I'd probably still be waiting for the dump to complete given the modem was only 9.6 kbps). I have no idea what it would have cost to do it right, but the drives needed back then, coupled with the infamous IBM service contract - meant we couldn't just hop over to the nearest Insight to grab a cheap hard drive and slap it in.

Today, I'd probably have the admin spin up another instance of the PICK system as another process on AIX, and (somehow) replicate the live data/code over and run in that instance. Still not "safe", but probably would have been much safer than what we were doing. But alas, I was but a kid at the time, and barely understood *nix (but that was where I first learned about it - and I also gained a healthy lesson/understanding/fear/respect for terminfo - for the purposes of supporting a variety of serial terminals and PC terminal emulators).

Re: Times I've Messed Up as a Developer

#104

Back in the nineties, at a previous employer, I wrote a code generator that read a kind of DSL from stdin and spat out C source to stdout. Having written the initial version and got it to compile, I thought I should test it before checking it into RCS for the first time. So I ran it with some simple input and piped the output to something like program.c. At that point I remembered that the code generator's main sourc…

A couple years ago, I was writing a script to run a codesigning system (watch an input directory, sign the file, move to output directory). I had been working on it for a couple days. I got confused with my filenames, and I deleted the script, thinking it was a temp file I'd just created.

Luckily, it was Python, which compiles to a bytecode representation when you run the script, and I had done a test-run of the script recently. After a little research into the available tools, I was able to extract the original source (and comments!) from the pyc file. It was a simpler solution than any of the un-delete utilities that I found.

Re: Times I've Messed Up as a Developer

#105

Fortune 500 company, Junior dev. Tried to log into our staging database, which has the same username, but different password than production. Tried 3 times, got the locked out error. Got frustrated, said I'd fix it after lunch, went out to eat, came back about 3 hours later after a doctor's appointment. My boss was waiting for me at the department door and I got sent back to his office for a stern talking to. I had l…

Did you have different credentials you were supposed to be using?

Re: Times I've Messed Up as a Developer

#107
post #12
post #7

I was on my way out the door at my first job, and an SEO person stopped me and asked me if I could fix something. I just needed to delete a single row from a database. Easy enough. I get as far as “DELETE FROM table_name” and for some unknown reason run the damn thing without a WHERE. All the rows, gone! We did have nightly backups but the guy with access to them was notoriously hard to get the attention of and lived…

Always write DELETEs as SELECTs, and once you run the SELECT and it returns the rows you want, then swap out the SELECT * with a DELETE.

It's like gun safety. All the rigor feels stupid until you hear stories about people not following the rules.

Re: Times I've Messed Up as a Developer

#109

Fortune 500 company, Junior dev. Tried to log into our staging database, which has the same username, but different password than production. Tried 3 times, got the locked out error. Got frustrated, said I'd fix it after lunch, went out to eat, came back about 3 hours later after a doctor's appointment. My boss was waiting for me at the department door and I got sent back to his office for a stern talking to. I had l…

Did you have different credentials you were supposed to be using?

Afterwards, yes, but before that all staging tables belonged to a single role under a single staging superuser.

Re: Times I've Messed Up as a Developer

#110
post #83
post #63

Earlier quoted context omitted.

You can also alias "rm -i" or "rm -I" to "rm" to avert major catastrophes. From man rm: -i prompt before every removal -I prompt once before removing more than three files, or when removing recursively; less intrusive than -i, while still giving protection against most mistakes

This alias seems to be set by default in many linux distributions these days (and has been that way for many years now). The problem is that you get used to this crutch and rely on it, until one day you're logged in someplace without the alias and end up deleting something you shouldn't. I'm not a fan and normally disable it. Instead, I prefer to be very careful and deliberate when using rm, especially with any wildc…

> This alias seems to be set by default in many linux distributions these days (and has been that way for many years now)

Which Linux distributions do this? I have not seen this alias set by default on any distribution that I've used recently (Gentoo, Linux Mint, Debian, Ubuntu, Crunchbang, Arch).

Post reply on HN