Software development is challenging. No one is perfect, and it is inevitable for programmers to write buggy code. Some people are calm, while others feel angry, frustrated, upset or discouraged. What happened to fixing the bug? It’s worth finding out.
This article lists some of the things a programmer might say or think when fixing a bug. I’m sure a lot of programmers have experienced programming struggles and laughed about it in hindsight.
1. “I don’t know whether to delete it or rewrite it”
Looking at old code, you always feel the urge to rewrite it. Ugly logical statements and verbose syntax greatly reduce code readability! But if the code works, why change it? I often find myself in this dilemma, and I’m sure it plagues many other programmers as well.
2. “I’ll go to GitHub and find a framework”
I think most of you know about GitHub, where many open source projects are released every day. Developers join the site, pull branches from existing projects, discuss them on wikis, or create their own codebase. The site provides many great plug-ins and templates that can be used for a variety of projects.
3. “Why does this script use so many libraries?”
If you’re using popular programming languages such as Java and Objective-C, the number of libraries your project depends on can get very large. This becomes obvious when adopting a framework that requires a large number of dependencies. Some JavaScript plug-ins also require a lot of extra files. Sometimes the clutter can be annoying, but at least it works!
4. “There must be a solution online”
When CONFRONTED with a problem, my first reaction is to surf the Internet. A lot of programmers ask questions on the forums that will eventually be answered. Google is very good at picking keywords that are relevant to your question and providing you with these useful forum posts. Unfortunately, sometimes there isn’t much information about a particular problem.
5. “Is there a plugin for this feature?”
Why reinvent the wheel? Plug-ins are a great way to extend a user interface, program, or web site. In addition, plug-ins can provide customization capabilities. If you can’t find one, why not develop your own?
6. “The website is ok, I’m afraid to run into IE”
Needless to say, rendering web pages in IE has brought a lot of trials and tribulations. From IE 5.5 to IE 9/IE 10, there has been an uphill battle to get better browser support. Web developers may be worried about Web debugging because opening a Web page in IE6 can be a nightmare. Thankfully, those days are fading into the past.
7. “This logical statement is not very logical”
If /else loops, for loops, while loops, do loops, these are all logical statements, and there are many more. As I read through the sample code, I repeatedly thought about how the logic in my code could have been better written. The sheer number of non-operators and comparison symbols will make your head spin. So, I often go back and revise the logic I’ve written.
8. “Write a function in half an hour, debug it in two hours”
You write a function in your head, and the function outputs a fatal error. In order to find the problem, you have to cut out the rest of the code, leaving only the lines of code that failed. When you finally find the problem and fix it, you feel exhausted but also relieved.
9. “Only after reading a few articles did I realize what I was doing was wrong”
I usually like to do things my way, but if things don’t go according to plan, there can be trouble. Many times I’ve had trouble starting a project and then started searching blogs for solutions. In the end I found out I was going about it the wrong way, it might be easier to start over! So doing some research at the beginning will definitely save time in the long run.
10. “There are good people on StackOverflow, they will help me”
I can’t tell you how many times I’ve solved a problem with StackOverflow. This community is full of talented and friendly people who will help you if you are willing to ask for help. Of all the online communities, StackOverflow is easily the one that offers the broadest support.
11. “Missing the close parenthesis, a lot of trouble”
Debugging code is about jumping back and forth, two steps forward, one step back, two steps forward, and so on. It’s weird to spend hours staring at code, looking for errors in function names or variable scopes, only to discover that the closing bracket is missing. I feel like a genius and a fool for wasting all my time on one tiny grammatical mistake.
12. “Take a break”
Sometimes you need to stand up and step away from the monitor for a while. After a few hours at the keyboard, taking a break will definitely help you think. Most health guidelines recommend taking a break every 30 to 60 minutes, but it all depends on your needs. You might also get annoyed if it’s always interrupted in the middle.
13. “Stop what you’re working on and pick it up later”
Besides getting away from the computer, this is another way to take a break. Maybe you have another job to do, so do it. This is a better way to allocate your time and resources, especially if you haven’t been able to solve a problem for five hours.
14. “Is there any classical music that inspires my programming skills?”
One idea is that playing classical music helps plants in their early stages of growth. I personally love the complex notes and music theory of classical music. Jazz, piano, big band, classical music all have a place in human culture. So does listening to music while programming really make you smarter when debugging code? Probably not, but hopefully it doesn’t make you any dumber.
15. “Maybe now is a good time to test Ballmer’s peak theory”
I think many of you know the Ballmer Peak theory: xkcd.com/323/ The theory states that Cheng…
16. “Who touched my code?”
It sounds delusional, but sometimes you have to wonder who’s writing the code while you’re busy catching up on your sleep. The busy projects of the past few weeks or months have left you feeling down. Sometimes you don’t remember adding something to the codebase — even a project you just looked at last week!
17. “I don’t know what that means”
The worst thing you can do is read the source code without knowing what to do. It could be your own project, it could be someone else’s project, but the problem is the same. Now, you have to decide whether to spend more time looking for alternatives or analyzing the script to make sense of it.
18. “I’m going to Google this error message”
After years of PHP development, I have to say Google is a good friend of mine. If you use other programming languages, such as Objective-C, C++, Java, Python, etc., you’ll probably have the same experience. Error messages try to help, but unless you’ve memorized the meaning of the various error codes, they look more like translated computer language. Thankfully, there’s plenty online to help us determine exactly what these error messages mean.
19. “I should call it a day, but I really want to solve this problem!”
We all know that when you want to give up on something, there is a feeling of frustration and a feeling that giving up is not the right choice. You want to move on and try new solutions. But what if you find yourself wasting another hour? I get this a lot, and it’s very frustrating.
20. “Oh my God, why didn’t I write a comment?”
It is not always necessary to write comments when writing front-end HTML/CSS/JS code. But for more complex scripts and programs, you need some type of annotation that you can come back to months or even years later. Sometimes you forget to comment functions and their arguments, output formats, and other basic data. When something goes wrong and you need to debug the entire script to find a solution, this can be confusing. At this point, you may wish you had added some useful comments.
21. “A moment ago it was working…”
Perhaps the most frustrating thing about developing a program is when nothing has been done — no updates, no code changes — and it suddenly doesn’t work. I swear, this happens all the time. Maybe some other program is running an older version? Sometimes, updating a small piece of code causes the entire program to crash, only to revert to the most recent working version and work from there.
22. “The whole program crashed because I forgot to add a semicolon”
Almost every programming language I’ve used requires line terminators, not all of them, of course, but the C/C++ family programming languages usually do. If you forget to add the closing semicolon, it’s just an innocent error, but the parser doesn’t understand this, and it will relentlessly throw a fatal error. Then, you have to spend another 20 minutes looking at the code, and you realize that a semicolon is missing. Perhaps this is the “fun” of debugging.
23. “I wonder how much it would cost to hire someone to fix my mistake?”
It was tempting to hire other developers to fix the problem, but clearly not financially viable. Besides, how can you learn from these mistakes if you don’t do it yourself? It feels good when you finally understand a programming concept after a lot of failure, but that didn’t stop me from thinking about hiring more people.
24. “A quick look at Hacker News is a sure way to increase your productivity”
Hacker News is a great place for programmers to learn about social News related to software and startups. The site has plenty of information about freelancing, time management, software development, startup and financing. While browsing the site may feel productive, it’s also consuming your time. It might be better to take a break every few hours to catch up on the news.
25. “There is no documentation for this API!”
If you are using plug-ins or frameworks that are not documented, the most frustrating thing is that you have to dig into their source code yourself. I like projects where developers spend time designing documentation. The documentation explains all the parameters and options available, and may even provide some sample code snippets. Unfortunately, not all projects are like this. The easiest way to do this is to stay away from projects that aren’t well documented so you don’t have to suffer so much.
26. “I wish I had backed up my database…”
When I’m developing and debugging code, I don’t always think about backing up the database. However, data backups provide a guarantee that you can roll back in time before making certain changes. Remember to keep copies of the site project files and database locally for future use! This can be an annoying task, but definitely not as annoying as rebuilding a corrupted SQL database.
27. “What’s the fastest way to solve this problem?”
After hours of clueless work, it’s clear that you may need to try a new approach. Before designing an interface, programmers want to get the functionality up and running. Determine the fastest, most accurate solution that works 100% of the time, and then move on to the icing on the cake.
28. “I bet a new version will fix this”
The team responsible for managing programming language dependencies and plug-ins does not need to release new versions frequently. Sometimes, updating the PHP/Ruby/Python/SQL version can solve debugging problems when transferring files from the local to the server. Local updates rarely help fix bugs in your source code unless your version is out of date. It’s worth a try!
29. “I should learn Git… But I want to start next week.”
Git, a version control system popular with programmers, has an easier learning curve than its competitors and is used to manage many online code repositories, such as Github and Bitbucket. Developers want to delay learning because it has a steep entry curve for beginners. However, once you understand its basic commands, Git becomes very simple.
30. “Throw this away, I’m going to start from scratch”
Sometimes, after spending hours trying out a solution, you’ll move your working files to an archive directory (or delete them) and start from scratch. It was a difficult decision to make with so little reward for the hours of hard work. But when I get stuck, starting over is often exactly what it takes to complete a project.
Look, is that you?
