30 Common Reactions Programmers Have When Things Go Wrong

By Jake Rocheleau. in Coding. Updated on April 11, 2018.

Developing applications can be a very stressful job. Nobody is perfect, and running into buggy code is fairly commonplace in this career. Some programmers get angry, frustrated, upset, discouraged even, while others play it cool. How we handle the process of fixing bugs is worthy of scrutiny.

I want to share a collection of phrases and ideas you’ll hear from programmers struggling when fixing their source code. It is all light-hearted humor, triggered when things become stressful. Generally the application will (eventually) work out and you will move onto the next great task.

Recommended Reading: Learning Programming: 10 Misconceptions That Are Not True

I am sure many web developers and software engineers can relate to these programming hardships, while still laughing in hindsight.

1. “I don’t know whether to delete this or rewrite it”

Going back to old source code from your past brings a temptation to rework larger block clusters. Ugly logic statements with verbose syntax is very hard to read! But then again, if it ain’t broke, don’t fix it. This is a struggle I often face and it surely plagues a number of other software developers.

2. “I should check Github for a starting framework”

I think most developers know about Github and the amazing open source projects being published every day. Programmers dabbling in all languages join the network to branch off existing projects, add wiki discussions, or make their own code repo. It is an excellent resource for cool plugins and templates to be used on various projects.

3. “Why does this script need so many libraries?”

Moving particularly into bigger languages such as Java and Objective-C, the amount of libraries can become fierce. It can be very noticeable when building off of a framework which requires a lot of grounding. Even some plugins for JavaScript will need a myriad of additional files. Sometimes the clutter will get annoying – but at least it works!

4. “There must be a solution somewhere on the Internet.”

My first reaction to a difficult problem is to check the Internet. Lots of programmers will post forum threads about their issues, and they will eventually be solved and archived. Google is fantastic at picking up keywords related to your issue and pointing you in the right direction of these helpful discussion threads. Unfortunately, sometimes there just isn’t much information out there on a particular issue.

5. “Is there a plugin for this functionality?”

Why reinvent the wheel? Plugins are a great resource for expanding the user interface of any program or website. Additionally they can offer some customization and unique options for the developers to work with. Plus if there isn’t already a plugin available, why not build one yourself?

6. “The site works, but I’m dreading Internet Explorer.”

I don’t need to mention the trials and tribulations which have come from the history of rendering webpages within Internet Explorer. From version 5.5 up to about IE9-IE10 there has been a constant struggle for greater browser support. Web developers may fear the debugging of a webpage, opening within IE6 to a rendering nightmare. Thankfully those days are slowly becoming a thing of the past.

7. “For a logic statement this doesn’t seem very logical.”

There are logic statements for if/else loops, for loops, while loops, do loops… the list is fairly lengthy. When looking over sample code I have relapses trying to figure out how my logic is supposed to work. The sheer number of NOT operators and comparison signs can have your head spinning. I frequently go back to update my own logic for good practice in the future.

8. “I spent 30 minutes writing a function and 2 hours getting it to work.”

Isn’t this the programming story of the decade? You are humming along just fine building what you know, when all of a sudden the function is outputting a fatal error. So now you have to go back removing blocks of code attempting to pinpoint the faulty line number. It can be exhausting yet a relief when you finally find the culprit and solve the case.

9. “After reading several blog posts, I now realize that I’ve been doing this completely wrong the entire time.”

I often like to dive head-first into topics with my own programming ideologies but this can lead to trouble down the road when things don’t go according to plan. There have been many times where I’ve started a project and ran into trouble, seeking blogs and other articles for support. Then I find out the whole method is practically wrong and it’d be easier to just start over! Doing a bit of research first will definitely save time in the long haul.

10. “The nice people on Stack Overflow can probably help me.”

I couldn’t begin to count the number of times that I have solved a difficult problem through Stack Overflow. The community is full of nice, intelligent people who are willing to help if you take the first step. Out of all the online forums this is definitely the most widely supported network for software programming and frontend/backend web development.

11. “All that trouble for a missing closing parenthesis.”

Debugging is all about the steps you take. Two steps forward, one step back, two more forward and so forth. The feeling of staring at code for hours just looking for some mistake in function names or variable scope, only to find a missing parenthesis, is a weird feeling. All that time lost over a minor syntax error. The feeling of being both a genius and fool at the same time.

12. “Welp, coffee break!”

Sometimes you just need to get up and away from the monitor. After hovering over the keyboard for hours at a time, it definitely helps to break up the routine. Most health guides recommend a break every 30-60 minutes. But it all depends on your needs and if you get annoyed more from stopping for a break in the middle of a program than not.

13. “I should put this project on hold and deal with it later.”

An alternative to work breaks is walking away from the project instead of just your computer. Maybe there is other work that needs to be done, so go on over and check that one out instead. This would be a better allocation of time and resources, compared to fretting away while attempting to solve a problem that you’ve been looking into for 5 hours straight.

14. “I wonder if classical music will stimulate my programming abilities.”

There is an idea that classical music could promote plant growth during the early stages of life. I personally love classical music for the intricate notes and complex musical theory. Jazz, piano, big band, classy music has a place in human culture around the globe. So could listening to smart music while programming actually make you smarter at debugging? Probably not, but hopefully it wouldn’t make you more clumsy either.

15. “Maybe now is a good time for testing the theory of Ballmer’s Peak.”

I think many readers know about Ballmer’s Peak which was coined by a particular xkcd comic. To simplify, the theory states that programmers hit a peak of coding ability after consuming a specific amount of alcohol. It was attributed to Steve Ballmer for his wacky antics which may be construed as the ramblings of a drunkard although it is somewhat ironic, as Ballmer was never truly a programmer at Microsoft. Guess we willl have to wait for somebody else to give this theory a trial run.

16. “Was somebody fiddling with my source code?”

It sounds like delusion and paranoia, but sometimes you just have to wonder who is writing this stuff when you are busy catching up on sleep. Looking over projects from weeks or months in the past can leave you with a sinking feeling. Sometimes you will find stuff that you never remember adding – even from projects you just looked into last week! I write it off as crazy but you never know…

17. “I have no idea what any of this means.”

The worst situation you can have is looking into source code with absolutely no idea what to do. This may arise from your own projects, or somebody else’s project, but it is all the same problem. Now you have to decide whether it is worth spending more time searching for an alternative or dissecting the script to learn how it works.

18. “I’m gonna need to Google that error message.”

After working in PHP for years I have to say that Google is my best friend when debugging problems. This is definitely the same case with Objective-C, C++, Java, Python, and other major languages. Error messages try to help but unless you have memorized what the different codes mean, it reads more like translated computer language. Thankfully there is a lot of support online for determining just exactly what these error messages really mean.

19. “I should stop and call it a day… but I really wanna figure this out!”

We all know that feeling of utter frustration where you want to call it quits, but it just feels like giving up isn’t the right choice. You want to keep pushing forward and try new solutions for debugging. But what if it turns into a waste of another hour? I am no stranger to this circumstance and it can be awfully disheartening.

20. “Oh dear, why didn’t I write any comments?”

When it comes to more basic frontend HTML/CSS/JS there isn’t always a need to leave comments. But more complicated scripts and programs will need some type of organization for when you want to look back in a few months, or even after a couple of years. Sometimes you will forget to comment about functions and their parameters, the output format, and other essential data. This will no doubt lead to confusion down the road when bugs start appearing and you have to debug the entire script for a solution. If only there were some helpful comments.

21. “This was working 20 minutes ago…”

Possibly the most frustrating part of building a program is when it goes from working to not working – without ANY updates to ANY part of the code! I swear it happens. And it doesn’t make any sense – maybe the other program was running a cached version? Then there are times when updating one tiny bit of code will cause the whole program to crash on error and just stop working entirely. Revert back to the most recent working copy and keep moving forward from there.

22. “You forget one lousy semicolon and the whole program comes crashing down.”

Almost every programming language I have used will require a symbol for line termination. Not all of them do, but it is definitely common in the C/C++ family. When you forget to add one terminating semicolon it is an honest mistake! But the parser doesn’t understand this and throws out a fatal error. Now you have to spend another 20 minutes scouring code for a technical fault, when the whole time, it was just missing a semicolon. Ah, the joys of debugging software.

23. “I wonder how much it would cost to pay someone to fix my mistakes?”

The overwhelming thought of hiring another developer is tempting, but obviously nowhere near financially viable. Plus how would you learn from all of these mistakes if you are not getting your hands dirty? It can feel good when you finally understand a programming concept, after failing multiple times. But it doesn’t stop this thought from crossing my mind ever so often.

24. “A quick visit to Hacker News is sure to improve my productivity.”

A lot of programmer’s favorite choice for social news on software & startups is the Hacker News frontpage. It has a lot of great information about freelancing, time management, software development, plus new startup launches and raising capital. Although HN can emulate the feeling of being productive by educating yourself, it can also be a drain on your time. Taking a quick recess to check up on news every few hours couldn’t be all that bad.

25. “How can this API have no documentation?!”

The most frustrating part about using a plugin or framework with bad documentation is that you have to look deep into the source code yourself. I simply adore projects where the developers will take the time to specifically design a usable documentation page. All the parameters and options are explained, possibly even used within some example code snippets. But sadly this is not always the case. It is easiest to stay away from poorly-documented work and save yourself the grief.

26. “I sure hope I’ve saved a backup copy of that database…”

Backups are not always on my mind when writing and debugging code. However, data backups offer a stepping stone to go back in time before certain changes were made. This is especially useful on a live server environment where changes are implemented immediately. Remember to keep local copies of your website files and databases in case of an emergency! It can be an annoying task, but not as annoying as rebuilding a corrupt SQL database.

27. “What is the quickest solution to get this working properly?”

After hours of turmoil looking for a custom solution it becomes very clear that you may need a new approach. Programmers want to get the functionality working first before designing a pretty interface around it. Determine the quickest, most accurate solution and implement this to be working at best 100% of the time. Then it is easier moving on to the pretty aesthetics.

28. “I bet updating my software will fix the issue.”

The teams who manage dependencies and plugins for programming languages do not need to push releases very often. Sometimes updating your PHP/Ruby/Python/SQL version may solve debugging issues when transferring files from your computer onto a live server. Local updates will very rarely help with fixing a bug in your source code, unless your version is hopelessly out of date. Hey it’s worth a shot!

29. “I should be more organized and study Git… But I’ll look into it next week.”

The open source version control package Git is extremely popular among programmers. It offers an easier learning curve than other competitors, and it is used in many online repos such as Github and Bitbucket. Developers will put off the idea because it definitely has a steep entry-level curve for beginners. However once you understand the basic commands then Git is a cakewalk. And it makes the practice of debugging with version control a lot clearer, too.

30. “Scrap this, I’m starting over from scratch.”

Sometimes after trying hours of solutions, you just have to move your working files to an archive directory (or delete them) and start again from scratch. The decision is tough considering how the previous hours have been toiled away for little payoff. But when I am in a rut, getting a fresh start is often just what I need to see a project through to completion.