Photo by Anna Shvets from Pexels
When you're new to something (like programming), you tend to look to those with more experience for guidance and inspiration. But it's easy to let that lead you to believe that everyone is better than you at that new thing you're trying to learn.
But coding (like everything else in life) takes practice! Even today's best programmers surely made some cringeworthy mistakes when they were first getting started.
So I'd like to take a minute to put some newbies' minds at ease and let them know that even experienced programmers made dumb mistakes when they started. (I can't speak for everyone, but some of us continue to make dumb mistakes on a semi-regular basis.)
My most embarrassing story probably comes from high school, when I was trying to "upgrade" our shared family computer's graphics capabilities. I installed a new video driver and some other software and thought I had everything set up and good to go. When I restarted the computer, nothing would display on the screen. It turns out that I'd basically just disabled the video card. We took it to a computer repair shop, but there was nothing they could do -- they just had to wipe the hard drive and start over.
The worst part is that my brother had done his summer book reports (maybe 100 pages of notes) and only had them saved on that computer. So with maybe a month before school started, he had to redo everything! To add insult to injury, I then tried (again) to upgrade the graphics (again) and the uninstalled the video drivers (again) and my brother lost his notes (again). I'm amazed he didn't throw me out a window after the second time.
How about you? What's your most embarrassing coding story? Or the worst piece of code you've ever written? Ever broken anything in production? Let's hear it!
Latest comments (42)
Probably when I completely forgot how to do headings for an HTML page, until I realized that I had a sticky note literally 5 inches away from my hand. I was stuck for hours, until I realized that im absolute garbage at coding. Fun.
When I started I used to do select * from table then filter the data in code.
Is it weird to say that I think I do not have an embarrassing story? I have made many mistakes, big and small, and still do. But I don't think any of them are embarrassing. Sure there were mistakes which, in hindsight, were stupid. But I never set out like "hold my beer, and watch this".
I think most people tend to make their biggest mistakes a few years into their career, where they have enough knowledge to break things but not enough wisdom to know how to avoid breaking things. If you've gotten past that hump, I'd say you're probably safe! (Hopefully!)
My most embarrassing one is likely when I took down our monitoring software when I was co-oping in college. I was building a new site and needed to add it to our monitoring, but I actually just broke the entire thing. I was petrified and didn't know what to do.
When I told me manager, he assured me that wouldn't let me actually configure the production monitoring system - I was after all still just co-op. ) I had been using the stage environment one the whole time. We figured out the problem and got our tools up and running again.
Back in the day, I were the sole active administrator for a private server in world of warcraft. Every wednesday morning, 6:30 am, I was obliged to update the game server with the weeks newest patches and fixes.
One wednesday morning, a morning like the rest of them, I woke up at 6 as usual and had my coffee while I prepared the deployment. The clock ticks and around 6:28 it was time to execute my prepared script on the server which would do everything in "screens" whilst I just supervise it.
Everything went well, green all the way, and off to university I go.
At the lunchbreak, I opened the community forums on my forums in mission to moderate its content while also replying to ingame tickets. I found to my surprise 2 separate forum threads and one ticket implying that "the thing that should be fixed is not fixed, therefore we as 25man guild cannot do this". At once I started looking into it whilst my staff went for damage control.
Only to find out, that the deployment I had done earlier in the morning, was the script for the stage server. Oh what an facepalm, oh so disappointed community members.
I initially pushed the initially empty sql database of a recruitment test app for the company to git and then pulled on the server. When the database had received thousands of entries, I made a local change and then force pushed to git and then pulled the empty db on the server. I spent hours panicking and frantically searching on how to undo a force push as recruitment department began messaging me that they couldnt find any entry... luckily for me I had stashed before pulling, even though I didn't know what stash meant and I just did it because of the warning (thank you git deities). That day I immediately learnt not to ever push your db, even if empty... also how to connect postgres and set up automatic back ups
On GitHub, I think there's an option to forbid
forcepushing tomaster. I'm sure it's saved a lot of people 😅Biggest "oh my god we're idiots" moment was when me and a colleague (both several years of professional experience at that point) spent almost a full hour debugging, diving into the internals of our frameworks and libraries, trying to figure out why our Typescript class just wouldn't initialise correctly.
Only to realise that we had written "contructor" instead of "constructor"
I still do this sometimes. It just goes to show how helpful syntax highlighting / static code analysis / type-checking tools can be. Working in dynamic languages is so much more messy and difficult because of this.
Killed a herd of cows with an extra 0.
I'm intrigued
It was a long time ago (~1985) and software development was very different back then. We wrote the code on coding sheets using pencil, then we went to site, log on to the mainframe, and type our code into the system.
Testing was done using a process called side-by-side testing. That is, the customer would run their existing system along side the new system, and cross check the results.
Anyway, back to killing the cows.
I was making a change to the feed formulation program, used to calculate the ingredients that go into animal feed. Specifically I was updating the part of the program that calculates the amount of active ingredients (aka drugs) to add to the feed.
This was a fairly complicated process, working from a recipe a feed might require a certain amount of an active ingredient at a certain potency, but the actual amount added depends on the potency of the available batches of the active ingredient in stock, each having their own potency value.
Anyway, as you may have guessed on keying the update to the software into the system, an extra 0 had been added (actually I think, it may have been omitted not added, can't really remember) resulting in a 10 fold increase in the potency of the active ingredient added to the feed.
First I knew about my coding error was when I was called into the managing directors office at the software company I worked for and told that the feed company was being sued by the farmer who had lost a herd of cows because they had been fed this feed which too high a concentrate of some drug. In turn the feed company was looking to sue the software company.
Bit of an oops moment I can tell you.
Anyway, you may wonder why I mentioned testing above. Well, because we were updating a live system, the only real way to test the changes made was to run the process and compare it to the old system, which was part of the contract between the software company and the feed company. The feed company, to save time, just assumed that the new system would be correct, and didn't bother running the process through the old system to verify the results.
So the feed company in the end were liable.
I tell this story from time to time to highlight the importance of testing.
That's a good story! But those poor cows :-(
I once coded in PHP. I know... Was bad...I'm ok now.
Sounds like the first words of a "PHP Programmers Anonymous" meeting 😆
i was working with other programmers, and i had a task to implement a new webpage.
It was a big legacy web system made with webforms.
So I based the new implementation in another page already created and deployed. AND for some reason i commented out this entire page...
So when i deployed my new page to prod, I also disabled one of the pages that customers are used to access....
Well, after some boss yelling I fixed it...
And after 1 month i got fired :(
But for good, because of that i am on a very big computer enterprise!!
My 2nd job, was working on a mid-range computer at the OS layer. They wanted me to add the ability to save files that had 3 character extensions like .txt, etc. I got it to work, tested it and sent it to distribution folks. 1 week later I found out that I regressed ability to save files without extensions. They had to pull back distribution to 115 countries. Ouch...
It really was the wild west before test automation...
I later became a test advocate, read testing books like crazy. At one point managed a team of 35 QA. People in 3 countries.
Best QA book was Software Testing Techniques. Boris Bezier It's still a good read but a bit dated.
When i was a fresh grad, I accidentally deleted our client's source code from their production site (They were hosted in cpanel) . A few a minutes after, we already received a complaint from the client. Really thankful that my manager was there to retrieve the backup.
"No code" before it was trendy 😁
I remember a moment of personal embarrassment that wasn't a huge deal, but early on with DEV, before we had much in the way of PR review or CI I was coding on the site by myself and I recall hearing the Mac "trashcan" sound in my headphones but wasn't sure what it was. I shrugged it off and moved on.
Later, after I'd deployed some code, I noticed that the logo was entirely missing. I'd accidentally put it in the trash somehow and deployed it with
git add .without noticing.It just felt embarrassing because I heard the trash can, and just didn't think much of it. Of course, things are much more careful these days, not that we don't push weird things up.
Surely someone has created the DEV logo in one div with just CSS by now. You could get rid of it entirely and save entire milliseconds of page load time! Younger Ben was just too radical for his own good.
Copying so many peoples code and not understanding what I built....or how to use it. Then having to scrap it and start from scratch.
On the bright side I have learned alot about what not to do when starting to code haha
I remember doing this really early on, too. One thing I remember having trouble with when I was brand new was returning values from functions. Scoping rules and the fact that you could only return a single object seemed unintuitive and overly restrictive. Not sure when it finally clicked, but now I have new and exciting things to be confused about haha
It was 2015. My first job as a developer. I truncated a production table with no backup thinking I was on my local environment. But lucky for me, the table was small and I could retrieve all the data back by calling 20 customers. Bad day.
*shudder*