The FAIL wall

Back when I started working as a programmer, my team was made up by a bunch of noobs. We were all bad at debugging and would spend countless hours chasing bugs. Some bugs were worse than others and some where dumber that others. Whenever we spend a lot of time looking for a problem just to turn out to be something so simple, we would then write down that shameful mistake on a dry-eraser board. Soon, the shameful stories started to pile up and the board became to be known as the wall of shame. I miss that board. It was a fun reminder of how dumb we were and how far we had come.

I want to replicate that here. I would love to hear your wall of shame stories. So please, leave your story on the comments. I am sure we all could use a reminder that we are not the only “dumb” programmer around 🙂


  1. There was this time I deleted and entire table in a production database because my query had the wrong comparison operator … thankfully this forced us to move forward with the project I was working on at the time. Still, that was the worst 30 mins of my programming life. The 30 minutes was the time it took me to build the courage to go tell my boss.


  2. This fail happened today. I was tasked with debugging an issue with a stored procedure, so I went to source control to grab it. Without going into too much detail about the circumstances, I had to copy the body of the proc and run it directly against a database that wasn’t on my local machine. When I ran the SQL script, I was able to replicate the reported issue, but there was also another issue with the script that wasn’t happened when the proc was ran in the real world, which was weird because I was running the proc against the same database as the automated job was running against. So I dug in and tried to figure out what was going on.

    Fast forward 4 hours and I still hadn’t tracked down the issue with the proc I was running. Frustrated, I decided to start from scratch so I found the proc in the database and had SSMS script it to a new SQL query. Imagine my surprise when the script was almost completely different than the one I was working on. The proc already in the database was newer than the one in source control.

    I’m still not sure if this was my fail for spending so much time not thinking of this or someone elses fail for altering a stored proc without committing it first to source control.


  3. Hi Carlos. Off topic, but I can’t find any other way to contact you. Thanks for your work on nextcloud_drobo. I found one problem when compiling nextcloud 11.0.0 (so maybe it fits this blog post after all…) needs one extra line:
    cp -vfa “target/${FOLDER}/.user.ini” “${DEST}/app/”

    Before doing this I got an error in Nextcloud: “There were problems with the code integrity check”

    When I added the line to and rebuilt I could get it working, thanks! Could you please update github?

    Also, with your permission, I would like to make the nextcloud.tgz file available on droboports, along with some setup instructions. Please email me to discuss.


    1. Alex
      thanks! I will update the code and generate a new release. and of course please do share it in drobo ports. I will email you when the new release is ready.


    2. Code updated and new release generated. Thanks!


  4. A coworker stored production assets in Dropbox. Chaos ensued.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.