post your experience with blowups/infinite forks/accidentally typing rm -r /root / things like this.

On one occasion, I had a file with data that was indexed by lower-case letters. And for some reason I wanted to change all the a's to aa's (maybe I was going to insert some ab's or something). So I go

sed -i 's/a/aa/' myfile

I walked down the hall to get a drink or something, and when I come back, the script's still running and the CPU is kinda laggy. So I open the directory and there's 70 GB file sitting there. (I only have like 20 G on my cloud space at work.)

Anyway, I just killed the script and deleted the file, so it wasn't really a disaster. so this story sucks. But hopefully others have witnessed/contributed to more significant and catastrophic mistakes.

7/29/2016 8:51:48 PM

I ran an update statement on a production database and forgot the where clause.

You only make that mistake once. Now I start with the where.

[Edited on July 29, 2016 at 10:33 PM. Reason : Yay for audit tables ]

7/29/2016 10:32:38 PM

I have no exciting stories. I just occasionally screw up while loops so they never end like every programmer ever.

8/1/2016 10:12:56 AM

classic asp...keep forgetting the goddamn rs.MoveNext(). infinite loop city!

8/1/2016 11:55:28 AM

I didn't write this, but I stumbled across it.

Our flagship ERP product uses SQL Server as its data store. When you upgrade to a newer version or install a new plug-in, changes to the schema are delivered through a separate schema update process. We have a separate utility program for applying this update.

This is simplifying the process a bit, but the important part is that the utility program uses a script that's just a text file of SQL script filenames. Since our schema changes are monolithic, the utility program can just read the last filename loaded from the previous update, seek to the matching line in the upgrade script, apply all the scripts referenced from that point forward to the database, and store the filename of the last script applied in the database.

When the value for that last script can't be found in the upgrade script, the utility program is supposed to throw an error and abort. However, there's a situation in which something far worse happens.

The utility program used to support SQL Server and Oracle databases, and there were two separate tracks of scripts for those. There are also two separate tracks on those platforms for Unicode and non-Unicode databases. Because of this, the filename match the utility program performs is fuzzy. For certain values not found in the script, the filename would actually match a much, much, much older file...and the utility program would work from there forward.

Now, the schema changes are monolithic, which means that every release includes this monstrous script with every schema script that has ever been released. This includes a number of scripts from the bad old days when we didn't maintain a separation between schema changes and data conversions. We also used to do a lot of very destructive schema changes, e.g. blindly dropping a table and recreating it with no regard for the client's data.

You can imagine the problems this caused.

8/1/2016 1:22:30 PM

Not a code bomb but I just pretty much assume you are an asshole who's trying to prove how smart you are if you use a ternary operator (eg ?).

Makes code more difficult to interpret on the fly and a pain to adjust the flow in the program when it's used in certain ways and you're basically asking for less experienced programmers to come along and fuck up your code.

Not saying there aren't exceptions but fuck off with that shit.

8/9/2016 9:46:07 PM

ternary operators rule

8/9/2016 10:15:52 PM

: googles ternary operator :

so this is a more compact what to do if-then-else statements?

8/10/2016 1:08:33 AM

Here's a fun one.

A couple of years ago, we released a new major version of our flagship ERP product. The upgrade required numerous data conversions, some major and some minor. An arguably minor one involved taking a dollar amount from one column on a table of financial records and setting that value on a new column added to the same table. Never mind why, it was a single UPDATE command, very straightforward!

The problem was that the developers and QA didn't bother to test this simple UPDATE on production-scale data. Some of our clients have decades of data. Neither column involved in the UPDATE is indexed. So come upgrade time, this step of the upgrade process stalled, because the conversion took hours to complete.

Worse, the utility program I mentioned in my last post is an ancient, single-threaded VB6 application. The database command runs on the same thread as the UI and blocks, so the application goes non-responsive until the UPDATE completes. It happens every time with every script, you just normally don't notice because they're fast. Of course, most users don't know that. They just think that if the application isn't responding and has been stuck for hours, something has gone wrong, so they kill the task and try again. Reasonable! But unfortunate.

Loads of clients got inconvenienced by this. Messy situation. I wound up delivering a workaround that fooled the utility into thinking that conversion script had already been run and required loading an alternative script for doing the conversion, namely one that indexed the column, performed the UPDATE, then dropped the index...and that was still faster!

8/10/2016 10:23:45 AM

Not really a code bomb per se but this one time I accidentally placed the corner of my bottle of tres commas tequila on the delete key on my keyboard and didn't realize it. Deleted so many lines of code and video content from our site.

8/10/2016 2:44:25 PM

^^^ yea, and fundamentally there's nothing wrong with them. like any nice thing, it's abused until you can't have it.

nothing wrong with:

var x = (y % 2 ? 'odd' : 'even');

but i've seen them nested 2, 3, 4 times deep... and those ppl should be shot. IMO they should generally only be used for very very simple and short decision statements

8/10/2016 10:39:51 PM

I don't think there's anything good about the conditional ternary operator.

You know what basically every conditional block in basically every high-level language has in common? They start with fucking "if." If I have to read your source code, I'm expecting to see ifs all over the place. I'm ready for them. I can understand them immediately.

When I see your stupid fucking ternary operator, all it tells me is that you thought saving a few characters on the line was more important than the legibility of your code. You're an asshole, fuck you, change it.

8/11/2016 6:29:35 AM

If you can't understand a ternary operator, then you need to go back to CSC116 and try again. People who go 18 levels deep with them are annoying, but there's no need to go like so:

if (foo) x = 1; else x = 2;

This code partially obscures the fact that you are assigning something to x conditionally. The ternary operator makes it immediately obvious that you are assigning to x, no matter what. Like I said, don't go apeshit with it, but for relatively simple operations, it's fine. Anything more than 2 layers deep, and you're abusing it.

Now, this shit I hate:
x = foo ? bar : baz ?? foobar != null ? whizzy : bangbus.

Fuck that noise.

But the ternary operator? It's like regions in C#: they have their place, but don't be a dick with them.

9/27/2016 1:05:59 AM

I'm a ternary fan, always have been. Got used to it in HDL since it's very natural for hardware, use it wherever i could.

Just started using null coalesce too... i'm guilty of putting ridiculous nested ternary statements, but only out of desperation in a rare circumstance trying to find a bug.

9/27/2016 1:52:54 AM

How exactly does that obscure the assignment of a value to x? Are you high?

9/27/2016 7:00:54 AM

TIL what a ternary operator is. Also, TIL that I use ternary operators in my Python code. They seem to be much nicer in Python than other languages, though.
result = x if a > b else y

Then again, I do have a few examples in my test code where I did rather terrible things just to see if I could (and I could!):

# Why use more than one line when you can create a monstrous Pythonic abomination on one line?
new_dictionary = {key: old_dictionary[key] for key in old_dictionary2
if ((key in old_dictionary)
and (('field1' not in old_dictionary2[key])
or (not old_dictionary2[key]['field1'])))}

I guess that isn't fully ternary, but it still was fun. One of those, "I am tired and miserable, but this will amuse me."

9/28/2016 11:05:06 AM

+1 for ternary operator

at first I was excited about null coalescing, but generally avoid it these days.

9/28/2016 8:51:03 PM

occasionally screw up while loops so they never end like every programmer ever

9/29/2016 7:21:02 PM

One time at my first job I plugged a switch into itself because the cable was mislabeled. Took the network down for like 30 minutes. If you're a programmer and need a break, try that. If it works, it's not like they're going to know it was you.

The ternary operator is expedient in C++ on occasion, like when you want a local variable that's a reference that should be initialized to one of two things and writing a function would be too dumb.

10/3/2016 2:49:39 AM

Quote :

"How exactly does that obscure the assignment of a value to x? Are you high?"

In that example, it's not too bad. Now, try this:

if ((some_condition1 || somecondition2 || foo || bar || baz) && other_condition && fizzle) someVariableNameThatLooksSimilarToOtherVariablesInScope = some_complicated_expression;
else someVariableNameThatLooksSimilarToOtherVariablesInScope = some_other_expression;
if (something_else_that_sucks_because_dickwads_dont_know_proper_whitespace_use) someVariableNameThatLooksSimilarToOtherVariablesInScopes = did_you_catch_that;

function(foo, bar, baz, foobar ? foo : bar);

if (foobar) function(foo, bar, baz, foo);
else function (foo, bar, baz, bar);

var temp = bar;
if (foobar) temp = foo;
function(foo, bar, baz, temp);

10/5/2016 11:31:33 PM