Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Times I've Messed Up as a Developer

medium.com

Post reply on HN
Print view View original

91–100 of 137 posts

Re: Times I've Messed Up as a Developer

#91

Post by bungie4 »

acoard wrote: post #82
bungie4 wrote: post #58

Late 90's, I'm lead dev for a large site. Company hires a DBA. We partner with a VERY large content provider. I'm awake for 48 hours buttoning things up, last minute stuff. I finally collapse from exhaustion only to be woken up at 7am on - go live day. Nothing works. A few moments debugging reveals that all the column names in a key set of our datasets have been renamed. No time to waste, I rename them all back as qu…

>We contact the DBA and explain the folly of his decision. >He then proceeds to rename everything AGAIN on a live system. What could his reasoning possibly be? Did he not understand your explanation?

We later found he was acutely OCD and a perfectionist, which I've since come to find is common in DBA's. He HAD to change the column names. He quite literally couldn't stop himself. Changing it in dev, QA and staging wasn't enough for him, it was an all or nothing proposition.

Re: Times I've Messed Up as a Developer

#92

Post by woliveirajr »

3131s wrote: post #63
seanwilson wrote: post #41

Earlier quoted context omitted.

This is why I do a "mv" to "tmp" instead of using "rm" when I can. Having special messages or colours to differentiate between production and other environments is a great idea as well. Generally if I'm about to do something on production, I'll close everything else to do with other environments as it's just too easy to slip up.

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

An then use 'yes' to avoid all those key pressing :)

Re: Times I've Messed Up as a Developer

#93

Post by Gaelan »

msangi wrote: post #70

Once I refactored some stringly typed C# code to use an enum with values Prod and Test instead of the two strings "Prod" and "Test". I was relying on expressions like mode == "Test" to fail to type-check to spot all the places that I needed to update. Sadly some parts of the codebase weren't very idiomatic and had some "Test".Equals(mode) This caused a bit of involuntary testing in production and thought me not to tr…

>stringly typed

I'm going to steal that one.

Re: Times I've Messed Up as a Developer

#94

Post by shocks »

woodrowbarlow wrote: post #78
seanwilson wrote: post #41

Earlier quoted context omitted.

This is why I do a "mv" to "tmp" instead of using "rm" when I can. Having special messages or colours to differentiate between production and other environments is a great idea as well. Generally if I'm about to do something on production, I'll close everything else to do with other environments as it's just too easy to slip up.

my go-to .bashrc hashes the hostname into a color and prints the prompt in that color. it has saved me from making a dumb mistake a few times.

Production prompts are red.

Staging prompts are yellow.

Development prompts are green.

Re: Times I've Messed Up as a Developer

#95

Post by woodrowbarlow »

tacone wrote: post #84
woodrowbarlow wrote: post #78

Earlier quoted context omitted.

my go-to .bashrc hashes the hostname into a color and prints the prompt in that color. it has saved me from making a dumb mistake a few times.

Could you post the code somewhere?

sure, although my technique is a bit kuldgy.

https://gist.github.com/woodrowbarlow/52b02ab27d0f8088891c3d...

look at `get_hash_color`.

Re: Times I've Messed Up as a Developer

#97

Post by JoeMalt »

donatj wrote: post #52
MaxBarraclough wrote: post #30

Earlier quoted context omitted.

This 'default' behaviour strikes me as one of SQL's worst faults. If you want to delete all rows, you should be made to explicitly type out that intention.

I'd say require a WHERE on deletes. If you want "WHERE true" that's fine, but require a WHERE.

If you start the MySQL Monitor with --i-am-a-dummy, this is enforced automatically

Re: Times I've Messed Up as a Developer

#98

Post by woodrowbarlow »

shocks wrote: post #94
woodrowbarlow wrote: post #78

Earlier quoted context omitted.

my go-to .bashrc hashes the hostname into a color and prints the prompt in that color. it has saved me from making a dumb mistake a few times.

Production prompts are red. Staging prompts are yellow. Development prompts are green.

yeah, that'd be great. but our staging units (i don't deal with production units) come and go so often that keeping a list of hostnames became unrealistic.

Re: Times I've Messed Up as a Developer

#99

Post by reddit_clone »

amyjess wrote: post #15
Spoom wrote: post #12

Earlier quoted context omitted.

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.

That's good advice in general, not just for SQL. For example, I often write my 'rm' commands as 'ls' at first and then swap out the command once I know it gets the right thing.

Yep. I do that too. Along the same lines I always do an 'echo' before I 'find -exec' anything.

Re: Times I've Messed Up as a Developer

#100

Post by khedoros1 »

woodrowbarlow wrote: post #98
shocks wrote: post #94

Earlier quoted context omitted.

Production prompts are red. Staging prompts are yellow. Development prompts are green.

yeah, that'd be great. but our staging units (i don't deal with production units) come and go so often that keeping a list of hostnames became unrealistic.

Is there something in your dev process that would actually require you to implement it with a list of hostnames, rather than just putting the "staging" version of .bashrc onto the staging machines, and the "dev" version onto dev machines?
Post reply on HN