views:

279

answers:

9

We all make mistakes, but some have bigger consequences than others. I'm interested in hearing about the biggest doozies all the smart programmers here have made in the past and how what they learned from it helped them to become a better programmer.

Mine:

I was developing a website which allowed users to post comments (that were moderated) on certain pages. My mistake was to write sanitation/moderation code for public input on each individual page that allowed comments to be posted. Inevitably when making an update I missed one of the pages by accident.

The page got flooded with pretty vulgar comments, which were only discovered after some users complained. Embarassing.

Lesson learned: avoid code duplication wherever possible.

A: 

1- Executed a delete statement without where clause in production environment.

2- Added a ‘&’ sign in the configuration file at the last time without testing and shipped that to client, where it was a complete disaster.

Prakash Kalakoti
+4  A: 

Making a last minute pre-release change that was obviously so simple that there was no way that it could be problematic or introduce a bug...

Guess what?

Visage
Everything went well?
James
+1  A: 

Not follow the standard way of coding. I have face a lot of problems specially in maintenance phase.

Arman
+4  A: 

Sending a testmail through an email module containing tekst: 'name of my collegue' is gay. The whole point was to see if this testmail would reach him. However through a stupid mistake of mine that mail was sent through to every email adress in our customers' customer list. ( all big shot hotel bobo's ). To add insult to injury, the return adress of that mail was the customers email adres.... Well, let's just say the pooh hit the fan bigtime.

Amelia
+5  A: 

Assuming all is ok and thorough testing is not required.

this. __curious_geek
+3  A: 

Two of us made the exact same mistake back in the bad old days when we were allowed to make changes to production on the fly. We both missed highlighting the where clause in an update statement and set our users logins to the same same login for all users. Oops.

The difference it turns out was the aftermath. I made the mistake first, noticed it when it happened, sent out an email to all the dev managers immediately telling what happened and that it would be fixed in five minutes or less. I grabbed the old data from the audit tables (I love audit tables) and fixed the table immediately. Because I acted quickly and let everyone know that if someone complained to tell them that the fix was being made, I had no problems from the error at all.

My co-worker wasn't so lucky. Several months later, she did the same thing to the same table. Difference was she didn't notice that all the records had been updated instead of one. She went on her merry way and the first anyone knew about her mistake was when multiple user complaints started coming in from every client. The problem was quickly escalated to the IT VP who then tracked down who made the change from the audit tables and had her fix it. She wasn't as familiar with the audit tables as I was and so it took her awhile to get it fixed. End result, all our sites were down (since only one person could log in) for several hours, clients were angry, the dev got a formal warning from HR and put on probation and would have been fired the next time she made an error and would have gotten no pay raise due to a bad evaluation.

What I learned is it isn't so much the mistake but how you handle the aftermath. Owning up and initiating the fix right away works a lot better than waiting until someone else notices in most organizations (and the ones where it doesn't, you really, really don't want to work for).

HLGEM
A: 

I've made so many big mistakes that I find it dificult to pin-point the biggest. Nonetheless, I think my greatest mistake is taking users for granted, believing that if users enjoy and praise you for the free stuff you offer, they will be prepared to pay a little, no matter how small, money for the same stuff in the event you changed your strategy. In software marketing, the equation has never been 2+2=4.

Always welcome.

Joseph
+2  A: 

Not verifying backups, testing before they are needed that they can be recovered. I lost the source code to an entire project, costing the company untold opportunities.

I learned: A backup that is not verified is just wishful thinking.

Wayne Conrad
A: 

Allowing products to ship with known but uncorrected defects.

Dave